Earlier  
Posted Nick Remark
#openstack-nova - 2019-10-31
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).
13:45:58 Sundar efried: Good. Yumeng wasn't clear about that last night.
13:46:47 Sundar efried, sean-k-mooney: On the PTG front,I'll schedule a cross-project Cyborg/Nova.
13:47:12 Sundar for whatever topics are remaining -- specs or patch
13:47:16 mriedem some non-voting jobs in check are more restrictive on when they run, see the nova-lvm job
13:47:27 mriedem talking about a gating cyborg job in nova is jumping the gun by a mile
13:47:46 Sundar mriedem: Sure, was just asking
13:48:54 mriedem dansmith: the state of the gate sub-thread about slowness and timing out of the POST to resize a server reminded me of something you said in my cross-cell series at some point, the api currently calls conductor which calls the scheduler and it's all blocking until we pick a dest compute and cast to it,
13:49:02 mriedem you said something about adding long_rpc_timeout to that,
13:49:11 sean-k-mooney Sundar: i can try to follow some of the etherpad remotely but i wont be at the ptg
13:49:36 dansmith mriedem: oh for resize...

Earlier   Later