| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-10-31 | |||
| 19:01:09 | mriedem | it's set on create and resize | |
| 19:01:27 | efried | is it used for anything, or just there kind of as a historical artifact? | |
| 19:02:01 | mriedem | quick grok shows the simple tenant usage api uses it | |
| 19:02:04 | mriedem | but probably shouldn't | |
| 19:02:30 | efried | okay. | |
| 19:02:31 | mriedem | oh it's only used there if the instance.flavor doesn't load | |
| 19:02:34 | mriedem | that's super old compat code though | |
| 19:02:51 | mriedem | it's used for filtering servers in GET /servers | |
| 19:03:07 | mriedem | and it's in the Migration object | |
| 19:03:13 | mriedem | old/new_instance_type_id | |
| 19:03:34 | mriedem | i think it's mostly vestigial though | |
| 19:03:36 | efried | And all of this (copying the flavor rather than just referring to it) is so things like rebuild behave sanely when the flavor is changed out of band. | |
| 19:03:37 | efried | right? | |
| 19:04:03 | mriedem | the flavor doesn't change on rebuild...but you mean in case the flavor extra specs change or something? | |
| 19:04:11 | mriedem | or if the flavor is deleted after the server is created and then you rebuild the server? | |
| 19:04:14 | mriedem | if so, yes | |
| 19:04:27 | mriedem | same reason we squirrel away the image meta used to create and rebuild the server | |
| 19:04:29 | mriedem | in case the image goes away | |
| 19:04:38 | efried | right, okay, thanks for confirming. | |
| 19:05:00 | mriedem | are you asking b/c of that spec about changing how flavor extra specs work? | |
| 19:05:05 | mriedem | i don't even want to look at that spec | |
| 19:05:35 | dansmith | changing how they work how" | |
| 19:05:36 | dansmith | ? | |
| 19:05:56 | mriedem | you'd have to look... | |
| 19:06:00 | efried | Yes. IMO it's a good idea. | |
| 19:06:03 | mriedem | i couldn't get past the problem statement | |
| 19:06:04 | efried | https://review.opendev.org/#/c/663563/6/specs/backlog/approved/add-flavor-metadata-or-metadata-group.rst | |
| 19:06:29 | efried | It's basically composable flavors. | |
| 19:06:40 | dansmith | oh jesus | |
| 19:07:04 | efried | so you can have a "flavor group" that describes, say, your qos extra specs, and another that describes your numa topo, and when you build an instance, you can specify multiple groups. | |
| 19:07:08 | efried | So that you don't have skittles. | |
| 19:07:27 | efried | kind of like what we're doing for cyborg device profiles, but generically. | |
| 19:09:15 | mriedem | but we don't have dynamic flavors | |
| 19:09:22 | mriedem | and what you described is basically dynamic flavors | |
| 19:09:39 | dansmith | less useful and more complex than dynamic flavors | |
| 19:09:48 | mriedem | create me an instance with this cpu/ram/disk but gimme some qos and numa on the side, regardless of how the flavor is mapped to aggregates | |
| 19:10:41 | efried | "flavor mapped to aggregates'? | |
| 19:11:51 | mriedem | yeah, pinning flavors to a subset of hosts in the deployment | |
| 19:11:59 | mriedem | capacity planning | |
| 19:12:06 | mriedem | isolation based on hw and features | |
| 19:12:07 | mriedem | etc | |
| 19:12:09 | dansmith | composing multiple things that define super detailed requirements seems like an invitation for "I can't find any combination of flavors that boot me an instance" | |
| 19:12:16 | efried | you mean by having a member_of in the flavor? | |
| 19:12:55 | efried | this idea isn't suggesting removing the ability to put extra specs into the flavor afaict | |
| 19:13:21 | efried | anyway, I've got no skin in this, I'm just reviewing someone's spec. If you guys have major objections, put 'em in the review. | |
| 19:20:58 | mriedem | i've gotta run to my kids halloween parade thing at the school, be back later | |
| 19:46:55 | openstackgerrit | Kobi Samoray proposed openstack/nova master: Avoid fetching metadata when no subnets found https://review.opendev.org/679247 | |
| 20:10:42 | openstackgerrit | Merged openstack/nova stable/ocata: Add functional regression test for bug 1669054 https://review.opendev.org/649419 | |
| 20:10:42 | openstack | bug 1669054 in OpenStack Compute (nova) ocata "RequestSpec.ignore_hosts from resize is reused in subsequent evacuate" [Medium,In progress] https://launchpad.net/bugs/1669054 - Assigned to Matt Riedemann (mriedem) | |
| 20:10:44 | openstackgerrit | Merged openstack/nova stable/ocata: Do not persist RequestSpec.ignore_hosts https://review.opendev.org/649420 | |
| 20:44:46 | mriedem | holy crap 2 changes merged | |
| 20:44:55 | mriedem | that's....spooktacular | |
| #openstack-nova - 2019-11-01 | |||
| 01:51:04 | openstackgerrit | Merged openstack/nova stable/stein: Switch to opensuse-15 nodeset https://review.opendev.org/692033 | |
| 01:51:11 | openstackgerrit | Merged openstack/nova master: Add functional test for two-cell scheduler behaviors https://review.opendev.org/452006 | |
| 02:37:56 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Allow specify user to reset password https://review.opendev.org/682302 | |
| 06:31:31 | openstackgerrit | Sundar Nadathur proposed openstack/nova-specs master: Updated Nova-Cyborg interaction spec. https://review.opendev.org/684151 | |
| 07:16:01 | openstackgerrit | Merged openstack/nova master: Refactor rebuild_instance https://review.opendev.org/688419 | |
| 08:23:43 | openstackgerrit | Merged openstack/nova stable/stein: libvirt: Ignore volume exceptions during post_live_migration https://review.opendev.org/691282 | |
| 08:31:32 | openstackgerrit | Silvan Kaiser proposed openstack/nova master: Move Nova Quobyte driver to LibvirtMountedFileSystemVolumeDriver https://review.opendev.org/687066 | |
| 08:32:23 | openstackgerrit | Silvan Kaiser proposed openstack/nova master: [WIP]Move Nova Quobyte driver to LibvirtMountedFileSystemVolumeDriver https://review.opendev.org/687066 | |
| 13:05:00 | openstackgerrit | Merged openstack/nova master: Default AZ for instance if cross_az_attach=False and checking from API https://review.opendev.org/469675 | |
| 13:09:49 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: libvirt: Ignore volume exceptions during post_live_migration https://review.opendev.org/691283 | |
| 13:12:28 | mriedem | need a couple of cores to review gibi's evacuate + qos ports changes, the top is trivial, the bottom is a little more work but not bad, lots of test coverage and i'm +2 on it https://review.opendev.org/#/q/topic:bp/support-move-ops-with-qos-ports-ussuri+status:open | |
| 13:14:48 | mriedem | s/a couple of cores/one other core/ | |
| 13:23:10 | efried | I tried to hit those on Wed but didn't have it in me. I'll try again today. | |
| 13:24:39 | efried | mriedem, dansmith: do you think the cyborg tempest job should ultimately be voting or nonvoting in nova? The ironic job is nonvoting but the neutron jobs are voting, so I'm not sure there's a clear precedent for "integration test with $service" | |
| 13:25:12 | sean-k-mooney | efried: well if neturon is broken we cant boot vms | |
| 13:25:39 | sean-k-mooney | efried: if ironic is broken we just can manage bematal but the other virt dirvers shoudl still work | |
| 13:25:53 | sean-k-mooney | efried: i would assume it would be non voting at least at first | |
| 13:26:08 | efried | seems like a reasonable line of thought. Thanks. | |
| 13:33:26 | mriedem | the ironic job is voting in other projects, just not nova, likely because no one cared to make it voting in nova | |
| 13:33:48 | mriedem | and historically the ironic jobs were very inconsistent and failed / timed out frequently | |
| 13:33:59 | Sundar | sean-k-mooney, efried: I agree it should be non-voting now. With the fake driver, we are putting up a VM without devices. | |
| 13:34:25 | sean-k-mooney | right its just testing the api workflow | |
| 13:34:33 | mriedem | we also have a barbican job in the experimental queue, but i'm not sure how stable that is either | |
| 13:34:34 | sean-k-mooney | even so that is valuable to test | |
| 13:35:12 | sean-k-mooney | with zuulv3 and the fact we can manage this all in repo its not hard to change if we think its stable and worth it | |
| 13:36:27 | Sundar | mriedem, sean-k-mooney, efried: What is the criterion to place a job in experimental, instead of check alone? | |
| 13:36:48 | efried | "We don't want this to run with every patch set" | |
| 13:36:54 | efried | "only on demand" | |
| 13:37:34 | efried | Considering how integrated the cyborg callouts are in the general flow of nova, IMO this one needs to be in check | |
| 13:38:34 | efried | ...once the code is in place. Which is what's signified by the job-add patch being on top of the series. | |
| 13:39:16 | sean-k-mooney | efried: ya i think it should be in check too as non voting | |
| 13:41:11 | Sundar | efried: Re. the criterion "We don't want this to run with every patch set" -- we may want to run the tests when anything changes in the compute manager or virt driver, at least. | |
| 13:41:26 | Sundar | Well, at least libvirt driver | |
| 13:41:38 | sean-k-mooney | Sundar: right erric was commenting about why it would be in experimental | |
| 13:41:59 | sean-k-mooney | if its in experimental one of the resaons for that is we dont want it to run on every patch | |
| 13:42:10 | sean-k-mooney | for cyborg we want it to run on most patches | |
| 13:42:23 | sean-k-mooney | so it better to keep it in check | |
| 13:42:36 | Sundar | sean-k-mooney: Sure, makes sense. How about gate? | |
| 13:42:39 | efried | Sundar: If you wanted to try to come up with a reasonable setting for 'irrelevant-files' you could do that. But for something coupled into the compute manager and virt driver and scheduler and conductor like this, I think that would be very difficult to nail down effectively. | |
| 13:42:54 | efried | Sundar: if it's nonvoting, it doesn't make sense for it to be in the gate queue. | |
| 13:42:56 | dansmith | definitely | |
| 13:43:01 | dansmith | maybe nova/doc :) | |
| 13:43:25 | Sundar | efried: So check only? | |
| 13:43:27 | sean-k-mooney | the default irrelevant-files we use for tempest jobs should be fine | |
| 13:43:46 | efried | Sundar: yes. Check, nonvoting. I commented as such in the patch. | |
| 13:43:54 | sean-k-mooney | Sundar: i think so we dont run most of the backend specific jobs in gate | |
| 13:44:18 | efried | which btw is here https://review.opendev.org/#/c/670999/ for those following along at home | |
| 13:44:57 | efried | Sundar: if we made it voting at some point, we would probably want to add it to gate for the same reasons that motivated us to make it voting (whatever those are). | |