-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Openapi schemas no additional properties #2355
Conversation
f89e28f
to
f0206af
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really like the approach of creating dedicated view clauses for broadcasts 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @CDimonaco
Great effort.
Unfortunately, there are many things wrong.
I think you have trusted too much in the current state of the schemas.
Many changes you did in the views are wrong, because you based them in the schema, but the schema itself is what it is wrong.
I think I have caught all the things.
Let me know if you need more details.
As a nitpick:
The database and sapsystem view changes. The content we send in the controller and in the broadcast should be the same. It you want to keep the duplicated code, to be explicit, so be it, but with the same content
@@ -8,6 +8,7 @@ defmodule TrentoWeb.V1.ClusterView do | |||
def render("cluster.json", %{cluster: cluster}) do | |||
cluster | |||
|> Map.from_struct() | |||
|> Map.delete(:deregistered_at) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call.
I don't know even know why we send this value in the host view, we don't use it in the frontend...
@@ -28,8 +28,6 @@ defmodule TrentoWeb.V1.HealthOverviewView do | |||
sid: sid, | |||
sapsystem_health: sapsystem_health, | |||
database_health: database_health, | |||
# deprecated field |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we shouldn't be removing this in reality.
the field is still in the schema, even with the deprecated value.
Unless we created a v2 version (which we don't want), we must keep them.
Most probably nobody is using it, but removing it would make the schema non backward compatible.
lib/trento_web/views/v1/host_view.ex
Outdated
|> Map.from_struct() | ||
|> Map.put(:sles_subscriptions, sles_subscriptions) | ||
|> Map.delete(:fully_qualified_domain_name) | ||
|> Map.delete(:selected_checks) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we remove this selected_checks
?
As far as I know it should be used in the frontend.
For me, the error is actually in the schema, that it is not include.
Can you confirm @dottorblaster @nelsonkopliku ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, we take this and put it in the hosts slice as it is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct, both when first loading the /hosts
api and when some event that gets projected changes the selected checks (which we broadcast)
@@ -51,6 +58,7 @@ defmodule TrentoWeb.OpenApi.V1.Schema.Host do | |||
type: :string, | |||
description: "Version of the agent installed on the host" | |||
}, | |||
health: ResourceHealth, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick.
Not about this field.
I have checked a bit the code, and the value we could deprecate is the deregistered_at
.
It is not used in the frontend anywhere.
So we could remove it in a potential, v2 version.
Anyway, it is not strictly about this PR. Up to you. If you don't do it, it is not a big deal.
instance | ||
|> Map.from_struct() | ||
|> Map.delete(:__meta__) | ||
|> Map.delete(:absent_at) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We shouldn't remove this field. It is used in the frontend.
The error must be that it is not defined in the schema.
end | ||
|
||
def render("broadcast_database.json", %{ | ||
database: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could render inside this the database.json
view.
After all, they have the exact same fields, both the database and instance (removing the deregistered_at
is not a big deal, we don't use it in the frontend).
Anyway, if having it explicit makes sense to you, all good from my side, but they should have the same content
instance | ||
|> Map.from_struct() | ||
|> Map.delete(:__meta__) | ||
|> Map.delete(:absent_at) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We cannot remove the absent_at
, it is used in the frontend.
And it would look like exactly as the broadcast
|> add_system_replication_status_to_secondary_instance | ||
end | ||
|
||
def render("broadcast_sap_system.json", %{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can remove the deregistered_at
from the broadcast as well
|> Map.delete(:__meta__) | ||
end | ||
|
||
def render("cluster_details.json", %{details: %{"sap_systems" => sap_systems} = details}) do | ||
sap_systems = | ||
Enum.map(sap_systems, &Map.take(&1, [:distributed, :filesystem_resource_based, :nodes])) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this for? to remove the sid
field?
The sid cannot be removed, it is used in the frontend.
Yet again, most probably the schema is what it is wrong
I took schema and tests for granted 👀 So, back to draft and we need to start back from schemas, good catch, fixing this things will give more confidence, but it's a real mess, we will learn a very valuable lesson in the end, I hope so 👀 Anyway some code duplication is completely on purpose, and if we want to avoid we need to rethink all the schemas because rn broadcasted info and controller one are very different |
This reverts commit 8869575.
19d291e
to
c30a5e9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now it looks great @CDimonaco
+1000
Description
This PR aims to fix the properties of OpenApi Schemas.
This change involves the schemas, controllers and views.
Now our openapi schema is consistent with web responses.
Controller response views and broadcast views are differentiated, in order to achieve consistency on both the transports.
I introduced a new convention the
broadcast_
prefix in views means that the views are used ONLY in the broadcast of messages.Remember to add the right labels to this PR.
Automated tests