| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-29 | |||
| 15:22:15 | sean-k-mooney | it just does not support mimium bandwidth guarentees | |
| 15:22:40 | gibi | sean-k-mooney: true, but as a first step we can trust the guest to only send/receive the requested bandwidth | |
| 15:22:50 | mriedem | sean-k-mooney: gibi: has anyone started a spec or etherpad for ideas or ML discussion, anything? | |
| 15:23:14 | gibi | mriedem: not from ericsson side | |
| 15:23:21 | sean-k-mooney | we had neutron or nova spec for this for pike | |
| 15:23:47 | gibi | sean-k-mooney: I think there was a neutron spec | |
| 15:24:11 | edleafe | cdent: taunted right back | |
| 15:24:12 | sean-k-mooney | ya ill see about geting a nova one created for queens and add it to the etherpad | |
| 15:24:21 | cdent | edleafe: gracias | |
| 15:24:29 | gibi | sean-k-mooney, mriedem: here is the neutron spec https://review.openstack.org/#/c/396297/ | |
| 15:25:14 | mriedem | cool thanks, i'll pass this along | |
| 15:26:29 | sean-k-mooney | mriedem: we have already landed part of this i think or atleas implemented it. what was missing on the nova side was a way to ensure we dont over subscribe which needs placemnet to do cleanly | |
| 15:27:10 | sean-k-mooney | mriedem: ya the sriov enforcement is implemented here https://review.openstack.org/#/c/401254/25 | |
| 15:28:22 | cfriesen | gibi: is it reasonable to trust the guests to do that? That seems like a private-cloud-only scenario. | |
| 15:28:53 | sean-k-mooney | cfriesen: we dont have to turst them in all cases | |
| 15:29:12 | sean-k-mooney | with sriov the hardwer can enforce the minium bandwith gureentee | |
| 15:29:46 | sean-k-mooney | with vpp we may be able to do that in software and we could also extend ovs in the future to do it but that is a lot more work | |
| 15:30:11 | gibi | cfriesen: this is a temporary solution until OVS can be used to actually limit the bandwidth | |
| 15:30:47 | gibi | cfriesen: but you are correct that this is for private cloud only | |
| 15:31:33 | cfriesen | sean-k-mooney: gibi: we'd probably make use of the SRIOV case | |
| 15:32:43 | sean-k-mooney | for the sriov case the hardware will enforce the minimum bandwidth. provided we dont oversubscribe. eg. create 11 vf with 1G minium bandwith on a 10G nice | |
| 15:39:15 | openstackgerrit | Lucian Petrut proposed openstack/nova master: [wip] Fix nova assisted volume snapshots https://review.openstack.org/498845 | |
| 15:44:16 | cdent | edleafe: back at ya | |
| 15:46:22 | edleafe | cdent: gee thanks! | |
| 15:46:44 | cdent | it’s a pleasure collaborating with you sir | |
| 15:46:48 | mriedem | lpetrut: mostly right, but some comments inline | |
| 15:46:59 | edleafe | cdent: wish I could say the same! :-P | |
| 15:47:09 | cdent | \o/ | |
| 15:48:46 | lpetrut_ | mriedem: great, thanks for the quick review | |
| 15:49:57 | lpetrut_ | mriedem: about the context manager: didn't use that so that the targeted cell remains set | |
| 15:51:32 | mriedem | oh hrm | |
| 15:51:37 | mriedem | lpetrut: yeah good point | |
| 15:51:47 | mriedem | maybe leave a comment in there then, in the code i mean | |
| 15:51:59 | lpetrut | sure | |
| 16:02:32 | openstackgerrit | Elod Illes proposed openstack/nova master: Functional test: evacuate with no compute https://review.openstack.org/498482 | |
| 16:03:08 | mriedem | #success gibi is now on the nova-core team | |
| 16:03:09 | openstackstatus | mriedem: Added success to Success page | |
| 16:03:23 | mriedem | i've successfully added success to the success page | |
| 16:03:48 | melwitt | \o/ | |
| 16:04:07 | ssmith | mriedem: Changed that one line of code and now get this on a locked instance: "Instance a29d1e77-5191-4629-a913-ae98ed22e284 is locked (HTTP 409)" | |
| 16:07:22 | ssmith | No "Locked" indicator on info of cli show so we have to remember if we get that message it's likely locked. Too bad, this is a great feature in AWS which is called "Termination Protection" | |
| 16:10:49 | mriedem | ssmith: nova also has that flag via the ec2api :) | |
| 16:10:54 | mriedem | disable_terminate i think it's called | |
| 16:11:33 | mriedem | ssmith: which cli doesn't show if it's locked or not? | |
| 16:11:50 | gibi | Thank you all of you support helping me becoming a nova-core. \o/ | |
| 16:11:53 | ssmith | opentack server show | |
| 16:12:23 | mriedem | ssmith: use microversion 2.9 | |
| 16:12:26 | mriedem | or greater | |
| 16:12:45 | mriedem | i dont know if the osc cli will print it though | |
| 16:12:56 | mriedem | but the locked field comes back in the GET /servers/id response in 2.9+ | |
| 16:13:00 | ssmith | nova show [server] does show locked or now | |
| 16:13:18 | mriedem | yeah, because nova cli negotiates for the latest microversion understood between the client and the server | |
| 16:13:22 | mriedem | by default | |
| 16:13:28 | mriedem | osc doesn't | |
| 16:13:53 | mriedem | ssmith: when you say, "Changed that one line of code and now get this on a locked instance: "Instance a29d1e77-5191-4629-a913-ae98ed22e284 is locked (HTTP 409)"" - you mean when you tried to delete the instance, right? | |
| 16:15:01 | ssmith | Yes, tried to delete. Get "Error: Unable to delete instance" in the UI and 409 on the cli | |
| 16:15:26 | mriedem | ssmith: yeah, so we'd need a change proposed on master that uses a new policy rule for this | |
| 16:15:29 | mriedem | rather than something in nova.conf | |
| 16:15:59 | ssmith | That would be better | |
| 16:15:59 | mriedem | ssmith: if this isn't something you actually want to work on, then you could propose a backlog spec and someone else could pick itup | |
| 16:16:15 | mriedem | https://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html | |
| 16:16:29 | ssmith | OK | |
| 16:17:02 | ssmith | And just to confirm no way to get the lock status to show in "openstack server show"? | |
| 16:17:28 | mriedem | ssmith: there is an option with the osc cli to specify a microversion | |
| 16:17:31 | mriedem | so i'd try that first | |
| 16:18:11 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Add contents pages https://review.openstack.org/498820 | |
| 16:18:11 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Rename cellsv2_layout -> cellsv2-layout https://review.openstack.org/498821 | |
| 16:18:12 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Add configuration index page https://review.openstack.org/498818 | |
| 16:18:12 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Cleanup of existing index pages https://review.openstack.org/498819 | |
| 16:18:13 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Add user index page https://review.openstack.org/498817 | |
| 16:19:11 | mriedem | of course i can't search for microversions in just the osc docs https://docs.openstack.org/python-openstackclient/latest/search.html | |
| 16:19:17 | mriedem | since the docs migration to use the new sphinx theme | |
| 16:19:18 | mriedem | RAR | |
| 16:19:37 | mriedem | ssmith: openstack help compute or something should give you the optoins | |
| 16:19:48 | mriedem | it's --compute-api-version or something | |
| 16:22:22 | mriedem | ssmith: --os-compute-api-version i think | |
| 16:22:32 | ssmith | ok | |
| 16:23:08 | mriedem | i don't know if the osc cli whitelists the fields it shows though | |
| 16:23:41 | ssmith | Compute API version, default=2.1 | |
| 16:23:41 | ssmith | os-compute-api-version <compute-api-version> | |
| 16:24:07 | mriedem | yeah, so specify 2.9 | |
| 16:25:04 | ssmith | openstack server show a29d1e77-5191-4629-a913-ae98ed22e284 --os-compute-api-version 2.9 WORKED | |
| 16:25:16 | mriedem | cool | |
| 16:25:41 | ssmith | Any way to permanently set the version? | |
| 16:25:52 | mriedem | env var | |
| 16:25:59 | mriedem | OS_COMPUTE_API_VERSION=2.9 i think | |
| 16:28:39 | ssmith | Did a "export OS_COMPUTE_API_VERSION=2.9" which worked | |
| 16:31:07 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Cleanup allocations on invalid dest node during live migration https://review.openstack.org/498861 | |
| 16:31:34 | mriedem | dansmith: cdent: gibi: here is the fix for the live migration pre-check error bug ^ | |
| 16:33:16 | efried | sean-k-mooney that first bp was https://blueprints.launchpad.net/nova/+spec/pci-by-device-id whose spec (https://review.openstack.org/497965) has some good discussion started. | |
| 16:34:16 | efried | jaypipes and I talked about it yesterday a bit and he encouraged me to move some of the main themes over to the other one stephenfin mentioned - https://blueprints.launchpad.net/nova/+spec/devices-as-resources - whose spec seed (not yet started) is here: https://review.openstack.org/497978 | |
| 16:34:27 | efried | ...and to start an etherpad for same topic for the PTG. | |
| 16:37:14 | openstackgerrit | Lucian Petrut proposed openstack/nova master: Fix nova assisted volume snapshots https://review.openstack.org/498845 | |
| 16:37:36 | openstackgerrit | Lajos Katona proposed openstack/nova master: WIP: Test server movings with custom resources https://review.openstack.org/497399 | |
| 16:41:27 | dansmith | mriedem: so, my feeling as we neared the end of pike was that we were really not doing ourselves any favors by trying to put the allocation stuff into the existing RT calls since we need to do different things and need some context from the compute manager to do the right thing | |
| 16:41:43 | dansmith | which is why we do some silly stuff in RT like looking at if prefix == 'old_' to do certain things | |
| 16:42:13 | dansmith | mriedem: for this migration uuid thing, I kinda want to add these new paths to compute manager itself, so at least we can delete RT eventually without needing to move things out of it | |
| 16:42:18 | dansmith | does that sound legit? | |
| 16:42:38 | dansmith | it might mean moving some of our existing allocation handling back out of RT as well and just clearly marking which bits are legacy pike behavior and not | |
| 16:46:00 | cdent | dansmith: I can only speak for myself, but I think that’s totally legit | |