Earlier  
Posted Nick Remark
#openstack-nova - 2018-02-14
21:45:50 mnaser yay..
21:45:58 mnaser should they be buried in cell0?
21:45:58 mriedem mnaser: just a guess, but that's my guess
21:46:01 dansmith efried: because we have to label each compute individually with the trait and I think that's what aggregates are for, but yep, I'll put it in as a slightly different thing.. just for you :)
21:46:20 efried Thanks dansmith. Kisses.
21:46:40 mriedem it's a valentines day miracle
21:46:54 efried dansmith: Having to label each compute individually with the trait - what I'm confused about on L46-7 is why that argument doesn't apply for BFV too.
21:47:47 dansmith efried: well, the way I phrased that is silly, since that's traits all up and down, but let me say it in the spec and then you can argue about it, if it's clear
21:47:51 mriedem efried: for one thing, nova-compute can report the BFV traits capabilities automatically, the operator / admin doesn't have to do that for every tenant
21:48:00 mnaser select * from block_device_mapping => Empty set
21:48:09 mnaser i guess i'll get them added..
21:48:19 efried mriedem: It can do that for host aggs too, though, nah?
21:48:34 dansmith mriedem: and compute can report aggregates automaticaly
21:48:47 mriedem that's an up-call for one thing
21:49:19 mriedem nova-compute would have to get the aggregates that the host is in, find the tenant_id meta on those, and convert that to traits on the RP
21:49:22 mriedem i agree we could do that,
21:49:22 efried mriedem, dansmith: Oh, so yeah, that was my point: we're talking about automatically mirroring host aggs as placement aggs; in the alternative I describe above, we would be instead automatically mirroring host aggs as traits on the compute node RP.
21:49:24 mriedem but it's an up-call
21:49:53 mriedem the bfv trait is much more clear to me as a 'trait',
21:50:03 dansmith efried: right, but then you create a tenant trait, apply to all computes. if you want to reassign a cell to a different tenant, you remove/reapply against all those computes
21:50:04 mriedem the tenant isolation thing is very much less a 'trait' in my head
21:50:07 dansmith efried: compared with:
21:50:25 efried ...same but for agg associations
21:50:27 dansmith efried: this cell is aggregate cell-foo, and add "tenant bar is allowed" to the cell-foo aggregate,
21:50:44 mriedem mnaser: oh i know the problem,
21:50:46 dansmith efried: then you can reassign a cell to a tenant in one place instead of mass add/remove of the other trait
21:51:04 efried Sorry, I don't get the difference.
21:51:10 dansmith efried: hangout?
21:51:11 efried If the trait is CUSTOM_CELL_FOO
21:51:12 mriedem mnaser: so in conductor schedule_and_build_instances, we call the scheduler for a host and if we get one, we look up what cell that host is in and create the instance and bdms in that cell,
21:51:24 efried dansmith: Sure
21:51:25 mriedem mnaser: if scheduling fails, we create the instance in cell0,
21:51:30 mriedem but we don't create the bdms in cell0
21:51:32 mnaser but not the bdms
21:51:49 mriedem exactamundo
21:51:50 mriedem melwitt: ^
21:51:52 dansmith efried: required https://hangouts.google.com/call/vebCoylDfu_0tvlCDPwmAAEE, edleafe mriedem jaypipes optional
21:52:04 mnaser i guess i'll look into making it create bdms in cell0
21:52:04 mriedem pants required?
21:52:11 dansmith mriedem: yes
21:52:28 mriedem mnaser: that or we unreserve the volumes for the bdms right there in conductor...
21:52:35 mriedem so that the api doesn't have to delete them locally
21:52:59 mriedem but then we get the "how many different nova services does it take to detach a volume" problem
21:53:01 mnaser that means that the volume will become available right away
21:53:06 mnaser but yeah
21:53:06 mnaser that
21:56:03 mriedem mnaser: melwitt: left notes on https://review.openstack.org/#/c/340614/ - thanks for the testing
22:01:21 openstackgerrit Jackie Truong proposed openstack/python-novaclient master: Microversion 2.61 - Add trusted_image_certificates https://review.openstack.org/500396
22:01:56 mnaser mriedem: melwitt i can do both (though storing bdms seems easier).. i'll leave the decision up to you
22:11:48 mriedem before all of this we'd have the bdms created in the api along with the instance (before cellsv2 happened), so might as well just go with that for starters and see how it goes
22:12:11 mriedem not api, the 'nova' db, but the nova-api service would create them in the nova db
22:13:22 melwitt mriedem: sure, I can take the meeting baton tomorrow. let me know if I need to update the agenda or if you already did
22:13:32 mriedem i have not updated the agenda
22:13:46 melwitt k. I shall agenda then
22:15:22 melwitt and that sucks about the bdms thing.
22:15:39 mriedem right so we'll likely need to stagger these patches for sanity
22:15:54 openstackgerrit Dan Smith proposed openstack/nova-specs master: Add placement-req-filter spec https://review.openstack.org/544585
22:15:56 dansmith efried: ^
22:16:00 mriedem regression test, do something about bdms in conductor on scheduling failure, then the local delete api patch
22:16:03 efried dansmith: ack
22:16:04 melwitt yeah, I was about to say ... should mnaser take that issue as a separate patch?
22:16:10 mriedem melwitt: i think so
22:16:19 mriedem we're going to want to backport all of this to ocata too
22:16:26 melwitt good times
22:16:40 mriedem this is the most fun i've had all week
22:16:47 melwitt SAME
22:18:26 mnaser I have 3 patches right now, fixing fixtures, functional tests and melwitt final patch on top. I’ll add the bdm creation in the stack.
22:18:34 mnaser I’ll make sure to keep them
22:18:40 mnaser Under the same topic
22:18:48 mriedem mnaser: thanks
22:18:48 mnaser (But first supper)
22:20:48 mlavalle melwitt: I added some topics to the Nova PTG etherpad. With those topics, I figured 2 hours. Right now I have the Neutron / Nova session from 3 to 5 on Thursday. When you have a chance let me know what you think. No need to rush
22:21:17 mlavalle fro 3 to 5 in the Neutron etherpad^^^^
22:21:43 mlavalle but I am keeping that afternoon open until you and I firm up the times
22:23:48 melwitt mlavalle: k, probably will be fine. just have to sync up with the ironic team. I'll let you know
22:31:11 mlavalle melwitt: :-)
22:40:26 openstackgerrit Matt Riedemann proposed openstack/nova master: Scheduler multiple workers support https://review.openstack.org/159382
22:53:20 openstackgerrit Matt Riedemann proposed openstack/nova master: Check for leaked server resource allocations in post_test_hook https://review.openstack.org/538510
23:04:00 openstackgerrit Dan Smith proposed openstack/nova master: Remove deprecated aggregate DB compatibility https://review.openstack.org/544698
23:04:01 openstackgerrit Dan Smith proposed openstack/nova master: Add AggregateList.get_by_metadata_value() query method https://review.openstack.org/544728
23:04:01 openstackgerrit Dan Smith proposed openstack/nova master: Add aggregates list to Destination object https://review.openstack.org/544729
23:04:02 openstackgerrit Dan Smith proposed openstack/nova master: WIP: Add request filter functionality and first filter https://review.openstack.org/544730
23:12:13 melwitt mlavalle: I've confirmed that 3-5 on thursday works for nova/neutron. thanks
23:12:30 mlavalle melwitt: Thank you!
23:26:40 mnaser yay adding bdms to cell0 fixed it
23:35:30 melwitt tonyb: this says ocata enters phase 3 support on 2/26 but also says 2/26 is the EOL date https://releases.openstack.org/ does that make sense to you?
23:39:18 mriedem melwitt: do you want/plan on doing a queens retrospective at the ptg?
23:41:16 melwitt mriedem: I'm not opposed to having one but I hadn't thought about it because no one had mentioned it (whereas we have had obvious interest in retro in the past). do you think we should just plan for one?
23:42:34 melwitt I also might have missed it if anyone has expressed interest in having a queens retro
23:45:57 mriedem it hasn't come up, but i assume we should at least make it an option
23:46:01 mriedem if no one has anything, it's a short thing
23:46:12 melwitt yeah, makes sense
23:46:29 mnaser i have 4 patches right, is the following order ok or should i reorder: fix cinder fixtures -> add func regr. tests -> add bdms to cell0 -> patch to remove ports and bdms
23:46:56 melwitt mriedem: maybe we could start off with that on wednesday since any takeaways could apply to later discussions
23:47:02 mriedem https://etherpad.openstack.org/p/nova-queens-retrospective
23:47:14 mriedem mnaser: sounds correct
23:47:54 mnaser ok awesome, i have to fix a few unit tests because of the changes in _bury_in_cell0 which now create bdms and should be ready for review soon
23:53:10 openstackgerrit Murali Annamneni proposed openstack/nova master: Enables MySQL Cluster Support for Nova https://review.openstack.org/446643
#openstack-nova - 2018-02-15
00:02:15 mriedem melwitt: this is what i wanted the retrospective link for http://lists.openstack.org/pipermail/openstack-dev/2018-February/127402.html
00:02:51 melwitt mriedem: a-ha, nice. I was just looking for that email to link in the agenda for tomorrow's meeting

Earlier   Later