16:33:12 <sdake> #startmeeting kolla
16:33:13 <openstack> Meeting started Wed Nov 11 16:33:12 2015 UTC and is due to finish in 60 minutes.  The chair is sdake. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:33:14 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:33:16 <openstack> The meeting name has been set to 'kolla'
16:33:20 <sdake> #topic rollcall
16:33:21 <rhallisey> hi
16:33:25 <jmccarthy> hi
16:33:28 <stvnoyes> hi
16:33:29 <sdake> yo \0/
16:33:40 <bmace> hey
16:33:49 <jpeeler> o/
16:33:58 <britthouser> o/
16:33:59 <pbourke> hi
16:34:08 <pbourke> SamYaple: yo
16:34:19 <SamYaple> pbourke: pong
16:34:27 <sdake> #topoic objectives for m1/m2/m3
16:34:35 <sdake> #topic objectives for m1/m2/m3
16:34:42 <sdake> hey folks
16:34:47 <sdake> I'd like to discusss at a high level what our objectives for m1/m2/m3 are
16:34:59 <sdake> to facilitate the priorities of blueprints
16:35:10 <sdake> I was thinking backend the filling out of the big tent nto m2/m3
16:35:19 <sdake> and fixing the gaps/problems in m1
16:35:23 <pbourke> https://etherpad.openstack.org/p/Kolla-Mitaka-Roadmap
16:35:52 <sdake> ya thats a pretty weak roadmap imo ;)
16:35:55 <sdake> we only ahd 40 mins
16:36:00 <pbourke> yeah but its a start
16:36:52 <sdake> things like upgrade are missing
16:37:00 <sdake> things like light out recovery are missing
16:37:09 <britthouser> So under big tent - are all those containerized and just need ansible? or some have no containers at all?
16:37:11 <sdake> does anyone care what order we go in?
16:37:23 <pbourke> nope
16:37:25 <SamYaple> britthouser: some stuff has no containers
16:37:27 <sdake> britthouser some have containers but most need both
16:37:29 <britthouser> Ok. thx
16:38:33 <pbourke> sdake: how do you want to drive it
16:38:42 <SamYaple> fyi im working on an outage so ill be in and out
16:38:42 <sdake> ok so nobody cares on ordering ? :)
16:38:42 <pbourke> brainstorm bp titles?
16:38:45 <SamYaple> sorry
16:38:51 <SamYaple> but ping me and ill respond
16:39:15 <sdake> i just want to know if we should lod all thegood work up front or spread it between miletstones
16:39:25 <sdake> the problem wiht loading it all up front is that we will b  bored for m2/m3
16:39:42 <sdake> of course my definition of good work is stuff that is highly technical and challenging and not repeititve
16:39:49 <sdake> this may be different then pbourke 's definition::)
16:40:01 <SamYaple> we need logging right now
16:40:10 <SamYaple> its needed for the gate to be effective
16:40:14 <SamYaple> and it needs to be backported
16:40:30 <sdake> i tought we had logging mnus a few sservices
16:40:33 <SamYaple> no
16:40:41 <SamYaple> none of the logging works like it should
16:40:46 <SamYaple> we dont capture stack traces
16:40:51 <SamYaple> those still go to stderr
16:40:59 <SamYaple> and we dont do any of the non-openstack services
16:41:19 <SamYaple> we need to get that done right and inc0 is out of commision for probably a few weeks
16:41:33 <SamYaple> I have other gate things I am doing on the side form my real job
16:41:36 <sdake> probably loner - job changes are very dirsuptive
16:41:50 <SamYaple> sdake: not a job change
16:41:53 <SamYaple> just a location change
16:42:02 <SamYaple> doesnt matter, either way its a big issue
16:42:14 <SamYaple> i think it can be solved fairly quickly, but someone needs to won it
16:42:17 <SamYaple> own*
16:42:22 <sdake> ok well since my memory is not lik ea computes, lets get the stuff in eherpad
16:42:34 <sdake> please folks open up that roadmap etherpad and lets brain storm all the stuff we need to taclke
16:42:42 <sdake> and i'll just put em all in m1
16:42:47 <sdake> and we can roll em as necessary to m2/m3
16:44:35 <sdake> find them and destroy them1
16:45:15 <britthouser> so roadmap sounds alot like the 1.1 list
16:45:33 <britthouser> is that b/c we'll do those in M1, before backport to liberty?
16:47:20 <SamYaple> britthouser: the 1.1 list is a subset of this
16:47:28 <SamYaple> pretty major subset
16:47:37 <britthouser> Ok...I'll double check the 1.1 list and make sure they are in the etherpad too
16:51:58 <sdake> ok if thre is nothing else i'll continue
16:52:11 <sdake> #topic mitaka #1 review
16:52:42 <sdake> #link https://launchpad.net/kolla/+milestone/mitaka-1
16:53:16 <sdake> things are looking pretty good, minus we rae not effectivel hditributing the work
16:53:42 <sdake> when i file all those blueprints after this meeting from the brainstorm session
16:53:45 <sdake> i would like folks to take on blueprints
16:54:16 <rhallisey> will do
16:54:27 <sdake> i'd ike to talk abou this blueprint Drop root privileges to the container's application PID/GID
16:54:42 <sdake> this is a test case of using work items to track work
16:54:50 <sdake> (work items re things in the eblueprint tracker fyi)
16:54:57 <SamYaple> despite the slowdown, Kolla is #12 for most reviews so far this cycle, so dont get too down people. we are still progressing
16:55:10 <sdake> if you haven't signed up for a peice of work - please ign up for some
16:55:20 <sdake> SamYaple ya the two weeks before and after summit area lawys really slow
16:55:35 <sdake> people on burnout on eithr end - then recovery- then ready to crank ;)
16:56:04 <sdake> any blueprint others would like to discuss?
16:56:12 <jasonsb> logging?
16:56:22 <SamYaple> jasonsb: i hit on that earlier
16:56:25 <sdake> there is no logging blueprint but there ill be sshortly
16:56:28 <jasonsb> if i get you a video soon can we target EFK stack?
16:56:47 <sdake> that sounds fantastic
16:56:52 <sdake> are we sitll going to use ssyslog per node?
16:57:22 <jasonsb> i was wondering that too
16:57:34 <SamYaple> i think we need to
16:57:36 <sdake> i would say yes
16:57:38 <jasonsb> harm was saying fluentd works good too
16:57:42 <SamYaple> ew are logging over the socket
16:57:42 <jasonsb> but i think syslog is better
16:57:45 <sdake> unless there was a compleeling reason not to
16:57:50 <SamYaple> then rsyslog would push to a central
16:57:58 <SamYaple> i dont want the individual services lggging over the network
16:58:02 <jasonsb> same tooling could be used for things which don't syslog
16:58:07 <jasonsb> i suppose that is one advantage
16:58:14 <jasonsb> (for fluentd)
16:58:59 <jasonsb> i think we are talking multiple logging bp's?
16:59:13 <jasonsb> or roll into one?
16:59:36 <sdake> why multiple
17:00:10 <jasonsb> to reduce risk of one thing slipping efecting the rest
17:00:21 <sdake> what multiple
17:00:24 <sdake> wrong question ;)
17:00:44 <SamYaple> we need one to make the logging work for all and work right (maybe reopen the old one...)
17:00:45 <sdake> jasonsb can you put em in our roadmap eetherpad
17:00:47 <jasonsb> it looked like there was some long tail stuff for logging
17:00:48 <SamYaple> and one for the multinode
17:00:56 <jasonsb> ie: getting all of the services to work just right
17:01:21 <jasonsb> SamYaple: +1
17:01:28 <sdake> got it
17:01:32 <sdake> ill add those then
17:01:50 <sdake> I still plan to put most of the new big tent serices in l2/l3
17:02:10 <sdake> so we can push those out to N if needed to make our implementation completely solid for N
17:02:14 <sdake> for M I mean
17:02:31 <sdake> push to M, solid for M
17:02:42 <sdake> psuh to N, solid for M
17:02:42 <sdake> groan
17:03:10 <sdake> and seriousy, we need to get ceilomete rdown
17:03:17 <sdake> its almost a compute kit serice
17:03:23 <sdake> please coolsvap get cracking :)
17:03:29 <SamYaple> sdake: coolsvap was working on that last I heard I believe
17:03:38 <SamYaple> the biggest problem there is HA mongodb
17:03:42 <sdake> yes i know
17:03:48 <SamYaple> that is not an easy thing and there is no glaera for mongodb
17:05:04 <sdake> i'd be satisified with a single non-ha ceilometer
17:05:24 <sdake> i realize tha is imprefet but atleaast it wold work some of the time
17:05:24 <SamYaple> no i dont want to do that
17:05:26 <sdake> vs none of the time
17:05:31 <SamYaple> then we have to provide a path for migration
17:05:53 <sdake> the power of the two words "tech preview"
17:06:50 <SamYaple> as long as we say no migration path im cool with that
17:06:50 <sdake> #topic open discussion
17:07:10 <sdake> ok folks from thee blueprint list looks like we hae a sle wof blueprints to sort out
17:07:15 <sdake> i'll get em filed, need people to sign up for them
17:07:20 <sdake> anyone have open discussion?
17:07:41 <bmace> i think we wanted to bring up if folks feel strongly about having the kollacli REST service in the python-kollaclient repo during dev at least.
17:08:27 <sdake> it shoudl be there all the time - i dont understand the  Q
17:08:33 <britthouser> I'm confused about a REST cli?
17:08:37 <bmace> we can obviously break it out into a separate repo at some point.  if there are no objections, for the sake of simplicity, it would be easier to refactor in a single repository
17:08:57 <britthouser> still coming up to speed here...sorry.
17:09:15 <pbourke> ideally it would be separate but can be done later
17:09:16 <bmace> i don't believe any of the other python-Xclient repos have REST server side code in them
17:09:26 <bmace> that is my point sdake
17:09:47 <pbourke> if you were going to combine it in an existing repo though the kolla one would nearly make more sense
17:09:50 <bmace> but since a lot of the code that will be in there is in the cli right now, it is far easier to refactor into a service in a single repo, and move it out wholesale later
17:10:15 <bmace> i think sdake already did a bunch of work to make the python-kollaclient repo
17:10:27 <pbourke> assuming a rest api is needed at all I haven't seen reasons for it yet
17:10:29 <nihilifer> +1 for pbouke, I'd also pick kolla repo for REST server if we don't want to make a separate repo for it for now
17:10:37 <bmace> and not all people using kolla want or need to care about a cli
17:10:42 <sdake> i'm good with refactoring the rest api wherever is good fot he des
17:10:56 <pbourke> bmace: everyone voted for it so they do care
17:11:03 <pbourke> bmace: even if they dont know it ;)
17:12:20 <bmace> sure, so how about we do the dev in python-kollaclient and we can move the REST service into base kolla if folks want once it is done?
17:12:40 <SamYaple> -1 on the REST api.... point me at a reason why we need it please
17:12:51 <SamYaple> i need convincing
17:12:54 <pbourke> id like that conversation to happen
17:12:55 <SamYaple> its been brought up before
17:13:02 <bmace> so that people can add their own UI or whatever programmatic control over kolla deploys?
17:13:09 <nihilifer> I guess for making a cli like in other bg tent project
17:13:16 <SamYaple> ok. so what deploys that?
17:13:21 <SamYaple> where does that run?
17:13:29 <SamYaple> its definetely outside of our project scope
17:13:31 <bmace> wherever they want
17:13:43 <sdake> i disagree about project scope
17:13:46 <sdake> it is a deployment tooll
17:13:52 <sdake> therefore in scope
17:14:01 <SamYaple> no its a rest api
17:14:04 <SamYaple> not a deployment tool
17:14:10 <SamYaple> this is a UI in front of the deployment tool
17:14:10 <sdake> to sserver deploying tooling
17:14:28 <bmace> you don't think our deployment is complicated enough that people might not want to mess with stuff by hand?
17:14:32 <sdake> i'd already call rest a ui
17:14:34 <SamYaple> you wont convince me that its in our current scope at all. but do we expand the scope? maybe
17:14:50 <sdake> alreadyhardly
17:15:01 <SamYaple> bmace: no? its 4 lines to deploy openstack
17:15:04 <bmace> lol
17:15:10 <bmace> sure, if you never want to change anything
17:15:31 <SamYaple> ok so point me at the openstack UI configuration tool for nova
17:15:32 <SamYaple> cinder
17:15:34 <SamYaple> neutron
17:15:41 <SamYaple> where is the rest api to change those configs?
17:15:43 <sdake> fuel has it
17:15:49 <sdake> fuel has a rest api for those iirc
17:15:55 <SamYaple> fuel is not an openstack project
17:16:09 <inc0> hey, meeting time moved?
17:16:10 <sdake> it sort of is, it just isn't a  governed project
17:16:12 <bmace> you know what people complain about with openstack, complexity to deploy. so don't point that out as a reason not to have a ui... it needs to be easier
17:16:16 <sdake> inc0 yur late bro ;)
17:16:18 <rhallisey> inc0, day light savings dude
17:16:22 <inc0> oO
17:16:30 <inc0> I thought it's in 15 minutes
17:16:31 <rhallisey> welcome to america inc0
17:16:48 <SamYaple> bmace: we deploy openstack, what deploys the thing you are tlakign about?
17:16:49 <inc0> duh, sorry guys
17:16:53 <SamYaple> bmace: does it need a backend?
17:16:54 <britthouser> Think of the API as allowing other programs to control Kolla instead of a user.
17:17:04 <SamYaple> bmace: what configures the inventory where it runs?
17:17:10 <sdake> the backend is the filesystem
17:17:28 <bmace> if people want to use it, they just run it, like a service.  i expect there would be an rpm to install it on some system, just like we do in the oracle distro for the CLI right now
17:17:33 <sdake> the softqware is run by init scripts or systemd or the like
17:17:46 <SamYaple> are we tlaking about some UI or a rest api?
17:17:50 <SamYaple> these are widly different things
17:17:56 <sdake> rest api
17:18:03 <inc0> what would rest api do in our case?
17:18:08 <inc0> we don't have any running service
17:18:10 <sdake> if someone wants to make a ui on top  more power to them
17:18:12 <SamYaple> how does that make it easier to deploy?
17:18:13 <sdake> but i think that would be outside scope of kolla
17:18:17 <bmace> essentially what the cli does now, breaking it out into a REST service that both the cli can use, but anyone else doing any other sort of deploy automation can use
17:18:27 <SamYaple> ok lets have some moderation here
17:18:32 <SamYaple> bmace: are you asking for a UI?
17:18:34 <inc0> bmace, that would be api of ansible or whatever
17:18:43 <bmace> a cli is a ui..
17:18:46 <pbourke> we already have a ui
17:18:48 <pbourke> bmace: +1
17:18:50 <SamYaple> bmace: GUI
17:18:55 <inc0> ncurses!
17:19:10 * sdake gets some salt for the popcorn
17:19:11 <SamYaple> UX is the new terms nowadays
17:19:15 <bmace> i don't plan on writing a gui right now, but with a rest api in place, people could make one if they want, they could do anything, programatically
17:19:34 <SamYaple> what does a rest interface get us right now that we dont have?
17:19:37 <inc0> bmace, again, we don't have running service
17:19:40 <SamYaple> how does that make it easier to deploy openstack?
17:19:42 <sdake> a rest ui is a comon pattern in software development because it gets rid of magic pushbutton
17:19:45 <inc0> nor we plan to, maybe besides mesos
17:19:49 <sdake> we want to get rid of magic pushbutton in our softtware
17:19:50 <inc0> but mesos has it's apis
17:19:53 <SamYaple> sdake: we dont have a service!
17:20:10 <sdake> SamYaple hwat about ansible and deploying all the things?
17:20:16 <sdake> that is deifnately a service
17:20:17 <SamYaple> thats not a service
17:20:24 <SamYaple> look up the definition of service
17:20:28 <inc0> service is constantly running daemon
17:20:36 <bmace> that is why i don't feel it needs to be in the core kolla repo, leave it out in another repo as an optional bit people can use, or not, with base kolla
17:20:37 <SamYaple> inc0: +1
17:20:40 <bmace> just like the cli
17:20:56 <SamYaple> bmace: im not saying im opposed to it, but i still havent heard what it adds for value
17:21:06 <SamYaple> not to meantion the chicken/egg situtation it gets us in
17:21:10 <sdake> it allows  people to write guis for kolla
17:21:15 <sdake> there I said what it offers
17:21:17 <sdake> enjoy :)
17:21:19 <bmace> it isn't that hard to start a service..
17:21:24 <SamYaple> sdake: great thats outside of scope
17:21:32 <sdake> gui is outside scope
17:21:34 <SamYaple> bmace: kolla doesnt touch the host
17:21:35 <sdake> enabling not outside scope
17:21:40 <bmace> an rpm can do it, an apt can do it
17:21:40 <SamYaple> bmace: it only starts containers
17:22:08 <SamYaple> pbourke: thgouts here?
17:22:11 <bmace> on the deploy host, there are install dependencies, docker, ansible, a number of bits..
17:22:13 <pbourke> this is quite a balanced argument :)
17:22:18 <pbourke> i completely see both sides
17:22:21 <sdake> persoanlly id' ike to see a nice gui for koll atoo
17:22:26 <inc0> well, I have issue with rest api
17:22:31 <SamYaple> a GUI doesnt require a rest api
17:22:33 <inc0> for us
17:22:35 <sdake> something that has a nice lock and shows you how long is left ;)
17:22:36 <SamYaple> inc0: i do as well for us
17:22:37 <pbourke> SamYaple: I was thinking that also
17:22:48 <SamYaple> sdake: I am actully ok with a GUI.... but not a rest api
17:22:54 <sdake> a gui requires a rest api to avoid magic pushbutton
17:23:00 <pbourke> SamYaple: the api standardises how they interact with kolla though
17:23:14 <SamYaple> no ansible does that
17:23:19 <pbourke> hmm
17:23:21 <sdake> otherwise the gui encodes business logic within it - no bueno
17:23:32 <SamYaple> sdake: then that requires a service
17:23:35 <pbourke> SamYaple: ansible is very flexible though
17:23:37 <SamYaple> and then chicken and egg
17:23:39 <rhallisey> hmm
17:23:44 <pbourke> SamYaple: too much so
17:23:44 <inc0> I would hate to end up with running gevent/greenlet/django/whatever which will do nothing
17:24:01 <inc0> besides running one command, which would be ansible-playbook
17:24:05 <SamYaple> why dont we table this. we have many far more important things to do
17:24:14 <SamYaple> if someone wnats to hammer out a spec we can all review it
17:24:24 <sdake> the reason i tcant be tabled is the work is beginning now
17:24:41 <nihilifer> what about just creating separate repo for REST API? you probably will not convince yourselves about whether it's good or not
17:24:43 <SamYaple> no a rest api or gui has nothing that is holding us up
17:24:50 <nihilifer> but it looks like some peaople or companies
17:24:53 <inc0> nihilifer, noone will stop that
17:25:08 <nihilifer> just want to write JS-based GUIS
17:25:17 <bmace> it would be in a separate repo, the python-kollaclient
17:25:18 <SamYaple> nihilifer: not under kollas name? no one will stop. under kollas name we need a spec
17:25:30 <inc0> fuel has cool gui, but also database, running service and other stuff
17:25:31 <sdake> bmace id recommend keeping in same repo for now
17:25:43 <SamYaple> inc0: correct
17:25:46 <inc0> we don't have database, running service and I don't want to have it tbh, not now in any case
17:25:50 <SamYaple> inc0: thats a huge thing
17:26:11 <pbourke> SamYaple: what do you have to say on sdake's pushbutton argument
17:26:19 <bmace> i tend to agree with the others though sdake, that the REST api shouldn't be in base kolla.  it is an optional thing, just like the cli, to make using kolla easier.
17:26:32 <SamYaple> pbourke: we are the deployers of openstack. we cant be consumed like openstack
17:27:00 <pbourke> SamYaple: we could be though
17:27:04 <inc0> in fact, we're quasi-openstack really
17:27:17 <SamYaple> pbourke: if we want to be tripleo and deploy openstack to deploy openstack, then yes we could
17:27:17 <inc0> or meta-openstack;)
17:27:24 <pbourke> ha
17:27:30 <inc0> metastack
17:27:32 <SamYaple> im not joking
17:27:36 <bmace> we have seen enough confusion by people doing kolla deploys already that it definitely need something on top of it to make it easier.
17:27:55 <pbourke> bmace: right but that's an arg for the existing cli, not the rest api
17:27:55 <SamYaple> bmace: you dont reduce confusion by adding complexity
17:28:07 <inc0> bmace, we have cli and we should work on it's usability imho
17:28:13 <SamYaple> right
17:28:20 <SamYaple> we _just_ agreed to work on this cli
17:28:22 <inc0> write good helps, make it usable
17:28:35 <inc0> make manpage;)
17:28:37 <SamYaple> if its as simple as `kolla deploy` `kolla add host` then i dont see what else we need
17:28:45 <pbourke> others could write GUIs in the same way the cli is written
17:28:48 <rhallisey> ya we just had a big doc change to address this
17:28:54 <inc0> ncurses! (I'll repeat it every now and then;))
17:29:23 <sdake> xthe argument for a rest api is to encodee our bussiness logic behind a programmatic api pbourke
17:29:42 <sdake> i do not like how the cli jamws the business logic and ci together
17:29:42 <sdake> its magic fucking pushbutton
17:29:52 <pbourke> true enough
17:29:52 <sdake> 'the death of every project ive been involed in that failed
17:29:54 <bmace> because if anyone wants to do any sort of programatic control, using expect and parsing cli output sucks
17:30:04 <SamYaple> our time is up guys
17:30:08 <SamYaple> lets move back to #kolla
17:30:10 <sdake> #endmeeting