| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-13 | |||
| 09:24:34 | mdbooth | mriedem: You're up early, btw. In Europe somewhere? | |
| 09:25:54 | mriedem_ | mdbooth: china | |
| 09:26:10 | mdbooth | Ah, so you've been up for a while :) | |
| 09:26:26 | mriedem_ | https://github.com/openstack/nova/blob/master/tools/test-setup.sh sets up the mysql and pg dbs for the opportunistic tests | |
| 09:26:47 | mdbooth | mriedem_: Thank you! | |
| 09:33:24 | mriedem | mdbooth: btw is rajesh aware of the spec for that metadata case sensitivity issue? | |
| 09:33:42 | mdbooth | mriedem: I was just putting a +1 on it and I noticed your comments. Reading... | |
| 09:34:02 | mdbooth | ratailor: ^^^ ? | |
| 09:35:33 | ratailor | mdbooth, I don't know about spec. | |
| 09:35:42 | gibi | mriedem: do you know if we can remove this in Stein? https://github.com/openstack/nova/blob/16f89fd093217d22530570e8277b561ea79f46ff/nova/virt/ironic/driver.py#L147-L149 | |
| 09:36:00 | mdbooth | At first glance it doesn't sound like a very good idea to me, tbh. | |
| 09:36:58 | mdbooth | So.. we've allowed users to define their own metadata for however long, and now we want to change it just because of a mysql misconfiguration? | |
| 09:36:58 | ratailor | mdbooth, let me go through the comments on patch. | |
| 09:37:01 | mriedem | gibi: maybe... | |
| 09:37:24 | mdbooth | That seems user hostile | |
| 09:37:33 | mriedem | gibi: we have a nova-status upgrade check for the ironic instance / flavor migration to resource classes | |
| 09:37:42 | ratailor | mdbooth, mriedem in that case, should I abandon the patch ? | |
| 09:37:48 | mriedem | gibi: i think we have something in the ptg etherpad about this, removing support for granular resources with ironic | |
| 09:38:39 | gibi | mriedem: Is it L25 in the etherpad? | |
| 09:39:17 | gibi | mriedem: it seems so. So I'm plugging my pain (https://review.openstack.org/#/c/583667/19/nova/tests/functional/test_servers.py@5135) into that item. thanks | |
| 09:40:04 | mdbooth | ratailor: It's up to you, but personally I'd see if the bp and spec still have weight behind them, especially given that they're user hostile and your patch shows that fixing the underlying issue isn't hard. | |
| 09:40:45 | mriedem | ratailor: mdbooth: right it's obviously still an issue, | |
| 09:40:53 | mriedem | and the spec was merged at some point, so there was a plan with code, | |
| 09:41:03 | mriedem | but then auggy was gone and sdague was gone and that whole HP team | |
| 09:41:11 | mriedem | er IBM team or whatever | |
| 09:41:46 | mriedem | gibi: yes that's the one | |
| 09:41:54 | mriedem | definitely want to remove that in stein if we can | |
| 09:41:55 | gibi | mriedem: thanks. I've added a note | |
| 09:43:03 | sean-k-mooney | mriedem: are you in china right now or is this very early for you. im guessing its quite late but just wondering what time zone your in since your not normally on at this time | |
| 09:43:37 | mriedem | sean-k-mooney: i'm in china this week | |
| 09:44:02 | mdbooth | ratailor: Looks like the proposed code wasn't merged and was abandoned. | |
| 09:45:02 | mdbooth | mriedem: Thanks for pointing that out. I'll follow up on the ML with a question around if this is still something we want to do. | |
| 09:45:33 | mdbooth | ratailor: Unless you want to do that? | |
| 09:45:55 | ratailor | mdbooth, no problem. | |
| 09:54:17 | mriedem | Kevin_Zheng: i think resize to same host might have fixed the doubled allocation issue after all - we move the "source" allocations to the migration record and the target (new flavor) allocations to the instance | |
| 09:55:21 | mriedem | Kevin_Zheng: although we'll still have allocations for both flavors against the same resource provider (compute node), so they are essentially doubled in placement... | |
| 09:57:09 | Kevin_Zheng | you mean already fixed? | |
| 09:57:46 | mriedem | well, depends on what is considered the issue; the instance, as a consumer, will only have allocations for the new_flavor during the resize, | |
| 09:58:02 | mriedem | but the resource provider (compute node) will have allocations for both the old_flavor and new_flavor, but to different consumers | |
| 09:58:10 | mriedem | so that is still an issue | |
| 09:58:38 | mriedem | if i resize from 2 VCPU to 4 VCPU, during the resize to same host, the host RP will have 6 VCPU being used, rather than 4 | |
| 09:58:46 | Kevin_Zheng | Ok got it | |
| 09:59:09 | Kevin_Zheng | But if it only has two more? | |
| 09:59:11 | sean-k-mooney | mriedem: that is only while the resize is happening correct | |
| 09:59:23 | Kevin_Zheng | Like only has 4 | |
| 09:59:39 | Kevin_Zheng | And we do 2->4 | |
| 09:59:40 | mriedem | sean-k-mooney: correct | |
| 09:59:55 | mriedem | Kevin_Zheng: if the host only has 4 VCPU inventory, the resize to same host would fail | |
| 10:00:16 | Kevin_Zheng | Yeah, but that’s our case | |
| 10:00:22 | mriedem | yeah... | |
| 10:00:25 | mriedem | alright, going to dinner | |
| 10:00:39 | Kevin_Zheng | Coll | |
| 10:00:41 | Kevin_Zheng | Cool | |
| 10:08:11 | mdbooth | ratailor: I wonder if we can get zzzeek to comment on http://lists.openstack.org/pipermail/openstack-dev/2018-August/133202.html | |
| 10:11:20 | ratailor | mdbooth, Thanks for putting it on ML nicely, I think we should get comment from him. | |
| 10:12:14 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: [placement] api-ref: Add missing aggregates example https://review.openstack.org/591332 | |
| 10:25:46 | openstackgerrit | Rajesh Tailor proposed openstack/nova master: Fix case-sensitivity for metadata keys https://review.openstack.org/504885 | |
| 10:38:03 | nalhat | Hi, Is any one aware about the filters used by nova: 'AggregateInstanceExtraSpecsFilter' while instance reservation(Blazar) | |
| 10:40:43 | nalhat | I was referring this doc: https://docs.openstack.org/blazar/latest/cli/instance-reservation.html for instance reservation by Blazar, at the time of creating an instance in nova with reservation id this filter comes in picture | |
| 11:52:07 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in test_compute_api.py (4) https://review.openstack.org/568462 | |
| 11:54:43 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: VMware: fix TypeError while get console log https://review.openstack.org/591365 | |
| 12:00:12 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in virt/test_block_device.py https://review.openstack.org/566153 | |
| 12:05:15 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in libvirt/test_driver.py (5) https://review.openstack.org/570842 | |
| 12:10:05 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in libvirt/test_driver.py (6) https://review.openstack.org/571330 | |
| 12:13:18 | openstackgerrit | Chris Dent proposed openstack/nova master: DNM: Add placement perf info gathering to end of nova-next https://review.openstack.org/591367 | |
| 12:14:46 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in libvirt/test_driver.py (7) https://review.openstack.org/571992 | |
| 12:18:32 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in libvirt/test_driver.py (8) https://review.openstack.org/571993 | |
| 12:22:25 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (3) https://review.openstack.org/574104 | |
| 13:10:14 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: [placement] api-ref: Add missing aggregates example https://review.openstack.org/591332 | |
| 13:47:46 | openstackgerrit | Chris Dent proposed openstack/nova master: DNM: Add placement perf info gathering to end of nova-next https://review.openstack.org/591367 | |
| 13:50:22 | efried | Scheduler meeting in 10 minutes in #openstack-meeting-alt | |
| 14:30:38 | dansmith | sahid: we wanted to make sure you saw this: https://review.openstack.org/#/c/591275/ | |
| 14:30:54 | dansmith | sahid: and that the rationale was clear, because we discussed mostly on irc | |
| 14:31:28 | dansmith | basically, I think that doing that in the libvirt driver will always be racy because of where the plug happens, | |
| 14:32:03 | dansmith | but since mriedem added it generically in the compute manager (where it can be done properly) it has the same effect you were going for | |
| 14:32:22 | dansmith | and, the two conflict of course because the wait in compute manager will "eat" the notification so that the libvirt wait will never see it | |
| 14:33:13 | dansmith | sahid: I also wonder if the race we identified is why you were seeing it not always work sometimes | |
| 14:33:30 | dansmith | the person that reported it on pike was always seeing it fail to win the race and thus never increase the speed limit | |
| 14:33:40 | gibi | tetsuro: would you mind if I rebase you report client 1.29 patches? | |
| 14:34:10 | gibi | tetsuro: I would like to see if 1.28 and 1.29 are still compatible codewise before I move forward with the split | |
| 14:34:14 | sahid | dansmith: initially i proposed to continue live-migration is a timeout occurs, since we know that some network issues might happen wich does not necessary mean the live-migration is failling | |
| 14:34:28 | tetsuro | gibi: no I don't mind at all. thanks! | |
| 14:35:00 | dansmith | sahid: right, which I'm not okay with, but I wonder if the "network issues" you saw were actually just because your approach was racy | |
| 14:35:33 | dansmith | sahid: here's the patch that added it to compute manager: https://review.openstack.org/#/c/558001/10/nova/compute/manager.py | |
| 14:35:53 | dansmith | sahid: which starts the wait *before* the pre-live-on-dest call runs which actually does the plug, so it's not racy | |
| 14:36:33 | dansmith | and you can see, that patch will consume the notification so that your wait in libvirt would never see it | |
| 14:36:52 | sean-k-mooney | dansmith: sahid well reducing the live migration bandwith was really the equvalent of a random sleep(x) as it was never guarneteed to be enough as even with the minium migration bandwith i could still complete before the netwroking was set up | |
| 14:37:34 | dansmith | sean-k-mooney: yeah I said that several times on the initial review :) | |
| 14:39:22 | dansmith | the assertion was made that we could only do it where he had it because of when/where the plug happens, | |
| 14:39:32 | dansmith | and that slowing the migration was the only way to catch it first, | |
| 14:39:38 | dansmith | but that clearly wasn't correct | |
| 14:39:57 | dansmith | so matt's version in compute manager does the full wait before we even start, which is definitely better | |
| 14:40:44 | sahid | how that is supposed to work? linux bridge agent is configuring the network only when it see the new tap device created | |
| 14:41:17 | sahid | that is basically why i took that way to fix the issue, libvirt is creating the tap device when calling migrateToURI | |
| 14:41:18 | dansmith | right, but that happens when we plug the vif, yeah? | |
| 14:41:27 | sahid | no | |
| 14:41:42 | dansmith | sahid: did you look at the bug reported by the guy on pike? | |
| 14:41:57 | dansmith | the event came *before* we even started listening for it | |
| 14:42:00 | sean-k-mooney | dansmith: for linux bridge no. we we do plug we call brctl add-interface bridge but the tap does not exist at that point | |
| 14:42:39 | dansmith | sean-k-mooney: do you mean add-br? | |