Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-02-25
22:32:00 mriedem granted one should probably never do that, and cinder doesn't allow you to detach like that (unless you force it)
22:33:51 sean-k-mooney oh am a.) the whould not do that :) and b.) ... i can test that tomorrow and let you know what happens. neutron will allow note allow you to set it to the python None but it will allow you to set it to the string "None"
22:34:08 sean-k-mooney * a.) they should not...
22:41:08 mriedem melwitt: the api change for this is merged https://review.openstack.org/#/c/636779/ so if you get a minute can you review the novaclient change, it should be pretty simple
22:41:12 mriedem i'm taking that one out of runways though
22:41:22 mriedem takashin: ^
22:41:37 melwitt mriedem: ok, can do. thanks
22:42:11 takashin mriedem: Okay. I will review it.
22:42:20 mriedem thanks
22:43:58 openstackgerrit Merged openstack/nova master: Send RP uuid in the port binding https://review.openstack.org/569459
22:44:14 openstackgerrit Merged openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317
22:47:35 openstackgerrit Merged openstack/nova master: Use placement.inventory.inuse in report client https://review.openstack.org/568639
22:50:59 melwitt congratulations :)
22:50:59 melwitt py27: commands succeeded
22:51:05 melwitt *eyes shimmering*
22:53:17 sean-k-mooney melwitt: :) what patch are you working on ?
22:53:34 melwitt counting quota usage from placement
22:53:47 melwitt when I see those green messages it's just like.... yess
22:53:57 sean-k-mooney and that is always nice to see but it kill me when pythone 3 fails after python 2 passes
22:54:13 melwitt oh yeah. that's bitten me before
23:02:00 openstackgerrit Chris Friesen proposed openstack/nova master: Flavor extra spec and image properties validation https://review.openstack.org/620706
23:04:02 yonglihe mriedem: just rebase to new microversion. zuul running.
23:04:23 mriedem yonglihe: yup i saw
23:04:26 cfriesen FYI, in the context of this ^ commit, I'm taking over from jackding.
23:05:32 sean-k-mooney cfriesen: ok. are you the only windriver person working on nova currently again?
23:06:34 sean-k-mooney cfriesen: als that is targetign train right? stephen has reproposed the spec for train
23:06:50 cfriesen sean-k-mooney: there are a couple other guys that will hopefully pop their heads up. :)
23:07:10 cfriesen sean-k-mooney: that's targetting stein and is currently on a runway
23:07:25 cfriesen sean-k-mooney: stephen proposed a whole separate thing for train
23:07:35 sean-k-mooney oh ok
23:07:54 sean-k-mooney ill also try and review that tomorrow so.
23:08:04 sean-k-mooney anyway ill call it a day there o/
23:08:35 cfriesen sean-k-mooney: I just took a quick look at it, need to review it fully. looks like he's proposing defining a proper generic schema for the various properties/extra-specs
23:08:50 cfriesen sean-k-mooney: later
23:08:57 sean-k-mooney stephenfin: spec
23:09:18 sean-k-mooney ya so there is a glance api we could already use
23:09:43 sean-k-mooney but we migth want to seperate it out into a reusable lib or something
23:10:25 sean-k-mooney he would like to have a single source to both use for validation and documentaiton generation acorss favor extraspec/image metatdata/volume metadata
23:10:50 sean-k-mooney the glance metadef api does that allready but he is also considering other options
23:17:35 openstackgerrit Yongli He proposed openstack/nova master: Add server sub-resource topology API https://review.openstack.org/621476
23:18:05 aspiers who's our resident KVM / machinetype expert?
23:18:21 aspiers I've just discovered a snag with SEV detection
23:19:28 aspiers libvirt's virConnectGetDomainCapabilities() API requires specifying a particular arch and machine type
23:19:52 mriedem aspiers: hook up with kash
23:19:53 mriedem kashyap
23:19:57 aspiers mriedem: thanks
23:20:30 aspiers so the results presumably could vary per architecture and machine type, although in practice it seems that if the SEV feature is supported, it is supported across all (arch, machine type) pairs the host provides
23:21:31 aspiers but in order to detect the SEV capability (and provide a trait), this API call needs to be done during initHost() where arch/machtype is not known, rather than just before booting an instance when it is known
23:22:21 aspiers since currently this getDomainCapabilities API call is only used for SEV detection and nothing else, I could hardcode it to x86_64 and a single machine type
23:22:27 aspiers but that seems a bit ugly
23:23:15 aspiers or I could call it once for each (arch, machine type) the host provides, and then if SEV is supported for any one of those tuples, mark the SEV capability as supported for the host
23:24:37 aspiers but kashyap isn't currently here it seems ...
23:32:32 melwitt kashyap is EU time zone
23:33:38 aspiers melwitt: OK thanks
23:36:41 cfriesen aspiers: don't we specify arch in the nova config?
23:37:37 aspiers cfriesen: I don't think so
23:38:46 aspiers but actually it's only one of two possibilities in the libvirt driver
23:39:13 aspiers cfriesen: https://github.com/openstack/nova/blob/c7f0d160e4df95cc82706bcd8c4a9890a4dfeb51/nova/virt/libvirt/driver.py#L438
23:39:34 aspiers so I can iterate over those two, but that still leaves the question of machine type
23:39:44 aspiers of which there are a zillion
23:39:52 cfriesen aspiers: ah...I was actually thinking of the "hw_machine_type" config option
23:40:02 aspiers ah yeah, that's different
23:40:14 aspiers and that's only a default
23:40:18 cfriesen right
23:40:40 aspiers but it seems wrong to call the virConnectGetDomainCapabilities API twice for each known machine-type
23:40:55 aspiers well not wrong, but inelegant at least
23:41:00 aspiers and expensive
23:41:10 cfriesen that is kind of icky. what if you stopped as soon as you got SEV supported for one machine type?
23:41:10 aspiers not that initHost() happens often, but still ...
23:41:48 aspiers well sure, could do that, but if I'm going to hardcode an assumption that this API call is only used for SEV capability detection then I could make it even simpler
23:42:54 cfriesen I think you could just make a "can host support SEV" call which just checks one known-to-be-valid config
23:43:03 aspiers exactly
23:43:19 aspiers but then what if something else in the future needs other data from this API?
23:43:29 aspiers or am I prematurely optimizing :)
23:43:55 cfriesen which API exactly are you talking about?
23:44:03 aspiers the one above
23:44:13 aspiers virConnectGetDomainCapabilities
23:44:37 aspiers actually I think I've just discovered a bug in libvirt
23:45:03 aspiers virsh domcapabilities --virttype kvm --emulatorbin /usr/bin/qemu-kvm --arch x86_64 --machine pc-i440fx-1.4 | xq /domainCapabilities/features/sev/@supported actually returns 'yes'
23:45:19 aspiers but SEV is not supported unless you use a q35 machine type
23:48:04 cfriesen I think you could just add a little helper function in virt/libvirt/guest.py that calls virConnectGetDomainCapabilities, then add another "is sev supported" helper function that calls the guest.py routine and is in turn called from LibvirtDriver.init_host()
23:48:54 openstackgerrit Chris Friesen proposed openstack/nova master: Improve libvirt image and snapshot handling https://review.openstack.org/616692
#openstack-nova - 2019-02-26
00:07:24 alex_xu mriedem: want to hear your opinion on https://review.openstack.org/#/c/634827/23/nova/objects/migrate_data.py@99
00:08:47 cfriesen is it still the case that traits in image properties are specified as "trait:HW_SOME_TRAIT=required" with a colon after trait?
00:09:26 cfriesen alex_xu: I've uploaded a new version of the image/flavor validation commit
00:10:12 alex_xu cfriesen: got it, I will try second round today
00:11:26 alex_xu cfriesen: for your trait question http://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/glance-image-traits.html
00:11:33 alex_xu so should be yes
00:34:21 openstackgerrit Takashi NATSUME proposed openstack/nova master: Fix resetting non-persistent fields when saving obj https://review.openstack.org/636271
01:08:04 mriedem alex_xu: i'm not sure i understand the question on the review :)
01:08:39 mriedem are you saying, since we already have the migration context, why not just store the information there rather than pass it over rpc with the MigrateData object?
01:13:07 alex_xu mriedem: migration_context has the claimed_instance_numa, and we also need host numa obj, and some host configuration(like shared cpu set?). Then we pass all of those back to the src node, and src node can use existed code to generate libvirt xml.
01:14:08 alex_xu mriedem: the currently way in the patch is only fetching the needed back to the host node, I think that is why we hack the xml in the src node.
01:15:01 mriedem as far as i know this is working similar to how we handle updating the xml on the source host for things like volumes and vifs
01:15:07 mriedem based on data from the dest host
01:16:17 alex_xu yes, I agree, we already have code work as this. Just want to ensure whether we want to change that, if people really thing it is ok, then i will continue review as the current way
01:17:46 mriedem well, there might be better alternatives, but at this point in the release it's probably too late to try them without for sure deferring this change to train
01:17:53 melwitt sorrt
01:17:54 openstackgerrit melanie witt proposed openstack/nova master: Add online data migration for populating user_id https://review.openstack.org/633351
01:17:54 openstackgerrit melanie witt proposed openstack/nova master: Populate InstanceMapping.user_id during migrations and schedules https://review.openstack.org/638574

Earlier   Later