| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-15 | |||
| 19:30:27 | mriedem | cfriesen: to map the host | |
| 19:30:29 | cfriesen | ah, right | |
| 19:30:49 | mriedem | node and service are in the same db api call, | |
| 19:30:57 | mriedem | unless we delete the compute node record(s?) directly in the api | |
| 19:31:15 | mriedem | which would be my preference b/c the auto/implicit delete in the db api is kind of gross | |
| 19:32:13 | dansmith | same db call, but node could go first | |
| 19:32:22 | dansmith | but yeah, don't so much care about those two, | |
| 19:32:51 | dansmith | as I'm not sure there are any FKs that would prevent us from deleting one and not the other | |
| 19:33:46 | mriedem | compute_nodes.service_id doesn't have a FK on it | |
| 19:33:55 | dansmith | yeah | |
| 19:34:08 | cfriesen | dansmith: what are the implications of a stale host mapping? | |
| 19:34:18 | dansmith | cfriesen: cruft | |
| 19:34:45 | dansmith | with no easy way to find and clean it up later | |
| 19:35:00 | cfriesen | got it, thanks | |
| 19:35:04 | mriedem | also, | |
| 19:35:12 | mriedem | i think you could re-discover the compute host in another cell, | |
| 19:35:18 | dansmith | true | |
| 19:35:19 | mriedem | and then the old host mapping would be pointed at the wrong cell | |
| 19:35:21 | dansmith | yeah | |
| 19:35:26 | mriedem | i feel like cern mentioned that | |
| 19:36:25 | claudiub|2 | did they express a con...cern? | |
| 19:36:31 | cfriesen | ew | |
| 19:36:31 | mriedem | cfriesen: i think this block is where you add the new deletes https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/services.py#L213 | |
| 19:36:36 | dansmith | claudiub|2: nice :) | |
| 19:36:39 | mriedem | claudiub|2: excellent | |
| 19:36:41 | claudiub|2 | :D | |
| 19:48:15 | cfriesen | mriedem: you think that's better than https://github.com/openstack/nova/blob/master/nova/compute/api.py#L4820 ? | |
| 19:49:23 | mriedem | cfriesen: could happen in compute api code too, doesn't matter a ton to me | |
| 19:49:57 | mriedem | cfriesen: note that this will also need an upgrade impact release note because the api will now require placement to be configured to do this | |
| 19:50:50 | mriedem | i think we should backport this though...so not sure how sticky that gets | |
| 19:50:55 | cfriesen | mriedem: if placement isn't configured, wouldn't it be okay to just continue on since there wouldn't be any records? | |
| 19:51:18 | mriedem | i mean [placement] configured specifically in the nova.conf you're running against nova-api, | |
| 19:51:24 | mriedem | which hasn't technically required placement before this | |
| 19:51:26 | mriedem | as far as i know | |
| 19:51:35 | mriedem | conductor, compute and scheduler all require placement already, but api doesnt | |
| 19:51:40 | cfriesen | ah, got it. I guess that'd be one advantage of doing it in nova-compute | |
| 19:51:56 | mriedem | there is no rpc cast from api to compute to delete itself | |
| 19:52:30 | cfriesen | yeah, got confused by the nova/compute/api.py path for a sec....too many things going on today | |
| 19:59:00 | cdent | jaypipes, efried, edleafe: on consumer generations. does that need an owner? is anything depending on it? I figure I can probably do it if it isn't needed asap (got forbidden first) | |
| 19:59:41 | efried | cdent: It does need an owner afaik. And it is not immediately urgent afaik. Thank you for volunteering. | |
| 19:59:52 | efried | mriedem: ^ | |
| 20:00:08 | jaypipes | cdent: needs an owner, yes. | |
| 20:01:04 | edleafe | I can pair with someone on that | |
| 20:01:36 | cfriesen | mriedem: on the mixed baremetal/hypervisor scheduler thing, I suspect the NUMATopologyFilter is actually okay as long as we don't have spec_obj.numa_topology | |
| 20:03:03 | mriedem | cfriesen: in that case the filter should just filter out an ironic host/node | |
| 20:03:08 | mriedem | but that's what i was trying to figure out | |
| 20:04:07 | mriedem | i.e. if NUMATopologyFilter just doesn't work with an all ironic deployment, then don't enable it, but if you're using a single scheduler for mixed VM/BM, that filter would also kick out requests for numa for ironic hosts in the deployment, | |
| 20:04:14 | mriedem | but i think that should be ok? | |
| 20:04:47 | cfriesen | mriedem: as long as requests for ironic instances don't specify a desired numa topology then I think it should be good | |
| 20:04:54 | mriedem | if we have a libvirt and ironic host as candidates, the ironic would is filtered out and the libvirt one should be ok | |
| 20:04:54 | cdent | edleafe: have you got something queued up after member_of? | |
| 20:05:19 | mriedem | cfriesen: well yeah, baremetal flavors shouldn't have numa things in them | |
| 20:05:35 | edleafe | in OpenStack, just the api-sig stuff: http and version discovery | |
| 20:06:48 | cdent | do you want something immediately queued up? If so you can be primary on consumer generations and I can be your buddy. Otherwise I can start it up in a few weeks | |
| 20:07:34 | edleafe | ok, I guess I'll grab it, and anyone who wants in on the fun is welcome to join | |
| 20:08:06 | openstackgerrit | Jay Pipes proposed openstack/nova master: mirror nova host aggregate members to placement https://review.openstack.org/553597 | |
| 20:08:18 | jaypipes | thx edleafe | |
| 20:10:39 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-ref: add a note in DELETE /os-services about deleting computes https://review.openstack.org/553598 | |
| 20:10:40 | mriedem | cfriesen: ^ while i'm remembering this compute delete thing | |
| 20:11:45 | openstackgerrit | sahid proposed openstack/nova master: libvirt: slow live-migration to ensure network is ready https://review.openstack.org/497457 | |
| 20:11:58 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-ref: add a note in DELETE /os-services about deleting computes https://review.openstack.org/553598 | |
| 20:24:58 | openstackgerrit | sean mooney proposed openstack/nova master: add mtu to libvirt xml for ethernet and bridge types https://review.openstack.org/553072 | |
| 20:37:01 | tssurya | cfriesen: just read the service-delete stuff ; its also been on our to-do list; so thanks for doing it. | |
| 20:38:27 | cfriesen | tssurya: just filed https://bugs.launchpad.net/nova/+bug/1756179 | |
| 20:38:29 | openstack | Launchpad bug 1756179 in OpenStack Compute (nova) "deleting a nova-compute service leaves orphaned records in placement" [Undecided,New] | |
| 20:39:18 | tssurya | cfriesen: ack | |
| 20:42:13 | mriedem | cfriesen: are you also going to work on the patch? | |
| 20:43:41 | openstackgerrit | Michael Still proposed openstack/nova master: Move configurable mkfs to privsep. https://review.openstack.org/551921 | |
| 20:43:41 | openstackgerrit | Michael Still proposed openstack/nova master: Move xenapi xenstore_read's to privsep. https://review.openstack.org/552241 | |
| 20:43:42 | openstackgerrit | Michael Still proposed openstack/nova master: Move xenapi disk resizing to privsep. https://review.openstack.org/552242 | |
| 20:43:42 | openstackgerrit | Michael Still proposed openstack/nova master: Move xenapi partition copies to privsep. https://review.openstack.org/553605 | |
| 20:44:41 | openstackgerrit | Lance Bragstad proposed openstack/nova master: Add scope_types to server policies https://review.openstack.org/525772 | |
| 20:45:08 | lbragstad | cc mriedem melwitt ^ new version availble re the RBAC cross-project sessions from dublin | |
| 20:45:47 | lbragstad | let me know if you'd like to go through it (i know mriedem mentioned something about reviewing it as a group) - i'm happy to help answer questions | |
| 20:48:45 | melwitt | thanks for the heads up | |
| 20:49:11 | cfriesen | tssurya: for your review at https://review.openstack.org/#/c/546660 should we also delete the "service" records along with the compute node records? | |
| 20:49:59 | cfriesen | tssurya: if you want to submit a patch for that bug, go for it. I probably won't get to it till late next week at the earliest | |
| 20:50:15 | tssurya | cfriesen : yea, sure I can work on it | |
| 20:51:15 | tssurya | regarding removal of "service" records, when I guess it makes sense to do when force deleting the cell and host | |
| 20:51:26 | tssurya | mriedem, dansmith : ^^ | |
| 20:51:30 | openstackgerrit | Lance Bragstad proposed openstack/nova master: Add scope_types to server policies https://review.openstack.org/525772 | |
| 20:52:02 | mriedem | this gets quite messy | |
| 20:52:15 | mriedem | because deleting a compute service in the api today also removes the compute host from any aggregates it's in | |
| 20:52:16 | tssurya | yes it will get messy, | |
| 20:53:09 | cfriesen | if you're deleting a cell or a host, doesn't it make sense to delete everything logically associated with that cell/host? | |
| 20:53:30 | mriedem | sure, but, | |
| 20:53:32 | mriedem | where does it end | |
| 20:54:13 | tssurya | I think it does make sense to do it, but to put it all in nova-manage... it gets dirtier and more complex | |
| 20:54:54 | mriedem | if only we had, oh idk, a rest api for managing cells.... | |
| 20:55:11 | tssurya | mriedem: :) | |
| 20:55:44 | dansmith | oh yeah, that'd make it so much better | |
| 20:56:21 | mriedem | it would solve all problems | |
| 20:56:34 | mriedem | cells api could be the new secretary of state | |
| 20:56:41 | mriedem | RIP REX | |
| 20:57:07 | melwitt | nova meeting in 3 minutes | |
| 21:00:06 | dansmith | tssurya: fwiw, my preference is that we not put as much stuff in cmd.manage as we have now, but break things out into modules like all the rest of our code, and make cmd.manage just the cli interface to those things | |
| 21:00:22 | dansmith | cmd.manage grew up over time, getting larger and larger, with people caring less about it because "meh, it's just nova-manage" | |
| 21:00:48 | tssurya | I totally agree that it is getting messier | |
| 21:01:34 | tssurya | (mostly because of me in the recent months) | |
| 21:01:44 | mriedem | let's blame belmiro | |