21:00:19 <alaski> #startmeeting nova_cells
21:00:20 <openstack> Meeting started Wed Jun  1 21:00:19 2016 UTC and is due to finish in 60 minutes.  The chair is alaski. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:23 <openstack> The meeting name has been set to 'nova_cells'
21:00:41 <alaski> anyone around today?
21:00:43 <bauzas> \o
21:00:43 <doffm> o/
21:00:45 <melwitt> o/
21:01:04 <alaski> great. I know everyone likes a long meeting but I'm going to try to keep this short today
21:01:12 <alaski> #topic Testing
21:02:18 <alaski> auggy is working on getting a multinode grenade job setup for cells testing. right now she's working on getting a sample job up and running to learn the ropes
21:02:33 <alaski> then she'll modify it for cells
21:02:40 <alaski> but atm she's at pycon
21:03:10 <alaski> #topic Open Reviews
21:03:19 <alaski> my favorite link https://etherpad.openstack.org/p/newton-nova-priorities-tracking
21:03:29 <alaski> anyone have a particular one they'd like to discuss?
21:04:14 <alaski> then we'll move on
21:04:19 <alaski> #topic Open Discussion
21:05:00 <doffm> Quotas spec got an update due to issues pointed out by johnthetubaguy, I have updated so hopefully unblocked now.
21:05:08 <alaski> great
21:05:40 <doffm> Thats all I have today. :)
21:05:49 <alaski> I'm working out upgrade details related to the race condition discussion from last week
21:05:54 <alaski> doffm: cool :)
21:06:03 <melwitt> are there any todos left that need doing other than reviews?
21:06:15 <melwitt> alaski: nice
21:06:50 <alaski> melwitt: there are probably some migrations to be done
21:07:17 <alaski> and there's the work to get the mq and db connection switching actually used
21:07:32 <doffm> Is someone at mirants working on that? (I saw a WIP somewhere)
21:07:37 <alaski> Andrey Volkov picked up the mq portion https://review.openstack.org/#/c/322181/
21:07:39 <alaski> doffm: yep
21:08:10 <alaski> he's new to openstack so guidance on the reviews would be helpful
21:08:18 <doffm> Ok.
21:08:35 <alaski> and I'm not aware of any work on the db side
21:09:13 <melwitt> okay, cool. I'll check with doffm what migrations may be left that I might be able to help with
21:09:24 <melwitt> and/or I could look at the db switching
21:09:37 <doffm> melwitt: Instance groups and Quota specs are still not approved.
21:09:45 <doffm> Both need doing, I'm planning to pick up quotas.
21:09:55 <doffm> (migrations)
21:10:00 <alaski> melwitt: cool
21:10:12 <alaski> oh, also I ran into an issue with instance tags that needs resolving
21:10:12 <melwitt> okay. do we need more specs for migrations? sorry I lost track of that
21:10:42 <doffm> I don't think so. Its easy to lose track so I should go back and make sure.
21:10:48 <doffm> I think thats it from our summit discussions.
21:11:30 <doffm> Sorry yes, we need to do all the resource provider stuff.
21:11:38 <melwitt> ah, right
21:11:39 <doffm> I don't know what the situation is there, I have lost track.
21:12:03 <bauzas> what do you want to know ?
21:12:10 <mriedem> o/
21:12:39 <bauzas> doffm: what do you mean by looking at the r-p ?
21:12:52 <alaski> I think it's mostly settled now right, it's just about moving what's in place and putting new things in the api db
21:12:57 <doffm> Who is going to do the db migration?
21:13:06 <bauzas> doffm: for aggregates N?
21:13:17 <alaski> dansmith has been working on it I believe
21:13:17 <bauzas> sorry, confused
21:13:24 <doffm> I guess thats what I'm asking, I don't know if there is a spec for the RP tables to be moved, or if we need a spec for that.
21:13:31 <bauzas> which db migration are you talking about ? inventories?
21:13:42 <doffm> Yeah.
21:13:57 <bauzas> oh, that's mostly *not* a DB migration
21:14:04 <bauzas> rather a new creation
21:14:13 <bauzas> and we merged a bit of that
21:14:18 <mriedem> the RP table move is part of the generic-resource-pools blueprint
21:14:22 <alaski> https://review.openstack.org/#/c/315682/
21:14:27 <doffm> Ok, thanks.
21:15:52 <alaski> so for instance tags, I realized (or Tempest beat me up about it) that instance tags can be set at any point in an instance lifecycle
21:15:52 <bauzas> (btw. saw the Aggregate series being a bit merged now)
21:16:20 <doffm> bauzas, everyone: thanks for reviews.
21:16:37 <alaski> I'd like to change it so that instance tags can be sent at boot time(they can't now), and then can't be changed until the instance is active
21:17:01 <alaski> but I haven't been able to push on that yet
21:17:23 <alaski> so that's also up for grabs melwitt
21:17:32 <melwitt> hm, so API change? sounds kinda big
21:17:45 <alaski> yeah
21:17:51 <melwitt> as in, a big deal changing the semantics
21:17:59 <alaski> adding them at boot time should be fairly non controversial
21:18:00 <bauzas> yup
21:18:11 <alaski> restricting when they can change is a big one
21:18:38 <doffm> Makes sense though. From a 'cloud applications, my instances is cattle not a pet' perspective.
21:18:40 <melwitt> right, okay
21:19:00 <alaski> but since they're intended to be used for scheduling being able to change them before scheduling is sort of odd
21:19:02 <woodster_> o/
21:19:03 <melwitt> alaski: is this captured anywhere on a review or ML that I missed?
21:19:09 <melwitt> the problem you ran into I mean
21:19:12 <mriedem> tags are used for scheduling?
21:19:27 <alaski> mriedem: not yet, but they're part of jay's generic scheduler proposal
21:19:41 <mriedem> to replace server groups
21:19:44 <alaski> melwitt: just a test failure on one of my patches, let me dig that up
21:19:49 <alaski> mriedem: yeah
21:20:01 <melwitt> alaski: I can find it, just needed a hint in the direction
21:20:03 <doffm> Server groups are getting replaced?
21:20:04 <mriedem> is that going to make newton?
21:20:10 <alaski> melwitt: I think it was https://review.openstack.org/#/c/263927/
21:20:20 <alaski> mriedem: no
21:20:35 <alaski> doffm: that's the not explicitly stated goal
21:20:36 <mriedem> ok, so let's ignore that for now :)
21:20:48 <mriedem> but this is a thing that breaks for cells v2 it sounds like
21:20:58 <melwitt> I guess this is news to me, the instance tags thing as part of the resource pools stuff. will go look back at that
21:21:09 <mriedem> melwitt: i don't think it's part of that
21:21:10 <mriedem> something else
21:21:21 <mriedem> something much more sinister!
21:21:28 <alaski> right, it's just affinity/anti-affinity I believe
21:21:44 <bauzas> alaski: well, it's a bit early to discuss about jay's spec I think
21:21:45 <melwitt> yeah, usually that's the server groups
21:21:55 <mriedem> so how does this fail for cells v2?
21:22:04 <bauzas> but I agree, server groups should die in fire
21:22:05 <alaski> mriedem: yes, what breaks is that if you set a tag before there's an instance in a cell there's nowhere to store the tag
21:22:36 <bauzas> like, try to boot an instance on another host but the host given by the affinity server group. good luck.
21:22:40 <alaski> every other resource like this I saw is gated behind a vm_state=ACTIVE check
21:22:49 <alaski> but instance tags are special
21:23:11 <mriedem> it was probably just not thought of
21:23:18 <melwitt> +1
21:23:20 <alaski> right
21:23:34 <mriedem> so you can't provide tags on boot today?
21:23:43 <alaski> correct
21:23:44 <bauzas> nope
21:23:55 <mriedem> but while scheduling you add the tag
21:23:58 <mriedem> and then kablammo
21:24:01 <alaski> which also seems like an oversight
21:24:03 <melwitt> okay so maybe that's not as big of a deal then. microversion and explain in release note and doc
21:24:21 <bauzas> not sure I see where tags are in use by the scheudler...
21:24:25 <mriedem> they aren't
21:24:29 <mriedem> it's before the instance is in a cell
21:24:42 <mriedem> so boot, add tag, place in cell - boom
21:25:03 <mriedem> hmm, i think that's maybe a bug fix?
21:25:05 <alaski> the add tag goes boom
21:25:13 <mriedem> not the boot thing, but restricting the add tag until it's active
21:25:19 <bauzas> it goes boom because it's in the cell db N
21:25:20 <bauzas> ?
21:25:23 <mriedem> i think i'd be good with bug fixing that in
21:25:38 <mriedem> providing tags on boot is an api change and spec
21:25:43 <mriedem> and not required for cells v2 right now
21:25:53 <alaski> mriedem: okay. we can propose it and see how it goes
21:26:07 <bauzas> oh, nvm my question, I had the reason
21:26:32 <melwitt> yeah, it'll depend on whether it's broken in its current form
21:26:36 <alaski> mriedem: yeah, that part's not required. my breakage is fixed by not setting tags before picking a cell
21:27:04 <mriedem> yeah let's just bug fix that
21:27:09 <mriedem> easy peasy
21:27:51 <alaski> cool
21:28:03 <alaski> melwitt: I think it's unintended in its current form
21:28:27 <alaski> and we need a workaround or fix to move forward on cells
21:29:12 <alaski> that's all I've got today
21:29:15 <alaski> anyone else?
21:29:59 <alaski> great
21:30:01 <alaski> thanks all!
21:30:06 <alaski> #endmeeting