-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Cc 7145 hcp link status api #20330
Cc 7145 hcp link status api #20330
Conversation
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.
Approved! Very nice work, I think some tests are incoming - but love seeing this up and will unblock us in some other PRs!
meta: { | ||
version: 2, | ||
uri: uri, | ||
}, |
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.
Is this just "magic" ™️ to make the repo service happy?
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.
yes 😅
isLinked: (body.status['consul.io/hcp/link']['conditions'] || []).some( | ||
(condition) => condition.type === 'linked' && condition.state === 'STATE_TRUE' |
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.
Was going to ask why we have the array methods here, but the API response does have conditions
to be an array, I wonder if we'd ever see multiple contradicting conditions?
I hope not - feels like something we should handle in the backend
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.
yea, it is how the backend responds as of now. I've just decided to check that condition is linked, just in case we will have some other stuff added in future.
But I totally agree, that as of now we don't assume to have something else to be returned from the endpoint
// set linked to false if the global link is not found | ||
if (e.statusCode === 404) { | ||
result = Promise.resolve({ isLinked: false }); |
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.
Love the comment!
if (e.statusCode === 404) { | ||
result = Promise.resolve({ isLinked: false }); | ||
} else { | ||
result = Promise.resolve(null); |
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.
So if we get an error (auth related or anything really), null
would probably act as an isLinked: false
as in code if we tried to do a
{{#if hcpLlink.isLinked}}
Say cluster is linked
{{else}}
<DisplayBanner />
{{/if}}
Thinking aloud, is that what we'd want to do?
- If we fail to fetch this result because our ACL token doesn't have enough permissions - this would return
notLinked
- which is okay - since we have code ensuring we only display banner if user has permission to link - If we fail for other reasons - I think we should probably check that we don't have a definitive result to the
is this cluster linked
in thehcp-link-status
service, which is what you were saying withrepo return null for the result object (to make it possible to understand when some other system/auth error raised)
I think
So I think this is fine/great! However we hook this up to the hcp-link-status
, we'll probably have to handle that there!
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.
yea, the idea was to add some state, where we could see that hcpLink
could not actually be observed as linked or not. there are other ways to do it, for sure, like to set {isLinked: null} or so.
So I open to discuss it
as |dc| | ||
> | ||
{{#if dc.data}} | ||
<HashicorpConsul | ||
<DataSource @src={{uri '/${partition}/*/${dc}/hcp-link' (hash dc=dc.Name partition=partition name=dc.Name) }} @open={{true}} as |hcpLink|> |
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.
Bit curious about this - Does this mean we'll fetch this upon application load? And this data will be accessible as the hcpLink
variable in this template?
Would we still need/want this if we're only requesting this inside of the hcpLinkStatus
service?
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 question. when application loading, we calling the service. but we have to call it on login as well
due to <HashicorpConsul>
component has the tag structure and we need the data in sidenav and in main tags, I've put the call to application and make it open
. it means that on login we will have it reloaded, same as on route change.
It is questionable though, when we need to reload it. let's say if we are linking in HCP, and does not reload page in core, I think we still should get the information if it is linked
actually it depends on the cost of calling the service, which in our case seems to be not too bad, because it uses local consul... what do you think?
2fbc210
to
c4a15ff
Compare
…nsul into CC-7145-hcp-link-status-api
This reverts commit 049ca10.
* Revert "feat: add alert to link to hcp modal to ask a user refresh a page; up… (#20682)" This reverts commit dd833d9. * Revert "chor: change cluster name param to have datacenter.name as default value (#20644)" This reverts commit 8425cd0. * Revert "chor: adds informative error message when acls disabled and read-only… (#20600)" This reverts commit 9d712cc. * Revert "Cc 7147 link to hcp modal (#20474)" This reverts commit 8c05e57. * Revert "Add nav bar item to show HCP link status and encourage folks to link (#20370)" This reverts commit 22e6ce0. * Revert "Cc 7145 hcp link status api (#20330)" This reverts commit 049ca10. * Revert "💜 Cc 7187/purple banner for linking existing clusters (#20275)" This reverts commit 5119667.
Description
https://hashicorp.atlassian.net/browse/CC-7145
Due to the API specific, it doesn't fall well to the data loading approach which is used for regular records.
So I did similar to autopilot loading, which as well not really fall under record architecture(list + crud).
for 404 link/global and for STATE_FALSE repository maps the
isLinking
value to false. For STATE_TRUE - to true. For other error codes, repo return null for the result object (to make it possible to understand when some other system/auth error raised)Testing & Reproduction steps
Linked is: {{hcpLink.data.isLinked}}
in a next lineconsul acl bootstrap
, using secretIdIt is also possible to check it with
yarn start
. Mock data set to STATE_TRUE by defaultlink/global could be added with triggering from browser console
Links
PR Checklist