| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-29 | |||
| 15:01:47 | edleafe | but there's no point if we're gonna be changing the interface to use objects | |
| 15:02:24 | mriedem | plus i couldn't backport this, and we need to backport this fix... | |
| 15:02:26 | mriedem | TODO in the code it is | |
| 15:03:24 | beagles | sean-k-mooney, thanks for the info btw! | |
| 15:03:25 | edleafe | mriedem: you mean you don't have any reference to the compute node in the migration? | |
| 15:03:27 | sean-k-mooney | mriedem: well for now you would have to do a condtional check to see if the uuid is present in the dictionary and look it up if not | |
| 15:03:39 | mriedem | edleafe: not when we're still in the conductor task | |
| 15:03:45 | mriedem | i have the dict returned from select_destinations | |
| 15:03:55 | mriedem | which has the host/nodename, which i can use to lookup the ComputeNode to get the UUID | |
| 15:03:56 | sean-k-mooney | beagles: no worries i was off since thursday so just go back | |
| 15:03:57 | mriedem | it's just a hassle | |
| 15:04:05 | artom | claudiub|2, fips have always been associated to ports IIRC | |
| 15:04:19 | edleafe | mriedem: I see | |
| 15:04:22 | mriedem | sean-k-mooney: i'd rather not write in dead code | |
| 15:05:13 | sean-k-mooney | mriedem: agreed but it may be needed for the backport. if we go to ovo defintions and and a object based interfaces then we can do it correctly in that version for queens on | |
| 15:05:48 | claudiub|2 | artom: yeah, you're right. anyways. will let you know what i'll find out | |
| 15:06:32 | artom | claudiub|2, sure, thanks | |
| 15:06:36 | cdent | edleafe: i lied, apparently i had something to say now | |
| 15:07:32 | edleafe | cdent: typical | |
| 15:08:05 | mriedem | sean-k-mooney: i'm just going to lookup the compute node using the host and node strings that i already have | |
| 15:08:07 | mriedem | old school | |
| 15:08:18 | mriedem | we can clean it up in queens with a uuid we get back later if that happens | |
| 15:08:20 | mriedem | hence the TODO | |
| 15:08:53 | cdent | edleafe: well you know, I was taunted, I couldn’t help myself, I’m an easy target for bait | |
| 15:11:25 | sean-k-mooney | speaking of ptg does anyone have the link to nova etherpads? | |
| 15:12:00 | mriedem | sean-k-mooney: https://etherpad.openstack.org/p/nova-ptg-queens | |
| 15:12:15 | sean-k-mooney | mriedem: thanks :) | |
| 15:12:42 | sean-k-mooney | i just got approval at the weekend to travel so not i need to book all the things | |
| 15:13:08 | mriedem | sean-k-mooney: and start coming up with 10 different scheduler filters you want to talk about | |
| 15:13:10 | mriedem | like in ATL | |
| 15:14:22 | sean-k-mooney | haha well perhaps. honestly alot of what i want to talk about on that front will hopefully be covered in the existing scheduler and placement sessiosn | |
| 15:18:58 | sean-k-mooney | that said some topics i want to ensure we can model with placement and traists are, verifed boot(not the same as trusted boot), fpgas for tenants, power management of guests, and bandwith based scheduling(maily for sriov but maybe others in the future). | |
| 15:19:56 | mriedem | i think the huawei product team has a requirement for sriov bandwidth based scheduling | |
| 15:19:59 | mriedem | but i don't really have details yet | |
| 15:20:11 | sean-k-mooney | im also interested in the pci overhal topics and live migration both across vif types and with sriov | |
| 15:20:47 | sean-k-mooney | mriedem: cool we started working on that last year i think rodolfo had some patches up at one point | |
| 15:21:08 | sean-k-mooney | we should be able to model that with nested resource providers. | |
| 15:21:13 | gibi | sean-k-mooney, mriedem: ericsson also interested in the bandwith based scheduling, both for sriov and for ovs port as well | |
| 15:21:25 | sean-k-mooney | each pf would have a pool of bandwidth that could be consumed by the vf | |
| 15:21:45 | sean-k-mooney | gibi: ovs does not support enforcing the bandwidth | |
| 15:21:58 | sean-k-mooney | actully it has bandwidth limits | |
| 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 | 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 | |