Support for commit-check and commit-check-result #497
Comments
|
I'm not familiar with this endpoint, but I've just had a peek at the documentation. Is it the case that you'd POST to Maybe this doesn't matter? |
|
I imagined it as two different functions. The time it takes to check is in the order of seconds / tens of seconds in my case, so in any case i would not aggregate them in a single call. For me a simple wrapper for the two calls is enough. |
|
I'm wondering about the general utility/safety of this sort of function in an environment where multiple applications may be meddling with the fabric at the same time. Maybe we can make it atomic-ish with some locking? Returning a "result" when the specific query to which it applies is ambiguous makes me a little nervous. Ideally, Or we throw up our hands and document the behavior :) I'll talk to the backend folks about potential pitfalls and follow up here. edit: How are you able to tell how long the check takes? Is that the time for a response when POSTing to the |
|
Oh, we recently added |
|
Out of curiosity, what are you using this API for?
…On Mon, Feb 17, 2025 at 12:18 PM riccardo-roveri-labs < ***@***.***> wrote:
The problem is in the API itself and is consistent with the UI, checking a
blueprint is an asyncronous operation. This is handled in the UI by polling
the blueprint status.
The result of check-result includes the following structure:
`{
systems: {} // not interesting for this purpose
blueprint: {
state:
blueprint_version:
validity: enum [fresh | unknown | stale
}
}`
PS: Thanks for the suggestion about Client.DoRawJsonTransaction()
—
Reply to this email directly, view it on GitHub
<#497 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AARW4W3LIFMEWFNM3E4TR632QIKVZAVCNFSM6AAAAABXJYTZ7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRTG4YDQNZVGU>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
[image: riccardo-roveri-labs]*riccardo-roveri-labs* left a comment
(Juniper/apstra-go-sdk#497)
<#497 (comment)>
The problem is in the API itself and is consistent with the UI, checking a
blueprint is an asyncronous operation. This is handled in the UI by polling
the blueprint status.
The result of check-result includes the following structure:
`{
systems: {} // not interesting for this purpose
blueprint: {
state:
blueprint_version:
validity: enum [fresh | unknown | stale
}
}`
PS: Thanks for the suggestion about Client.DoRawJsonTransaction()
—
Reply to this email directly, view it on GitHub
<#497 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AARW4W3LIFMEWFNM3E4TR632QIKVZAVCNFSM6AAAAABXJYTZ7KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRTG4YDQNZVGU>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
The problem is in the API itself, checking a blueprint is an asynchronous operation. This is handled in the UI by polling the blueprint status. The result of You can check if is not pending anymore and the validity is In any case you need to poll for the PS: Thanks for the suggestion about |
The response was incomplete because i fat-fingered :P I want to check if the blueprint status valid before committing. I believe that Apstra checks it anyway before applying it to the devices but i want to catch it earlier. Hope it makes sense |
User hits the "check" button in the UI, and the UI's background polling eventually surfaces any errors which may exist? I think if we implemented this in the SDK, we'd want to idiot-proof it using one of the approaches you mentioned. Would that be over-stepping in your opinion? |
Yes exactly, it first stays in a loading state then shows the user the new state by polling the API in the background.
I am too inexperienced in this world to give you an answer. In my opinion if you are using this library you should know what are you doing, otherwise stick to the UI. I have some doubt about polling, does not feel right to me, are you already doing it in other functions? Maybe a less ergonomic but safer option would be to make the user pass the version of the blueprint. If in the |
Yes. Take this transaction which I happened to have on my screen from some recent experiment. It's a snapshot from Wireshark: 
So, yeah. There's a bunch of polling handled behind the scenes in the SDK. |
|
If the user understands if is the ideal solution. I think anyone using this SDK would be doing the same with the raw api, fire a I am no go expert but maybe you can fire this in a goroutine and return a chan that the user waits on for the result so is obvious that is async. I would also throw an error if the result has the field |
|
I whipped up a dumb example of using the raw json method in case it proves helpful: func TestFoo(t *testing.T) {
ctx := context.Background()
cfg := apstra.ClientCfg{
Url: "https://apstra.example.com",
User: "redacted",
Pass: "redacted",
}
client, err := cfg.NewClient(ctx)
if err != nil {
t.Fatal(err)
}
blueprintId := "d4199834-e7d0-4795-9f16-4f9ed059d37a"
ccrUrl, err := url.Parse(fmt.Sprintf("/api/blueprints/%s/commit-check-result", blueprintId))
req := apstra.RawJsonRequest{
Method: http.MethodGet,
Url: ccrUrl,
}
var resp struct {
Blueprint struct {
State string `json:"state"`
} `json:"blueprint"`
}
err = client.DoRawJsonTransaction(ctx, req, &resp)
if err != nil {
t.Fatal(err)
}
t.Log(resp.Blueprint.State)
} |
|
Update: I've talked with engineering folks and understand this API endpoint much better now. I think we'll be able to deliver something useful. |
I did not find functions to call
/api/blueprints/{blueprint_id}/commit-checkand/api/blueprints/{blueprint_id}/commit-check-result.Is it possible to implement them in the library? They seem fairly simple endpoint.
Thanks,
Riccardo Roveri
The text was updated successfully, but these errors were encountered: