| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-06-26 | |||
| 16:29:29 | dansmith | okay, but if you do multiple of those request objects... | |
| 16:29:55 | dansmith | but that's what I was asking above, if it ever makes sense to have physnets and tunneled be true | |
| 16:30:48 | stephenfin | Yeah, it wouldn't make sense to have both attributes if we split this up | |
| 16:31:17 | dansmith | I guess I'm also still a little confused now, because it seems like you're representing multiple networks here, | |
| 16:31:25 | stephenfin | Because on the individual objects (one per request, I guess?) if physnet_name was set, tunneled would always be False | |
| 16:31:28 | stephenfin | I am | |
| 16:31:31 | dansmith | but have no info on which network is connected to which physnet, or which numa node | |
| 16:31:42 | dansmith | although I guess you've got that in config on compute... | |
| 16:31:44 | stephenfin | I don't care about the former | |
| 16:32:00 | stephenfin | I just care that I am connected to these physnets | |
| 16:32:18 | mriedem | stephenfin: wouldn't it be 1 per nic in the request? | |
| 16:32:35 | stephenfin | per NIC? | |
| 16:32:42 | mriedem | per requested network | |
| 16:32:59 | mriedem | you said, "Because on the individual objects (one per request, I guess?)" | |
| 16:33:10 | stephenfin | Oh, sorry, network request | |
| 16:33:36 | stephenfin | But also, not really if, say, network foo and network bar had the same physnet attribute | |
| 16:33:42 | mriedem | right that's what i'm saying, because create_resource_requests loops over the requested networks | |
| 16:33:51 | mriedem | oh | |
| 16:34:39 | stephenfin | You could be attaching multiple ports that are all sharing the same network | |
| 16:34:48 | mriedem | yup | |
| 16:35:17 | mriedem | or none of the networks have provider:physical_network | |
| 16:35:29 | stephenfin | yeah | |
| 16:35:57 | stephenfin | I guess you could say I'm trying to distill what the user requested to: what physnets, if any, are these networks mapped to and are any of the networks tunneled | |
| 16:36:31 | mriedem | above you said, "if physnet_name was set, tunneled would always be False" | |
| 16:36:40 | dansmith | right, confused about the 'and' there | |
| 16:37:02 | stephenfin | that's if I was to not use this combined object as I'm doing | |
| 16:37:28 | stephenfin | it's possible that half of the requested networks could be tunneled and the other half could be L2 type with a physnet attribute set | |
| 16:37:43 | mriedem | so the other way you can do this is just store a list of requested networks that are physical networks, right? and then infer the tunneled value if that's not empty | |
| 16:37:50 | dansmith | so in that case, wouldn't physnets be non-empty and tunneled be True? | |
| 16:38:01 | stephenfin | for the combined object, yeah | |
| 16:38:14 | dansmith | mriedem: right, that's where I thought we were going with the multiples here | |
| 16:38:32 | mriedem | stephenfin: you seem to be contradicting what is possible regardless of how you plan on modeling it | |
| 16:38:46 | mriedem | if physnets: tunneled = False, unless you have requested tunneled networks | |
| 16:38:51 | stephenfin | lemme scroll up | |
| 16:38:54 | stephenfin | I thought you were suggesting that I have some kind of list object with multiple sub objects? | |
| 16:39:05 | mriedem | no | |
| 16:39:07 | stephenfin | hence "Because on the individual objects (one per request, I guess?)" | |
| 16:39:44 | mriedem | honestly i'm confused as to what you need to model because the tunneled value logic seems to change | |
| 16:40:10 | dansmith | I'm super confused | |
| 16:40:25 | dansmith | because, aside from "what is possible" I feel like he's contradicting his own statements | |
| 16:40:29 | mriedem | i would just prefer, if possible, to keep business logic out of the objects used to model the requested network | |
| 16:40:32 | dansmith | which I'm sure is just me | |
| 16:40:47 | stephenfin | OK, I _really_ need to go, but maybe we can just do a hangouts tomorrow to work through this | |
| 16:40:59 | mriedem | ok | |
| 16:41:01 | stephenfin | I'm obviously doing an awful job of explaining this | |
| 16:41:03 | stephenfin | :) | |
| 16:41:13 | dansmith | finally, we agree on something :) | |
| 16:41:19 | stephenfin | heh | |
| 16:41:32 | stephenfin | Cool, I'll set that up tomorrow afternoon my time | |
| 16:54:17 | openstackgerrit | Surya Seetharaman proposed openstack/nova stable/queens: Make nova list and migration-list ignore down cells https://review.openstack.org/578152 | |
| 17:28:22 | openstackgerrit | Merged openstack/nova master: Remove mox in test_conductor.py (1) https://review.openstack.org/564658 | |
| 17:36:48 | openstackgerrit | jiang wei proposed openstack/nova master: Add action initiator attribute to the instance payload https://review.openstack.org/536243 | |
| 17:57:02 | openstackgerrit | Dan Smith proposed openstack/nova master: Allow templated cell_mapping URLs https://review.openstack.org/578163 | |
| 18:30:45 | melwitt | mriedem: I'm wondering if the https://blueprints.launchpad.net/nova/+spec/vrouter-os-vif-conversion is similar to this patch we merged earlier in the cycle https://review.openstack.org/534371 , that one was relatively simple | |
| 18:40:31 | mriedem | similar | |
| 18:58:28 | melwitt | seems like it should be okay then. I'll put it on the agenda for next meeting | |
| 19:47:39 | mriedem | is everyone else tired of seeing this? | |
| 19:47:40 | mriedem | mox_fixture = self.useFixture(moxstubout.MoxStubout()) | |
| 19:47:40 | mriedem | nova/test.py:323: DeprecationWarning: Using class 'MoxStubout' (either directly or via inheritance) is deprecated in version '3.5.0' | |
| 19:48:10 | mriedem | cuz uh, i know how to make it go away | |
| 19:48:31 | melwitt | how | |
| 19:48:50 | mriedem | change to use MoxStubout from mox3 instead of oslo.test http://git.openstack.org/cgit/openstack/mox3/tree/mox3/fixture.py#n21 | |
| 19:49:11 | melwitt | but mox3 is evil! | |
| 19:49:22 | mriedem | it's the devil i know | |
| 19:49:30 | melwitt | heh | |
| 19:51:43 | openstack | Launchpad bug 1778784 in OpenStack Compute (nova) "mox_fixture = self.useFixture(moxstubout.MoxStubout()) usage is deprecated from oslo.test 3.5.0" [Medium,Triaged] | |
| 19:51:43 | mriedem | https://bugs.launchpad.net/nova/+bug/1778784 | |
| 20:18:04 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Remove compatibility code for instance groups https://review.openstack.org/578192 | |
| 20:18:05 | mriedem | dansmith: i think you're going to just really love this ^ | |
| 20:20:06 | dansmith | meh | |
| 20:20:15 | mriedem | sounds like love to me | |
| 20:22:00 | dansmith | I will trade you for: https://review.openstack.org/#/c/578163/ | |
| 20:22:35 | mriedem | i think we have a bug for that actually | |
| 20:25:01 | openstack | Launchpad bug 1717915 in oslo.messaging "nova services and transport_url, cannot connect to vhost if specified" [High,Incomplete] - Assigned to Ken Giusti (kgiusti) | |
| 20:25:01 | mriedem | https://bugs.launchpad.net/nova/+bug/1717915 | |
| 20:25:06 | mriedem | dansmith: does that in any way solve that problem? | |
| 20:26:18 | mriedem | i think there is also a minimum version of oslo.db needed for this... | |
| 20:27:40 | dansmith | mriedem: hmm, I don't think so, and that syntax may break this | |
| 20:27:44 | dansmith | mriedem: a minimum oslo_db for what? | |
| 20:27:48 | mriedem | sec | |
| 20:28:06 | mriedem | https://review.openstack.org/#/c/539035/ | |
| 20:28:14 | mriedem | i assume ^ is related | |
| 20:28:59 | dansmith | mriedem: that's part of their workaround | |
| 20:29:08 | dansmith | mriedem: that isn't needed if we have this, regardless of the oslo_db version | |
| 20:33:18 | dansmith | so, that bug says, I think, that oslo.msg does a split(',') on the netloc part of the url, yeah? | |
| 20:33:39 | dansmith | that'll break my extraction of the username and password,at least, and probably the hostname | |
| 20:36:33 | dansmith | ugh, yeah | |
| 20:36:53 | dansmith | I dunno why that was done instead of just multiple full urls.. | |
| 20:56:13 | mriedem | dansmith: ok comments inline | |
| 20:56:40 | mriedem | reading mike's comment now, i suppose i should have read that first | |
| 20:57:17 | melwitt | does anyone know off the top of their head how instances can end up with no InstanceMapping? | |
| 20:58:11 | melwitt | chatting with someone from rdo cloud about it, it's happened to them a couple of times | |
| 20:58:52 | mriedem | no instance mapping or no cell mapping in the instance mapping? | |
| 20:58:53 | melwitt | it seems like something that could only happen during an upgrade, if instance(s) were somehow missed upon nova-manage cell_v2 map_instances | |
| 21:01:16 | melwitt | I'm not sure yet, will be looking at the details tomorrow (they're in EU time zone). but just wanted to ask in case this was a common thing other people have seen | |
| 21:01:36 | openstackgerrit | Merged openstack/nova master: Remove support for /os-fixed-ips REST API https://review.openstack.org/568516 | |
| 21:02:04 | melwitt | we know CERN has hit the no cell mapping in the instance mapping, and I still don't understand how that occurs | |
| 21:07:27 | mriedem | i do | |
| 21:07:38 | mriedem | well i know one way you can hit it | |
| 21:07:42 | mriedem | https://review.openstack.org/#/c/576161/ | |