Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-08-29
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
16:47:13 mriedem dansmith: i think in general that's OK given we've already started duplicating some allocation-specific stuff in the compute manager outside of the RT
16:47:28 dansmith yeah
16:47:39 mriedem e.g. https://review.openstack.org/#/c/496976/
16:47:53 dansmith I just spent 45 minutes trying to detect the condition I need from down in RT and it just doesn't make any sense I think
16:48:05 mriedem it's also harder to debug
16:48:08 mriedem because of the layering
16:48:15 dansmith yeah
16:48:22 mriedem RT is always a new journey for me everytime i have to look into it
16:59:27 openstackgerrit Matt Riedemann proposed openstack/nova master: Refactor LiveMigrationTask._find_destination https://review.openstack.org/498874

Earlier   Later