14:00:10 <edleafe> #startmeeting nova_scheduler
14:00:10 <openstack> Meeting started Mon Mar  6 14:00:10 2017 UTC and is due to finish in 60 minutes.  The chair is edleafe. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:13 <openstack> The meeting name has been set to 'nova_scheduler'
14:00:20 <edleafe> ANyone around today?
14:00:43 <cdent> o/
14:01:30 <bauzas> \o for 25 mins
14:01:34 <edleafe> my we're a popular bunch!
14:01:40 <jroll> \o
14:02:30 <cdent> ommmmm
14:02:50 <edleafe> Well, let's start
14:02:57 <edleafe> #topic Specs and reviews
14:03:18 <edleafe> Nothing was added to the agenda, so let's go over the current focus
14:03:26 <edleafe> Traits spec:
14:03:27 <edleafe> #link https://review.openstack.org/#/c/345138/
14:03:57 <edleafe> I was hoping that jaypipes would explain some of his concerns about the API
14:04:11 <edleafe> I mean, I get it, but it's not totally clear
14:04:52 <bauzas> I need a second loop over that spec
14:04:53 <cdent> you mean on the actions on /traits ?
14:05:01 <edleafe> yeah
14:05:22 <edleafe> cdent: BTW I agree with the idempotent PUT
14:05:34 <cdent> that's because it's right ;)
14:05:42 <diga> o/
14:05:50 <edleafe> of course!
14:06:31 <cdent> I think the issue with /traits is would you ever want to replace or remove everything?
14:07:31 <edleafe> cdent: so should you be able to delete one?
14:07:33 <edleafe> two?
14:07:34 <edleafe> ten?
14:07:50 <cdent> just one, at its own URL?
14:08:06 <cdent> I'm not a fan of writes on collection URLs
14:08:23 <edleafe> You mean like PUT /traits?
14:08:29 <cdent> but I'm not sure if that's jay's issue. I pretty much had the same question (if you see my last comment I was wondering where it went)
14:08:39 <cdent> yes
14:09:46 <edleafe> Well, PUT is pretty clear in its intended behavior. Maybe a POST for the "add to the current set of traits" case?
14:11:31 * cdent shrugs
14:11:42 * alex_xu waves late
14:11:50 <cdent> I don't know what's wrong with singular PUTs to /traints/{trait}
14:11:58 <cdent> s/nts/ts/
14:12:04 <edleafe> cdent: nothing
14:12:17 <cdent> edleafe: _only_ singluar puts
14:12:32 <edleafe> it's a PUT with a JSON body that is destructive
14:12:38 <edleafe> oh
14:12:50 <edleafe> that could be tedious :)
14:13:24 <cdent> we have computers to do tedious things for us (and loops!) and thus make code less complicated
14:13:29 <edleafe> especially with the PUT /rp/{id}/traits/{trait} format
14:13:43 <edleafe> where you have to associate traits with RPs
14:14:03 <alex_xu> jaypipes and dansmith just worry about the "PUT/DELETE /traits" is unsafe. The user may delete all the traits accidental
14:14:04 * cdent shrugs
14:15:22 <edleafe> So we would also have to remove the CLI stuff like: openstack resource-provider trait add $RP_UUID  --traits $TRAIT $TRAIT...
14:16:13 <alex_xu> edleafe: yea, I forget cleanup that
14:16:30 <edleafe> alex_xu: that's what I'm not clear on. If the traits are not associated with anything, why is that a problem?
14:16:49 <edleafe> alex_xu: if any trait is in use, return 409
14:17:02 <alex_xu> edleafe: yes, I have same thinking with you, it isn't very unsafe
14:17:03 <edleafe> nothing gets deleted
14:17:44 <johnthetubaguy> maybe add that discussion in the alternatives section in the spec? would that help?
14:17:47 <alex_xu> but i'm ok to add those API when found we really same bulk create
14:17:51 <alex_xu> later
14:18:00 <johnthetubaguy> 409 for in use seems a nice compromise to me
14:18:26 <johnthetubaguy> makes it hard to be accidentally destructive, or something
14:18:34 * jroll is having a hard time seeing a use case for "delete all custom traits"
14:18:43 <cdent> jroll: exacty
14:18:45 <alex_xu> at least PUT/DELETE /traits is called by the deployer, it isn't something we need in the scheduler report client
14:19:10 <johnthetubaguy> oh, delete all, yeah, not sure why thats needed
14:19:17 <edleafe> jroll: what about wanting to create all custom traits at once?
14:19:30 <jroll> edleafe: I see no deletes there :)
14:19:38 <edleafe> With a PUT there would be
14:19:59 <edleafe> (if any existed beforehand)
14:20:08 <jroll> maybe there's something I haven't read yet
14:20:36 <jroll> edleafe: so your use case is "instead of adding to existing traits, a deployer might update custom traits by deleting all and re-adding"?
14:20:49 <cdent> replacing entire set
14:21:05 <edleafe> Well, that's the semantics of a PUT
14:21:19 <johnthetubaguy> what about adding the simple one by one bits now, and adding the bulk later, if we end up needing them?
14:21:32 <edleafe> johnthetubaguy: that's what cdent was proposing
14:21:43 <alex_xu> johnthetubaguy: +1 to that
14:21:49 <johnthetubaguy> I guess I am +1 cdent then
14:22:00 <alex_xu> so +1 to cdent :)
14:22:14 <jroll> yeah I'm +1 for that
14:22:15 <edleafe> FWIW, I don't have a use case for this in mind. I just didn't understand the scary destructive potential
14:22:23 * jroll now sees the PUT case, just isn't sure it's needed yet
14:22:29 <johnthetubaguy> could always push the other ideas into a follow spec, if people want to have that conversation, just makes it non blocking (you probably said that already, sorry)
14:23:20 <alex_xu> It is really a API only called once after a new cloud deployment.
14:24:01 <edleafe> So to summarize: we'll update the spec to include these concerns, and if at a later date we find we need to add those API calls back, we'll handle that in a follow-up spec
14:24:06 <edleafe> Is that about right?
14:24:15 <cdent> sounds right
14:24:48 <bauzas> not sure I followed the concerns, so please -W the spec with the consensus
14:25:20 * bauzas needs to disappear per $family dutiezs
14:25:22 <johnthetubaguy> keeping it simple sounds good, so +1
14:25:24 <edleafe> #agreed We will update the traits spec to remove the mass creation/deletion of traits, and if at a later date we find we need to add those API calls back, we'll handle that in a follow-up spec
14:25:37 <alex_xu> +1
14:25:43 <bauzas> edleafe: thanks for summarizing, I'm good with that
14:26:23 <edleafe> OK, let's move on
14:26:24 <edleafe> Traits POC series, starting with:
14:26:25 <edleafe> #link https://review.openstack.org/#/c/416007/
14:27:00 <edleafe> alex_xu: any concerns or problems with that series?
14:27:08 <alex_xu> edleafe: thanks, I have three patches up for review
14:27:34 <alex_xu> I think the only interesting thing is in https://review.openstack.org/#/c/441829/
14:28:11 <alex_xu> It adds a TraitCache, more than ResourceClassCache, it adds one more cache based on namespace
14:28:46 <edleafe> alex_xu: So is the concern about using underscore as a namespace separator?
14:29:26 <alex_xu> edleafe: no, the underscore already get some agreement, currently we already change to use underscore in anywhere
14:29:56 <edleafe> alex_xu: ok, good
14:30:06 <alex_xu> the concern I guess is more about whether people like that namespace based cache and whether the data structure is good for people
14:30:22 <edleafe> Are there any disagreements to discuss?
14:30:43 <edleafe> heh, you type faster :)
14:31:07 <alex_xu> really? I type faster :)
14:31:46 <alex_xu> Matthew have a suggestion about using a tree of dicts. But he also is looking for more comments.
14:32:11 <alex_xu> Just introduce the interesting thing at here, and looking for more feedback on the reviews
14:32:25 <edleafe> OK, then all of us should review https://review.openstack.org/#/c/441829/ for opinions on the caching by namespace design
14:32:37 <alex_xu> edleafe: yea, thanks
14:33:14 <edleafe> There is also the Nested Resource Providers series, starting with:
14:33:17 <edleafe> #link https://review.openstack.org/#/c/415920/
14:33:38 <edleafe> Sort of stagnant right now
14:33:39 <cdent> no recent activity on that
14:33:41 <cdent> jinx
14:33:55 <cdent> I've just realized that nobody bought me a coke in Atlanta :(
14:33:57 <edleafe> Typing speeds: alex_xu > edleafe > cdent
14:34:18 <alex_xu> \o/
14:34:49 <edleafe> Let's move on
14:34:53 <edleafe> #topic Bugs
14:35:00 <edleafe> Any new bugs to discuss?
14:35:23 <diga> I have to discuss on notification review
14:35:29 <diga> can I ?
14:35:55 <cdent> sure
14:35:58 <diga> cdent: https://review.openstack.org/#/c/423872/ about your comment on line 26:
14:35:58 <cdent> link?
14:36:02 <diga> These use cases sound a bit made up. I mean they sound reasonable and all, but do we have actual use cases expressed by real humans for these notifications? If so, it would be great if we could capture those
14:36:21 <diga> cdent: I posted your comment above
14:36:51 <cdent> Yeah, that's just a general concern about us adding notifications for everything everywhere. Is there actually someone or something that's going to do something with these?
14:36:55 <diga> cdent: I dont understand "use cases expressed by real humans for these notifications"
14:37:06 <diga> cdent: can you explain what you want here
14:37:38 <cdent> sure, so you say "maintainer wants to get the notifications when there are resources..."
14:37:48 <cdent> My question is _why_ does the maintainer want that?
14:38:10 <diga> okay
14:38:20 <edleafe> Or to rephrase: what could they possibly do with that information?
14:38:27 * cdent nods
14:38:38 <jroll> I know our public cloud would love to get a notification when a compute node comes online or goes offline
14:38:56 <cdent> jroll: but that's not what this is, this is a proxy for that
14:39:06 <jroll> the latter you could alert on
14:39:24 <diga> notifications is for getting actual status of resource on some time interval
14:39:33 <jroll> cdent: true, do we have notifications in nova for compute_nodes changes?
14:39:43 <diga> cdent: will update the info on that
14:40:08 <cdent> diga: the question continues from there: what do you do with that status?
14:40:31 <cdent> What I'm trying to avoid here is just creating notifications because we can _and_
14:40:56 <diga> cdent: got your question
14:40:59 <diga> okay
14:41:00 <cdent> avoiding using the activity of placement to substitute for where we need notifications elsewhere that are more directly tied to use cases
14:41:30 <diga> ok
14:42:34 <jroll> I'm thinking this might get real useful in the future; a capacity tracking system could just watch the placement service instead of watching nova, ironic, cinder, neutron, etcetc
14:42:46 <diga> cdent: I will think through this, come with actual notifications need for use cases
14:42:58 <cdent> thanks diga
14:43:02 <jroll> (not sure about today though)
14:43:14 <diga> cdent: welcome!
14:43:50 <edleafe> With that, let's move on to...
14:43:52 <edleafe> #topic Open discussion
14:44:17 <edleafe> Anything to discuss?
14:44:22 <diga> edleafe: what is timeframe for pike-1 release
14:44:35 <diga> sorry pike-1 cycle
14:44:35 <jroll> quick question here - we talked about the ironic driver munging instance.flavor at some point to add the resource class, do we need a spec for that?
14:44:45 <jroll> diga: GET /v1/nodes/<ident>/states
14:44:49 <jroll> nope, bad paste
14:44:52 <jroll> https://releases.openstack.org/pike/schedule.html
14:44:54 <cdent> https://releases.openstack.org/pike/schedule.html
14:44:55 <jroll> that's the one :)
14:44:56 <cdent> dammit again
14:45:01 <jroll> :P
14:45:02 <edleafe> cdent: too slow
14:45:14 * cdent inserts jroll before cdent in typing speed list
14:45:15 <diga> :) okay
14:45:16 <cdent> so much fail
14:45:39 <edleafe> jroll: that's a good question
14:45:45 <cdent> jroll: I'd say probably yes
14:45:47 <edleafe> jroll: I would assume yes
14:45:54 * jroll nods
14:45:55 <edleafe> oh no, cdent is getting faster
14:46:05 * cdent limbers up
14:46:06 <jroll> should I just maybe make one spec to cover that and the flavor changes?
14:46:16 <cdent> that seems a reasonable starting point
14:46:21 <jroll> well, there's a few flavor changes, let me rephrase
14:46:25 <edleafe> jroll: I would prefer that, but I'm not Matt
14:46:42 <jroll> one for the overall "extra specs can override things" and another for the "plan to get ironic using this"
14:46:54 <jroll> is what I'm thinking
14:47:04 <edleafe> "override things"??
14:47:44 <jroll> edleafe: e.g. flavor.vcpus=0 + flavor.extra_specs:vcpus:2 => uses 0 for scheduling but 2 for display
14:47:53 <jroll> er, that's backwards
14:47:59 <jroll> but that thing :)
14:48:10 <diga> edleafe: I filed one bug today on nova_cell0 DBNonExistanceError
14:48:14 <vkmc> pabelanger, hey there! continuing debugging the package-installs problem... this is the build log http://paste.ubuntu.com/24125072/ for the elements I'm working on here https://review.openstack.org/#/c/411500/
14:48:22 <vkmc> pabelanger, you mentioned something about the version
14:48:24 <jroll> vkmc: wrong channel? :)
14:48:30 <vkmc> yes, sorry
14:48:46 <jroll> edleafe: to be clear, line 61 here https://etherpad.openstack.org/p/nova-ptg-pike-placement
14:49:10 <diga> ok
14:49:31 <edleafe> jroll: ah, I see. Didn't realize that display was an issue
14:49:41 <diga> if someone has any idea about this - https://bugs.launchpad.net/nova/+bug/1670262
14:49:41 <openstack> Launchpad bug 1670262 in OpenStack Compute (nova) "DBNonExistenceDatabase: Unknown database "nova_cell0"" [Undecided,Incomplete]
14:50:07 <diga> I installed devstack, then while launching instance I get this, this may be the devstack fix
14:50:21 <jroll> anyway I should be able to start hacking on this next week sometime, so I hope to have some specs to review in 2 weeks at the latest
14:50:39 <edleafe> jroll: sounds good
14:51:40 <edleafe> diga: you should probably ask that in the #openstack-nova channel. I know that others have dealt with this
14:51:50 <diga> edleafe: Sure
14:52:21 <edleafe> Anything else to discuss? Or should we get back to our lives?
14:52:29 <cdent> you have a life?
14:52:35 <edleafe> such as it is
14:52:38 * cdent wows
14:53:26 <edleafe> OK, thanks everyone!
14:53:27 <edleafe> #endmeeting