14:00:27 <edleafe> #startmeeting nova_scheduler
14:00:27 <openstack> Meeting started Mon May  1 14:00:27 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:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:31 <openstack> The meeting name has been set to 'nova_scheduler'
14:00:34 <cdent> o/
14:00:39 <mriedem> o/
14:00:44 <edleafe> Who's here?
14:00:52 <jaypipes> 0/
14:01:00 <jaypipes> or o/
14:01:25 <cdent> jaypipes: I think the first was right, you do have an impressively large head
14:01:40 <jaypipes> cdent: lol
14:01:50 * edleafe thought cdent was going to make a zero brains crack
14:02:09 <cdent> look at the big brains on jay!
14:02:36 <edleafe> #topic Specs & Reviews
14:02:48 <edleafe> os-traits
14:02:49 <edleafe> #link Sync os-traits in placement DB https://review.openstack.org/450125
14:03:00 <edleafe> Is this something we need? Or should we only do this if we see a performance hit?
14:03:31 <jaypipes> I don't think it's a performance thing
14:03:58 <mriedem> sfinucan would probably warn them against using anything from "from nova.cmd import common as cmd_common"
14:04:07 <jaypipes> ya
14:05:02 <edleafe> so is this something necessary?
14:05:02 <mriedem> he's been alerted
14:05:52 <mriedem> so what is this for? if we don't find a trait in the db we lookup in the library?
14:06:03 <mriedem> i still haven't read the traits spec
14:06:21 <mriedem> and if your library is backlevel then you're kind of screwed for new traits
14:06:26 <cdent> mriedem: its to put all the traits in the db
14:06:29 <cdent> instead of using the library
14:06:31 <edleafe> It's for when the os-traits lib changes
14:06:41 <edleafe> This will update the copy in the DB
14:06:50 <jaypipes> mriedem: yeah, basically it adds records for the standard traits (os-traits traits) into the API DB and ensures there's records in the traits table with the name of the trait and an autoincremt id.
14:06:52 <edleafe> So we can do all those yummy SQL joings
14:06:53 <mriedem> but if we don't find a trait in the db we fallback to the library?
14:06:55 <edleafe> joins
14:07:23 <mriedem> how often are operators expected to run this?
14:07:29 <jaypipes> mriedem: whereas we have all the standard resource classes use their "ID" from the fields.ResourceClass.STANDARD enum, we don't have the same luxury for standard traits.
14:07:30 <mriedem> on a cron?
14:07:55 <jaypipes> mriedem: whenever os-traits does a release and they want to use one of the new traits in that release.
14:08:06 <jaypipes> mriedem: it's not too onerous, really...
14:08:29 <mriedem> it's not just operators using traits though right? but i guess they can control if they expose the support
14:08:49 <mriedem> are the traits available in a cloud discoverable by the end user?
14:08:55 <cdent> so, just for sake of devil's advocate, what's wrong with validating input against the os.traits module, and then storing the strings in the db?
14:09:26 <jaypipes> mriedem: yes
14:09:32 <mriedem> oh right,
14:09:37 <mriedem> /traits
14:09:38 <mriedem> derp
14:09:39 <jaypipes> right
14:10:01 <jaypipes> cdent: either way, it will depend on the release of os-traits the controller has installed.
14:10:14 <mriedem> ok i was concerned about interop, but since it's discoverable i care less
14:10:33 <mriedem> so if i'm an operator, i probably run this like i run nova-manage db sync
14:10:37 <cdent> jaypipes: sure but if you don't sync, then you don't have to sync
14:10:50 <cdent> which is one less thing to forget
14:11:11 <cdent> and the package will automatically depend on the os_traits lib
14:11:18 <cdent> so the question still stands: what's wrong with strings?
14:11:51 <jaypipes> cdent: yeah, we could also do a "hey, check if the $TRAIT_NAME is in os-traits. If it isn't, return 404. If it is, check if it's in the DB and if not, add it. but that would be a little less efficient, yes?
14:11:59 <jaypipes> so maybe this is a perf thing after all :)
14:12:22 <cdent> if we are worried about efficiency on a list of strings that is <10,000 entries, aren't we...confused?
14:13:42 <cdent> (I'm not exactly opposed to the change, I just want to be clear on the reasons)
14:15:27 <edleafe> Well, why don't we all review that change, and comment on the review?
14:15:36 * cdent nods
14:15:39 <edleafe> Next up:
14:15:40 <edleafe> Claims in the Scheduler
14:15:42 <edleafe> #link Claims in the scheduler series: https://review.openstack.org/#/c/460177/
14:15:46 * jaypipes nods too
14:16:08 <edleafe> Sylvain is off today like a good French worker
14:16:18 * cdent is a bad worker
14:16:47 <edleafe> I'm concerned with the last one in that series
14:17:09 <edleafe> Moving claims to the scheduler because of a previous premature optimization choice seems... bad
14:17:24 <edleafe> s/the scheduler/the conductor
14:18:38 <cdent> I think perhaps at this point we're just going to have to go with the WIP aspect of all this
14:18:59 <edleafe> Yes, and keep providing direction
14:19:00 <cdent> however, I'd prefer if we were WIPping in the general direction of the original plan, and then moving away from that if it proves incomplete
14:19:03 <jaypipes> edleafe: k, will review that today.
14:19:49 <edleafe> So yeah, it is all still WIP, so let's make sure we actually *make progress*
14:19:59 <cdent> progress++
14:20:05 <mriedem> keep in mind,
14:20:20 <mriedem> there is also a push for a general long-term direction to make the scheduler a library,
14:20:25 <mriedem> so we can drop another service you have to run
14:20:28 <mriedem> that's motivating some of this
14:21:08 <mriedem> at this point,
14:21:16 <mriedem> i've already forgotten all of the pros/cons of each approach really,
14:21:22 <mriedem> and they weren't all documented in the spec
14:21:36 <edleafe> Having the scheduler as a library doesn't seem to impact this at all
14:22:21 <edleafe> In general, we always assumed that the thing making the choice from placement would then make the allocation
14:23:32 <mriedem> i honestly don't even remember why we said conductor needs to do it last week
14:23:32 <edleafe> Moving on... Nested Resource Providers
14:23:32 <edleafe> Nested Resource provider series still doesn't show any signs of life
14:23:35 <edleafe> #link Nested RPs: https://review.openstack.org/#/c/415920/
14:23:46 <edleafe> jaypipes: status?
14:24:13 <jaypipes> edleafe: I'd like to get the shared resources pike series done first, along with the get_inventory() patches.
14:24:20 <mriedem> oh right the scheduler interface... ignore me
14:24:21 <jaypipes> edleafe: then rebase and move forward with n-r-p
14:24:39 <mriedem> jaypipes: that makes sense, since nrp needs to give it's inventory via get_inventory
14:24:50 <jaypipes> right
14:24:54 <edleafe> jaypipes: link?
14:24:58 <jaypipes> sec
14:25:10 <jaypipes> #link get_inventory: https://review.openstack.org/457782
14:25:21 <jaypipes> #link shared-resources-pike: https://review.openstack.org/460798
14:25:33 <edleafe> cool, thx
14:25:38 <jaypipes> currently fixing up comments on https://review.openstack.org/460798 from you and cdent.
14:25:43 <edleafe> Will look those over later
14:26:19 <edleafe> next up: Ironic testing for custom Resource Classes
14:26:21 <edleafe> # link Ironic custom RC tests https://review.openstack.org/#/c/443628/
14:26:35 <edleafe> Anyone have anything to comment on that?
14:26:52 <jaypipes> no, just need to review.
14:27:04 <edleafe> ok, then... Docs
14:27:05 <edleafe> #link Placement API ref https://review.openstack.org/#/q/topic:cd/placement-api-ref
14:27:14 <jaypipes> also rpodolyaka just got married on Saturday, so he's out for a few :)
14:27:18 <edleafe> looks like that series is making some progress
14:27:25 <edleafe> how dare he!
14:27:39 <jaypipes> and avolkov is also still on PTO
14:28:11 <edleafe> cdent: anything to add about docs?
14:28:41 <cdent> I was looking this morning at what's required to do the actual publishing (not draft). shouldn't be too onerous
14:29:03 <cdent> but will require a special job because of the placement-within-nova-ness
14:29:45 <edleafe> fun
14:29:49 <mriedem> because the existing job assumes a file structure right?
14:30:21 <cdent> mriedem: yes
14:30:28 <cdent> it's a small difference
14:31:28 <edleafe> OK, any other specs/reviews to discuss?
14:32:49 <jaypipes> edleafe: no specs, but I have an open item to discuss. :)
14:33:03 <edleafe> jaypipes: opens is coming up soon
14:33:06 <jaypipes> kk
14:33:08 <edleafe> #topic Bugs
14:33:08 <edleafe> #link Placement bugs https://bugs.launchpad.net/nova/+bugs?field.tag=placement
14:33:28 <edleafe> One new bug, that I see cdent has already responded to
14:33:28 <cdent> there was a new one, I responded to it asking for n-cpu logs
14:33:31 <cdent> jinx!
14:33:32 <edleafe> jinx
14:33:37 <cdent> yay!
14:33:52 <edleafe> anything else about that bug?
14:34:01 <edleafe> ...or any other bug?
14:34:05 <cdent> it's probably  the <Directory> thing
14:34:43 <edleafe> let's move on
14:34:45 <edleafe> #topic Open discussion
14:34:49 <edleafe> jaypipes?
14:35:33 <jaypipes> so, I have two talks on the placement API in Boston. I'm done with slides for one of them and 85% done with the other one. I was hoping I could get feedback from folks on them?
14:35:55 <jaypipes> already shared with mriedem and dansmith but I'd like to share with edleafe, cdent and others if that's ok?
14:36:09 <cdent> yes please
14:36:12 <edleafe> of course
14:36:17 <jaypipes> ok, thanks guys.
14:36:27 <jaypipes> you'll see a google docs share notice shortly.
14:36:44 <edleafe> jaypipes: use my gmail addy: edleafe@gmail.com
14:36:49 <jaypipes> will do, thx
14:36:54 <edleafe> makes sharing gdocs easier
14:37:22 <jaypipes> also, word of warning: the slide template is the Mirantis Boston summit template. I don't control it or the fonts. :)
14:37:34 <edleafe> excuses, excuses...
14:37:52 <jaypipes> cdent: you have a gmail
14:37:53 <jaypipes> ?
14:37:59 <cdent> chris.dent
14:38:05 <jaypipes> k, thx
14:38:27 <jaypipes> k, shared. thx in advance for the feedback.
14:38:31 <edleafe> OK, looking forward to tearing up jay's slide decks
14:38:35 <jaypipes> I'll share the second talk shortly.
14:38:38 <jaypipes> :)
14:38:46 <jaypipes> go for it, edleafe!
14:39:00 <edleafe> Anything else for open discussion?
14:39:50 <edleafe> wow, even the crickets are quiet this morning!
14:39:54 <jaypipes> heh
14:39:56 <edleafe> #endmeeting