| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-12-03 | |||
| 17:36:54 | dansmith | artom: okay, in the upstream channel I'm really only asking about things that matter to upstream :) | |
| 17:37:09 | sean-k-mooney | jaypipes: is there a responce to the os-vif one or is it another one? | |
| 17:37:14 | dansmith | just wondering if there will be meat to review this year or not, as it doesn't seem like there's much up right now | |
| 17:37:29 | artom | dansmith, I know, but was giving you context | |
| 17:37:55 | dansmith | alright | |
| 17:38:03 | artom | dansmith, maybe not a full 15 oz steak, but like, a chicken cutlet? | |
| 17:39:42 | jaypipes | sean-k-mooney: no, I mean you are asking for kuryr-kubernetes folks to respond to your questions in your ML thread and I'm saying I'll wait to hear from them until I weigh in. | |
| 17:39:57 | sean-k-mooney | jaypipes: ah ok | |
| 17:40:54 | sean-k-mooney | ya ill proably jump into there irc tommorw and flag it to them | |
| 17:54:08 | mriedem | so we're not trying hard to get numa-aware live migration done in stein upstream, got it | |
| 17:58:12 | efried | jaypipes: I redid the three patches starting at https://review.openstack.org/#/c/620711/ per your comments. Gate failures are spurious, rechecking. tssurya confirmed they've been running with this code in their env and it's performing as expected. | |
| 17:58:19 | sean-k-mooney | mriedem: it will likely be hard to get it runway ready and reviewd before jan 10, it likely can be dont before upstream feature freeze but it likely will be non trival to review | |
| 17:58:19 | openstack | bug 1806064 in OpenStack Compute (nova) rocky "Volume remains in attaching/reserved status, if the instance is deleted after TooManyInstances exception in nova-conductor" [Medium,Triaged] https://launchpad.net/bugs/1806064 | |
| 17:58:19 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add functional regression test for bug 1806064 https://review.openstack.org/621664 | |
| 17:58:20 | mriedem | s10: melwitt: ^ | |
| 17:58:45 | cfriesen | artom: we'll happily try to break any patches you come up with. :) | |
| 17:58:54 | mriedem | sean-k-mooney: feature freeze is not jan 10 | |
| 17:59:29 | mriedem | FF is march 7 | |
| 18:00:29 | sean-k-mooney | oh i taught it was mid febuary but i guess im mixing that up with non-client libs | |
| 18:01:09 | tssurya | efried: we will try to put up a blog post soon with the plots and perf-improvement | |
| 18:01:35 | efried | tssurya: That would be awesome, my boss was just asking me if such a thing was available. | |
| 18:01:41 | mriedem | tssurya: are there plans to test that out with the ironic computes? | |
| 18:01:45 | mriedem | so those can be upgraded? | |
| 18:02:08 | mriedem | you had to downgrade ironic computes to queens right? | |
| 18:02:14 | tssurya | mriedem: yea we are working on the ironic driver and for sure will have it upgraded asap | |
| 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 | artom | cfriesen, please do | |
| 18:03:06 | mriedem | er, | |
| 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: Delete the placement code https://review.openstack.org/618215 | |
| 18:07:02 | openstackgerrit | Chris Dent proposed openstack/nova master: Use external placement in functional tests https://review.openstack.org/617941 | |
| 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 | |