Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-15
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
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
21:01:54 tssurya hehe yea!
21:06:07 openstackgerrit Lance Bragstad proposed openstack/nova master: Set scope_types for admin_action policies https://review.openstack.org/553612
21:16:36 openstackgerrit Lance Bragstad proposed openstack/nova master: Set scope_types for admin password policies https://review.openstack.org/553613
21:33:52 openstackgerrit Claudiu Belu proposed openstack/nova master: db: Adds live-resize to Migration model migration_type https://review.openstack.org/185961
21:59:32 mriedem Kevin_Zheng_: you reported the bug related to this https://blueprints.launchpad.net/nova/+spec/add-server-group-remove-member-notifications but for telemetry and searchlight - given the states of those projects, do they actually care about solving this now?
21:59:40 mriedem https://bugs.launchpad.net/nova/+bug/1639152
21:59:42 openstack Launchpad bug 1639152 in OpenStack Compute (nova) "Send out notification about server group changes when delete instances" [Wishlist,Confirmed] - Assigned to Takashi NATSUME (natsume-takashi)
22:00:11 dansmith mriedem: it requires conf
22:00:15 dansmith so I would kinda expect not
22:00:36 dansmith we will backport it because it's important enough, but I don't know that it fits the usual backport candidate mold
22:00:39 mriedem we can backport bug fixes sometimes as long as the config doesn't change any default behavior
22:00:51 dansmith it should be safe from that regard
22:01:04 mriedem by "we will backport" you mean the royal we?
22:01:04 dansmith it's really a feature used to fix a bug, IMHO,
22:01:11 dansmith so a bp isn't wrong I don't think
22:01:13 dansmith mriedem: we as in redhat
22:01:20 mriedem that's what i meant :)
22:02:02 mriedem alright i guess people that want it in stable can always patch out of tree if we're not going to backport upstream
22:02:15 dansmith I'm not saying we can't or shouldn't
22:02:16 mriedem i heard windriver has already had this for a year
22:02:23 dansmith I would have expected you to say no
22:02:39 dansmith if you think it's legit, then I think it's reasonable
22:02:42 mriedem having a blueprint tag on it makes it more awkward to backport
22:02:48 dansmith well,
22:02:50 mriedem i don't have the context on the thing,
22:02:51 dansmith it's not a bug in nova
22:02:56 mriedem just saw 'meltdown'
22:03:05 dansmith it's a bug in .. I dunno.. the whole arrangement of things
22:03:17 mriedem in computers?
22:03:22 mriedem just say computers
22:03:31 dansmith nova doesn't let you specify a thing that only the operator can know, and is needed to mitigate performance loss after applying the meltdown fixes
22:03:35 dansmith it's completely a nova feature,
22:03:55 dansmith but operators will need it to fix a bug or regressed behavior in lots of other things (kernel, qemu, etc)
22:04:16 mriedem hmm, this reminds me,
22:04:47 mriedem stable/ocata and stable/pike started crapping recently (right before the ptg) because of qemu / libvirt package updates for CVEs related to meltdown and spectre in the UCA

Earlier   Later