21:00:35 <mikal> #startmeeting nova
21:00:36 <openstack> Meeting started Thu Jul 30 21:00:35 2015 UTC and is due to finish in 60 minutes.  The chair is mikal. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:39 <openstack> The meeting name has been set to 'nova'
21:00:42 <dansmith> o/
21:00:43 * bauzas holding off until nova meeting begins
21:00:43 <mnestratov> o/
21:00:43 <melwitt> o/
21:00:43 <n0ano> o/
21:00:43 <bauzas> hah
21:00:43 <alaski> o/
21:00:44 <earlephilhower> o/
21:00:45 <scottda> hi
21:00:45 <bauzas> \o
21:00:48 <mikal> Good morning!
21:00:52 <xyang> Hi
21:00:57 <mikal> So, let's get started
21:01:04 <mikal> #topic [kml: 20150725-1]
21:10:02 <dansmith> mikal: I think we've said it.
21:10:04 <mikal> #topic Critical bugs
21:10:08 <mikal> None that I can see?
21:10:32 <mikal> #topic Stable branch status
21:11:01 <mikal> There are definitely reviews for kilo and juno in gerrit
21:11:09 <mikal> But I don't have the state of those in my head
21:11:15 <dansmith> we just had a release i think
21:11:18 <mikal> So unless someone else has stuff to say here we'll move on?
21:11:27 <dansmith> so there are things probably pending that freeze being lifted
21:11:49 <dansmith> nothing specifically burning that I know of though
21:11:54 <mikal> Cool
21:12:08 <mikal> #topic Reminders
21:12:10 <bauzas> just something about cells
21:12:20 <bauzas> but we agreed on saying it was unsupported :D
21:12:28 <mikal> John has asked people to remember to use the priority tracking etherpad when reviewing
21:12:38 <mikal> And to take a look at the trivial patch list as well
21:12:45 <dansmith> there are a list of non-priority features to review on there,
21:12:46 <mikal> But I guess its kind of a moot point with a wedged gate
21:12:52 <dansmith> ordered by age.. for the deadline today
21:13:01 <dansmith> I've been going through and reviewing those, marking the merged ones as merged
21:13:15 <mikal> Cool
21:13:27 <dansmith> would be nice if the cores that are active before the actual deadline could take a trip through
21:13:34 <med_> (thanks all who approved my trivial devref related nova bugfix early this week)
21:13:34 <dansmith> starting at line 191 (currently) in the pad
21:13:57 <mikal> dansmith: are you ordering me to travel more?
21:14:12 <dansmith> mikal: s/trip/looksee/
21:14:21 <mikal> Ahhh, I see
21:14:22 <mikal> Ok
21:14:29 <mikal> Shall we move on to stuck reviews?
21:14:36 <dansmith> aye
21:14:42 <mikal> #topic Stuck reviews
21:14:56 <nic> The first one is mine, the second one looks like cop+paste errors
21:14:56 <rodolfo-alonso> hi
21:14:58 <mikal> We have two here, which I think is at least partially because we tlked through this process at the mid-cycle again
21:15:02 <rodolfo-alonso> sorry
21:15:19 <mikal> nic's is https://review.openstack.org/#/c/122523/
21:15:27 <mikal> nic: : want to intorduce it?
21:15:44 <dansmith> is this stuck?
21:16:09 <dansmith> no review since feb
21:16:13 <dansmith> != stuck
21:16:14 <openstack> dansmith: Error: "=" is not a valid command.
21:16:18 <dansmith> heh
21:16:18 <mikal> Well, nice has been rebasing it for two months, so I think he still expects it to stand a chance of merging
21:16:26 <nic> Sure.  The short, short, short version: booting from AMIs sets the kernel console params such that /dev/console is attached to a read-only device, making "rescue mode" on distros that support it, unusable
21:16:28 <mikal> nic even
21:16:41 <dansmith> right, but
21:16:50 <dansmith> "Please note "stuck review" means a review where there is some disagreement that needs resolving. Its not for reviews that just haven't had attention,"
21:17:02 <nic> Since unilaterally flopping the params caused problems, the current patch lets operators define the default to "whatever the hell they want"
21:17:25 <med_> +1 dansmith
21:17:52 <bauzas> moving on then ? :)
21:17:56 <nic> II was pointed in a direction to fix it, and when I went in that direction, I was told to go in anotehr direction
21:18:05 <rodolfo-alonso> yes
21:18:10 <rodolfo-alonso> sorry for c+p
21:18:14 <nic> So there's disagreement amongst you guys as to what should be done here
21:18:22 <rodolfo-alonso> the problem is the solution proposed
21:18:27 <rodolfo-alonso> it's far more complicated
21:18:42 <dansmith> nic: well, this disagreement was last cycle and not really preventing this from merging
21:19:03 <dansmith> I don't actually see anyone telling you to put it back into the config
21:19:12 <mikal> I was hoping that what we could do is quickly discuss next steps for this one, instead of having a process discussion
21:19:43 <dansmith> nic: last review from danpb still asserted it should be not global config
21:19:47 <dansmith> which I agree with
21:19:54 <mikal> It seems to me that a spec for this one for M is probably where we're at given people have questions about the design and it has an impact on operators?
21:20:16 <dansmith> maybe.. I feel like if it was an image/flavor property, we'd be done by now, without a spec :)
21:20:37 <mikal> Well, ignoring the tempest two step
21:20:41 <dansmith> which is what all the feedback has been, AFAICT
21:20:45 <mikal> (Which might not be needed if this was an image property)
21:20:57 <bauzas> that reminds me another bug about tty logging
21:21:07 <bauzas> given what danpb said at last
21:21:08 <dansmith> danpb says it's already supported
21:21:08 <nic> But we can't go chasing images around the cloud, setting proerties on them.  A system-wide default is the only sane way to approach this when you've got the million-monkeys problem
21:21:27 <mikal> nic: you can set it for flavors though right?
21:21:37 <dansmith> I think several people disagree with your assertion
21:23:21 <dansmith> yeah,
21:23:21 <mikal> dansmith: how does a deployer ensure that new images uploaded have the right properties to work with their cloud?
21:23:23 <dansmith> this is already available here:
21:23:31 <nic> It's image metadata; and if you set this, you have to backfill all the fidgety bits that Nova fills in for you automatically
21:23:33 <dansmith> guest.os_cmdline = img_props.get('os_command_line')
21:23:56 <nic> Right.  You can only replace the cmdline, you can't fix parts of it
21:23:57 <dansmith> mikal: put it in the flavor?
21:24:42 <dansmith> nic: so break it into tokens and merge the tokens from the image into what we've collected so far?
21:25:08 <bauzas> nic: FYI https://review.openstack.org/#/c/188058/
21:25:48 <nic> danpb seems to not like that one, either
21:26:04 <mikal> So, I think there are some suggestions on how to proceed
21:26:12 <nic> Yes, we can move on
21:26:14 <mikal> nic: how about you and I sit down and talk this through a bit more next week?
21:26:22 <nic> Can do
21:26:26 <mikal> Cool
21:26:47 <mikal> #topic Open Discussion
21:27:01 <rodolfo-alonso> Sorry?
21:27:05 <rodolfo-alonso> I have a stuck review
21:27:10 <mikal> rodolfo-alonso: oh, did I miss something?
21:27:19 <rodolfo-alonso> Yes
21:27:24 <mikal> Sorry, one sec
21:27:26 <mikal> #undo
21:27:27 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0xa958a90>
21:27:30 <rodolfo-alonso> I c+p wrong
21:27:43 <mikal> rodolfo-alonso: Ok, so what are we talking about?
21:27:46 <rodolfo-alonso> I have this https://review.openstack.org/#/c/189279/8/doc/source/filter_scheduler.rst
21:27:59 <rodolfo-alonso> the problem is the solution proposed is far more complicated
21:28:16 <rodolfo-alonso> It's cleaner to have an isolated class
21:28:57 <bauzas> rodolfo-alonso: well, I really care about our user interfaces
21:28:59 <mikal> bauzas: sounds like one for you?
21:29:18 <rodolfo-alonso> I know and I undertand
21:29:34 <bauzas> rodolfo-alonso: each filter we're adding is giving another possibility for an user
21:30:19 <bauzas> rodolfo-alonso: so, I don't want to block you because of a specific thing, but I think the behaviour is quite close to what we already have
21:30:23 <rodolfo-alonso> That's the key, add a new possibility, isn't it?
21:30:34 <rodolfo-alonso> No, it's not
21:30:37 <rodolfo-alonso> I
21:30:39 <rodolfo-alonso> Sorry
21:30:49 <rodolfo-alonso> We studied the behaivour
21:30:55 <rodolfo-alonso> of the other filter
21:31:02 <rodolfo-alonso> and it's better (and cleaner)
21:31:09 <rodolfo-alonso> to have this other class
21:31:16 <bauzas> so, another option
21:32:45 <bauzas> like I'm saying, I'm trying to see the difference with what we currently have and see how we can diff that
21:33:12 <dansmith> rodolfo-alonso: it's important to articulate why a thing is better, not just assert it
21:33:15 <rodolfo-alonso> Sean Mooney all
21:33:26 <rodolfo-alonso> already explained it very well
21:33:41 <bauzas> rodolfo-alonso: I certainly understand that your proposal gives more possibilities
21:34:01 <rodolfo-alonso> the AggregateInstanceExtraSpecsFilter does not allow you to reserve portions of your cloud for vms that require limited resources this filter does. it would not be a small change to extend the AggregateInstanceExtraSpecsFilter to cater for this usecase.
21:34:04 <bauzas> rodolfo-alonso: and I also understand that the existing AggregateInstanceExtraSpecsFilter is not enough to fit your expected behaviour
21:34:23 <bauzas> rodolfo-alonso: what if you invert the logic ?
21:34:24 <rodolfo-alonso> No, because the logic is restrictive
21:34:38 <bauzas> rodolfo-alonso: I really care about keeping the existing behaviour
21:34:53 <bauzas> rodolfo-alonso: but I don't care about the implementation of AggregateInstanceExtraSpecsFilter
21:35:09 <bauzas> rodolfo-alonso: we have hints that define our contract
21:35:17 <rodolfo-alonso> The existing behaviour it's not going to be modified
21:35:19 <bauzas> well, not hints, but agg metadata
21:35:41 <dansmith> mikal: I feel like this can probably happen during non-meeting time in #-nova
21:35:47 <rodolfo-alonso> Ok
21:35:50 <bauzas> rodolfo-alonso: IIUC, the AggregateInstanceExtraSpecsFilter is a subcase of what you're going to propose
21:36:00 <mikal> bauzas: do you think in hindsight this is a case where we shouldn't have approved the blueprint as trivial, because of the user interface implications of a new filter?
21:36:29 <bauzas> mikal: that's the problem, we have an user interface called aggregate metadata
21:36:33 <mikal> bauzas: can you sit down with rodolfo-alonso in -nova and talk this thorugh sometime and get back to us with what comes from that?
21:37:00 <bauzas> mikal: sure thing - provided not in the next 2 weeks
21:37:06 <bauzas> or I defer to jaypipes :)
21:37:13 <mikal> Ok, that's fair
21:37:22 <mikal> I think we need to move on or we'll not end in time
21:37:23 <rodolfo-alonso> thanks!
21:38:24 <mikal> #topic Open Discussion
21:38:24 <bauzas> rodolfo-alonso: let's discuss that offline in #nova right after the meetinhg
21:38:24 <mikal> So there are a few points on the minutes for here
21:38:24 <rodolfo-alonso> bauzas: perfect!
21:38:25 <mikal> John wants a spec tweak reviewd, but I think I can just do that after the meeting
21:38:58 <mikal> nic: its too late for that spec you link to for liberty unfortunately, the deadline for new specs passed quite a while ago
21:39:08 <mikal> nic: but I think the ceph bug fix can be reviewed on its merits
21:39:24 <nic> The groundswell of support for that spec makes it such that I had to at least try
21:39:36 <nic> People are kind of sort of going a little crazy for it
21:39:41 <mikal> nic: yeah, its a process thing unfortunately
21:39:57 <mikal> nic: we're in the phase of the release where we're stabilizing, not adding new things
21:39:59 <vilobhmm> mikal : as per https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule looks like the feature free is aug 18 for liberty which initially was july 16th i guess…so does that mean that code cans till be submitted for features/specs that have already been accepted for liberty ?
21:40:04 <nic> Somebody (I forget who) tried to language-lawyer it such that it's actually an old spec and can get let through
21:40:09 <nic> Gotta admire that kind of gumption
21:40:30 <mikal> vilobhmm: the freeze for non-priority features is July 30 though'
21:40:46 <mikal> vilobhmm: after that, we only merge high priority features (as defined at the summit in Vancouver)
21:41:05 <vilobhmm> mikal : ok..thanks!
21:41:21 <mikal> alaski: are you around to talk about this db flavor comment int the agenda?
21:41:26 <alaski> I am
21:41:38 <bauzas> oh right
21:41:44 <alaski> so belmoreira is in the process of creating flavor tables in the new nova_api db
21:41:45 * bauzas giggles
21:41:54 <alaski> and a question came up about http://git.openstack.org/cgit/openstack/nova/tree/nova/db/sqlalchemy/migrate_repo/versions/216_havana.py#n88
21:42:04 <alaski> the db migration that prepopulates flavors
21:42:13 <dansmith> ugh
21:42:17 * med_ felt that pain today
21:42:21 <med_> it don't work
21:42:21 <alaski> basically, can we stop doing that?
21:42:28 <bauzas> +1
21:42:36 <mikal> So, what happens for new installs?
21:42:43 <bauzas> devstack-ish rather?
21:42:48 <mikal> An admin has lavors before their first thing?
21:42:51 <dansmith> we really need to have some tool to do that
21:42:57 <mikal> Sorry, has to create flavors?
21:42:58 <dansmith> because doing it in a migration is just insanity
21:43:09 <bauzas> why not a devstack change ?
21:43:11 <alaski> mikal: yes, that would be an alternative
21:43:13 <dansmith> nova-manage install-default-flavors
21:43:17 <bauzas> and then a Depends-On tag ?
21:43:20 <alaski> properly documented of course
21:43:21 <mikal> dansmith: I would not be opposed to that
21:43:42 <mikal> bauzas: we need to care about more than just devstack here though right?
21:43:44 <melwitt> bauzas: well, that's not a way to deploy nova (devstack)
21:44:00 <dansmith> or even /usr/share/nova/doc/contrib/make_sample_flavors.sh
21:44:08 <bauzas> mikal: melwitt: agreed but I think vendors are keen to propose that
21:44:10 <bauzas> ?
21:44:16 <bauzas> dansmith: yeah that ^
21:44:17 <alaski> I'm not opposed to nova-manage, but would prefer docs and perhaps a script like dansmith just suggested
21:44:26 <dansmith> script is better I think
21:44:32 <mikal> I think you could rgue its weird that we tell admins they will always have flavors which might be grossly inappropriate for their cloud
21:44:39 <bauzas> I mean, a nova-manage cmd should huge for me
21:44:40 <melwitt> yeah
21:44:49 <alaski> mikal: right, and a few need to then go strip them out
21:44:49 <dansmith> mikal: arguing about the existing behavior right?
21:44:53 <bauzas> mikal: exactly
21:44:55 <mikal> For example, an ironic only nova would never ever want a m1.tiny
21:45:08 <mikal> dansmith: yes, I am agreeing that we should stop doing this thing
21:45:14 <dansmith> mikal: not true, I'm planning to go public with my Rpi cloud soon
21:45:16 <mikal> It doesn't seem like a bug fix though
21:45:19 <mikal> Is this a M spec?
21:45:36 <alaski> this is an L cells spec, so still under priority rules
21:45:36 <dansmith> I dunno, it's a weird grey area
21:45:40 <bauzas> well, technically a DB migration :(
21:45:46 <dansmith> bauzas: not really
21:45:57 <alaski> well, it's sort of something that wasn't thought about in the spec
21:45:58 <bauzas> we could just modify 218_havana.py ?
21:46:05 <dansmith> bauzas: yes, IMHO
21:46:10 <bauzas> uh
21:46:14 <bauzas> ok
21:46:26 <dansmith> kinda defeats the purpose to do anything else, right?
21:46:34 <dansmith> it's not schema, it's just data
21:46:38 <mikal> We'd need to make sure the docs on this one are sane too
21:46:59 <bauzas> and UpgradeImpact as well...
21:47:12 <mikal> alaski: I think the punch line is no one thinks your proposal is a bad idea
21:47:40 <alaski> what we can do is just not worry about copying that logic to the new tables
21:47:49 <alaski> and leave removal for later if that helps
21:47:55 <dansmith> alaski: ah, we drop the behavior by attrition
21:48:00 <mikal> Heh
21:48:11 <alaski> exactly
21:48:15 <dansmith> and then we can drop the actual data in the migration when we drop the old flavor tables from the cell schemas I guess
21:48:26 <dansmith> i.e once we start using api for flavor lookups,
21:48:35 <dansmith> the data that gets installed by the first migration will just never be seen
21:48:36 <bauzas> +1
21:48:38 <dansmith> wait a cycle, drop
21:48:45 <bauzas> sounds neat
21:48:45 <dansmith> alaski: right?
21:48:49 <mikal> I like that plan
21:48:52 <alaski> dansmith: yep
21:48:58 <dansmith> sounds good to me
21:49:02 <mikal> alaski: sounds like you have permission then
21:49:04 <alaski> the main thing now is to not copy that over
21:49:08 <alaski> excellent
21:49:20 <mikal> Last thing on the agenda then
21:49:25 <mikal> melwitt: you have a favourite bug?
21:49:58 <melwitt> mikal: :) I just wanted to tell people about it, I've been seeing a lot of comments on it the past week https://bugs.launchpad.net/bugs/1396965
21:49:59 <openstack> Launchpad bug 1396965 in OpenStack Compute (nova) "Add capability to detach root device volume of an instance, when in shutoff state" [Wishlist,Opinion]
21:49:59 <uvirtbot> Launchpad bug 1396965 in nova "Add capability to detach root device volume of an instance, when in shutoff state" [Wishlist,Opinion]
21:50:01 <uvirtbot> Launchpad bug 1396965 in nova "Add capability to detach root device volume of an instance, when in shutoff state" [Wishlist,Opinion] https://launchpad.net/bugs/1396965
21:50:07 <tpatil_> mikal: I also want to talk about my spec later
21:50:41 <melwitt> people seem to care about it a lot so I just wanted to mention it for general awareness
21:50:41 <mikal> tpatil_: the problem there is we passed the spec approval deadline a long time ago for L, that spec can't get approved until M at this point
21:50:51 <mikal> melwitt: sounds fair
21:51:15 <mikal> tpatil_: oh, its a backlog spec
21:51:25 <mikal> tpatil_: I didn't notice that at first, sorry
21:51:25 <tpatil_> mikal: yes
21:52:08 <mikal> tpatil_: I think you're going to have to hang ten for a few more days, a lot of the reviewers are tied up in mid-cycle travel and the non-priority freeze right now
21:52:18 <tpatil_> mikal: OK
21:52:21 <mikal> But things should be a bit better in a week or so
21:52:21 <dansmith> speaking of that: https://review.openstack.org/#/c/205277/
21:52:34 <dansmith> I think that reflects what we discussed, just needs a +W
21:52:48 <mikal> dansmith: I will review after the meeting then
21:52:54 <dansmith> thanks
21:52:58 <mikal> dansmith: not that it will merge...
21:53:05 <mikal> So, we have five more minutes
21:53:07 <mikal> Use them wisely
21:53:08 <dansmith> heh
21:53:53 <hshiina> excuse me, one of my non-priority patches has not been reviewed by core reviewers.
21:54:05 <hshiina> https://review.openstack.org/#/c/202605/
21:54:32 <med_> sounds like a feature
21:55:04 <med_> ah, and it is referenced, my bad
21:56:08 <mikal> hshiina: all I can offer is that I will try to get a review done on that before the deadline
21:56:24 <melwitt> I don't see that one in https://etherpad.openstack.org/p/liberty-nova-priorities-tracking
21:56:49 <dansmith> I'm -1ing that right now
21:56:53 <dansmith> so probably not going to make it
21:57:49 <mikal> I guess discussion of that one continues in the review then
21:58:03 <mikal> Shall we wind this meeting up?
21:58:34 <mikal> I will take silence as yes
21:58:37 <mikal> Thanks peoples!
21:58:41 <mikal> #endmeeting