| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-07 | |||
| 16:58:19 | dansmith | on my test system, I have nothing in cell0 for info caches, so it's not like we're creating them there by accident or something | |
| 16:58:29 | mriedem | i don't see "Automatically allocating a network for project" | |
| 16:59:17 | dansmith | should that be logged by n-cpu? | |
| 16:59:21 | mriedem | yeah | |
| 16:59:45 | mriedem | https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L1495 | |
| 17:00:51 | dansmith | yeah | |
| 17:00:59 | mriedem | i'm also not seeing this https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L1542 | |
| 17:01:04 | mriedem | ^ is called via the api | |
| 17:01:20 | mriedem | oh well i should look for that in the n-api logs | |
| 17:02:44 | mriedem | i don't see that in n-api logs either | |
| 17:02:58 | mriedem | i wonder if somehow the auto_allocate flag isn't getting set on the NetworkRequest object? | |
| 17:03:46 | dansmith | not sure why that would be.. we don't even persist that right? | |
| 17:06:33 | mriedem | we don't persist it | |
| 17:06:41 | mriedem | are we somehow mangling what we pass between n-api and conductor? | |
| 17:07:17 | mriedem | i would doubt it because otherwise we wouldn't have any tests that create a server on a specific nic passing | |
| 17:07:27 | mriedem | which i believe is most of tempest | |
| 17:07:36 | mriedem | they all have tenant-isolated networks | |
| 17:09:12 | dansmith | mriedem: no mangling that I know of, and this all passes on the same stack of patches with normal devstack, AFAICT | |
| 17:11:09 | mriedem | ok. notifications meeting atm and then i'll keep digging. | |
| 17:11:12 | mriedem | we might need a debug logging patch | |
| 17:13:42 | dansmith | okay thanks for helping | |
| 17:14:45 | mriedem | https://www.youtube.com/watch?v=RWc5gsU-eeY | |
| 17:15:13 | mriedem | mtreinish: ^ | |
| 17:16:33 | openstackgerrit | Eric Fried proposed openstack/nova master: PowerVM Driver: spawn/destroy #3: TaskFlow https://review.openstack.org/438729 | |
| 17:16:51 | dansmith | heh | |
| 17:16:51 | openstackgerrit | Eric Fried proposed openstack/nova master: PowerVM Driver: spawn/destroy #4: full flavor https://review.openstack.org/391288 | |
| 17:17:45 | efried | thorst adreznec esberglu Need re-+1 on https://review.openstack.org/#/c/438729/ (TaskFlow) please. | |
| 17:24:48 | mdbooth | lyarwood: Before I looked, I thought there was a swap_volume flow where we simply replaced 1 volume with another, contents and all. However, looking now it appears we'll always attempt to rebase the contents of the old volume on to the new volume. Is that right, or am I just blind today? | |
| 17:25:46 | lyarwood | mdbooth: we always rebase, even with the cinder retype flow | |
| 17:26:00 | mdbooth | Well the cinder retype flow is the one I knew did it | |
| 17:26:15 | mdbooth | I thought the crackpot flow didn't do it though, for some reason | |
| 17:26:27 | mriedem | efried: you guys are using taskflow huh | |
| 17:26:32 | lyarwood | mdbooth: yeah volume-update does it as well | |
| 17:26:41 | efried | mriedem Yes. | |
| 17:26:45 | mdbooth | lyarwood: Thanks | |
| 17:26:49 | efried | That's... good, right mriedem ? | |
| 17:26:56 | mriedem | efried: we've never used it in nova | |
| 17:27:03 | mriedem | i know cinder uses it, sort of, for some tihngs | |
| 17:27:09 | mriedem | but never liked it enough to use it for all operations | |
| 17:27:10 | efried | Oh. I was under the impression that e.g. libvirt used it. | |
| 17:27:16 | mriedem | maybe it's fine on a small scale confied to a single virt driver | |
| 17:28:17 | efried | mriedem We find it super useful for rollbacks. | |
| 17:30:25 | mriedem | like spawn fails, detach interfaces and block devices? | |
| 17:30:31 | efried | yup | |
| 17:30:53 | mriedem | dude you can totally just have a 300LOC mega method with lots of try/excepts :) | |
| 17:31:44 | efried | Hey, y'all are the ones who wanted smaller change sets. | |
| 17:31:53 | efried | We'll bloat it later for ya. | |
| 17:33:53 | mdbooth | jaypipes: Did somebody bust you out of some meetings? | |
| 17:33:54 | jaypipes | dansmith: and yes, I'm listening to "Business Time" | |
| 17:34:01 | dansmith | good man | |
| 17:35:09 | cburgess | sdague: OMG thats awesome. I offered that up as a joke of the problems such a model could create. I love that its officially a rejected model for the reason that it makes me sad. | |
| 17:35:34 | jaypipes | mdbooth: :) | |
| 17:39:26 | mriedem | jaypipes: https://www.youtube.com/watch?v=w5Fgp-KihIA | |
| 17:39:30 | mriedem | ^ is what you're looking for | |
| 17:39:32 | sfinucan | mdbooth: Done https://review.openstack.org/#/c/438970. Thanks for breaking that out | |
| 17:39:47 | mdbooth | Thanks for looking :) | |
| 17:40:06 | dansmith | mriedem: right before we call from conductor to the compute to do the build, requested_networks is None for that test | |
| 17:40:45 | mriedem | gotta go, people looking over my shoulder waiting for lunch | |
| 17:40:47 | mriedem | will check when i'm back | |
| 17:46:21 | jaypipes | mriedem: lol | |
| 18:02:13 | macsz | bugs team meeting in #openstack-meeting-4 | |
| 18:13:30 | dansmith | jaypipes: would you prefer I double the math in the tests, keep the single-cell mock, or completely change the way that test works here? https://review.openstack.org/#/c/441388/3 | |
| 18:15:03 | dansmith | just doubling the math does verify that we're iterating over the two default cells, so maybe that's the better way | |
| 18:16:13 | jaypipes | dansmith: got it. a short comment above would suffice I think | |
| 18:16:28 | jaypipes | dansmith: just to assuage the reader of the test at a later time ;) | |
| 18:16:29 | openstackgerrit | Dan Peschman proposed openstack/nova master: No API cell up-call to delete consoleauth tokens https://review.openstack.org/415922 | |
| 18:16:51 | dansmith | jaypipes: lemme do the double math and then document that bit to explain the multiple cells thing.. that'll validate what we're doing, be less code, and more obvious I think | |
| 18:16:56 | dansmith | since it's all contained in a helper checker | |
| 18:17:11 | jaypipes | cools with me | |
| 18:23:27 | jaypipes | mdbooth: around? | |
| 18:25:10 | jaypipes | mdbooth: would you mind reading my review comment on https://review.openstack.org/#/c/399679/ and commenting on that? Basically, the patch introduces the potential of the libvirt.xml file storing in the owner metadata block a user *ID* that doesn't match the user *name* -- same for project ID being different than the project name. Because the patch sets the userid to the instance.user_id (the owner user) and username to context.user_name (which | |
| 18:25:10 | jaypipes | could be the admin). | |
| 18:44:56 | jaypipes | dansmith: Snoop Dan? :) | |
| 18:45:54 | dansmith | jaypipes: yeah, I'm o-g | |
| 18:46:15 | jaypipes | dansmith: the original grokster. | |
| 18:48:44 | mriedem | jaypipes: on the searchlight connectivity check, i replied in the spec, but i think we just handle it like we did for the placement safe_connect thing in the scheduler report client, but we don't retry | |
| 18:49:00 | mriedem | if it's there use it, else we log a warning, set a flag and don't retry until restart | |
| 18:49:16 | jaypipes | mriedem: cools with me. | |
| 18:49:48 | mriedem | figuring out if searchlight even supports versioned notifications from nova is priority 1 for me atm, because i don't think they do | |
| 18:49:52 | mriedem | which is a pretty big blocker for us | |
| 18:50:23 | cdent | mriedem: you mean being willing to store different versions, differently? | |
| 18:50:34 | mriedem | cdent: no, like actually listening for that type of notification | |
| 18:50:57 | jaypipes | mriedem: they listen on the same queue, no? | |
| 18:51:45 | mriedem | yeah i think so https://github.com/openstack/searchlight/blob/2.0.0/searchlight/elasticsearch/plugins/nova/notification_handler.py#L73 | |
| 18:52:09 | mriedem | i'm not entirely sure that this maps the same https://github.com/openstack/searchlight/blob/2.0.0/searchlight/elasticsearch/plugins/nova/notification_handler.py#L82 | |
| 18:57:35 | mriedem | cdent: jaypipes: for example, searchlight has https://github.com/openstack/searchlight/blob/2.0.0/searchlight/elasticsearch/plugins/nova/notification_handler.py#L92 | |
| 18:57:39 | mriedem | compute.instance.power_off.end | |
| 18:57:47 | mriedem | our versioned notification sample has https://github.com/openstack/nova/blob/master/doc/notification_samples/instance-power_off-end.json#L2 | |
| 18:57:51 | mriedem | instance.power_off.end | |
| 18:58:04 | mriedem | i'm not sure where the compute. prefix comes from | |
| 18:58:50 | cdent | mriedem: it looks like it may be something they are doing: https://github.com/openstack/searchlight/blob/2.0.0/searchlight/elasticsearch/plugins/ironic/notification_handlers.py | |
| 18:58:56 | cdent | (sorry, line 37) | |
| 18:59:50 | mriedem | cdent: i'm not so sure https://github.com/openstack/nova/blob/master/nova/rpc.py#L292 | |
| 19:00:10 | cdent | indeed | |
| 19:00:21 | openstackgerrit | Dan Smith proposed openstack/nova master: Get instance availability_zone without hitting the api db https://review.openstack.org/439754 | |
| 19:00:22 | openstackgerrit | Dan Smith proposed openstack/nova master: Enlighten server tags API about cells https://review.openstack.org/440856 | |
| 19:00:22 | openstackgerrit | Dan Smith proposed openstack/nova master: Teach HostAPI about cells https://review.openstack.org/442162 | |
| 19:00:23 | openstackgerrit | Dan Smith proposed openstack/nova master: Make os-availability-zones know about cells https://review.openstack.org/442163 | |
| 19:00:23 | openstackgerrit | Dan Smith proposed openstack/nova master: Target cell in super conductor operations https://review.openstack.org/438022 | |
| 19:00:24 | openstackgerrit | Dan Smith proposed openstack/nova master: Change MQ targeting to honor only what is in the context https://review.openstack.org/438023 | |