| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-15 | |||
| 14:28:24 | mriedem | sdague: ack, this is the bug https://bugs.launchpad.net/python-openstackclient/+bug/1697452 | |
| 14:28:24 | openstack | Launchpad bug 1697452 in python-novaclient "openstack client dumps debug info on console even without specifying --debug option" [Undecided,Confirmed] | |
| 14:29:10 | mriedem | frickler: thanks for bringing it up | |
| 14:29:33 | sfinucan | mriedem: Cool. I'm your guy, in that case. Assuming nothing is happening til Queens anyway | |
| 14:29:37 | mriedem | sfinucan: nicolasbock is also docs CPL so you can double team | |
| 14:29:46 | sfinucan | seeing as the spec need to be approved | |
| 14:29:53 | sfinucan | Sounds good | |
| 14:30:04 | mriedem | btw, does double-team translate in irish? | |
| 14:30:14 | mriedem | https://en.wikipedia.org/wiki/Professional_wrestling_double-team_maneuvers | |
| 14:30:22 | sfinucan | tag-team, I guess? | |
| 14:30:35 | sfinucan | or just "team up" | |
| 14:31:10 | openstackgerrit | Sean Dague proposed openstack/python-novaclient master: Revert "client.logger.warning wrongly used in migrations" https://review.openstack.org/474600 | |
| 14:31:34 | sdague | mriedem: ^^^ | |
| 14:31:46 | nicolasbock | Hi sfinucan | |
| 14:31:53 | sdague | oh, crap, I did the wrong revert direction | |
| 14:31:55 | sdague | doh | |
| 14:31:57 | sdague | one sec | |
| 14:32:06 | nicolasbock | let me know how you want to 'tag-team' :) | |
| 14:33:59 | openstackgerrit | Sean Dague proposed openstack/python-novaclient master: Revert "client.logger.warning wrongly used in migrations" https://review.openstack.org/474600 | |
| 14:37:23 | openstackgerrit | Ed Leafe proposed openstack/nova master: WIP - Add traits to the ResourceProviders filters https://review.openstack.org/474602 | |
| 14:37:46 | edleafe | jaypipes: bauzas: ^^ | |
| 14:48:38 | ftersin | mdbooth: hi. have you had a chance to look at the reviews which i told you at Tuesday? | |
| 14:49:08 | mdbooth | ftersin: Still no, I'm afraid. Caught up with downstream work. | |
| 14:49:40 | sean-k-mooney | moshele: sfinucan question inline in https://review.openstack.org/#/c/460278/3 | |
| 14:50:15 | sean-k-mooney | moshele: sfinucan: moshele can you confim if that was the last commit required for the hw offload? | |
| 14:51:14 | moshele | sean-k-mooney: yes all the patches are merged | |
| 14:51:45 | sean-k-mooney | moshele: ok then assuming the recheck passes py3 im happy to +2 | |
| 14:52:12 | moshele | sean-k-mooney: cool , sfinucan: can you remove you -2 | |
| 14:52:58 | sean-k-mooney | moshele: i have the recheck running. the six error should now be fixed in the gate so im expecting it to pass | |
| 14:53:25 | moshele | sean-k-mooney: thanks | |
| 14:54:46 | ftersin | mdbooth: could you estimate when you become able to work on the reviews? | |
| 14:55:33 | mdbooth | ftersin: I'd hoped this week, but now I'd guess maybe early next week. Tuesday-ish? | |
| 15:00:48 | ftersin | mdbooth: i think that not so much time is left in Pike for such big work. Because that it'd be perfect if we start in the closest future | |
| 15:01:40 | openstackgerrit | Moshe Levi proposed openstack/os-vif master: hardware offload support for openvswitch https://review.openstack.org/460278 | |
| 15:04:11 | sfinucan | moshele: Will do | |
| 15:14:43 | cfriesen | dansmith: can "nova-manage db online_data_migrations" run with nova-conductor not running? | |
| 15:14:57 | dansmith | of course | |
| 15:16:48 | cfriesen | thanks | |
| 15:19:12 | sfinucan | nicolasbock: Hey - sorry, was in a meeting | |
| 15:19:31 | sfinucan | I don't think there's too much to be done right now. asettle is gone for the week so the spec is stuck | |
| 15:19:48 | sfinucan | Maybe just review that spec and see if you agree with it. I'll do the same myself tomorrow | |
| 15:28:48 | tasker | morning! I'm tracking down a problem with evacuation in Mitaka and came across https://review.openstack.org/#/c/385086/, which mentions commit c15ed42. I cannot find that commit anywhere. Similarly, Artom is mentioning (in more than one bug / review) that "since event dispatching is fixed" this is not a problem anymore, but saying so without reference. Can someone put their finger on these patches? | |
| 15:29:00 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Add Cinder v3 detach to swap_volume https://review.openstack.org/456971 | |
| 15:30:28 | tasker | is Artom referring to this one? https://review.openstack.org/#/c/371048/ | |
| 15:35:55 | mriedem | tasker: probably | |
| 15:47:39 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Provide original fault message when BFV fails https://review.openstack.org/467715 | |
| 15:48:36 | nicolasbock | sfinucan, no problem | |
| 15:48:42 | nicolasbock | sfinucan, I'll have a look at it | |
| 15:52:29 | mriedem | dansmith: i just found that if we try to create a server with tagged devices and it lands on a host that doesn't support that, it's going to abort the build rather than reschedule | |
| 15:52:29 | mriedem | https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L1766 | |
| 15:52:34 | mriedem | doesn't that seem...wrong? | |
| 15:52:54 | dansmith | um, why? | |
| 15:52:58 | mriedem | in thinking about the "95% of reschedules are due to claim contention" thing | |
| 15:53:14 | dansmith | it's an abort not a reschedule right? | |
| 15:53:15 | mriedem | why wouldn't we reschedule to try another host | |
| 15:53:45 | dansmith | because you likely picked a flavor that has you on a specific hypervisor type anyway, so reschedule would just waste resources until you run out of retries | |
| 15:54:38 | mriedem | seems like a big assumption | |
| 15:54:51 | mriedem | i don't need a special flavor to create a server with nic/bdm tags | |
| 15:55:19 | mriedem | granted, the chances of hitting a xen host and failing and then hitting a libvirt host are probably slim anyway | |
| 15:55:27 | mriedem | or chances of having a mixed compute env to start with anyway | |
| 15:55:36 | mriedem | *mixed hypervisor | |
| 15:57:17 | jaypipes | is it wrong that ever since Trump got elected, I can't stop myself from saying "Melania Witt" every time I see melwitt's IRC nick? :( | |
| 15:57:32 | mriedem | heh, just thinking out loud, my compute is managing vcenter, and consecutive_build_service_disable_threshold defaults to 10, and someone tries to create a server with tagged devices, | |
| 15:57:41 | mriedem | after 10 tries that compute and my entire vcenter behind it is disabled now | |
| 15:58:27 | dansmith | mriedem: the point is, I think that most people end up with flavors that correspond to hypervisors if they have multiple in their cloud, | |
| 15:58:40 | dansmith | mriedem: and the reason we don't support device tagging is because the hypervisor driver doesn't support it | |
| 15:58:47 | dansmith | mriedem: so rescheduling the same flavor isn't going to help | |
| 15:59:04 | mriedem | yeah - yo'ure kind of screwed in the non-mixed hyperivsor vmware case above | |
| 15:59:08 | mriedem | but then you disable the config option | |
| 15:59:24 | mriedem | or make the vcenter driver support tagged devices | |
| 15:59:31 | dansmith | right, so I don't really see any situation where rescheduling on that failure makes sense | |
| 15:59:35 | dansmith | it's a config/support issue | |
| 16:01:16 | mriedem | do the driver capabilities feed into the ComputeCapabilitiesFilter? | |
| 16:01:27 | mriedem | i've never been able to read that filter code and understand it | |
| 16:01:46 | dansmith | um, I dunno | |
| 16:02:04 | dansmith | you mean to avoid scheduling to nodes that claim not to support this thing? | |
| 16:02:10 | dansmith | I don't think this is one of those things, but I guess it could be | |
| 16:02:47 | mriedem | something like that | |
| 16:02:55 | mriedem | i think ComputeCapabilitiesFilter checks compute node stats | |
| 16:03:01 | mriedem | which is the nova.compute.stats.Stats object i guess | |
| 16:03:09 | dansmith | sure, but I'm not sure I see this as a huge deal :) | |
| 16:03:44 | mriedem | it's not a huge deal b/c it's always been a mess | |
| 16:03:52 | mriedem | it just ties back into the capabilities api stuff | |
| 16:04:06 | mriedem | and the fact you can request something and end up on a host that doesn't support it and then it's NoValidHost | |
| 16:04:21 | dansmith | no, | |
| 16:04:25 | dansmith | you won't get novalidhost there | |
| 16:05:08 | dansmith | but yeah, I agree it'd be nice to avoid that situation, I just mean going to some extreme like exporting a stat just for this flag to eliminate this for device tagging (and not all the other things generic capabilities would solve) doesn't seem worth it tome | |
| 16:06:20 | mriedem | i guess you don't get NoValidHost, you get an instance in ERROR state with a BuildAbortException recorded as the fault | |
| 16:06:23 | mriedem | anywho | |
| 16:06:28 | dansmith | yeah | |
| 16:06:47 | bauzas | sorry, got distracted but just saw this thread | |
| 16:07:08 | bauzas | yeah, we already have some filters for matching with hypervisors "capabilities" | |
| 16:07:21 | bauzas | one for matching flavors against it, and the other for images | |
| 16:07:50 | bauzas | say you have a flavor, you can restrict it to some computes based on their "capabilities" | |
| 16:07:56 | bauzas | ie. old traits style | |
| 16:08:10 | dansmith | yeah this isn't quite that.. similar but not exactly | |
| 16:08:15 | dansmith | from the filtering side I mean | |
| 16:08:18 | bauzas | but sshhhttt, or jaypipes would tableflip :p | |
| 16:09:08 | dansmith | this would be something where we'd have to add the capability or trait of "can do device metadata" to what they or their image asked for | |
| 16:09:23 | dansmith | since they shouldn't have to ask for a trait of device-metadata _and_ set the device metadata themselves | |