| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-27 | |||
| 17:06:30 | efried | jaypipes: I guess it has to look at the flavor to figure out that the BW should be split up 200 for one and 300 for the other? | |
| 17:09:39 | efried | dansmith: I would have totally seen through that. | |
| 17:10:59 | mriedem | there is a 1 week period right? | |
| 17:11:10 | mriedem | because efried has been nit pickin the shit out of my patches lately | |
| 17:11:37 | efried | mriedem: You like the abuse. | |
| 17:11:53 | mriedem | that reminds me, | |
| 17:11:53 | efried | mriedem: I'm nitpicking your patches so dansmith will +1 me. | |
| 17:11:55 | mriedem | you bastard, | |
| 17:12:00 | mriedem | i have to switch back to KSA | |
| 17:12:16 | efried | Well, we should be getting rid of neutronclient eventually anyway. | |
| 17:12:21 | mriedem | ha | |
| 17:12:22 | efried | and using raw ksa. | |
| 17:12:28 | mriedem | i will be dead and buried before that happens | |
| 17:12:29 | efried | like we're doing with ironic | |
| 17:12:37 | cfriesen | efried: why does placement combine the two requests? | |
| 17:12:41 | efried | But you don't have to do that. You can catch exceptions for error paths instead. | |
| 17:13:02 | mriedem | efried: i'd rather just say don't raise errors and check the response status code | |
| 17:13:19 | efried | mriedem: You could shim the neutronclient... | |
| 17:13:25 | efried | kidding | |
| 17:13:59 | efried | cfriesen: This is code not yet written. But if nothing else, it's because (I think) the syntax of the response has a dict keyed by resource class. So there would be no way to split them up even if we wanted to (without some new syntax). | |
| 17:14:37 | efried | cfriesen: But you raise a good point: since it's not written yet, we could still consider new syntax in the new microversion that introduces granular. | |
| 17:14:51 | efried | cfriesen: But that spec is already approved, so sorry, too late :P | |
| 17:15:12 | jaypipes | efried: yes | |
| 17:15:46 | mriedem | anyone know what is up with this sriov bond thing https://review.openstack.org/#/c/463526/ ? | |
| 17:15:52 | mriedem | sahid might but he's gone now | |
| 17:17:10 | openstackgerrit | Merged openstack/nova-specs master: Few correction in the server filter/sort spec https://review.openstack.org/527019 | |
| 17:17:18 | mriedem | dansmith: on the volume-backed rebuild + new image spec, i think i want to just say, add an api to cinder to re-image the volume and once that is in place, nova will use it | |
| 17:17:30 | mriedem | because cinder also has things it needs to update about the image in the volume, i.e. some image metadata stuff | |
| 17:17:45 | dansmith | mriedem: that would certainly be the nicest way yeah | |
| 17:17:47 | mriedem | because i don't think we want to do the volume create / delete swap thing, it's too messy | |
| 17:17:57 | mriedem | quotas, types, etc | |
| 17:18:23 | dansmith | I don't think create/swap/delete would be the way anyway, | |
| 17:18:34 | dansmith | we'd just lay the image down on the volume ourselves I think, | |
| 17:18:40 | dansmith | but that's definitely a whole big thing | |
| 17:18:42 | sean-k-mooney[m] | mriedem: is this yet another attempt at this or is it carring on form the previous attempts | |
| 17:18:47 | cfriesen | efried: if you send in two granular resource requests for resources1 and resources2, wouldn't it make sense to get back a dict of {resource1:<rp>, resource2:<rp>} or similar? They could still be the same RP. | |
| 17:18:47 | mriedem | and the volume image meta would be out of date | |
| 17:18:57 | mriedem | sean-k-mooney[m]: the sriov bond spec? it's old | |
| 17:19:00 | mriedem | and looks stale/abandoned | |
| 17:20:22 | sean-k-mooney[m] | mriedem: oh that is the bound spec that wanted to use neutron config element to configure bonds. ya i hated that part of it | |
| 17:20:36 | sean-k-mooney[m] | mriedem: ya there was also https://review.openstack.org/#/c/182242/ and there are 2-3 other ones dateing back to mitaka | |
| 17:21:36 | mriedem | dansmith: ok done https://review.openstack.org/#/c/532407/ | |
| 17:21:37 | efried | gibi: In case you're in the middle, just finished review of https://review.openstack.org/#/c/502306/21 | |
| 17:22:13 | sean-k-mooney[m] | mriedem: but yes no one has touched it since december so i think https://review.openstack.org/#/c/463526/43 is abandoned. its still proposed against queens | |
| 17:23:11 | dansmith | mriedem: so, we'll need to detach the volume in order for cinder to be able to do that, which is basically equivalent to root-detach, which we already failed to do in the past.. just.. sayin' | |
| 17:23:12 | mriedem | i abandoned https://review.openstack.org/#/c/182242/ today | |
| 17:23:20 | gibi | efried: thanks, I'm currently working on an update. I will try to address your comments in that as well | |
| 17:23:55 | mriedem | dansmith: detach or disconnect from the host? | |
| 17:24:11 | mriedem | we need to at least keep the volume reserved for the instance | |
| 17:24:14 | dansmith | mriedem: can we do those separately? | |
| 17:24:16 | mriedem | yes | |
| 17:24:20 | dansmith | okay | |
| 17:24:24 | dansmith | then, disconnect I guess | |
| 17:24:30 | mriedem | it's basically shelve | |
| 17:24:34 | dansmith | as long as cinder doesn't have a fit with that internally | |
| 17:24:35 | mriedem | shelve the root volume | |
| 17:24:41 | dansmith | mriedem: ...which you can't do with bfv | |
| 17:24:44 | mriedem | cinder would only care about the attachments | |
| 17:24:45 | dansmith | well, | |
| 17:24:48 | dansmith | you can maybe, | |
| 17:25:03 | dansmith | but not without detaching the root, which I guess is your point | |
| 17:25:29 | mriedem | honestly i don't know if volume-backed shelve works | |
| 17:25:36 | mriedem | since snapshot for a volume-backed instance is different in the api | |
| 17:25:36 | dansmith | I guess the root detach thing was mostly hard because of the desire to attach it to something else in the mean time, | |
| 17:25:40 | mriedem | and the shelve snapshot happens in hte compute | |
| 17:25:42 | dansmith | which wouldn't be the same problem here | |
| 17:26:06 | dansmith | so I think that makes more sense then yeah | |
| 17:26:27 | sean-k-mooney[m] | mriedem: for volumes backed instance i would not expect you to snapshot it at all jsut keep the volume | |
| 17:26:45 | dansmith | just want to make sure we're not sending them off on a mission that, upon completion, leaves more hard nova problems we might punt on | |
| 17:26:47 | mriedem | shelve supports volume-backed instances, it just casts directly to offload | |
| 17:26:58 | mriedem | dansmith: feel free to comment on the spec | |
| 17:27:20 | sean-k-mooney[m] | mriedem: for image backed guest we have too so we can free up the space on teh compute node but for volumes there is no reason to clean it up in the backing store just to put it into an image | |
| 17:27:27 | mriedem | i just can't imagine this is all better done inside nova | |
| 17:28:02 | dansmith | mriedem: no definitely not, just thinking through it | |
| 17:28:27 | dansmith | mriedem: you know, given all the many quagmires that came from nova-cinder interaction in the recent past | |
| 17:29:56 | sean-k-mooney[m] | mriedem: dansmith shelve for a volume backed instance should be jsut, shotdown instance, detach volume and clean up host resouces for vm no? then unshelve is jsut select host to boot on, set up entworking etc and attach volume and boot form it? | |
| 17:30:10 | mriedem | yeah so for volume-backed shelve, there is no snapshot, on unshelve we just re-attach the volumes to the instance on the new host | |
| 17:30:26 | dansmith | mriedem: you're saying that works today right? | |
| 17:30:34 | mriedem | we don't detach the volume, it stays reserved so someone else can't take it while the instance is shelved | |
| 17:30:40 | mriedem | dansmith: looks like it should from the code, | |
| 17:30:44 | mriedem | would need to test it of course | |
| 17:30:48 | dansmith | it's the disconnect that is the important bit for detaching it from the current host | |
| 17:30:49 | dansmith | yeah | |
| 17:30:50 | sean-k-mooney[m] | mriedem: well i dont know if thats what happens today but i think that is what we should be doing | |
| 17:31:04 | mriedem | on shelve offload we delete the instance on the host so that does the disconnect | |
| 17:31:43 | mriedem | sean-k-mooney[m]: yes that's what happens today | |
| 17:31:58 | mriedem | we terminate connections on shelve offload, and then re-attach on unshelve | |
| 17:33:40 | kashyap | imacdonn: I'll write an e-mail to the Operators-List / Dev this week, it's better if we discuss the version stuff there. | |
| 17:34:37 | imacdonn | kashyap: OK | |
| 17:34:43 | mriedem | dansmith: left a note in https://review.openstack.org/#/c/532407/ about the order of operations so we don't forget | |
| 17:34:48 | kashyap | cfriesen: Hey, was AFK (and I will be again in 10 mins). About your question -- | |
| 17:35:08 | dansmith | mriedem: cool | |
| 17:35:37 | mriedem | same guys are pushing for volume-backed rescue https://review.openstack.org/#/c/532410/ | |
| 17:35:41 | kashyap | cfriesen: As it stands, we are allowing this one choice to alleviate the existing problem. The allowing flags for 'host-model' thing, we can work it out when we lift the restriction | |
| 17:35:42 | openstackgerrit | Merged openstack/nova-specs master: Amend the "add extra-specs to flavor" for create and update API https://review.openstack.org/554134 | |
| 17:35:48 | kashyap | cfriesen: Does that sound reasonable to you? | |
| 17:35:48 | sean-k-mooney[m] | mriedem: this is a different topic so lets not rat hole on it but if i shelve an insatce with an active multi attach volume will one of the other attachment become active. i guess you cant boot from a multi attach volume either right? | |
| 17:36:06 | mriedem | sean-k-mooney[m]: you can boot from a multiattach volume | |
| 17:36:43 | mriedem | volume attachments aren't like port bindings, there isn't an active one and an inactive one | |
| 17:36:56 | mriedem | they do have attach modes, so r/o and r/w | |