20:00:48 <sdake> #startmeeting kolla
20:00:49 <openstack> Meeting started Mon Feb 23 20:00:48 2015 UTC and is due to finish in 60 minutes.  The chair is sdake. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:52 <openstack> The meeting name has been set to 'kolla'
20:01:09 <sdake> #topic rollcall
20:01:21 <sdake> hideyo [\p/___
20:01:24 <daneyon> here
20:01:25 <jpeeler> hi
20:01:35 <rhallisey> hi
20:02:17 <sdake> #topic agenda
20:02:20 <sdake> https://wiki.openstack.org/wiki/Meetings/Kolla#Agenda_for_next_meeting
20:02:23 <sdake> any additions?
20:02:25 <sdake> daneyon you about?
20:02:34 <daneyon> yes
20:02:43 <sdake> sweet
20:02:59 <sdake> #topic H/A in Kolla Containers
20:03:04 <daneyon> looking at the HA spec BP
20:03:10 <sdake> #link https://blueprints.launchpad.net/kolla/+spec/create-spec-ha
20:03:49 <sdake> so that is sort of my crack headed idea for doing HA using multiple containers per node
20:03:55 <sdake> I guess we can leave that open for discussion
20:04:07 <sdake> do folks have interest in adding this tech to kolla postmilestone #3?
20:04:16 <sdake> or extending milestone #3 out to beginning of april to include it
20:04:36 <daneyon> +1 to add HA port ML3
20:04:41 <daneyon> post
20:05:09 <sdake> ok I'll start working on the blueprint now, t hat way it is ready to go when we are done with milestone #3
20:05:16 <sdake> #topic parameterizing containers
20:05:33 <sdake> #link https://blueprints.launchpad.net/kolla/+spec/create-spec-params
20:05:40 <sdake> rather the spec, not hte blueprint
20:06:07 <sdake> this is about all the bajiollion key value pairs in openstack
20:06:13 <sdake> that we dont' export but shoudl export some
20:06:26 <sdake> this is probably post milestone #3 work as well
20:06:31 <sdake> but needs to be done for kolla to be usable
20:06:50 <sdake> any thoughts?
20:07:00 <sdake> the eletronics are eating our brains!!
20:07:07 <ccrouch> can we follow what tripleo did already?..
20:07:15 <sdake> what did they do already
20:07:15 <daneyon> I think the K/V pairs can get out of control, so where do we draw the line?
20:07:37 <sdake> daneyon agree- ccrouch what did tripleo do ?
20:08:26 <ccrouch> e.g. allow a subset to be easily overrideable with common names, then allow support for specifying any key/value using a standard dotted/namespaced notation
20:08:34 * ccrouch looks for an example
20:08:47 <ccrouch> keeping going :-)
20:09:03 <sdake> sounds difficult to implement in shell
20:09:05 <sdake> but possible
20:09:20 <sdake> the problem we have is we have some which are mandatory and others which may not be
20:09:44 <sdake> daneyon I think we  will have to tackle custom key/value pairs at some point, but we need to draw a line at some point :)
20:09:54 <sdake> how to draw that line - unknown
20:10:12 <sdake> perhaps have people describe a use case where the config option is necessary for their use
20:10:21 <sdake> and we can start out with ones we know will be valauble
20:10:43 <sdake> so the breaking factor here is the overhead of getting someone to describe a use case
20:10:51 <sdake> that should dissuade random "I want xyz"
20:10:55 <daneyon> sdake: maybe we follow a rule that we support the K/V pairs identified in the official openstack install docs?
20:11:19 <sdake> support is a whole nother world of pain :)
20:11:26 <sdake> I'm just talking about enabling
20:11:47 <sdake> I think we leave support to "if it works with the default,s then gtfo" :)
20:12:22 <ccrouch> https://github.com/openstack/tripleo-image-elements/blob/f029d3c27283874d609aa842f794cd75c09e2f4f/elements/nova/os-apply-config/etc/nova/nova.conf is an example of a parameterized nova.conf
20:12:25 <sdake> ok well enough on that, we can come back to it when milestonen #3 is coming closer to an end
20:12:43 <ccrouch> with specific parameters specifiable via heat
20:12:48 <sdake> I thought tripleo-image-elements as a repo was going  bye bye?
20:13:28 <ccrouch> where lines 240 lets you specify a value for any arbitrary nova conf property
20:13:32 <daneyon> these files are going to be so painful to maintain
20:14:11 <sdake> I prefer maintain crudini files with a bunch of variables
20:14:19 <sdake> then a key/value translator
20:14:42 <ccrouch> (2:12:48 PM) sdake: I thought tripleo-image-elements as a repo was going  bye bye?
20:14:42 <ccrouch> i have no idea. I'm just using it as an example of where you can set some stuff "more simply" and then for "not normal setting" its possible to provide a value too
20:14:58 <ccrouch> sdake: its too different schools of thought
20:15:04 <sdake> got it
20:15:17 <sdake> ya I see line 240 - custom config at that point
20:15:18 <ccrouch> 1) generate the full .conf yourself
20:15:18 <ccrouch> 2) tweak the project generated .conf
20:15:27 <ccrouch> s/two/too
20:15:37 <sdake> atm we use crudini to tweak the config
20:15:53 <sdake> which I am perfectly happy with tbh :)
20:16:18 <daneyon> and we have to supply crudini all the non-default K/V pairs
20:16:41 <sdake> yup, so that work is already done
20:16:50 <ccrouch> i think there could be a more automated way to go from a set of K/V pairs to an updated config file
20:17:04 <ccrouch> but perhaps that is a premature optimization
20:17:10 <daneyon> maybe we can tweak the confg scripts to do a loop for non default crudini settings?
20:17:11 <sdake> feed into a crudini loop? :)
20:17:29 <sdake> I like the config scripts as they are
20:17:31 <sdake> simple to comprehend
20:17:43 <sdake> one thing I would change is I woudl crudini *everything*
20:17:56 <sdake> that way everything in the shell script is what gets deployed
20:18:06 <sdake> we may do that already - I'm not sure
20:18:23 <daneyon> but crudini only works on ini style files... correct?
20:18:33 <sdake> this is a problem with crudini
20:18:39 <ccrouch> to be honest i dont think this is critical, because people are going to want to come in and reimplement the containers anyway using their preferred config mgmt tool. I think we should just be looking at implementing a reference impl at the moment
20:18:53 <sdake> +1 to reference implementation
20:19:00 <daneyon> +1 on ref impl
20:19:02 <sdake> doubtful people will reimplement the contaniers, but who knows :)
20:19:10 <sdake> #topic Continuous Integration functional testing status
20:19:15 <sdake> There are two cats working on this
20:19:23 <sdake> one guy is Nikolay who is workign on the gate
20:19:33 <sdake> jpeeler is working on the software the gate will run
20:19:49 <sdake> I haven't had a chance to speak with Nikolay this week, so not sure where he is with his work
20:19:59 <sdake> jpeeler, you got backlogged behind some other more pressing work right?
20:20:23 <jpeeler> for now yes, but later this week i'll get going on it
20:20:28 <sdake> nice
20:20:35 <sdake> lets try to get it going as a complete solution in 1-2 weeks
20:20:41 <sdake> I'll talk to nikolay tomrrow
20:20:48 <sdake> #topic Milestone #3 planning
20:20:53 <sdake> ok, this is a big one
20:21:01 <sdake> I took that monster spec I wrote, and broke it into a bunch of tasks
20:21:30 <sdake> #link https://blueprints.launchpad.net/kolla
20:21:50 <sdake> everything that is mielstone #3 is mandatory to implement the original blueprint I specced out
20:22:03 <sdake> atleast essential/highs
20:22:31 <sdake> anyone interested in taking on some blueprints, keeping in mind our deadline is March 19th for finishing
20:22:53 <sdake> I feel like I've got a pretty full plate for March 19th
20:23:01 <sdake> I have another project, magnum whic h is gunning for march 19th as well
20:23:15 * sdake puts on the leonadis cape
20:23:22 <rhallisey> :p
20:23:29 <rhallisey> I'll take the quickstart
20:23:42 <daneyon> let me look over them for a min
20:23:55 <sdake> ok its assigned
20:24:01 <sdake> thanks rhallisey
20:24:06 <daneyon> i can do this: https://blueprints.launchpad.net/kolla/+spec/container-set-database-control
20:24:42 <daneyon> i can do this: https://blueprints.launchpad.net/kolla/+spec/container-set-api-control
20:24:43 <docaedo> @rhallisey - while you're working on the quickstart, feel free to ping me for review stuff, I'm about to need a quick-start dev guide anyway :)
20:25:01 <sdake> docaedo welcome to the party!
20:25:16 <daneyon> I don;t fully understand this bp: https://blueprints.launchpad.net/kolla/+spec/container-set-service-control
20:25:18 <rhallisey> docaedo, sure, I'll give it go later this week
20:25:39 <sdake> daneyon that is all the containers required to do service control
20:25:44 <sdake> like nova-scheduler
20:25:45 <sdake> heat-engine
20:25:49 <sdake> glance-registry
20:25:51 <sdake> stuff like that
20:26:07 <daneyon> sdake: thx.
20:26:10 <sdake> I think the containers are done
20:26:17 <sdake> what is needed is making them conform to fig
20:26:26 <sdake> and tidying them up a bit
20:26:52 <sdake> anything that says" container set" in front of it is really about integration with fig more then dealing with writing containers
20:26:52 <daneyon> sdake: i should be able to handle that bp too
20:27:00 <sdake> daneyon can yo uassign yourself?
20:27:09 <daneyon> let me try
20:27:54 <ccrouch> i can try to help out with container-set-api-control
20:27:58 <daneyon> sdake: done
20:28:03 <sdake> jpeeler rhallisey anything else you can help on?
20:28:19 <sdake> ccrouch daneyon is yoru man, or he could hand it off entirely if you want to tackle it
20:28:30 <jpeeler> don't want to overcommit
20:28:43 <sdake> jpeeler why overcommitting and imploding is so much fun ;-)
20:28:46 <ccrouch> doh!
20:28:50 * sdake runs
20:28:59 <rhallisey> sdake, we'll see it depends on if I can clear stuff out in the backlog
20:29:03 <sdake> ok thanks jpeeler, feel free to ping me offline if you find some time
20:29:08 <sdake> sounds good rhallisey
20:29:20 <ccrouch> i refreshed too slowly :-) and missed it was already assigned to daneyon
20:29:22 <rhallisey> selinux can randomly explode so you never know
20:29:25 <sdake> so deadline, March 19th
20:29:47 <sdake> we will slip to finish teh feature set up until April 10th or so
20:29:59 <sdake> but lets try to get er done by march :)
20:30:10 <sdake> so we can link up with the rest of openstack release schedule
20:30:12 <sdake> #topic open discussion
20:30:27 <sdake> red makes a really bad color for a unicorn
20:31:18 <sdake> any open discussion or shall I finish themeeting?
20:31:34 <sdake> ok thanks for comingf olks
20:31:42 <daneyon> thx!
20:31:44 <sdake> remember if you ahve agenda items to add to the meeting, please feel free to do so
20:31:48 <sdake> #endmeetingn
20:31:50 <rhallisey> thanks :)
20:31:52 <sdake> #endmeeting