Earlier  
Posted Nick Remark
#openstack-nova - 2019-12-13
13:21:23 tobiash hi, I'd like to revive discussion on this nova-spec which was proposed for rocky and abandoned: https://review.opendev.org/572805. What is the preferred way of doing this? Shall I create a new change or ask a nova-core to hit the restore button?
13:23:02 gibi tobiash: restored the spec. Please update it (e.g. move it to the ussuri dir at least)
13:23:19 tobiash gibi: thank you very much!
13:24:09 sean-k-mooney tobiash: you will need to add the new feature liason field at a minium to get it to pass the gate checks
13:24:21 sean-k-mooney there is a description of that in the readme
13:24:43 tobiash sean-k-mooney: thanks for the hint
13:24:45 sean-k-mooney there may be some other template changes too but i think that is the main one since rocky
13:26:11 openstackgerrit Eric Xie proposed openstack/nova master: Fix error when live-migrating instance cause of gic version https://review.opendev.org/698905
13:38:40 openstackgerrit Tobias Henkel proposed openstack/nova-specs master: Add spec for downloading images via RBD https://review.opendev.org/572805
13:54:58 openstackgerrit Matthew Booth proposed openstack/nova master: Don't retry database connections from command line applications https://review.opendev.org/666892
14:01:46 openstack Launchpad bug 1856311 in OpenStack Compute (nova) "server_external_events response status is always 'completed' instead of event status which requested as failed" [Undecided,New]
14:01:46 mriedem efried: have you seen this? https://bugs.launchpad.net/nova/+bug/1856311
14:03:49 efried mriedem: nope, /me clicks
14:04:01 efried what, now that I'm a server-external-events expert?
14:04:18 mriedem yes you own it now
14:04:26 mriedem but it looks like it's not what i thought they were complaining about
14:04:27 efried I haven't looked at the novaclient shim at all yet
14:05:00 sean-k-mooney is that valid? i would have assuemd that status faild for network-vif-plugged ment the pluggin failed
14:05:46 sean-k-mooney and code 200 ment the event was sucessfully recieved?
14:06:04 sean-k-mooney i dont actully know if that is how it works
14:06:40 sean-k-mooney oh sorry read that wrong
14:09:00 mriedem https://github.com/openstack/nova/blob/e6f742544432d6066f1fba4666580919eb7859bd/nova/api/openstack/compute/server_external_events.py#L133
14:09:02 mriedem it's working as designed
14:09:12 mriedem completed == we got the event and we're sending it on for processing, thanks for calling
14:09:15 sean-k-mooney ya i think so too was just readin the api ref
14:09:22 mriedem dansmith: correct ^?
14:09:41 mriedem laura did rub cbd oil all over my lower back this morning though so i might just be like super duper high
14:11:13 sean-k-mooney mellow maybe cbd does not have the more interesing sideeffects
14:12:41 mriedem heh, i know, but it's a ruse i like to play on my wife like i have no idea and i'm 85
14:18:55 efried I'm supposed to be vacationing starting next week...
14:18:55 efried https://review.opendev.org/#/c/686804/
14:18:55 efried gibi, stephenfin: Will y'all have a chance to look at the vTPM spec today?
14:19:56 gibi efried: sorry. I will not have the chance today
14:20:20 gibi efried: or at least I cannot promise
14:20:30 efried okay.
14:22:07 stephenfin Afraid I'm in the same boat. Stuck with internal stuff :(
14:22:59 efried Okay.
14:24:29 sean-k-mooney if i get this backport done soon ill try to look at it again that said i think its going to be pretty close jsut reading your comments
14:26:22 efried thanks sean-k-mooney
14:31:56 dansmith mriedem: completed in the return from the api means "got it dude" yes.. but status in the actual event body is the external service telling nova (i.e. compute) if something worked or not
14:32:24 mriedem right
14:32:32 mriedem hey nova, this event failed; ok, ack
14:32:46 dansmith yup
14:37:19 mriedem stephenfin: thanks for hitting all of those cross-cell resize changes
14:45:08 stephenfin mriedem: np
14:45:50 stephenfin It was pretty much just functional tests once I got past the remaining conductor tasks. Need to go find someone else now :)
15:02:41 openstackgerrit Eric Fried proposed openstack/nova master: DRY: Build ImageMetaPropsPayload from ImageMetaProps https://review.opendev.org/698803
15:10:25 KeithMnemonic dansmith: Thanks for pushing that patch through. Do you think you could please also do that last cherry pick in that set? https://review.opendev.org/#/c/690735/2
15:11:06 dansmith are we still doing stuff for pike?
15:11:18 dansmith mriedem:
15:13:02 mriedem it's in EM (as is queens) so we can if people have a need,
15:13:19 mriedem i know suse cares about it and so does ericsson since they have products based on pike
15:13:37 mriedem and as you know rhosp cares about queens (or at least the internal CI/CD stuff at RHOSP cares about queens)
15:13:48 dansmith yeah, already did the queens one
15:14:25 dansmith EM means "we can throw anything in there anyone cares about without inspecting it or worrying about breakage" right?
15:14:49 mriedem heh, not really
15:15:03 mriedem it just means it's there if people want a common place to backport, we can merge things, but we don't have to
15:15:13 dansmith KeithMnemonic: can you please +1 those patches with "I stake my reputation on the fitness of this patch as I have tested it fully" ?
15:15:31 mriedem https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance
15:15:56 dansmith mriedem: right, I thought we said EM would be like a dumping ground, where we wouldn't try to keep tests working, etc
15:16:07 mriedem "There is no statement about the level of testing and upgrades from Extended Maintenance are not supported within the Community."
15:16:20 mriedem i wouldn't say we don't try,
15:16:24 mriedem but we don't bend over backwards
15:16:48 mriedem if tests are failing for some reason and there is a trivial way to fix, sure, but if things are chronically busted and no one is working on it or it's a lot of work then it's fine to EOL
15:17:21 mriedem iow, EM == best minimal effort, buyer beware
15:17:40 Sundar efried: Re. https://review.opendev.org/#/c/631244/51/nova/conductor/manager.py@1578, when you say: "FWIW, I still don't like this.", what is 'this'?
15:18:07 mriedem dansmith: i've also told KeithMnemonic that suse can just cherry-pick those for their internal pike series and not be blocked on us
15:18:36 dansmith mriedem: yeah, it'd be nice if he'd at least +1 that he wants them and that they've confirmed they're good or something
15:18:42 KeithMnemonic dansmith let me test in on a pike cloud i have and will update the bug.
15:19:00 KeithMnemonic mriedem: we have that cherry pick ready locally if needed
15:19:13 dansmith KeithMnemonic: you haven't actually tested these?
15:19:21 KeithMnemonic but since the patch is still there and not pulled i figured it would be best to see if it can go in upstream
15:19:25 KeithMnemonic i did
15:19:50 KeithMnemonic on rocky
15:20:04 KeithMnemonic let me go back and do pike as well
15:20:08 KeithMnemonic it wont take me long
15:20:23 dansmith yeah, that's not the same
15:20:27 mriedem note that in at least one case i'm aware of, we had merged a backport to rocky and someone from canonical came back to me later saying it didn't actually fix the bug and they were right and we needed to follow up with a rocky only fix
15:20:28 KeithMnemonic ok fair enough
15:20:46 mriedem so, it happens
15:21:31 KeithMnemonic so that is funny, sort of i just got merged a cheey pick for a missing "prev" button on the horzion instance panel, that is actually broken in master
15:22:21 efried Sundar: I don't like "Hey, also send a required trait asserting that the compute is capable of accelerator stuff, because the fact that it's exposing inventory isn't sufficient"
15:23:05 dansmith efried: it's not exposing inventory, cyborg is exposing the inventory, right?
15:23:23 KeithMnemonic and mriedem they are telling me it is due to nova api behavior ;-)
15:23:38 Sundar efried: The trait can be used by Cyborg to not publish inventory.
15:23:38 efried dansmith, Sundar: If a rogue external agent (whether it's cyborg, neutron, random $service, an admin) goes around adding shit to the provider tree, all bets are off as far as I'm concerned.
15:23:58 efried Yes, that ^ is cyborg not being rogue, and it is sufficient IMO.
15:24:14 efried dansmith wants to not trust cyborg et al that far.
15:24:16 dansmith efried: then we should do a service version check
15:24:55 Sundar efried: does that not apply to any trait?
15:24:56 efried I'm not going to block on this. I appreciate the reasoning. I just don't like it. So you can ignore that part and focus on the "if you're going to do it, you need to do it this way" part of the comment.
15:24:57 dansmith efried: we have gone a long way with not breaking our internal RPC APIs, please give that the credit due, and let's use the tools (any of them) that we have to keep those guarantees strong
15:27:33 Sundar dansmith: We discussed 2 changes: A. Per-ARQ events B. Handling old compute nodes, one option being trait usage. I can do Part A now. Are you ok with that partial update?
15:28:15 Sundar Part B perhaps requires more discussion, and Ill do that later
15:28:51 dansmith Sundar: there are multiple parts of B that need to be done, the trait so that at least cyborg can tell, and then the second part is what we do on the nova side.. exposing the trait is not contentious, so you should do that
15:29:08 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix accumulated non-docs nits for cross-cell-resize series https://review.opendev.org/698935
15:29:27 dansmith if you want to wait until january I will be glad to write the hard service version check
15:31:03 mriedem this kind of hard service version check when the trait isn't available? https://review.opendev.org/#/c/695220/4/nova/compute/api.py@3938
15:32:37 Sundar dansmith: OK. Just to be clear, you don't see the point in reviewing A alone now?
15:33:09 stephenfin smcginnis: Didn't you have a patch for the requirements tooling to allow me to do this? https://review.opendev.org/#/c/698895/1/doc/requirements.txt

Earlier   Later