14:59:50 <bauzas> #startmeeting gantt
14:59:51 <openstack> Meeting started Tue May  6 14:59:50 2014 UTC and is due to finish in 60 minutes.  The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:59:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:59:55 <openstack> The meeting name has been set to 'gantt'
15:00:09 <PaulMurray> hi bauzas
15:00:10 <bauzas> hi all
15:00:15 <jay-lau-513> hi
15:00:19 <toan-tran> hi all
15:00:25 <bauzas> n0ano is off today, so I'm chairing this one
15:00:45 <toan-tran> just before we start, I would like to add into 'Open' a topic
15:00:53 <toan-tran> on a new blueprint that we proposed
15:00:55 <bauzas> toan-tran: sure, go ahead
15:01:12 <bauzas> we can even create a dedicated topic for your needs ;)
15:01:19 <toan-tran> :)
15:01:35 <bauzas> could I just have the title ?
15:01:46 <toan-tran> cpu allocation per flavor
15:01:57 <toan-tran> cpu allocation ratio per flavor
15:02:01 <toan-tran> :)
15:02:06 <bauzas> ok, keep me aware if I'm forgetting it :)
15:02:16 <toan-tran> will do :)
15:02:18 <bauzas> let's start
15:02:30 <bauzas> hello all
15:02:44 * johnthetubaguy waves
15:02:46 <bauzas> #topic Actions items from previous meetings
15:03:02 <bauzas> (argh, made a typo)
15:03:19 <bauzas> #link http://eavesdrop.openstack.org/meetings/gantt/2014/gantt.2014-04-29-15.00.html
15:03:37 <bauzas> a few actions were created
15:03:42 <bauzas> YorikSar, you there ?
15:03:59 <YorikSar> bauzas: o/
15:04:05 <bauzas> YorikSar: cool
15:04:08 <bauzas> an action was open for you
15:04:14 <bauzas> to create the nova-specs bp
15:04:16 <bauzas> I saw it
15:04:18 <YorikSar> I've put first version of the spec to the Gerrit.
15:04:23 <bauzas> cool, nice work
15:04:31 <bauzas> could you please give us the link ?
15:04:37 <YorikSar> I've added those who I could find in last meeting logs to reviewers
15:04:41 <bauzas> cool
15:04:46 <bauzas> YorikSar: nice catch
15:04:53 <YorikSar> #link https://review.openstack.org/92128
15:04:55 <bauzas> thanks
15:05:04 <YorikSar> (I hope that'll work for meeting bot)
15:05:08 <bauzas> it will
15:05:33 <bauzas> let's discuss it on a separate topic
15:05:50 <YorikSar> I'm looking forward to reviews. I've never put together a blueprint with this new template in repo
15:05:54 <bauzas> ok, n0ano also had action to look over https://review.openstack.org/82778
15:05:56 <YorikSar> bauzas: Sure
15:06:13 <bauzas> I guess he had no time
15:07:02 <bauzas> IMHO, prolonging this action doesn't make sense as we're 1 week close to the summit
15:07:16 <bauzas> so, let's move to the next topic
15:07:24 <bauzas> unless someone is feeling different :)
15:07:44 <toan-tran> no, please proceed :)
15:07:50 <bauzas> ok
15:07:52 <bauzas> #topic Status on forklift efforts
15:08:13 <bauzas> well, far less progress here, I was really busy by my vacations
15:08:36 <bauzas> but still, there 3 things you need to know
15:08:57 <bauzas> #link https://review.openstack.org/82133 is merged
15:09:20 <bauzas> so I'll focus my attention on delivering first implementation by the next weeks
15:09:32 <bauzas> of course, progress will be impacted by Summit
15:09:39 <toan-tran> bauzas: super
15:09:49 <bauzas> implementation of this blueprint can be found here as draft :
15:10:02 <bauzas> #link https://review.openstack.org/82778
15:10:21 <toan-tran> bauzas: just a question
15:10:24 <bauzas> sure
15:10:36 <bauzas> this blueprint is targeted for Juno-1
15:10:43 <toan-tran> in the srt you said that only aggregate tables & vm tables are concerned
15:10:50 <toan-tran> what about host_state?
15:10:59 <toan-tran> computes_* tables?
15:11:26 <bauzas> I haven't said that in this blueprint ;,)
15:11:40 <bauzas> that's another blueprint, targeted for Juno-2
15:11:50 <toan-tran> oops, sorry, wrong blueprint :)
15:11:55 <bauzas> #link https://review.openstack.org/#/c/89893/
15:12:04 <bauzas> but indeed, there is room for discussion here
15:12:18 <bauzas> so, yes, HostState is a class, not a DB table
15:12:33 <toan-tran> bauzas: the table is compute_*
15:12:37 <bauzas> HostState is persisted by compute_nodes
15:13:01 <YorikSar> At least for now...
15:13:03 <bauzas> johnthetubaguy: I'm pretty well interested in your feedback for https://review.openstack.org/#/c/89893/
15:13:21 <bauzas> YorikSar: at least until no-db-scheduler is merged yes :)
15:13:24 <johnthetubaguy> bauzas: yeah, I will take a look, interested to get this reviewed before the summit
15:13:43 <bauzas> johnthetubaguy: I'm planning to discuss over it by the Gantt session
15:13:55 <bauzas> johnthetubaguy: because there are some performance concerns as reviews
15:14:16 <bauzas> johnthetubaguy: if you look at the discussion in the previous patchset
15:14:38 <bauzas> johnthetubaguy: so, I think that's a good fit for trying to get opinions before Summit
15:15:15 <johnthetubaguy> bauzas: agreed, its a good topic to discuss, and there are a few performance things that worry me at least, but I feel there are some good options to fix those
15:15:36 <bauzas> indeed, and that's good place for discussing it at Summit
15:15:44 <johnthetubaguy> yup
15:15:56 <bauzas> ok, any other questions about these 2 blueprints ?
15:16:04 <toan-tran> some filters use compute_nodes tables
15:16:14 <toan-tran> which is updated by nova periodic tasks
15:16:24 <toan-tran> how to separate them?
15:16:35 <bauzas> compute_nodes is planned to stay where it is :)
15:16:56 <toan-tran> bauzas: then how corefilter & ramfilter work then?
15:17:01 <bauzas> thanks to the first bp (sched-lib), RT will update compute_nodes seamlessly
15:17:33 <bauzas> compute_nodes is planned to stay on the Gantt side of the whiteline
15:17:42 <bauzas> so filters won't be impacted
15:17:54 <bauzas> RT will be
15:18:02 <bauzas> hence the sched-lib blueprint
15:18:22 <toan-tran> ok
15:18:46 <toan-tran> another question: how this bp & no-db work together?
15:18:58 <bauzas> toan-tran: that's an excellent question
15:19:15 <johnthetubaguy> toan-tran: I guess the nova-spec review for no-db should sort that out, it changes things slightly
15:19:21 <bauzas> toan-tran: and as for all excellent questions, it doesn't have an answer yet :)
15:19:34 <toan-tran> bauzas: can anything that this bp pull out be used in no-db?
15:19:53 <bauzas> toan-tran: AIUI, nope
15:19:57 <toan-tran> meaning: instead of putting it in a separated db, put it in memcache?
15:20:15 <bauzas> toan-tran: ideally, access to DB should be proxified
15:20:35 <bauzas> toan-tran: so whatever the backend is, the calls would stay the same
15:20:40 <toan-tran> bauzas: +1
15:20:43 <johnthetubaguy> so I think the no-db scheduler will be a new scheduler-lib, if we get it right
15:21:03 <bauzas> woah
15:21:19 <bauzas> good place for discussion over here then
15:21:51 <toan-tran> YorikSar: what do you think?
15:21:54 <bauzas> I was just thinking that instead of calling db_api.whatever() we were calling nodb.whatever()
15:22:19 <toan-tran> bauzas: well, it's more complicated than that
15:22:30 <bauzas> well, I love complications :)
15:22:36 <toan-tran> db_api has its own model
15:22:52 <toan-tran> I don't know if memcache has similar thing
15:22:57 <YorikSar> no-db scheduler only delivers host stats to the scheduler. I guess it can be a start for a scheduler-lib
15:23:01 <bauzas> hence the word 'proxy' :)
15:23:56 <bauzas> YorikSar: have you validated scheduler-lib interfaces ?
15:23:57 <YorikSar> In current state it "simply" replaces calls like db_api.put_my_state and db_api.get_all_states with requests to synchronizer.
15:24:32 <YorikSar> bauzas: Nope.
15:24:39 <bauzas> but calls to db_api.put_my_stats will now go to sched_lib.update_stats()
15:24:55 <YorikSar> I guess I should take a closer look to all those blueprints.
15:25:07 <bauzas> so I think you could take use of sched-lib as facade for your own implem
15:25:33 <bauzas> so that the interface would stay the same
15:25:43 <YorikSar> bauzas: Then we'll replace whatever is inside sched_lib.update_stats with calls with call to synchronizer.
15:25:50 <YorikSar> bauzas: Yes, exactly.
15:25:59 <bauzas> that's my idea yes
15:26:15 <bauzas> well, at least it should be optional and flag-driven :D
15:26:34 <bauzas> as I said, a common facade for 2 implems
15:26:36 <YorikSar> bauzas: We'll see ;)
15:27:00 <bauzas> YorikSar: I suggest you to look at https://review.openstack.org/#/c/82133/19/specs/juno/scheduler-lib.rst
15:27:14 <bauzas> you'll find the specs for the interface
15:27:15 <YorikSar> I think once people take a look at what those changes actually do they won't be afraid of switching on-the-fly.
15:27:42 <bauzas> maybe it's worth moving from this topic to the no-db sched one ?
15:27:53 <bauzas> so we could easily discuss on this
15:28:04 <bauzas> unless someone wants to talk about sched forklift ?
15:28:17 <YorikSar> bauzas: I'll take a look at blueprints tomorrow.
15:28:42 <bauzas> and I also have to review yours
15:29:17 <bauzas> #topic no-db scheduler
15:29:35 <bauzas> #action bauzas to review https://review.openstack.org/92128
15:30:08 <bauzas> YorikSar: do you have other things to raise over this topic ?
15:30:23 <bauzas> I mean, about design or queries?
15:30:44 <YorikSar> bauzas: I guess, I'll be waiting for reviews on spec.
15:31:13 <YorikSar> I've came onto one problem though. It's about compute_nodes you've mentioned.
15:31:20 <bauzas> YorikSar: sure ?
15:31:28 <bauzas> YorikSar: what's your problem ?
15:31:37 <YorikSar> I think they should go. :)
15:31:45 <bauzas> lol
15:31:55 <YorikSar> They hold mostly info used for scheduling only.
15:32:14 <bauzas> then, I would have to say to leave them where it is :)
15:32:40 <toan-tran> bauzas: I remember Boris discussed it long ago
15:32:54 <YorikSar> And when I took a look at what should be moved to one big JSON state, it seemed to me that all fields there have nothing (little) to do with the rest of Nova.
15:32:56 <toan-tran> saying that the Synchronizer will take care of that
15:33:07 <bauzas> mmm interesting view
15:33:23 <bauzas> if you look at the Juno-2 bp for isolating DB scheduler
15:33:30 <bauzas> I have a problem over here
15:34:00 <bauzas> I mean, we say that scheduler should not access other tables but the ones he manages for persistence
15:34:08 <YorikSar> There are places where compute_nodes are requested along with stats just for couple fields stored in them. I'm not sure how to handle that.
15:34:25 <bauzas> but the problem is that scheduler is directly reading other Nova objects states, like aggregates
15:34:30 * YorikSar adding another blueprint to the reading list...
15:34:51 <bauzas> so, if we say that compute_nodes should get rid off
15:35:02 <bauzas> with a big JSON state
15:35:22 <bauzas> that means that related objects should also be considered as this
15:35:30 <bauzas> aggregates and instances at least
15:36:02 <bauzas> well, to be honest, JSON and DB are 2 edges of the same thing
15:36:05 <YorikSar> bauzas: I think we should separate data that relates to hosts from data that relates to instances.
15:36:13 <bauzas> except the persistence thing of course
15:36:43 <YorikSar> So aggregates are for hosts, so they should go to (dark) scheduler side.
15:36:46 <PaulMurray> YorikSar, is the instance state you are thinging of independent of host
15:36:49 <bauzas> could you please keep it in mind for your blueprint ?
15:37:44 <bauzas> I'm also wondering how no-db sched will manage extensible RT
15:38:06 <bauzas> as the bp is now validated, unless I'm wrong PaulMurray?
15:38:17 <PaulMurray> bauzas, waiting for a second +2
15:38:41 <bauzas> PaulMurray: ok cool
15:38:56 <YorikSar> PaulMurray: I guess scheduler will have to manage a list of resources anyway. So at least list of instances on the host will remain in scheduler.
15:38:56 <PaulMurray> bauzas, most code is done - just the spec to go :)
15:39:11 <bauzas> PaulMurray: I saw that RT using objects is also validated as bp
15:39:21 <PaulMurray> bauzas, yp
15:39:25 <bauzas> PaulMurray: yep, I had no chance to review latest pachsets
15:39:27 <PaulMurray> s/yp/yep/
15:39:38 <bauzas> (about extensible RT I mean)
15:40:31 <PaulMurray> bauzas, my biggest problem was I had a url longer than 79 characters
15:40:35 <bauzas> so, YorikSar that means I think that the no-db sched bp should only focus on access to DB and proxy them
15:41:04 <bauzas> PaulMurray: oh bad, have you had -1 for this ?
15:41:13 <PaulMurray> from jenkins
15:41:18 <bauzas> PaulMurray: dammit
15:41:25 <toan-tran> PaulMurray: that's pretty much the problem with jenkins
15:41:34 <toan-tran> :D
15:41:40 <PaulMurray> no worries - I made the world pep8 compliant so I could use a shorter url to refer to
15:41:59 <bauzas> is there a PEP8 gate now for nova-specs ?
15:42:04 <bauzas> wasn't aware of
15:42:06 <YorikSar> bauzas: Yes. It's just proxying calls that used to target DB to wibbly-wobbly vortex that just delivering data to scheduler.
15:42:19 <PaulMurray> bauzas, no, not really, just 79 character width limit
15:42:34 <bauzas> YorikSar: ok cool so that should be not impacting other bps
15:42:51 <bauzas> provided the DB API remains the same :)
15:42:55 <YorikSar> PaulMurray: I've pasted some long URLs to my spec and Jenkins never complained. Mb you should have only URL on the line to make it pass?..
15:43:15 <bauzas> YorikSar: +1
15:43:27 <bauzas> YorikSar: I never went thru this problem
15:43:30 <PaulMurray> YorikSar, maybe - the check only failed today - it past last week
15:43:37 <bauzas> strange
15:43:53 <bauzas> ok, could we consider to move to the Design sessions topic ?
15:43:55 <YorikSar> Maybe they've changed coins in cointosser
15:44:23 <YorikSar> bauzas: Surt
15:44:29 <bauzas> #topic Juno Summit design sessions
15:45:10 <bauzas> #link https://etherpad.openstack.org/p/Gantt-summit-sessions
15:45:35 <bauzas> here is the final planning for scheduler-related sessions
15:46:31 <bauzas> I please ask proposers to fill in https://wiki.openstack.org/wiki/Summit/Juno/Etherpads#Nova
15:46:53 <bauzas> I began to put some ideas in https://etherpad.openstack.org/p/juno-nova-gantt-apis
15:46:59 <bauzas> that's draft of course
15:47:08 <toan-tran> is there a link for all the session plan?
15:48:01 <bauzas> toan-tran: which kind of link do you need ?
15:48:19 <toan-tran> well, a link that shows all the date & time of the sessions
15:48:29 <bauzas> ah
15:48:33 <toan-tran> http://junodesignsummit.sched.org/ only shows presentation session, not degisn sessions
15:48:37 <bauzas> take the sched.org things
15:48:47 <bauzas> toan-tran: you made confusion ;)
15:49:06 <jgallard> toan-tran,  https://wiki.openstack.org/wiki/Summit/Juno
15:49:10 <bauzas> toan-tran: http://junodesignsummit.sched.org/ is the Design sumit
15:49:22 <toan-tran> bauzas: ok :D
15:49:59 <bauzas> http://openstacksummitmay2014atlanta.sched.org/ is for the regular Openstack Summit
15:50:08 <toan-tran> bauzas: right :)
15:50:53 <bauzas> just a quick reminder that you can see other people's attendance by looking over each person agenda
15:51:31 <bauzas> like mine http://openstacksummitmay2014atlanta.sched.org/
15:51:33 <bauzas> oops
15:51:36 <bauzas> http://openstacksummitmay2014atlanta.sched.org/sbauza
15:51:41 <bauzas> etc.
15:51:55 <PaulMurray> bauzas, also if you put a picture in it makes it a lot easier for people to find you (if you want to be found :)
15:52:04 <bauzas> PaulMurray: +1 :)
15:52:15 <bauzas> PaulMurray: even if the picture is 4 years old...
15:52:17 <PaulMurray> bauzas, by "you" I mean "one" of course
15:52:27 <PaulMurray> bauzas, all mine are 10 years old
15:52:31 <bauzas> :)
15:52:33 <PaulMurray> I still look the same :)
15:52:46 <bauzas> ok, we still have 2 topics to discuss and 8 mins left
15:52:54 <bauzas> sorry for rushing this
15:53:10 <bauzas> #topic cpu allocation ratio per flavor
15:53:18 <bauzas> toan-tran: you're up
15:53:25 <toan-tran> thanks
15:53:37 <toan-tran> Here is the spec: https://review.openstack.org/#/c/87213/
15:53:42 <toan-tran> #link https://review.openstack.org/#/c/87213/
15:53:56 <toan-tran> currently the cpu_allocation_ratio is put into the aggregate
15:54:20 <toan-tran> thus a host will accept the VMs within its ratio
15:54:36 <toan-tran> however
15:54:56 <toan-tran> it is sometimes prefereable that the we want to put it in the flavor
15:55:14 <toan-tran> for instance:
15:55:35 <toan-tran> Flavor 1 has cpu_ratio 1
15:55:42 <toan-tran> Flavor 2 has cpu_ratio 2
15:56:05 <toan-tran> meaning that the first flavor will not accept sharing its core with others
15:56:21 <toan-tran> while flavor 2 can share up to 1 more VM in the same core
15:56:40 <toan-tran> so if a host has 12 cores
15:57:07 <toan-tran> he can accept 12 VMs of flavor 1, or 24 VMs of flavor 2, or 6 from flavor 1 + 12 from flavor 2
15:57:18 <bauzas> ok, I see
15:57:24 <toan-tran> that's what we want to realize
15:57:32 <bauzas> we're running out of time, I can propose you to discuss over this first in the bp
15:57:38 <PaulMurray> toan-tran, have you looked at extensible RT
15:57:50 <PaulMurray> https://review.openstack.org/#/c/86050/
15:57:57 <bauzas> PaulMurray: +1
15:58:09 <toan-tran> PaulMurray: not yet,
15:58:10 <PaulMurray> toan-tran, could be useful
15:58:16 <toan-tran> yeah
15:58:24 <toan-tran> it sounds like what we want in conjunction
15:58:25 <bauzas> ok, we're definitely eating time
15:58:43 <bauzas> any other opens to place before Summit ?
15:58:45 <toan-tran> actually there are several methods, including cgroup & quota:cpu
15:59:40 <bauzas> guys, we're running out of time
16:00:01 <toan-tran> well, I guess I can put back the bp  for another time then :)
16:00:03 <bauzas> I can propose to discuss over other topics outside here
16:00:14 <bauzas> cool thanks
16:00:16 <bauzas> #endmeeting