| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-19 | |||
| 14:35:18 | efried | cdent We're mostly talking about the 'new neutron port binding api' spec | |
| 14:35:23 | dansmith | that means the scheduler can't pick a host with suitable bandwidth for the migration though right? | |
| 14:35:24 | efried | cdent but bleeding into the bw rp one. | |
| 14:35:33 | sean-k-mooney | cdent: cool ill re read. if the neutron folks are oke with it ill update it shortly | |
| 14:36:00 | dansmith | or for a new build for that matter | |
| 14:36:02 | cdent | efried: that one is somewhere in the my “next” queue | |
| 14:36:04 | sean-k-mooney | efried: yes these two are tightly coupled in some respects | |
| 14:36:13 | efried | dansmith Can pick it, but wouldn't allocate it. | |
| 14:36:37 | dansmith | efried: == resource race == fail | |
| 14:36:50 | sean-k-mooney | dansmith: it can do a first pass without knowing the network backend and then we do the port bind in the conducto before casting to the compute | |
| 14:36:54 | mriedem | gibi: this is very simple if you can take a look https://review.openstack.org/#/c/512626/ | |
| 14:37:00 | efried | How do we get around a race *somewhere*? | |
| 14:37:08 | gibi | mriedem: looking... | |
| 14:37:08 | sean-k-mooney | dansmith: we might be able to do it in the schduler but have not look to see where yet | |
| 14:37:27 | dansmith | sean-k-mooney: efried: that gets us a two-phase commit of allocations and we have to rollback from those both and then reschedule.. avoiding that is the whole point of doing this in the scheduler | |
| 14:37:58 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Migrate from 'ip' commands to 'pyroute2' https://review.openstack.org/484386 | |
| 14:38:00 | efried | Yeah, definitely don't disagree with that. But we're also doing a "bind early, fail early" thing with the port. | |
| 14:38:02 | sean-k-mooney | dansmith: well thats one of the reasons i want nova to do the claim instead of neutron | |
| 14:38:49 | efried | So either we [bind early, allocate late] and have the race there, or [bind early & allocate network stuff early, allocate non-network stuff late] and have the race there. | |
| 14:39:08 | efried | I guess the former is cleaner. | |
| 14:39:13 | dansmith | um | |
| 14:39:13 | mriedem | tbc, the 'use neutron port binding API' spec is really not the same thing here, has nothing to do with allocations - it's about using port binding during live migration | |
| 14:39:19 | mriedem | we should have probably renamed that spec title :) | |
| 14:39:27 | mriedem | the bw provider one is the thing talking about claims | |
| 14:39:41 | mriedem | the call i setup in 20 minutes is about the live migration spec, not the bw provider one | |
| 14:39:46 | dansmith | yeah, I'm clearly missing some context from the bw one since I'm thinking about the live migration one | |
| 14:39:57 | mriedem | yes people are blurring them | |
| 14:40:02 | efried | mriedem Regardless, there needs to be a stake in the ground about who's the consumer of the nw resource, who does the allocation, and when. | |
| 14:40:03 | dansmith | effing people | |
| 14:40:26 | mriedem | efried: that doesn't have to be decided for https://review.openstack.org/#/c/375580/ | |
| 14:40:28 | efried | Unless the vif isn't a resource.... | |
| 14:40:30 | mriedem | the call in 20 minutes is for ^ | |
| 14:40:47 | mriedem | because i can actually see that getting done in queens | |
| 14:40:53 | mriedem | i can't see bw provider getting done in queens | |
| 14:41:04 | mriedem | it's dependent on at least 3 other things and we're unclear on the design still | |
| 14:43:22 | sean-k-mooney | mriedem: idealy though we would use the same workflow for spawning a new instance as we do for moving an instance | |
| 14:43:39 | sean-k-mooney | mriedem: interms of when and where we claim resouces | |
| 14:44:33 | mriedem | i don't disagree, but today we aren't claiming anything in placement for networking | |
| 14:44:57 | sean-k-mooney | mriedem: how did you sent that invite by the way? it went straight into my calander and i dont see the email at all | |
| 14:46:19 | sean-k-mooney | mriedem: well we are for routed networks correct? | |
| 14:46:27 | sean-k-mooney | mriedem: or is that done by neutron? | |
| 14:46:59 | mriedem | sean-k-mooney: nova doesn't do anything for routed networks yet | |
| 14:47:09 | sean-k-mooney | ok that must be in nova so. | |
| 14:47:12 | mriedem | that was related to johnthetubaguy's prep for network-aware scheduling thing | |
| 14:47:16 | sean-k-mooney | *neutron | |
| 14:47:22 | mriedem | neutron is doing something yes | |
| 14:48:18 | johnthetubaguy | the only bit nova does is not error when a port has no ip if its on a routed network | |
| 14:49:23 | dansmith | heh | |
| 14:49:29 | dansmith | the only thing nova does is not explode | |
| 14:49:30 | sean-k-mooney | just pinging mlavlle on the neutron channel to see if he is oke with doing the claim in the port bind. if so ill update the neutron and nova spec to reflect that | |
| 14:49:41 | dansmith | sean-k-mooney: hold up dude, | |
| 14:49:58 | dansmith | we should have a discussion, because I think we're missing something important if we do it that way | |
| 14:50:32 | sean-k-mooney | dansmith: im not going to update anything untill after the call | |
| 14:50:38 | dansmith | okay | |
| 14:50:40 | sean-k-mooney | i just want to get his initall reaction | |
| 14:51:33 | sean-k-mooney | if its a non starter from a neutron perspective that is good to know :) | |
| 14:56:02 | mriedem | again, the primary purpose of the call is about the live migration spec, not the bw provider spec, | |
| 14:56:06 | mriedem | if there is time i'm sure we can get into that | |
| 14:57:13 | sean-k-mooney | mriedem: right be we still need to decide on where to do the port bind and activate the binding for the live migration too so we can regenerate the xml if needed | |
| 14:58:08 | sean-k-mooney | mriedem: for example vhost-user socket path changes or you migrate form linux bridge to ovs | |
| 15:02:42 | mriedem | johnthetubaguy: were you going to join? | |
| 15:02:57 | johnthetubaguy | mriedem: ah, I didn't get the invite / behind on mail | |
| 15:02:57 | mriedem | https://hangouts.google.com/hangouts/_/calendar/bWF0dHJpZWQyMkBnbWFpbC5jb20.6jrqpj946jj56uo6dsuj4gnmjj | |
| 15:07:51 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: cover migration cases with functional tests https://review.openstack.org/493865 | |
| 15:20:45 | openstackgerrit | Merged openstack/nova-specs master: Add serial numbers for local disks https://review.openstack.org/511466 | |
| 15:21:05 | openstackgerrit | Takashi NATSUME proposed openstack/nova-specs master: Abort Cold Migration https://review.openstack.org/334732 | |
| 15:21:40 | openstackgerrit | Takashi NATSUME proposed openstack/nova-specs master: Abort Cold Migration https://review.openstack.org/334732 | |
| 15:24:21 | stvnoyes | Hi nova cores, There's a stale bugfix review (https://review.openstack.org/#/c/389798) that needs a core review. It's a pretty simple change (in the nova compute api) so it should hopefully be quick(?). Thanks. | |
| 15:40:35 | bauzas | graaaah, the Gerrit flickering when you open a comment makes me mad | |
| 15:42:43 | efried | bauzas If you can snap a video of that happening, send it to sdague | |
| 15:43:21 | bauzas | jaypipes: I officially hereby invoke your SQL skills and ask you if you know if SQLA can support an index of a tuple of multiple fields where one of them comes from a inherited mixin | |
| 15:43:38 | bauzas | jaypipes: context being https://review.openstack.org/#/c/507762/12 | |
| 15:44:07 | bauzas | that's where a POC would help a specs review :) | |
| 15:44:46 | dansmith | bauzas: reports are that if you set render=slow it will be better about that | |
| 15:46:00 | sdague | I apparently have never seen this thing (or noticed it) | |
| 15:46:49 | jaypipes | bauzas: you can include fields from a mixin into an index, sure. | |
| 15:48:58 | jaypipes | bauzas: added a comment (and link to an example) to the spec | |
| 15:49:38 | bauzas | jaypipes: oh fsck, deleted of course | |
| 15:49:50 | openstackgerrit | Ed Leafe proposed openstack/nova master: Remove the Pike migration code for flavor migration https://review.openstack.org/494206 | |
| 15:50:07 | bauzas | but yeah the tuple is wrong then, since we support soft-deletions for instance actions... | |
| 15:50:24 | bauzas | not sure you can really *delete* an action tho | |
| 15:52:09 | bauzas | dansmith: sorry, WDYM ? | |
| 15:52:52 | jaypipes | bauzas: the gerrit flickering annoyance. | |
| 15:53:02 | efried | bauzas Go into settings => diff preferences and set Render => Slow | |
| 15:53:07 | dansmith | bauzas: https://imgur.com/a/Oq5rw | |
| 15:53:08 | dansmith | bauzas: gerrit, diff settings, render -> slow | |
| 15:53:10 | bauzas | aaaah cool | |
| 15:53:12 | jaypipes | bauzas: go to settings, then diff prefs, then render => slow. | |
| 15:53:15 | bauzas | ta ! | |
| 15:53:21 | jaypipes | lol, three of us :) | |
| 15:53:22 | efried | I win | |
| 15:53:29 | dansmith | what? I was totally first | |
| 15:53:37 | dansmith | by six seconds | |
| 15:53:39 | bauzas | dansmith: +1 marmelade | |
| 15:53:44 | dansmith | hehe | |
| 15:54:16 | bauzas | dansmith: you should seriously consider then a checked-in luggage :p | |
| 15:54:31 | dansmith | willd o | |
| 15:54:34 | dansmith | er, will do | |
| 15:57:49 | openstackgerrit | John Griffith proposed openstack/nova-specs master: Add multiattach support to Nova https://review.openstack.org/499777 | |
| 16:16:08 | bauzas | stephenfin: honestly, if all is about code refactoring for Queens, I don't think it needs a spec *unless two points* | |