| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-19 | |||
| 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 | mriedem | https://hangouts.google.com/hangouts/_/calendar/bWF0dHJpZWQyMkBnbWFpbC5jb20.6jrqpj946jj56uo6dsuj4gnmjj | |
| 15:02:57 | johnthetubaguy | mriedem: ah, I didn't get the invite / behind on mail | |
| 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* | |
| 16:16:19 | bauzas | #1 we don't use a new framework | |
| 16:16:38 | bauzas | #2 we don't change the consumed interface we have for all our customers | |
| 16:16:57 | stephenfin | You mean *assuming* those things? | |
| 16:17:01 | stephenfin | As opposed to unless | |
| 16:17:05 | bauzas | in other words, if we still have a backwards-compatible behaviour | |
| 16:17:20 | stephenfin | The CLI won't change from a users perspective | |
| 16:17:24 | bauzas | stephenfin: my point is that you said there are multiple issues | |
| 16:17:26 | stephenfin | All that will change is return code and docs | |
| 16:17:38 | stephenfin | And the return code one could wait | |
| 16:17:49 | bauzas | I'd love to see what could be done without cliff and what other things need it | |
| 16:17:53 | stephenfin | We would be changing the framework, though end-users won't see this | |
| 16:18:15 | stephenfin | I'm not dropping the cliff bit - it's still the main reason for this :) | |
| 16:18:24 | openstackgerrit | Eric Fried proposed openstack/nova master: Service user token requested with no auth https://review.openstack.org/512329 | |
| 16:18:42 | stephenfin | Otherwise is just deleting some dead code but no more. cliff delivers enough tangible benefits to justify its inclusion | |
| 16:18:56 | stephenfin | and means nova is using the exact same tooling as everyone else in OpenStack | |
| 16:18:59 | stephenfin | *CLI tooling | |
| 16:19:00 | bauzas | stephenfin: what I'm saying is that we don't need a spec for something just pure internal refactoring, but I guess pulling a dependency like cliff is more than just internal refactoring | |
| 16:19:17 | bauzas | stephenfin: how do you see the implementation path ? | |
| 16:19:20 | stephenfin | Yeah, I'm not sure if it is, hence the question :) | |
| 16:19:33 | stephenfin | Pretty much what I said in the spec (I think) | |
| 16:19:38 | stephenfin | Dump all the deprecated stuff | |
| 16:19:38 | bauzas | stephenfin: fix first some issues, then use cliff for only some subcommands? | |
| 16:19:56 | bauzas | or do you plan to just change all at once ? | |
| 16:20:32 | bauzas | stephenfin: the problem is that a cliff move would be like super low priority | |
| 16:20:42 | bauzas | so I'm afraid that effort could be multi-cycle | |