Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-15
19:28:20 mriedem that's also orphaned right?
19:28:26 dansmith yeah
19:28:59 mriedem so,
19:29:13 mriedem 1. delete RP in placement (because if we fail to delete the compute node or the service, it will get re-created),
19:29:16 mriedem 2. delete the service/node,
19:29:20 mriedem 3. delete the host mapping
19:29:21 mriedem ?
19:29:39 dansmith well, 1. also because if we fail, they can't do it again if we delete the local entry
19:30:00 dansmith technically, we can find the service record again if we delete the host mapping,
19:30:13 dansmith so probably good to delete that first, then node, then service last of all
19:30:20 cfriesen what's the host mapping used for?
19:30:21 dansmith so placement, mapping, node, service
19:30:26 dansmith cfriesen: finding it by name in a cell
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 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:31 cfriesen ew
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 cdent edleafe: have you got something queued up after member_of?
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: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 xenapi xenstore_read's to privsep. https://review.openstack.org/552241
20:43:41 openstackgerrit Michael Still proposed openstack/nova master: Move configurable mkfs to privsep. https://review.openstack.org/551921
20:43:42 openstackgerrit Michael Still proposed openstack/nova master: Move xenapi partition copies to privsep. https://review.openstack.org/553605
20:43:42 openstackgerrit Michael Still proposed openstack/nova master: Move xenapi disk resizing to privsep. https://review.openstack.org/552242
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

Earlier   Later