17:02:51 <alaski> #startmeeting nova_cells
17:02:52 <openstack> Meeting started Wed Dec 16 17:02:51 2015 UTC and is due to finish in 60 minutes.  The chair is alaski. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:53 <purp> Piece of earth. =]
17:02:53 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:56 <openstack> The meeting name has been set to 'nova_cells'
17:03:00 <leecalcote> Goodwill towards people
17:03:19 <alaski> anyone around for the cells meeting?
17:03:22 <mriedem> o/
17:03:26 <doffm> o/
17:03:29 <rlrossit> o/
17:03:34 * rlrossit lurks in the shadows
17:03:38 <alaski> heh, new faces
17:03:46 <doffm> I warned you ")
17:04:02 <alaski> :)
17:04:09 <alaski> none of the regulars showed up this week though
17:04:15 <alaski> so this'll be quick
17:04:28 <alaski> #link https://wiki.openstack.org/wiki/Meetings/NovaCellsv2
17:04:35 <alaski> #topic cells testing
17:04:48 <alaski> melwitt normally provides the update here
17:04:56 <alaski> but it's been quite on this front for a bit now
17:05:05 <alaski> *quiet
17:05:36 <alaski> I guess I should call out https://review.openstack.org/#/c/225199/
17:05:41 <mriedem> the link doesn't work for the cells v1 testing,
17:05:47 <mriedem> but i haven't heard of any issues with the cells v1 job
17:06:10 <alaski> huh, looks like logstash was upgraded
17:06:24 <alaski> #action alaski redo the cellsv1 testing link
17:06:36 * bauzas waves super late
17:06:37 <mriedem> you just noticed that?
17:06:42 <mriedem> :P
17:06:57 <mriedem> graphite is probably a better indicator of the job status anyway
17:07:00 <mriedem> i could dig up those links
17:07:23 <bauzas> mriedem: we can also ask grafana to be updated
17:07:23 <alaski> heh, I should probably look at logstash more. but you and bauzas do such a great job dissemenating info
17:07:37 <mriedem> one question i had about cells v2 + testing,
17:07:38 <alaski> mriedem: okay, that would be great
17:07:45 <mriedem> was are we at any place today where we could start some very trivial job
17:07:51 <mriedem> like just making sure things setup and start properly
17:08:09 <mriedem> or what is the criteria before we can do something interesting in a CI job for cells v21?
17:08:11 <mriedem> *v2
17:08:39 <alaski> mriedem: if everything works as plans then non-cells turns into cellsv2 mostly without anyone noticing
17:09:03 <alaski> so I don't think we'll need a separate job
17:09:03 <mriedem> oh right
17:09:32 <alaski> there may be some devstack updates to make sure the nova-api db is up and running and new things are configured though
17:09:33 <mriedem> which would also give us neutron
17:09:52 <alaski> yeah
17:09:59 <mriedem> so things like neutron callbacks should implicitly work with cells v2?
17:10:09 <alaski> yes
17:10:12 <bauzas> mriedem: alaski: yup, I feel that should be mostly grenade changes without really needing new tempest coveragre
17:10:15 <bauzas> (hopefully)
17:10:31 * melwitt sneaks in late
17:11:48 <alaski> mriedem: there's going to be a routing layer to send api requests to the right cell for an instance, but it'll be used by default.  and no having to add new calls to it
17:12:16 <alaski> any more on testing?
17:12:35 <alaski> #topic Open reviews
17:12:43 <alaski> this is mostly just advertising https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking
17:12:56 <alaski> there are some cells patches up there, and any news ones should be added there
17:13:21 <alaski> #topic Open Discussion
17:13:39 <doffm> As well as reviews is it worth me trying my hand at: https://blueprints.launchpad.net/nova/+spec/cells-scheduling-interaction?
17:13:53 <doffm> I would need some assistance at first / questions about spec.
17:14:09 <alaski> sure
17:14:11 <melwitt> I did some work to make see how we can get coverage of ssh verification in our tempest job and then found out someone else already did the same thing (tempest config option for secgroups)
17:14:26 <alaski> doffm: I just posted a patch to start it off, but we can certainly collaborate on the spec
17:14:32 <melwitt> gerrit's not working for me right now, I want to link the patch
17:14:36 <doffm> alaski: Sounds good.
17:14:42 <alaski> melwitt: gerrit is upgrading atm
17:14:53 <rlrossit> melwitt: gerrit be down for the next 4 hours
17:15:00 <melwitt> oh
17:15:14 <bauzas> yeah, that's not really impacting me
17:15:16 <bauzas> :)
17:15:20 <bauzas> come in EU, folks
17:15:25 <alaski> melwitt: when you do get the link can you add it to https://etherpad.openstack.org/p/mitaka-nova-priorities-tracking
17:16:00 <melwitt> alaski: sure. it hit a snag, got a -1 review over at tempest so we need to see how we can resolve the issues raised
17:16:16 <alaski> gotcha
17:16:27 <mriedem> melwitt: https://review.openstack.org/#/c/225199/ ?
17:16:46 <melwitt> mriedem: I can't see that right now but if it's the tempest config option for security groups, then yes
17:16:56 <mriedem> melwitt: that's chuck's, yeah
17:17:22 <melwitt> yeah. we need that because currently we've got no test coverage of network connectivity for instances booted with cells
17:17:49 <mriedem> b/c those tests assume security groups
17:17:55 <melwitt> right
17:18:14 <melwitt> we used to have coverage by the devstack tempest job that did the exercises.sh
17:18:26 <melwitt> it at least did pings
17:18:52 <melwitt> I don't remember if it did ssh too
17:18:59 <alaski> was there pushback on the idea itself, or just an issue with the specific changes?
17:19:38 <mriedem> there was some comment about neutron
17:19:50 <mriedem> i didn't really dig in, but noted that we don't have a job for cells v1 + neutron
17:20:02 <mriedem> we could, i had the patches for it, but thought no one wanted that right now
17:20:08 <bauzas> right
17:20:11 <melwitt> I think it's around the fact that the config option only makes sense for cells and not so much in general. that is, security groups are only a problem for cells with nova-network
17:20:42 <mriedem> well, security groups are optional regardless of cells
17:20:48 <melwitt> the other issue raised was how disabling security groups but leaving ssh verification in makes the assumption that the default group will have port 22 open
17:20:50 <mriedem> that's why this is a feature toggle in tempest
17:20:51 <alaski> yeah
17:20:56 <bauzas> it's mostly because we want to be super clear that cells v1 is experimental and that we shouldn't boil the ocean of fixing it
17:21:45 <alaski> how is the default group set?  is that baked into nova, or done via nova-manage or something?
17:21:46 <mriedem> i don't have an answer for the default secgroup and port 22
17:22:00 <mriedem> i thought it was baked in
17:22:06 <mriedem> would have to dig though
17:22:13 <melwitt> I also think it's baked in
17:22:18 <mriedem> or rlrossit would have to look
17:22:35 <alaski> if that's the case I think it would be reasonable to assume it's open, if that's the default
17:22:58 <alaski> since Nova would be unlikely to change that for backwards compat reasons
17:24:00 <melwitt> yeah, I'm not sure what the default port status is or how it gets to be open during the test jobs
17:24:14 <mriedem> https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L4354
17:25:31 <mriedem> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/security_group_default_rules.py
17:25:34 <mriedem> so must be coming in from the api
17:25:45 <mriedem> i dont see anything in nova-manage for it
17:26:01 <alaski> okay.  so assuming port 22 is open isn't really valid then
17:26:34 <rlrossit> wait are we wondering if port 22 is open in the default secgroup from the get-go?
17:26:42 <rlrossit> default usually has nothing open
17:26:48 <melwitt> yeah, that's what I thought
17:26:49 <alaski> yeah, okay
17:26:53 <rlrossit> but an API call can open up whatever you want on the default group
17:27:06 <mriedem> also note that the security group API is completely pluggable
17:27:18 <mriedem> so we can't even say nova-network/neutron here
17:28:37 <alaski> pluggable enough to have a security group api defaulting everything open?
17:29:08 <mriedem> sure
17:29:10 <alaski> could be something added and used for cells if that would work
17:29:57 <melwitt> I guess I'm confused because something must be opening port 22 since the test does work even when skipping the security group creation
17:30:16 <mriedem> i'm checking devstack
17:30:28 <melwitt> that is, we should be able to get it to work without adding something
17:31:17 <rlrossit> my guess would be in tempest if you have checking ssh enabled, it would turn on 22 in the default secgroup for you
17:31:50 <rlrossit> I guess this is semantics, but skipping security group *creation* doesn't count changing the default...
17:32:17 <alaski> melwitt: I wonder if the security group failures are just when one needs to be looked up in the cell
17:32:32 <alaski> security group creation should work, it just doesn't propogate beyond the api
17:32:36 <melwitt> alaski: right
17:33:20 <alaski> setting the default to be open might work, if that's passed down with the boot request properly
17:33:31 <alaski> and using a custom one could still be broken
17:33:54 <alaski> I'm just guessing, it's been a while since I looked at the failures
17:35:11 <melwitt> yeah, I think so. somehow that's how it is currently, with chuck's patch, the server basic ops test works using the default group, somehow port 22 is open. I just can't find where that's being set so far
17:35:47 <mriedem> mtreinish was looking too
17:35:53 <mriedem> maybe we just set an action item to figure it out
17:35:55 <mriedem> and move on
17:36:00 <alaski> yeah
17:36:08 <mtreinish> mriedem: there is a validation config group in tempest that's used to control how tempest ssh's into things
17:36:19 <mtreinish> (well to a certain extent anyway)
17:36:35 <mtreinish> and there are options there to set the resources created as part of setup to enable ssh
17:36:39 <alaski> #action figure out how default security group works will cellsv1, and address concerns around a tempest feature toggle for it
17:36:53 <mtreinish> https://github.com/openstack/tempest/blob/master/tempest/config.py#L671
17:37:18 <mtreinish> specifically https://github.com/openstack/tempest/blob/master/tempest/config.py#L678-L683 seem to be what you're looking for
17:37:41 <mtreinish> the helps probably need to be reworded
17:38:03 <alaski> cool
17:38:12 <doffm> Quick question.. could anyone point me to any discussion about cells v1-v2 upgrades?
17:38:16 <alaski> once gerrit is back up we can look at how that connects with what was being done
17:38:37 <mriedem> https://github.com/openstack/tempest/blob/master/tempest/common/validation_resources.py
17:38:38 <doffm> I don't know.. well i don't know what decisions have been made with regards to upgrades.
17:39:03 <alaski> doffm: I'm not sure anything has been written down about that.  at least not much
17:39:45 <melwitt> mtreinish mriedem: thank you! mystery solved
17:39:47 <alaski> doffm: the basic gist is that a current cellsv1 global cell is treated as a cellsv2 api cell, and cellsv1 cells are migrated into cellsv2 cells
17:40:27 <mtreinish> melwitt: one thing is that those options might not be universally honored yet, it's still an inprogress bp
17:40:32 <alaski> doffm: sorry, a cellsv1 global cell turns into a full cellsv2 deploy, and cellsv1 cells are migrated up into the new cells
17:40:37 <mtreinish> but I think for everything you run on the cells job it's probably fine
17:40:56 <melwitt> okay
17:41:40 <doffm> alaski: Thanks. I think its something that we (here) have to look in to.
17:42:07 <alaski> doffm: it's something I should be pushed into writing down so others can look at it and poke holes in it
17:42:46 <alaski> I have one open discussion topic: we should cancel the next two meetings due to holidays.
17:42:58 <melwitt> +1
17:43:15 <doffm> +1
17:43:37 <alaski> so we would start back at 2100UTC on the 6th of Jan
17:43:49 <alaski> cool
17:43:52 <alaski> anything else today?
17:44:32 <alaski> I'm excited to see some new faces.  welcome aboard
17:44:33 <bauzas> 2100UTC ? great
17:44:34 <alaski> thanks all!
17:44:40 <doffm> Thanks.
17:44:51 <mriedem> you're excited to see my face even?
17:45:07 <mriedem> let's jump to -qa and talk to andreaf
17:45:08 <alaski> a tiny bit
17:45:15 <alaski> #endmeeting