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