| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-03 | |||
| 18:02:27 | tssurya | mriedem: yea the prod is still in queens for ironic compute | |
| 18:02:59 | mriedem | efried: do i smell pbc results? | |
| 18:03:06 | mriedem | er, | |
| 18:03:06 | artom | cfriesen, please do | |
| 18:03:08 | mriedem | checkpoint results | |
| 18:03:16 | tssurya | efried: will let you know as soon as we post one :) we have a huge reduction in requests per min from 120K to 10K | |
| 18:03:26 | efried | mriedem: Yeah, we call it checkpoint these days. | |
| 18:03:33 | artom | mriedem, I *do* bring out the worst in you ;) | |
| 18:07:02 | openstackgerrit | Chris Dent proposed openstack/nova master: Use external placement in functional tests https://review.openstack.org/617941 | |
| 18:07:02 | openstackgerrit | Chris Dent proposed openstack/nova master: Delete the placement code https://review.openstack.org/618215 | |
| 18:40:57 | jaypipes | efried: tssurya also confirmed they're not using it for Ironic. :) | |
| 18:41:37 | jaypipes | efried: or are you just referring to *some* of those patches and not the one that could be trouble for Ironic installs? | |
| 18:42:21 | efried | jaypipes: I fixed the one we were concerned about for ironic as well. But yeah, it would be nice if we could get results from CERN playing with it live. | |
| 19:12:16 | dansmith | mriedem: questions in https://review.openstack.org/#/c/393930/4 | |
| 19:14:19 | dansmith | well, a question and a suggestive comment I guess | |
| 19:20:42 | jaypipes | jangutter: I support sean-k-mooney's suggestions about renaming VIFBase to VIF. | |
| 19:21:03 | jaypipes | jangutter: in the context of our planned changes to the 2.0 os-vif modeling. | |
| 19:22:36 | sean-k-mooney | jaypipes: at the end of the day it will have very little differnece from a code point of view but as a new person looking at it nameing is important and "base" implys meaning that we dont enforce which might confuse people | |
| 19:22:52 | jaypipes | ++ | |
| 19:23:25 | sean-k-mooney | it was never something that annoyed me enough to "fix" but if we are cleaning up things we might as well clean that up too | |
| 19:23:38 | jaypipes | right, my thoughts exactly. | |
| 19:25:06 | sean-k-mooney | that is a change that will break kuryr but again they should not have been inheriting form VIFBase anyway. we can use debtcollector to not break them untill i port over there vifs. | |
| 19:25:32 | sean-k-mooney | i wont get to it for a few weeks but i should get to it i january | |
| 19:28:32 | mriedem | dansmith: replied | |
| 19:29:33 | jaypipes | sean-k-mooney: well, again, kuryr should be pinning to a *specific* os-vif library release, so we should be safe to make these changes, along as they don't up their pinned release. same for nova, frankly. | |
| 19:32:39 | sean-k-mooney | ture but we have a kuryr ci job that will bitch since it runs against os-vif master | |
| 19:33:04 | sean-k-mooney | same as or nova job that test stuff before we merge it | |
| 19:33:39 | jaypipes | sean-k-mooney: that's fine (and works as expected, yeah?) | |
| 19:35:03 | sean-k-mooney | they are there to catch non backwards compatible changes so yes it works as expected but i just ment unless we make the change in a backward compatible way the zuul job will fail | |
| 19:36:41 | dansmith | mriedem: yeah I forgot about the distinction of the before-virt and after-virt nature of the two places we stash that stuff | |
| 19:36:48 | sean-k-mooney | e.g. if we renamed VIFBase to vif without the compaiblity code or removing the use of VIFbase in kuryer the kuryr-kubernetes-tempest-daemon-octavia would fail and stop use merging it in os-vif | |
| 19:37:30 | dansmith | mriedem: note that pulling it from an api node via instance_extra is the same number of hits to the db as just doing an query for all the virtual_interfaces for the instance presumptively, since the api is hitting the db directly | |
| 19:42:11 | openstackgerrit | David Hill proposed openstack/nova master: Add secret=true to fixed_key configuration parameter https://review.openstack.org/621684 | |
| 19:47:28 | mriedem | since john hopkins isn't around anymore, | |
| 19:47:38 | mriedem | i wonder who would care enough to unwind all of this deprecated code we have to remove it https://review.openstack.org/#/c/621684/1/nova/conf/key_manager.py | |
| 19:48:01 | mriedem | now that barbican is a required service or whatever the TC calls it | |
| 19:48:16 | mriedem | cdent: what is the latest opinion on barbican being required and co-gating? | |
| 19:48:24 | mriedem | base devstack still doesn't install barbican as far as i know | |
| 19:48:55 | mriedem | although not sure we'd need barbican anyway since i think in the gate we'd just use a fake key manager from castellan | |
| 19:49:32 | cdent | fungi is your guy on that stuff, as I recall, but also the new styleeee seems to be "depend on castellan instead" | |
| 19:49:48 | mriedem | right b/c barbican is just a castellan backend | |
| 19:50:33 | mriedem | i also see that nova registers but doesn't doc the castellan options in our config option docs build, yay | |
| 19:50:34 | cdent | the base services stuff, to my eye, stalled | |
| 19:50:38 | fungi | _if_ you need users to provide data to the keystore though, recommend barbican rather than reimplementing bits of it badly just to avoid dependence on it | |
| 19:51:02 | mriedem | i just want to burn code that's been deprecated in nova for years now | |
| 19:51:14 | mriedem | but it was all added by john hopkins people that are no longer around | |
| 19:51:41 | cdent | https://media.giphy.com/media/wKiZeZVXS5MQg/giphy.gif | |
| 19:52:00 | mriedem | moonrise kingdom? | |
| 19:52:06 | fungi | addams family ii | |
| 19:52:09 | sean-k-mooney | im not familar with that option when it refers to key manager is it refing to keyparis or to something else | |
| 19:52:10 | mriedem | oh heh | |
| 19:52:18 | cdent | yeah | |
| 19:52:40 | fungi | sean-k-mooney: secret data store | |
| 19:53:30 | fungi | oh, you mean in the nova key_manager config | |
| 19:54:07 | sean-k-mooney | ya. oh like the secrets you would normally store in a tpm or secure enclave | |
| 19:55:03 | sean-k-mooney | cdent: makes me think of fallout or a furnace/oven | |
| 19:55:11 | mriedem | i guess we do have the castellan opts in our [key_manager] group https://docs.openstack.org/nova/latest/configuration/config.html#key-manager | |
| 19:55:16 | mriedem | with barbican as the default backend | |
| 19:55:55 | cdent | good luck everyone | |
| 19:56:49 | mriedem | and we use that fixed_key in devstack yet https://github.com/openstack-dev/devstack/blob/78a564bb0304b6f930e1491e7e116a0a0f6d9ab6/stack.sh#L1271 | |
| 19:56:52 | mriedem | https://review.openstack.org/#/c/439855/ | |
| 19:57:06 | fungi | sean-k-mooney: yes, makes me wonder if apple devs were playing fallout ii at the time they came up with the term for their hsm | |
| 19:58:32 | mriedem | ah yes https://github.com/openstack-dev/devstack/blob/a61b4704871e7b0ae88a50932576e961eca615e4/lib/nova#L430 | |
| 19:58:43 | fungi | mriedem: any reason we can't just add barbican to default devstack configuration? it doesn't have to be in the base services list | |
| 19:59:11 | mriedem | anecdotal comments from when i asked sdague about that years ago was that barbican broke their api frequently | |
| 19:59:28 | fungi | i'm assuming the nova feature in question is not part of any required capability for interop | |
| 19:59:34 | mriedem | so making that a required thing in the integrated gate was not something he wanted to do | |
| 19:59:46 | mriedem | fungi: no, just would like to remove a bunch of old deprecated code in nova | |
| 20:00:01 | sean-k-mooney | maybe the iniset macros does someith im not aware of but should that not set it to the lital string nova.keymgr.conf_key_mgr.ConfKeyManager | |
| 20:00:09 | mriedem | i also care very little about this issue atm - it's just something i think about every time i have to look at any of that code | |
| 20:00:23 | mriedem | sean-k-mooney: it does | |
| 20:00:46 | fungi | seems to me like telling people to deploy barbican if they want users to be able to upload key material is fine | |
| 20:00:49 | mriedem | http://logs.openstack.org/77/615677/13/check/tempest-full/f0fd07c/controller/logs/etc/nova/nova_conf.txt.gz | |
| 20:01:10 | mriedem | cinder is in the same boat here carrying the same debt | |
| 20:01:24 | mriedem | http://logs.openstack.org/77/615677/13/check/tempest-full/f0fd07c/controller/logs/etc/cinder/cinder_conf.txt.gz | |
| 20:02:19 | sean-k-mooney | ok was that intentional. looking at https://docs.openstack.org/nova/latest/configuration/config.html#key_manager.backend it looks wrong to me | |
| 20:02:32 | fungi | https://governance.openstack.org/tc/reference/base-services.html#current-list-of-base-services does specifically state "...any user interaction with secret material should be left to a dedicated API instead (preferably as provided by Barbican)." | |
| 20:03:31 | openstackgerrit | Adrian Chiris proposed openstack/nova master: Add free for claimed, allocated devices https://review.openstack.org/616120 | |
| 20:03:32 | openstackgerrit | Adrian Chiris proposed openstack/nova master: Allow per-port modification of vnic_type and profile https://review.openstack.org/607365 | |
| 20:03:32 | openstackgerrit | Adrian Chiris proposed openstack/nova master: Add get_instance_pci_request_from_vif https://review.openstack.org/619929 | |
| 20:03:33 | openstackgerrit | Adrian Chiris proposed openstack/nova master: SR-IOV Live migration indirect port support https://review.openstack.org/620115 | |
| 20:04:27 | fungi | the only thing which has really slowed me from proposing a barbican-specific entry there similar to keystone's is identifying services exposing features which are better served by barbican's api (as opposed to just backend use via castellan) | |
| 20:08:28 | sean-k-mooney | hum it looks like https://github.com/openstack-dev/devstack/commit/a5b72b053efec9af8a57c59b35f96142e4f38433 set that value 4 year ago but that looks like its wrong to me sice both nova and nueton says the backend can be "valut" or "barbican" | |
| 20:08:58 | sean-k-mooney | actuly a little under 3 but same difference | |
| 20:09:01 | mriedem | you're missing this https://github.com/openstack/castellan/blob/6336a59b9b5f373efa653e6fcce8ea1c964fdbae/castellan/key_manager/migration.py#L30 | |
| 20:09:09 | mriedem | there is a special hack in castellan for nova and cinder | |
| 20:09:16 | mriedem | which have their own no-op in-tree key managers for testing | |
| 20:09:37 | mriedem | ConfKeyManager is not documented since it's not something we want people using in prod | |
| 20:10:15 | mriedem | the backend itself is open-ended https://github.com/openstack/castellan/blob/master/castellan/key_manager/__init__.py#L25 | |
| 20:10:30 | sean-k-mooney | oh ok... it would be nice to atleast document that in hte nova code but maybe i missed it | |
| 20:15:04 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Create BDMs/tags in cell with instance when over-quota https://review.openstack.org/621692 | |
| 20:18:40 | mnaser | can i ask what's the state of https://review.openstack.org/#/c/554218 or https://review.openstack.org/#/c/554212 ? -- i have a use-case that might need pre-emptible instances so im curious about those | |
| 20:18:46 | mriedem | this ^ is a pretty straight-forward regression fix since pike | |
| 20:23:18 | sean-k-mooney | mnaser: anyway i had taught we said we woudl try and complete those in denver but honestly i dont know | |
| 20:23:57 | tssurya | mnaser, sean-k-mooney: yea we had discussed it in denver ptg, at this point I think it needs more core reviews | |
| 20:24:18 | sean-k-mooney | tssurya: and a couple of pep8 fixes :) | |
| 20:24:30 | mnaser | sean-k-mooney, tssurya: i can help in contributing the code needed and cleaning it up | |
| 20:24:48 | tssurya | sean-k-mooney: heh right | |
| 20:24:49 | mnaser | both add a lot of flexibility in terms of being able to do more | |
| 20:25:22 | sean-k-mooney | mnaser: yes when i was at intel i was also looking at other ways of using the pending state. | |