Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-03
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: Add get_instance_pci_request_from_vif https://review.openstack.org/619929
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: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.
20:25:51 sean-k-mooney mnaser: e.g. useing it as a maker to signal that i need to autoscale the cloud rather the reap instances
20:26:07 sean-k-mooney mnaser: yep that was basicaly my idea too
20:26:09 mnaser pretty much :)
20:26:11 mnaser also saving power
20:26:16 tssurya mnaser: thanks for the interest, I think that would be great! my colleague had a couple of code patches also up for review https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/enable-rebuild-for-instances-in-cell0 and https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/introduce-pending-vm-state
20:26:59 tssurya but basically he is waiting for the specs to get merged, please feel free to chip in your ideas/ help is surely appreciated
20:27:02 sean-k-mooney the idea was if you have a mixed iroic/rsd and libvirt could you could provision new libvirt nodes in a seperate admin tenant using the resocses from teh ironic/rsd nodes
20:27:33 mnaser sean-k-mooney: and that means you can have baremetal and/or ironic in the same cloud and be able to share those resources across
20:27:51 mnaser tssurya: ill try to see whats going on with the pep8 at least
20:27:59 mnaser sounds silly but set it up for success :p
20:28:28 mriedem personally i haven't looked at the latter spec, and haven't been back to the former since i ripped it up in june
20:29:05 mriedem and then no one was really talking about it anymore
20:29:13 mriedem and we already have a bunch of other stuff going on
20:29:28 mriedem so i wasn't going out of my way to look for more shit we can cram into this release while we still have other fires burning
20:29:31 mriedem but that's just me
20:29:38 sean-k-mooney mnaser: yep. we did not have time to explore it fully because of resoucign but we belived the pending state was generally useful beyond the proposed usecase
20:29:48 openstackgerrit Mohammed Naser proposed openstack/nova-specs master: Enable rebuild for instances in cell0 https://review.openstack.org/554218
20:29:54 mnaser i fixed the pep8 for all that matters
20:30:24 tssurya mnaser: thanks!
20:30:54 mnaser mriedem: do you see a more ideal/cleaner path for pre-emptible instances within nova?
20:31:09 sean-k-mooney mnaser: mriedem i think johnthetubaguy had this working out of tree last cycle i belive so it would be interesting to know what is out standing but ya i also know we have a lot of todos
20:32:26 sean-k-mooney from a parity point of view vs aws it would be nice to have. anyway my pizza is just cooked so im going to say goodnight
20:32:29 sean-k-mooney o/
20:34:05 tssurya sean-k-mooney: there was a presentation at the summit on the same: https://www.openstack.org/summit/berlin-2018/summit-schedule/events/22438/science-demonstrations-preemptible-instances-at-cern-and-bare-metal-containers-for-hpc-at-ska
20:34:05 mriedem mnaser: honestly i'm not at all up to date on what's being proposed anymore
20:34:20 mriedem something something build failure -> notification loop -> rebuild from cell0
20:34:44 mnaser mriedem: yeah that idea seems to be around having an option where nova leaves thing in PENDING instead of ERROR when NoValidHost
20:35:03 mnaser and then $some_service would do things and either request rebuild or reset state to error
20:42:50 dansmith mnaser: yep that's what we discussed in dublin
20:43:04 dansmith I too haven't circled back to it because progress seems to be very infrequent and it's hard to maintain context on it
20:43:46 mnaser yeah i can imagine losing context over time with a lot of stuff going on can be hard :x
20:43:55 mnaser i just mostly sync'd up through a bunch of reading and talks
22:17:43 mriedem dansmith: thanks, lots of good comments in there https://review.openstack.org/#/c/616037/
22:25:53 dansmith mriedem: cool, I'll try to get to the rest of it soonish
22:58:57 openstackgerrit Surya Seetharaman proposed openstack/nova master: WIP: API microversion bump for handling-down-cell https://review.openstack.org/591657
22:58:57 openstackgerrit Surya Seetharaman proposed openstack/nova master: Add DownCellFixture https://review.openstack.org/614810
#openstack-nova - 2018-12-04
01:33:22 Zer0Byte_ hey
01:33:29 Zer0Byte_ i have a quesstion maybe someone can help me
01:34:09 Zer0Byte_ im trying to setup hw:cpu_cores in openstack queens but just create each cpu as sockets and complety ignore this value
01:34:16 Zer0Byte_ ?
01:34:16 Zer0Byte_ any idea if i have to set something else
02:01:23 openstackgerrit Jason SUN proposed openstack/os-vif master: Change openstack-dev to openstack-discuss https://review.openstack.org/621825
02:04:36 openstackgerrit zhongshengping proposed openstack/nova master: Change openstack-dev to openstack-discuss https://review.openstack.org/621827
02:11:25 izza_ can anyone help me about tensorflow..
02:23:41 openstackgerrit Merged openstack/nova master: SIGHUP n-cpu to clear provider tree cache https://review.openstack.org/615646
02:29:04 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Change openstack-dev to openstack-discuss https://review.openstack.org/621846
02:33:45 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Handle tags in _bury_in_cell0 https://review.openstack.org/621856
02:42:21 openstackgerrit Jason SUN proposed openstack/python-novaclient master: Change openstack-dev to openstack-discuss https://review.openstack.org/621869
03:22:56 izza_ hello

Earlier   Later