| opendevreview | zhou zhong proposed openstack/nova master: nova-manage: modify image properties in request_spec https://review.opendev.org/c/openstack/nova/+/924319 | 02:29 |
|---|---|---|
| opendevreview | zhou zhong proposed openstack/nova master: nova-manage: modify image properties in request_spec https://review.opendev.org/c/openstack/nova/+/924319 | 02:42 |
| *** bauzas_ is now known as bauzas | 04:41 | |
| *** chuanm0 is now known as chuanm | 07:25 | |
| *** bauzas_ is now known as bauzas | 07:29 | |
| bauzas | gibi: other cores : we need a second core approval against https://review.opendev.org/c/openstack/nova-specs/+/907702 | 09:49 |
| bauzas | as a reminder, today EOB is our spec approval freeze day | 09:50 |
| gibi | bauzas: done, I agree we can document the remaining agreements in a follow up to the spec. | 10:22 |
| gibi | so I approved it. | 10:23 |
| mikal | bauzas: ugh, I'm not going to be able to update the kerbside spec before the end of your day. I thought the deadline was tomorrow, and I have most of a prototype but then need to update the spec to match. | 10:29 |
| mikal | bauzas: I wanted to get a working prototype beforehand so I was confident I was describing it correctly. | 10:30 |
| mikal | bauzas: what are my chances of a one or two day extension? | 10:30 |
| opendevreview | Merged openstack/nova-specs master: libvirt: AMD SEV-ES support https://review.opendev.org/c/openstack/nova-specs/+/907702 | 10:37 |
| mikal | Speaking of which, has anyone ever gotten a GET /os-console-auth-tokens/{console_token} to work? I get a 404 which I can't really explain. | 11:42 |
| opendevreview | Andrey Kurilin proposed openstack/nova master: Propagate neutron's error during removeSecurityGroup action https://review.opendev.org/c/openstack/nova/+/924399 | 11:51 |
| opendevreview | Michael Still proposed openstack/nova-specs master: Propose a new API microversion for a spice-direct console. https://review.opendev.org/c/openstack/nova-specs/+/915190 | 12:29 |
| mikal | sean-k-mooney: I've updated the spec. I just got the console access URL stuff you asked for working in a prototype. | 12:30 |
| mikal | sean-k-mooney: sorry it took so long, I had some personal life stuff I've had to deal with in the last week or so. | 12:30 |
| sean-k-mooney | mikal: you dont need to appoliges, life happens | 12:32 |
| mikal | sean-k-mooney: yeah I dunno, I feel like the last month or so has been pretty weird over here. | 12:33 |
| mikal | sean-k-mooney: anyways, I have the flow you wanted working: request console access URL through existing API with new console type -> get URL to kerbside with console access token -> request URL -> kerbside uses token to validate and lookup connection info -> kerbside returns a .vv file for your SPICE client. | 12:34 |
| mikal | sean-k-mooney: the code is not ready to push to gerrit yet, but I am now confident I can make that flow work. | 12:34 |
| mikal | sean-k-mooney: which means arguably there is no API security impact, as the console auth lookup API is pre-existing and already did what I needed | 12:34 |
| sean-k-mooney | do we need a sepreate config option ? CONF.spice.kerbside_base_url or would https://docs.openstack.org/nova/latest/configuration/config.html#serial_console.base_url work | 12:35 |
| sean-k-mooney | sorry not serial | 12:35 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#spice.html5proxy_base_url | 12:35 |
| sean-k-mooney | i guess hte name of that is slightly confusing | 12:36 |
| sean-k-mooney | mikal: im basically wonderign if we could rename html5proxy_base_url to proxy_base_url | 12:36 |
| sean-k-mooney | and use it for both | 12:36 |
| mikal | sean-k-mooney: yeah, I wanted to differentiate the two services. | 12:36 |
| mikal | sean-k-mooney: I would be ok with that, but that would come with upgrade work for deployers. | 12:37 |
| sean-k-mooney | do you want to suport haveing both the existing html5 proxy and kerbside at the same time | 12:37 |
| sean-k-mooney | mikal: evenrually when we do a rename we keep the old value for a couple of cycles | 12:37 |
| mikal | sean-k-mooney: actually, yes I suspect people would want that. HTML5 is fine for quick and dirty things, but not for desktop VDI replacement. | 12:38 |
| sean-k-mooney | ok that works for me | 12:38 |
| mikal | That is, if I was building Citrix on OpenStack, I'd probably want both. | 12:38 |
| sean-k-mooney | mikal: ya so to get the port/host infor you will need to call the /os-console-auth-tokens api as admin i belive | 12:40 |
| mikal | sean-k-mooney: yeah, I am assuming the security for that is already correct given that's pre-existing. | 12:40 |
| sean-k-mooney | it would be nice to allow that to be called as the serivce user so that is the only policy change requried | 12:40 |
| mikal | Does that need to be in the spec? | 12:40 |
| sean-k-mooney | but i agree that most of the api change is removed now | 12:40 |
| sean-k-mooney | it woudl be nice to cacue the tin the spec but i would not stirlcly hold a -1 for that alone | 12:41 |
| sean-k-mooney | if you want to respine that is fine but i woudl be ok with a follow up patch post spec freeze too | 12:41 |
| sean-k-mooney | mikal: stricly speaking spec freeze is eob today so im going to finish reviewing this and ill leave a comemnt to that effect regarding policy | 12:42 |
| mikal | sean-k-mooney: yeah, I feel like I am skating on the edges of missing the deadline. I asked bauzas if I could have a day or two extension, but didn't get a reply yet. | 12:42 |
| mikal | I thought the freeze was EOD tomorrow, which is my bad. | 12:43 |
| sean-k-mooney | mikal: so on one hand we premetivly moved it 2 weeks past our normal deadline. on the other given you have a partly wroking poc and you have already adapted the appoch to the direction i asked for i would be ok with extending until the next team meeing via the spec freez process if bauzas is | 12:44 |
| mikal | Oh bugger. I _do_ need a schema change. There is only one port column in the ConsoleAuthToken table and I need two (one for TLS). | 12:44 |
| mikal | I'll tweak the spec now. | 12:44 |
| sean-k-mooney | ok well that is easy to add to the spec i dont think that woudl be contoverial | 12:45 |
| mikal | Look, if I've missed the deadline so be it. Its frustrating but its not the end of the world. | 12:45 |
| opendevreview | Michael Still proposed openstack/nova-specs master: Propose a new API microversion for a spice-direct console. https://review.opendev.org/c/openstack/nova-specs/+/915190 | 12:47 |
| sean-k-mooney | mikal: i think you have some other issues | 12:48 |
| sean-k-mooney | mikal: im not seeing the propsoe chage header | 12:48 |
| mikal | I'm not sure what a "propose change header" is? | 12:49 |
| mikal | Oh you mean in Gerrit? | 12:49 |
| sean-k-mooney | yep it will fail our ci job | 12:49 |
| sean-k-mooney | https://github.com/openstack/nova-specs/blob/master/specs/2024.2-template.rst?plain=1#L92 | 12:49 |
| sean-k-mooney | oh no | 12:50 |
| sean-k-mooney | you have it but you started descibibg the propsoed change in the problem description section | 12:50 |
| sean-k-mooney | lets ignore that for now but basiclly the "Problem description" shoudl descibe the "what" and "why" not the "how" | 12:51 |
| sean-k-mooney | so the discussion of config option or api shoudl be in the propsoe changes btu that not a big deal | 12:51 |
| mikal | So basically everything except the first para of "problem description" should move down? | 12:51 |
| sean-k-mooney | technially yes to the sart of the propsoed changes | 12:52 |
| sean-k-mooney | the usecases section is correct | 12:52 |
| mikal | Done. | 12:52 |
| opendevreview | Michael Still proposed openstack/nova-specs master: Propose a new API microversion for a spice-direct console. https://review.opendev.org/c/openstack/nova-specs/+/915190 | 12:52 |
| sean-k-mooney | cool ill contineu reviewing the new version | 12:53 |
| sean-k-mooney | sofar the content looks fine to me | 12:53 |
| sean-k-mooney | mikal: by the way if you have not seen this https://review.opendev.org/c/openstack/nova-specs/+/920687 i think that woudl also be very useful to you | 12:56 |
| sean-k-mooney | we may not have time to fully review and approve that todya as well | 12:56 |
| sean-k-mooney | but i think both your fature and that could work nicely togetter going forward | 12:57 |
| mikal | Oh that's interesting. SPICE tunnels USBredir over its transport, and that already works in my prototype | 13:03 |
| mikal | That spec presumably is also proposing to add the same USB devices that I need to add for that to work in SPICE? I shall read the spec. | 13:04 |
| sean-k-mooney | yes and adding image/flavor properies to say how many | 13:04 |
| sean-k-mooney | there is a lot of overlap in some respect although they were happy with the html5 proxy for there usecase | 13:05 |
| sean-k-mooney | form the naming im pretty sure this is for https://shadow.tech/ | 13:06 |
| mikal | The HTML5 proxy supports USB redirection? I find that surprising. | 13:06 |
| sean-k-mooney | mikal: why? it a javascript applcation hosted on a webserver that tunnes the raw spice protocal over a webseocket | 13:06 |
| sean-k-mooney | we are litrally just wrapping the spice tcp connetcion into a websocket and providign that to the browser | 13:07 |
| mikal | So I haven't looked at the websocket proxy much, but the javascript app is definitely missing stuff -- it doesn't support all the compression options that the protocol does for example. Its missing GLZ IIRC. | 13:07 |
| sean-k-mooney | mikal: right but that not a limitaiton fo openstack | 13:08 |
| mikal | That's fair. | 13:08 |
| sean-k-mooney | showdow likely have there own client that they are using with the websocket directly | 13:08 |
| sean-k-mooney | they are defeitly not using horizon's or skylines | 13:09 |
| mikal | Their site definitely mentions apps, but also says they have browser support. | 13:10 |
| mikal | But yeah, they seem to be proposed a relatively overlapping subset of what I am proposing. | 13:10 |
| sean-k-mooney | yep but you can do a lot in in a moddern browser :) | 13:11 |
| sean-k-mooney | anyway if we can enabel both yoru use cases i would be happy too | 13:14 |
| sean-k-mooney | mikal: +1 https://review.opendev.org/c/openstack/nova-specs/+/915190 minor line lenght issue on line 79 and you still need to menation addding the tls_port in the respocne | 13:18 |
| sean-k-mooney | mikal: but if you fix those i think im +2 on the spec | 13:19 |
| sean-k-mooney | i have also resolved teh irrelevent comments form older version so it shoudl be simpler to review now | 13:20 |
| sean-k-mooney | bauzas: gibi can ye review ^ if you have time | 13:20 |
| bauzas | I'll do | 13:20 |
| opendevreview | Michael Still proposed openstack/nova-specs master: Propose a new API microversion for a spice-direct console. https://review.opendev.org/c/openstack/nova-specs/+/915190 | 13:31 |
| mikal | sean-k-mooney: I've done both of those. | 13:31 |
| mikal | sean-k-mooney: all of your comments about docs and so forth seem reasonable to me, but I am not passionate about updating the spec to include them right now given I worry that will derail the review process. | 13:33 |
| mikal | sean-k-mooney: thanks for taking the time to work through the spec with me by the way, I appreciate it. | 13:35 |
| sean-k-mooney | mikal: +2, no worries, happy to collaberate on thigns like this | 13:44 |
| sean-k-mooney | i may or may not be able to comit to reviewing it before feature freeze but ill try as time allows | 13:44 |
| mikal | pep8 hates me. | 13:45 |
| sean-k-mooney | you know you can run that locally via docs right :P | 13:45 |
| mikal | It only reported one error last time, so I thought if I fixed that it wouldn't be angry any more... | 13:45 |
| sean-k-mooney | ah | 13:46 |
| mikal | I have learnt my lesson | 13:46 |
| sean-k-mooney | ya we normaly config it to keep going but that does not alwasy work depending on the tool we use | 13:46 |
| opendevreview | Michael Still proposed openstack/nova-specs master: Propose a new API microversion for a spice-direct console. https://review.opendev.org/c/openstack/nova-specs/+/915190 | 13:47 |
| mikal | Well, it passes locally now so let's see what Zuul thinks. | 13:47 |
| mikal | I really should go to bed, its nearly midnight here. I guess I'll see if this thing is approved in the morning. Thanks again for your help. | 13:48 |
| mikal | sean-k-mooney: it passes CI now, so that's nice. On that note I'm off to bed. | 13:57 |
| bauzas | sean-k-mooney: mikal : I have two comments in https://review.opendev.org/c/openstack/nova-specs/+/915190 | 14:49 |
| bauzas | one about testing at least | 14:49 |
| bauzas | I'm okay with accepting this spec, but only provided we're clear on the testing side | 14:50 |
| sean-k-mooney | bauzas: well i suggested tempest testign at the ptg and we said we shoudl not make that a requirement | 14:51 |
| sean-k-mooney | so the expection is unit and fucntional tests only | 14:51 |
| sean-k-mooney | wiht no devstack based tempest job | 14:51 |
| dansmith | did we? | 14:52 |
| sean-k-mooney | i origally asksed for a devstack plugin and to enabel it in one of our jobs but dansmith and other feel that was two high a bar to require in the spec | 14:52 |
| dansmith | I really thought I brought up that we at least sniff test the RFB banner for our existing vnc stuff | 14:52 |
| bauzas | sean-k-mooney: see my comment | 14:52 |
| sean-k-mooney | dansmith: i susggested a temept test like that but i tought you said no to that | 14:53 |
| bauzas | I proposed a fake object in the functional tests that would reproduce some external call | 14:53 |
| sean-k-mooney | dansmith: im not agaisn doing that just liek we do for vnc | 14:53 |
| dansmith | sean-k-mooney: okay I thought the opposite, but it's been a while | 14:53 |
| bauzas | but I'm afraid unittests and API functional tests aren't enough | 14:53 |
| sean-k-mooney | bauzas: sure so i think we can approve the spec as is if you have no other obejctsion and work on a trivial devstack plugin with mikal as part fo the implemnation and add this into one of our exsitign jobs | 14:56 |
| bauzas | sean-k-mooney: I'm not really asking for a devstack plugin | 14:56 |
| sean-k-mooney | the plugin would resided in the kerbside repo or a new dedeicated repo | 14:56 |
| sean-k-mooney | bauzas: well something need to be able to deploy kerbside | 14:56 |
| bauzas | I'm just asking for a fake object that would simulate the HTTP calls | 14:56 |
| bauzas | so we just call we correctly call it | 14:57 |
| sean-k-mooney | we dont call kerbside | 14:57 |
| sean-k-mooney | it calls us | 14:57 |
| sean-k-mooney | we shoudl have tempest coverage for the new api changes | 14:57 |
| sean-k-mooney | or could | 14:57 |
| sean-k-mooney | but im not sure that give use anything over the api sample tests | 14:58 |
| sean-k-mooney | unless we actully deploy with kerbside as well in a tempest job | 14:58 |
| bauzas | hmmmmmmmmm | 14:58 |
| bauzas | the whole spec is about passing a configurable URL to our API | 14:59 |
| bauzas | that's it | 14:59 |
| sean-k-mooney | not entirly | 14:59 |
| sean-k-mooney | it about that + adding new devices to the xml | 14:59 |
| sean-k-mooney | and 2 addtion tional api chagnes | 14:59 |
| sean-k-mooney | 1 to define the console type | 15:00 |
| sean-k-mooney | and another to expsoe the tls_port via the existing admin only console token api | 15:00 |
| bauzas | lemme be clear | 15:00 |
| bauzas | I was confusing | 15:00 |
| bauzas | " | 15:00 |
| bauzas | "The user then fetches that URL, and Kerbside delivers a .vv file with the | 15:00 |
| bauzas | connection information for a SPICE client. Kerbside uses a call to | 15:00 |
| bauzas | `/os-console-auth-tokens/bf2e6883-...` to determine the validity of the | 15:00 |
| bauzas | console authentication token, and the connection information for the console." | 15:00 |
| bauzas | here, I think we can have a functional test that would reproduce the kerbside server by calling the os-console-auth-tokens | 15:01 |
| bauzas | as a mock object | 15:01 |
| sean-k-mooney | sure | 15:01 |
| sean-k-mooney | but thats just a standar fucntional test | 15:01 |
| bauzas | this way, we wouldn't need to depend on kerbside | 15:01 |
| sean-k-mooney | sure but i was edxpecting that already | 15:02 |
| bauzas | right, that's what I'm asking in https://review.opendev.org/c/openstack/nova-specs/+/915190/13/specs/2024.2/approved/libvirt-spice-direct-consoles.rst | 15:02 |
| bauzas | from what I just read, mikal only proposed manual testing | 15:02 |
| sean-k-mooney | we can make that more explit but i was starting form a baseline of "all new feature should have unit and functional tests as our minium baseline" | 15:03 |
| sean-k-mooney | no | 15:03 |
| bauzas | for functional tests, quoted " However, a test for the | 15:03 |
| bauzas | API microversion will be added" | 15:03 |
| bauzas | which is different from having a mock object that would simulate kerbside external call to Nova | 15:03 |
| sean-k-mooney | so i expect the testing section of the spec to call out any special testing behiound our baselien | 15:04 |
| sean-k-mooney | i dont in genrall expect to say "we will add unit and fucntional tests" but if you want that to be updated to included that im fine with that | 15:04 |
| sean-k-mooney | the sepcific thing you asked for however i dont think makes sense for us to test | 15:05 |
| sean-k-mooney | nova has 2 existign apis both fo which have test coverage | 15:05 |
| sean-k-mooney | the console url show rpvoded a url that is templated based on `spice.kerbside_base_url` | 15:06 |
| bauzas_ | okay, then I'll accept the spec but asking for a FUP | 15:06 |
| sean-k-mooney | the url provided to the use rwhen they do show has a console token which kebside will use to call /os-console-auth-tokens | 15:06 |
| sean-k-mooney | so im expeicting 2 seperte tests | 15:06 |
| sean-k-mooney | one to cover the new console type for console url show | 15:07 |
| sean-k-mooney | and one to test the addtion of a tls_port for spice-direct in /os-console-auth-tokens | 15:07 |
| *** bauzas_ is now known as bauzas | 15:12 | |
| opendevreview | Merged openstack/nova-specs master: Re-propose using extend volume completion action for 2024.2 https://review.opendev.org/c/openstack/nova-specs/+/917133 | 15:53 |
| bauzas | sean-k-mooney: dansmith: gibi: I know this is late, but could you please look at https://review.opendev.org/c/openstack/nova-specs/+/922201 if you have time today ? | 16:05 |
| bauzas | I can also try to look at it before leaving | 16:05 |
| dansmith | there's a ton of unresolved comments on that? | 16:09 |
| bauzas_ | I think fwiesel replied on sean's comments | 16:12 |
| bauzas_ | but sure, I can look at those | 16:12 |
| dansmith | but there's a bunch that reference lines not even in the file anymore and so they're stacked at the top | 16:13 |
| bauzas_ | due to an older revision | 16:13 |
| bauzas_ | but I can clean them up or stick them | 16:13 |
| bauzas_ | lemme look before you go in | 16:13 |
| sean-k-mooney | if the lazy loadign was optional and off by defualt. i could maybe see triling this but im still not entirly sure this the best approch | 16:16 |
| bauzas | sean-k-mooney: can you then just reply to Fabian's comments ? | 16:27 |
| bauzas | I agree with the fact that I wouldn't rush to merge that spec given your concerns | 16:27 |
| bauzas | I'd rather propose that spec to be discussed at the next PTG | 16:27 |
| bauzas | fwiesel ^ | 16:27 |
| dansmith | he does specify it being optional, but not sure about default | 16:31 |
| dansmith | but I agree, I'm really not sure about the claims made in there, as this seems like it would be a gateway to increasing load | 16:31 |
| sean-k-mooney | i woudl actully prefer to reduce the load on neutron by reviving https://review.opendev.org/c/openstack/nova/+/786348 | 16:32 |
| dansmith | it may be better in the one case where you want to re-fetch one thing, but it seems like it opens the ability (and perhaps even required behavior) of generating many more small requests at the behest of a client that may want to DoS the metadata server | 16:32 |
| dansmith | I thought the plan was just to cache that stuff in with metadata instead of always fetching it from neutron, tbh | 16:33 |
| sean-k-mooney | well thats what the older patch is doing | 16:33 |
| dansmith | idk that we need to store it in info_cache directly and I can see reasons why that would be bad and confusing | 16:33 |
| dansmith | the older patch is storing it in info_cache, rihgt? | 16:33 |
| sean-k-mooney | its adding the security groups to the network info cache | 16:33 |
| sean-k-mooney | which speed up both the metadta api and server show | 16:33 |
| dansmith | right, but what I'm saying I thought the plans was, is to just cache it in the built metadata | 16:33 |
| dansmith | yeah I know, but if you immediately add a floating and then server show and it's not there, that's going to suck | 16:34 |
| sean-k-mooney | oh am i was not in the ptg session so i dont know | 16:34 |
| dansmith | which I think is why we're not doing that today, IIRC | 16:34 |
| sean-k-mooney | we do already cache all the metadata once built today btu its time based with no way to triger the invalidation | 16:34 |
| dansmith | network-changed doesn't dispatch for adding a floating right? | 16:34 |
| sean-k-mooney | it might but i dont think applciationcation should be relaying on the metadata contnet to be up to date | 16:35 |
| sean-k-mooney | we do get network-chaged for a number of things but i dont knwo of a list that is written down anywhere to check | 16:35 |
| dansmith | I was talking about server show | 16:35 |
| dansmith | I don't think applications can rely on anything other than metadata for that info right? | 16:36 |
| sean-k-mooney | they shoudl really call neutorn if the need the athoritive info | 16:36 |
| sean-k-mooney | but if they dont know they are on openstack then no | 16:36 |
| sean-k-mooney | this is all they have | 16:36 |
| dansmith | applications inside guests can't do that unless they have creds, which we also don't provide them with :) | 16:36 |
| dansmith | like some thing that needs to provision on boot and know it's external IP so it can offer it up to clients needs to ask metadata for that info | 16:37 |
| sean-k-mooney | yep ops have asked for that JWS tokens speficically | 16:37 |
| sean-k-mooney | dansmith: so the boot case shoudl be up to date today beacue its the first request but yes if it change during the boot | 16:38 |
| sean-k-mooney | i.e. a floting ip was added while it was booting it could be racy | 16:39 |
| sean-k-mooney | what would be nice at somepoint is to be able to povide a short lived bootsrap took like kubernbetes does but thats a much bigger feature | 16:40 |
| sean-k-mooney | dansmith: may main concern with the lazy loading spec is it does not explain how its going to do this | 16:41 |
| sean-k-mooney | liekk is the plan ot create a url router within the metadata code to fetch only the conent for that file via decompoing things into lots of funcitons | 16:42 |
| sean-k-mooney | or do some kind of properlty based laze loading on a class | 16:42 |
| sean-k-mooney | there is really just https://review.opendev.org/c/openstack/nova-specs/+/922201/9/specs/2024.2/approved/lazy-metadata-loading.rst#79 | 16:44 |
| dansmith | sean-k-mooney: yeah, if there's a race in the boot, add floating, cloud-init sequence it could be wrong | 16:53 |
| sean-k-mooney | so to me the metadata api comes under the banner of "no more proxy apis" in nova | 17:08 |
| sean-k-mooney | i.e. its not a data socue that shoudl be proxiying up to date info form other service its just a cached view of some useful info | 17:08 |
| sean-k-mooney | so the idea that applciations are writen to poll it at a rate | 17:09 |
| dansmith | idk, I don't think that's reasonable if there is literally no other way to get the info and we're holding the guest in our hand | 17:09 |
| sean-k-mooney | that is enough to cause load issues is kind of bizar to me | 17:09 |
| dansmith | like, if we start provisioning them with credentials and a directory, then I'm all for it | 17:09 |
| dansmith | (provisioning with credentials that can be renewed I should say) | 17:09 |
| sean-k-mooney | ya so at some point i think that should be done like how pods in k8s get service credital tokens to be able to talk to k8s | 17:10 |
| *** elodilles is now known as elodilles_ooo | 17:10 | |
| sean-k-mooney | but short term if we can optimise it then ok im just concerned by the lack of detial on how | 17:10 |
| dansmith | right | 17:10 |
| dansmith | people have been asking for that for a long time | 17:10 |
| opendevreview | Sylvain Bauza proposed openstack/nova master: cpu: Only check governor type on online cores https://review.opendev.org/c/openstack/nova/+/924427 | 17:11 |
| sean-k-mooney | ya i think its a reason able thing to od at least if the user opts into it | 17:11 |
| sean-k-mooney | but its not what the spec is adressing | 17:11 |
| bauzas | sean-k-mooney: I had to drop due to a bugfix, but please just capture your concerns on that lazy-loading metadata spec so you can move on | 17:12 |
| bauzas | and we'll revisit that spec at the PTG | 17:12 |
| sean-k-mooney | bauzas: i rased most of them in the spec already, mainily i dont know how they are planning to implemnte the lazy loading and im concured it will break cloud-init or cirros-init due to the fact they dont retry by default and some recuest take longer then other to formulate | 17:16 |
| bauzas | ++ | 17:17 |
| sean-k-mooney | bauzas: bascily cloud-init and cirros-init today only retry the first request and assuem the rest will be fast and work first try by default | 17:17 |
| sean-k-mooney | cloud init cna be configured to retry its just not the default | 17:17 |
| sean-k-mooney | so if this is on by defualt im concerned it woudl regression previous bugs we had where vms would not get an ssh key inejcted ectra | 17:18 |
| dansmith | sean-k-mooney: yeah, that's exactly my concern about making this less obvious by having some requests work and some not because they're all independent on the backend | 17:20 |
| dansmith | I missed your comment about that but +100 | 17:20 |
| dansmith | I think if we want to defeat caching in certain circumstances we *should* make cloud-init declare when it wants uncached data or not, | 17:20 |
| dansmith | and otherwise we're just guessing | 17:20 |
| dansmith | but splitting this into N backend requests doesn't seem to improve things at all to me | 17:21 |
| sean-k-mooney | i was wondering if there was soem way to use etag or just support triggerting the cache invalidation form the clinet side i.e. cluod init | 17:26 |
| sean-k-mooney | or curl | 17:26 |
| sean-k-mooney | i dont know what the standard convetion is for that at a http level but im sure there is one | 17:26 |
| sean-k-mooney | sound like there is a semi standardisaed HTTP PURGE method that cloudflare, varnish and squid all support to do this | 17:30 |
| dansmith | cache-control, I mentioned it in my review | 17:31 |
| sean-k-mooney | cache-contol is slightly different | 17:31 |
| sean-k-mooney | that says if caching layers are allowed to cache it or not and for how long | 17:32 |
| dansmith | it's usable on request as well | 17:32 |
| sean-k-mooney | that works with etag to allow the caching server to know if the content changed | 17:32 |
| sean-k-mooney | oh really | 17:32 |
| dansmith | https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control | 17:32 |
| sean-k-mooney | so you can send a cache-contole no-store or similr | 17:32 |
| dansmith | max-age, no-cache, etc would be perfect here I think | 17:32 |
| sean-k-mooney | ya i tought that was responce only | 17:33 |
| sean-k-mooney | but if it can be in the request | 17:33 |
| sean-k-mooney | then yes | 17:33 |
| sean-k-mooney | ya so that seams quite reasonabel to look into | 17:34 |
| opendevreview | Merged openstack/nova-specs master: Propose a new API microversion for a spice-direct console. https://review.opendev.org/c/openstack/nova-specs/+/915190 | 17:56 |
| *** bauzas_ is now known as bauzas | 19:26 | |
| opendevreview | melanie witt proposed openstack/nova master: nova-manage: Add flavor scanning to migrate_to_unified_limits https://review.opendev.org/c/openstack/nova/+/924110 | 20:40 |
| opendevreview | melanie witt proposed openstack/nova master: nova-manage: Add flavor scanning to migrate_to_unified_limits https://review.opendev.org/c/openstack/nova/+/924110 | 23:40 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!