Earlier  
Posted Nick Remark
#openstack-nova - 2019-02-08
19:16:50 openstackgerrit Corey Bryant proposed openstack/nova master: xenapi/agent: Change openssl error handling https://review.openstack.org/635533
19:22:25 cfriesen If I were to request a release of os-traits (in order to make use of the new vTPM traits) would I ask for release 0.10.1 or 0.11.0?
19:23:03 melwitt new traits = "new features" so a minor version bump
19:23:35 aspiers melwitt: speaking of traits, do you have any thoughts on the above? I can submit a review easily
19:25:13 leakypipes aspiers: no reason other than legacy I think... I'd welcome a cleanup patch.
19:25:28 melwitt ok, good. I was about to say, I don't know and I'd ask jay
19:25:36 aspiers :)
19:25:50 aspiers leakypipes, melwitt: coming in about 15 seconds ...
19:25:51 cfriesen aspiers: I see you just added some stuff to os-traits...were you planning on requesting a new release?
19:26:13 openstackgerrit Adam Spiers proposed openstack/nova master: Convert CPU_TRAITS_MAPPING to use os_traits https://review.openstack.org/635919
19:26:16 aspiers cfriesen: don't need one urgently yet - still working on the code to consume the new trait :)
19:26:39 cfriesen aspiers: I'm in the same boat, just don't want to get caught waiting too long
19:26:52 aspiers cfriesen: fair enough
19:27:33 aspiers leakypipes, melwitt: added you as reviewers
19:28:01 mriedem dansmith: yeah good point, that should move
19:28:10 dansmith I shall convert
19:28:27 dansmith I shall wait until you drop your +2
19:28:31 melwitt aspiers: ack
19:28:44 mriedem dansmith: already done
19:28:55 dansmith mriedem: I shall be already done as well
19:28:56 mriedem dansmith: are you just going to move it to https://review.openstack.org/#/c/591657/ ?
19:29:28 openstackgerrit Elod Illes proposed openstack/nova stable/pike: Handle IndexError in _populate_neutron_binding_profile https://review.openstack.org/635921
19:30:41 dansmith mriedem: am I?
19:31:06 aspiers leakypipes: just checking IIUC: is update_provider_tree() the right place to add a call to new code which tests for SEV support and then calls provider_tree.add_traits() if support is found?
19:31:51 aspiers leakypipes: I guess _get_cpu_traits() might be the other candidate, but that seems dependent on the guest CPU mode, which I don't think we want for SEV
19:32:32 mriedem dansmith: i'm not sure what 'convert' meant
19:32:36 mriedem oh -1?
19:32:42 dansmith mriedem: heh yeah, convert my vote
19:32:48 mriedem ah i see
19:32:55 mriedem saved my sweet sweet stats sheet
19:33:01 mriedem a true gentleman
19:33:21 mriedem aspiers: yes upt
19:33:28 mriedem to set inventory/aggregates/traits/etc
19:33:31 aspiers mriedem: thanks!
19:33:38 mriedem aspiers: fried_rice is your captain for upt
19:33:44 aspiers got it :)
19:33:55 aspiers hmm, that nick is making me hungry
19:53:07 aspiers leakypipes, fried_rice, mriedem: I'm wondering if it makes sense to detect SEV support in get_available_resource(), possibly under data["cpu_info"]
19:53:39 mriedem for what reason?
19:54:10 aspiers for one, so it's visible via the API
19:54:37 mriedem it is visible the API,
19:54:38 mriedem the placement API
19:54:42 mriedem as a trait on the compute node resource provider
19:55:09 aspiers right, but not via "openstack hypervisor show" IIUC?
19:55:11 mriedem we're not trying to game all new traits into the old hypervisor stats API
19:55:15 mriedem correct
19:55:16 mriedem and that's ok
19:55:28 mriedem in the long long future the hypervisor stats/show stuff could be proxied to placement
19:55:30 aspiers ah OK, so the idea is to move away from the old API?
19:55:32 aspiers got it
19:56:34 aspiers that thought arose because the get_domain_capabilities() I've added sits next to get_capabilities() https://review.openstack.org/#/c/633855/1/nova/virt/libvirt/host.py
19:56:50 aspiers which is currently called from _get_cpu_info()
19:57:34 mriedem but you can also get that via update_provider_tree yes?
19:57:40 mriedem self.host.get_domain_capabilities()
19:57:43 aspiers yup
19:57:46 mriedem if 'sev' in caps: add_my_trait()
19:57:53 aspiers makes sense, thanks!
19:57:59 mriedem the cpu feature flag stuff sort of works like that
19:58:54 fried_rice aspiers: Give me a bit, I'm on a call, but - yes, at a glance, it makes sense to me that SEV support would be discovered and the trait injected in update_provider_tree.
19:59:14 aspiers fried_rice: cool, thanks!
19:59:28 aspiers I need to grab some dinner
19:59:31 aspiers back in a bit
19:59:35 fried_rice aspiers: Or, during init_host, add it to the virt driver's capabilities dict.
20:00:18 fried_rice but that relies on a) an in-flight patch from mriedem that converts those to traits on the compute RP, and b) making the capabilities dict an instance var on the relevant virt drivers, like PowerVM has.
20:02:05 aspiers interesting, I'll check that out
20:02:50 fried_rice aspiers: a) is https://review.openstack.org/#/c/538498/
20:03:10 mriedem "in-flight"
20:03:13 mriedem more like crash landed
20:03:23 aspiers LOL :)
20:03:58 cfriesen melwitt: fried_rice: if we're using the "cycle-with-intermediary" library pattern for os-traits, shouldn't there have been a release already after stein-2?
20:04:46 fried_rice aspiers: b) is visible in the out-of-tree PowerVM driver where we set a capability depending on which disk driver we're using: https://github.com/openstack/nova-powervm/blob/master/nova_powervm/virt/powervm/driver.py#L175-L181
20:05:04 melwitt cfriesen: yes. I had thought the release team was going to propose them but it looked like they didn't
20:05:07 fried_rice cfriesen: I wouldn't expect os-traits releases to be a big deal wrt milestones, but whatevs.
20:05:49 cfriesen fried_rice: not that it's a big deal, but according to http://lists.openstack.org/pipermail/openstack-dev/2018-October/135689.html it was going to be automatic
20:05:56 fried_rice gotcha
20:05:57 melwitt they did a release of os-traits at s-1 but not for s-2
20:06:18 aspiers fried_rice: in case you're interested, this is the first step towards detection of SEV support which will be consumed by the code which provides the new trait
20:06:21 aspiers https://review.openstack.org/#/c/633855/
20:06:25 fried_rice were there changes between m-1 and m-2?
20:06:35 melwitt yeah, I wondered if maybe there weren't
20:06:50 fried_rice aspiers: ack, I've had that spec on my list for yonks. hope to get around to reading it eventually ...
20:06:55 aspiers fried_rice: thanks a lot for all the info, I'll take a look
20:07:04 aspiers hehe
20:07:39 aspiers OK, I really REALLY need dinner now. bbl ;-)
20:07:40 cfriesen melwitt: what was the exact cutoff? the vTPM stuff went in on Jan 8, and there was a minor change on Jan 5
20:08:05 cfriesen anyways, I'll propose a release
20:08:53 melwitt not sure. smcginnis, do you know how the auto release works? we noticed there wasn't an automatic release proposed for os-traits at s-2
20:16:55 melwitt yeah, I don't find any auto-proposed releases for s-2 like this one from s-1 https://review.openstack.org/612843
20:58:40 smcginnis melwitt, cfriesen: Were there more than 1 or 2 non-zuul, functional changes? It's possible it was accidentally skipped if it didn't look like there were really changes to get out.
20:59:29 cfriesen smcginnis: one actual change went in on jan 8, so maybe that was it.
21:00:30 smcginnis Actually, looks like that didn't merge until the 11th, so it was most likely after we checked.
21:00:33 smcginnis https://review.openstack.org/#/c/629299/
21:01:27 melwitt smcginnis: there was one functional change, I think. I tried a gerrit search for project:openstack/releases message:"stein milestone-2" and didn't find any other auto-generated releases
21:01:51 melwitt (unless the commit message format changed)
21:02:16 smcginnis I can't remember if we used "stein milestone-2" in the commit messages for those.
21:05:19 melwitt ok, I was curious if any other project got an auto-proposed release for s-2 but didn't know how to find
21:06:29 melwitt it was nice having it for s-1 anyway :)
21:10:25 melwitt mriedem: can you sanity check me, is this backward incompatible, the 'only_contrib' removal? it looks to me like it's removed but not backward incompat https://github.com/openstack/python-novaclient/compare/11.1.0...master
21:13:58 mriedem no it's not, so a minor version bump at least
21:14:06 mriedem that warning has been there since pike i think

Earlier   Later