Earlier  
Posted Nick Remark
#openstack-nova - 2019-02-21
15:58:11 mgoddard it doesn't matter what is reported to placement, this is about the ironic node config
15:58:38 mriedem ok i see https://review.openstack.org/#/c/608573/3/nova/virt/ironic/driver.py@815
15:58:56 mriedem so if the values are 0 we won't report those resource classes for inventory
16:00:00 mriedem i guess https://docs.openstack.org/ironic/rocky/install/configure-nova-flavors.html doesn't mention anything about 0ing out the node property values,
16:00:04 mriedem is that in the ironic docs somewhere?
16:01:15 bauzas gibi: I'm just starting to sharpen my pen for reviewing network-bw-providers
16:01:26 bauzas gibi: did the implementation diverged from the spec https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/bandwidth-resource-provider.html ?
16:01:38 bauzas gibi: that helps me catching up quickier
16:02:04 gibi bauzas: the name of the resource classes got shorter, and there are extra object model addition that was not covered by the spec
16:02:16 mriedem and the microversion...
16:02:20 gibi bauzas: but I think the basic logic and goal did not changef
16:02:25 gibi mriedem: ++
16:02:57 bauzas gibi: okay, gtk
16:03:19 bauzas mriedem: a new API microversion ?
16:03:27 bauzas if so, I'll be able to get it
16:03:42 gibi bauzas: yes a new microversion to enable the feature for server create/delete
16:04:00 bauzas gotcha
16:04:50 mgoddard mriedem: let me check the docs
16:05:17 mriedem i guess i just don't know how those values are zeroed out - the node API? something in ironic-inspector?
16:08:03 mgoddard mriedem: the node 'properties' field is just a dict, it defaults to being empty
16:09:04 openstackgerrit Matt Riedemann proposed openstack/nova stable/rocky: Don't emit warning when ironic properties are zero https://review.openstack.org/608573
16:09:25 mriedem mgoddard: https://review.openstack.org/#/c/608573/3..4//COMMIT_MSG
16:09:34 mgoddard mriedem: I can't find anything that explicitly says not to set those properties, but that is what we test in devstack: https://github.com/openstack/ironic/blob/master/devstack/lib/ironic
16:09:42 mgoddard mriedem: search --property
16:10:21 mgoddard mriedem: nice, thanks for updating
16:10:38 mriedem i only see https://github.com/openstack/ironic/blob/master/devstack/lib/ironic#L2082 but that's something else
16:10:40 mriedem that's the flavor not the node
16:11:00 mgoddard L1996 is node creation
16:11:32 openstackgerrit Merged openstack/python-novaclient master: Make Server.networks use a predictable sort order https://review.openstack.org/638214
16:11:33 openstackgerrit Merged openstack/python-novaclient master: API microversion 2.69: Handles Down Cells https://review.openstack.org/579563
16:11:36 mgoddard only property is cpu_arch, and possibly root_device
16:12:29 mriedem ok and we don't get a KeyError because of https://review.openstack.org/#/c/608573/4/nova/virt/ironic/driver.py@245
16:12:59 mgoddard right
16:13:05 mriedem so we'll warn there too :)
16:13:25 mriedem oh wait
16:13:29 mriedem nevermind we default to -
16:13:31 mriedem *0
16:13:41 mgoddard yeah
16:14:26 mriedem ok approved
16:14:37 mriedem please re-do the queens backport using the updated stable/rocky change
16:15:01 mgoddard great, thanks. will do
16:15:12 mriedem sorry for the trouble. i had put off sorting this one out for weeks.
16:16:13 mgoddard no problem, I know the kind of task :)
16:16:39 tbachman z;. ¸d fgi`q1e
16:16:47 tbachman
16:27:26 melwitt o/
16:28:00 mriedem cdent: efried: i'm kind of at a loss as to what to do about this stable/rocky nova backport which is a fix from extracted placement in stein https://review.openstack.org/#/c/608903/
16:28:24 mriedem as far as i know, nothing is "using" nested providers in rocky - i know nova isn't, but i'm not aware of anything else either
16:28:33 mriedem so i'm leaning to not backport this if we don't need it
16:28:45 cdent mriedem: my inclication would be to wait until somebody asks
16:28:58 mriedem same
16:29:06 mriedem i think in that case i'm going to abandon
16:29:17 mriedem with all due respect to mr nakamura
16:30:08 cdent all respect is due mr nakamura
16:47:50 openstackgerrit Mark Goddard proposed openstack/nova stable/queens: Don't emit warning when ironic properties are zero https://review.openstack.org/608611
16:59:23 mriedem dansmith: can you send this queens backport to its maker https://review.openstack.org/#/c/623547/
16:59:48 dansmith aye
17:16:13 ralonsoh jaypipes, sean-k-mooney : so what's the plan here https://review.openstack.org/#/c/482226/48/vif_plug_ovs/tests/functional/base.py? To import from os-vif.tests.[functional|unit].base in the other projects. Am I right?
17:17:13 sean-k-mooney i think for this patch yes. i want do refactor some of the code in general in train
17:17:34 sean-k-mooney deduping that file would be on that list
17:18:15 sean-k-mooney ill try and do a review of all the open os-vif patches again today/tommorow
17:18:36 sean-k-mooney ideally we can then to a relase on monday
17:19:01 ralonsoh sean-k-mooney, ok, I'll submit a patch to move functional.base to os-vif, and import from there
17:19:06 sean-k-mooney jaypipes: does that sound ok to you?
17:19:34 sean-k-mooney ralonsoh: i dont think we need to do that in stien
17:19:44 sean-k-mooney it can wait till after we do the release.
17:20:11 ralonsoh sean-k-mooney, perfect
17:21:23 sean-k-mooney ill send a ml post tomorrow with the patches i would like to see in the final release for stien so i would more or less like to avoid more churn
17:26:34 mriedem dansmith: let me know when you're tired of stable pings but https://review.openstack.org/#/c/635072/ also
17:26:43 mriedem i'll shift to bugging others
17:28:01 openstackgerrit Sundar Nadathur proposed openstack/nova master: WIP: Add Cyborg device profile groups to spec obj. https://review.openstack.org/631243
17:28:01 openstackgerrit Sundar Nadathur proposed openstack/nova master: ksa auth conf and client for cyborg access https://review.openstack.org/631242
17:28:02 openstackgerrit Sundar Nadathur proposed openstack/nova master: WIP: Get resolved Cyborg ARQs and add PCI BDFs to VM's domain XML. https://review.openstack.org/631245
17:28:02 openstackgerrit Sundar Nadathur proposed openstack/nova master: WIP: Create and bind Cyborg ARQs. https://review.openstack.org/631244
17:28:12 dansmith makes me feel useful and like a slacker all at once
17:30:37 sean-k-mooney stephenfin: i like the direction of your sphinx docs changes in os-vif
17:30:48 sean-k-mooney stephenfin: ill try and review them tomorrow
17:30:57 stephenfin sean-k-mooney: Ta. Just need to fix the pep8 issue
17:31:26 sean-k-mooney quick question https://review.openstack.org/#/c/638053/2/tox.ini
17:31:51 sean-k-mooney do we still need to specify the interperter version or will python3 work instead of python3.6
17:33:49 sean-k-mooney i think python3 should work but i know not show why we set 2.7 explctily before
17:34:23 sean-k-mooney stephenfin: oh ^ was for you
17:35:46 sean-k-mooney i might jsut drop the change in version and add a sperate python3 functional env instead
17:36:36 stephenfin sean-k-mooney: The precedence for Python version is (a) specific environment 'basepython' version, (b) global 'basepython' value, (c) implicit value from a testenv factor (i.e. 'py27'), (d) system Python
17:37:46 sean-k-mooney stephenfin: right but the function job failed because 3.6 was not on the host it ran on so im wondering can i just set python3 and use whatever version of python 3 is available
17:37:53 stephenfin sean-k-mooney: Actually, that was the way that it was before tox 3.1. Since then, (b) and (c) are switched and you'll get a warning if they conflict
17:37:54 stephenfin sean-k-mooney: Ahh
17:38:35 stephenfin sean-k-mooney: Yeah, then yeah, 'python3' is good
17:38:46 stephenfin *Yeah, then 'python3' is good
17:39:05 sean-k-mooney ok thanks ill repspin with that :)
17:39:09 stephenfin (It'll run whatever python3 is symlinked to on the distro)
17:39:24 sean-k-mooney would you prefer if i had two envs or one
17:39:49 sean-k-mooney e.g. should i keep a functionl 2.7 env and add a functional-py3 env
17:40:10 jaypipes ralonsoh: ++ what sean-k-mooney said.
17:40:32 stephenfin sean-k-mooney: I'm happy to drop py2.7 functional tests if we still have unit tests. mriedem might have something to say as well, since he's done some work here lately, I think
17:40:51 sean-k-mooney actully i should check the pti docs and see what it say we should do for stien
17:40:52 stephenfin s/drop py2.7/switch from py2.7 to py3/
17:42:18 bauzas melwitt: hum, I guess we probably have to work on https://etherpad.openstack.org/p/nova-tc-vision-self-eval
17:42:51 melwitt yes. I've done nothing yet :( not a great timing for this one, near the end of the cycle
17:43:14 sean-k-mooney stephenfin: hehe i mean i would like to drop py2.7 but we cant do that until U

Earlier   Later