20:01:53 <sdake_> #startmeeting kolla
20:01:53 <openstack> Meeting started Mon Oct  6 20:01:53 2014 UTC and is due to finish in 60 minutes.  The chair is sdake_. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:57 <openstack> The meeting name has been set to 'kolla'
20:02:06 <sdake_> howdy \o/
20:02:14 <sdake_> #topic rollcall
20:02:14 <rhallisey> heyy
20:02:15 <jdob> o/
20:02:21 <SpamapS> o/
20:02:22 <dvossel> hi
20:02:25 <jlabocki> hello
20:02:28 <bthurber> /thumbs
20:02:33 <jpeeler> hi
20:02:37 <mspreitz> o/
20:02:38 <fvollero> howdy \o/
20:02:54 <sdake_> #topic agenda
20:02:55 <imcleod> hi (lurking)
20:03:02 * stevebaker lurks
20:03:03 <sdake_> https://wiki.openstack.org/wiki/Meetings/Kolla#Agenda_for_next_meeting
20:03:13 <sdake_> anyone interested in adding any agenda items?
20:03:33 * fvollero looks at imcleod suspiciously
20:03:36 * SpamapS reads
20:03:59 * SpamapS nods no
20:04:05 <sdake_> ok
20:04:11 <sdake_> #topic Release cycle discussion
20:04:27 <sdake_> I have a proposal for our release cycle based upon my experiences with early days of Heat
20:04:44 <sdake_> What I'd like to do is have a milestone 1 and milestone 2 where we implement in a somewhat hacky fashion most of the functionality
20:04:47 <larsks> Here!
20:04:52 <sdake_> howdy larsks
20:04:58 <fvollero> larsks: howdy!
20:05:01 <sdake_> milestone1 = Oct 17th (2 weeks out)
20:05:09 <sdake_> milestone 2 = Oct 31 (4 weeks out)
20:05:18 <sdake_> so 2 2 week dev cycles
20:05:24 <sdake_> then 3 1 month dev cycles
20:05:30 <sdake_> then enter the integrated release
20:05:41 <sdake_> (so 6 month cycles from that point forward)
20:05:51 <SpamapS> sdake_: Have you given anyt hought to the swift model .. release more often and try very hard to never break an API?
20:06:11 <sdake_> SpamapS I like that model actually :)
20:06:18 <sdake_> but we will break the api early
20:06:28 <sdake_> I was thinking the integrated release will be when we freeze the api
20:06:38 <sdake_> but I'm not totally clear on the best approach
20:06:45 <sdake_> I'd just like to get a couple early releases out
20:06:47 <SpamapS> Oh I'd call that 1.0 then. :)
20:06:51 <sdake_> I find this helpful to set stakes in the ground :)
20:06:57 <SpamapS> 0.xx == we might break the API
20:07:12 <larsks> (Or even sdakes in the ground)
20:07:23 * sdake_ has been called steak before :)
20:07:26 <larsks> :)
20:07:36 <sdake_> SpamapS that approach wfm
20:07:54 <SpamapS> also It's looking more like there may not be an integrated release beyond the very tight core projects.
20:08:16 <sdake_> SpamapS ok that makes sense
20:08:22 <sdake_> well, lets do this
20:08:30 <sdake_> Lets shoot for 2 milestones with 2 week windows
20:08:33 <sdake_> and then revisit the topic?
20:08:45 <fvollero> /whois portante
20:08:53 <SpamapS> busted. ;)
20:08:57 * sdake_ rofls
20:09:04 <portante> peter portante, works/worked on openstack swift
20:09:04 <fvollero> yep :)
20:09:12 <larsks> sdake_: That sounds fine.
20:09:28 <portante> I work at Red Hat with rook
20:09:29 <fvollero> portante: yeah, wanna check before saying something stupid :)
20:09:32 <sdake_> ok cool, if there are no objections then we will proceed with the 17th as our milestone release 1
20:09:32 * SpamapS will support what the group decides, is just here to learn and interject at times. :)
20:09:47 <daneyon> I agree with the 2 wk cycles then revisit.
20:10:00 <sdake_> cool sounds like we have a winner :)
20:10:06 <sdake_> #topic multi-dev workflow
20:10:19 <sdake_> larsks can you give us a description of the multi-dev workflow
20:10:25 <larsks> Sure.
20:10:39 <larsks> The build scripts that recently landed will, by default, push to a docker tag based on your current commit id.
20:10:56 <larsks> This helps to prevent stomping on someone else's images (but does not completely prevent it)
20:11:05 <larsks> and it also prevents accidentally stomping on the release images.
20:11:18 <larsks> The build scripts can be configured locally so that, e.g., you always build into your own namespace instead.
20:11:24 <larsks> And always to, e.g., the "latest" tag.
20:11:40 <larsks> There is a --release option that must be used when building to the kollaglue  namespace with the "latest" tag.
20:11:45 <larsks> That's it in a nutshell.
20:11:52 <sdake_> the cool thing about all this is we dont have to add a million people to the kolla upstream org in docker.io
20:12:10 <sdake_> iirc there is documentation
20:12:23 <larsks> sdake_: Yes, in docs/image-building.md
20:12:35 <sdake_> cool, so devs, I'd recommend reading through that
20:12:40 <sdake_> it should take 5-10 minutes
20:12:45 <larsks> And yell at me if something is broken.
20:12:59 <sdake_> any questions?
20:13:07 <fvollero> sdake_: what about the environment ?
20:13:25 <sdake_> fvollerro I dont understand the Q
20:13:35 <sdake_> which environment specifically?
20:14:07 <sdake_> larsks can you link the heat-kube repo with #link?
20:14:09 <fvollero> sdake_: yeah, sorry, dev environment, we need to be aligned, pinned to a min specific version of docker ?
20:14:24 <larsks> #link https://github.com/larsks/heat-kubernetes
20:14:34 <sdake_> fvollero check that out
20:14:51 <sdake> any other QS?
20:15:13 <larsks> fvollero: that link is not going to answer your question...but I don't think we're sensitive to docker version, at least as far as building goes.
20:15:14 <fvollero> larsks: sdake : thanks a bunch
20:15:22 <sdake> cool
20:15:25 <sdake> #topic crux
20:15:31 * larsks hides.
20:15:37 <sdake> robot where are you
20:15:42 <sdake_> #topic crux
20:15:58 <sdake_> mind giving a rundown of crux larsks
20:16:01 <larsks> Sure.
20:16:40 <larsks> So, we need a way to create keystone users, tenants, services, endpoints, etc.  It needs to be idempotent, so that restarting a container does not blow up.  And it should not require a lot of extraneous shell script logic to make it work.
20:16:59 <larsks> I dusted off some code at wrote at my last job that handles this sort of thing for users, and expanded it to handle services and endpoints, too.
20:17:18 <larsks> You can say, "user-create -n lars -t myproject -p secret -r admin", and it will:
20:17:23 <larsks> - create the myproject tenant, if necessary
20:17:23 <SpamapS> larsks: there's a _ton_ of code in tripleo-image-elements and/or os-cloud-config that does this...
20:17:29 <larsks> - create the "admin" role, if necessary,
20:17:35 <larsks> - create the "lars" user, if necessary
20:17:41 <larsks> - assign the role, if necessary
20:17:52 <larsks> I looked at the os-cloud-config stuff, and it looked like an unnecessarily big hammer.
20:17:53 <sdake_> SpamapS I think there is general agreement we want to replace this with os-cloud-config in milesxtone 2
20:17:59 <larsks> I'm not sure.
20:18:07 <larsks> It's possible I didn't looked closely enough.
20:18:21 <sdake_> the cool thing about os-cloud-config is it has all the magic
20:18:23 <larsks> If someone wants to put together a demo that uses os-cloud-config instead, that would be a useful comparison.
20:18:24 <SpamapS> larsks: perhaps the hammer got that big because tripleo has found the larger spikes deeper in.. ;)
20:18:36 <larsks> SpamapS: Maybe, but we might not have the same issues.
20:18:45 <larsks> Anyway, like I said, if someone can put together a demo that would help.
20:19:07 <larsks> In the meantime, I would like to advocate for approving my changes for now, because it will really simplify things in the short term.
20:19:09 <sdake_> doesn't have to be a demo, patch would ge thte job done
20:19:19 <larsks> We can always wipe it out in favor of something eles down the road.
20:19:26 <sdake_> ya if we can get some reviews on that change, it would be appreciated
20:19:42 <larsks> Is there a way to see "all pending changes for the kolla project"?
20:19:43 <sdake_> larsks do you have a link to the review
20:19:51 <sdake_> larsks you can click watched projects
20:19:58 <sdake_> and add kolla to your watched projects
20:19:58 <SpamapS> Indeed, just pointing out that the need for an API bootstrap is not exactly new nor is it poorly handled in the existing code base.
20:20:13 <larsks> here is that review: https://github.com/larsks/heat-kubernetes
20:20:16 <larsks> Whoops.
20:20:19 <larsks> I meant: https://review.openstack.org/#/c/126067/
20:20:23 <sdake_> SpamapS my approach is fast and furious with lots of mistakes early on :)
20:20:27 <larsks> Stoopid multiple clipboards.
20:20:33 <sdake_> I'd like to tidy these sorts of issues up though over time
20:20:38 <sdake_> like after each milestone
20:20:39 <SpamapS> sdake_: perhaps you can avoid _a few_ of the mistakes that we already made?
20:20:45 <sdake_> agree
20:20:50 <sdake_> it was just a joke :)
20:21:01 <sdake_> vin diesel reference
20:21:10 <rhallisey> ha
20:21:21 <SpamapS> I'm pretty sure this particular part will "just work" as long as you have OpenStack API's. :)
20:21:57 <larsks> SpamapS: Write us a demo! I stopped looking at os-cloud-config when it started trying to ssh places on me...
20:22:01 <sdake_> so if we could get some reviews on 126067 it would be appreicated
20:22:09 <larsks> ...but I new that I already had some code handy that did this.
20:22:30 <larsks> If you can replace "crux" in that review with "os-cloud-config" with the same or similar semantics, I am all for it.
20:22:30 <sdake_> well here is my take
20:22:33 <SpamapS> larsks: how does the current code initialize keystone's admin token and PKI?
20:22:35 <sdake_> larsks already has a patch ready to go
20:22:48 <sdake_> we fcan nuke it in milestone 2
20:22:58 <sdake_> and switch to os-*-*
20:23:09 <sdake_> SpamapS does that approach work for you?
20:23:11 <larsks> SpamapS: admin_token is set via an environment variable right now, since it needs to be shared across containers.
20:23:27 <SpamapS> Oh hey no don't stop for this. I am a big fan of set based design. I just want to make sure os-cloud-config isn't completely left behind because of a misunderstanding.
20:23:32 <larsks> SpamapS: PKI is initialized using the PoC setup-pki-script, whatever it is called.
20:24:01 <SpamapS> larsks: ok, admin token works the same in the current code, and the SSH in is just to setup the PKI.
20:24:02 <sdake_> SpamapS cool sounds like we are all in violent agreement then that os-cloud-config needs more analysis from the core team
20:24:19 <sdake_> by more, I mean some :)
20:24:36 <SpamapS> larsks: let's compare notes after the meeting
20:24:41 <sdake_> any Qs?
20:24:41 <SpamapS> or after the milestone
20:24:44 <SpamapS> whichever you choose. :)
20:24:54 <larsks> SpamapS: Either!  But not right after the meeting, because I will be commuting.
20:25:09 <sdake_> #topic milestone #1 blueprints
20:25:24 <sdake_> #link https://blueprints.launchpad.net/kolla/milestone-1
20:25:37 <sdake_> I believe this is the minimum set of features we want for milesetone 1
20:25:50 <sdake_> we can possibly drop heat and neutron if we want to hit the 17th and those aren't going to make it
20:25:58 <sdake_> would folks open that up in their browser?
20:26:09 <larsks> sdake_: "keystone" is missing I think.
20:26:14 <larsks> Ooops.
20:26:15 <larsks> nEver mind.
20:26:38 <sdake_> so 3 days of dev - 2 implements blueprints
20:26:39 <larsks> Should "glance" be essential rather than "high"? We won't be able to boot into a nova container with it...
20:26:40 <sdake_> \o/
20:26:42 <sdake_> moving fast!@
20:27:05 <sdake_> larsks just changed to essential
20:27:35 <sdake_> I'd like to go through each of the blueprints and get a status report if possible
20:27:42 <tsv> hi there, I added a new blueprint to containerize Barbican: https://blueprints.launchpad.net/kolla/+spec/kube-barbican-container
20:27:44 <sdake_> radez any word on kube-glance-container?
20:27:55 <larsks> sdake_: I'd like to update on that, actually.
20:28:12 <sdake_> tsv sounds good I'll prioritize after meeting
20:28:12 <larsks> sdake_: I have working mariadb/keystone/glance as part of the work I was doing with the haproxy stuff.
20:28:13 <radez> yea larsks did some work...
20:28:26 <larsks> I fixed a bunch of stuff in the glance container as part of that, since I needed it working to test keystone integration.
20:28:26 <tsv> sdake_, thanks!
20:29:06 <larsks> I have a series of patches to land if folks are happy with the haproxy idea I floated on the mailing list.
20:29:15 <sdake_> larsks cool so there are just some patches that need reviews?
20:29:49 <larsks> There may be, pending response on that haproxy topic.  There are some pending reviews right now that probably need to land first.
20:30:03 <sdake_> cool
20:30:09 <daneyon> sdake_: I have a neutron container running the API here #link https://github.com/danehans/docker-neutron-server I am working on building my kolla dev environmnt and porting over the work from my docker-neutron-server repo.
20:30:24 <sdake_> #action core team to review kolla patch queue to unblock glance
20:30:42 <sdake_> daneyon nice!
20:30:47 <sdake_> you want to take that blueprint then?
20:31:17 <rhallisey> sdake_, I already gave it to him
20:31:24 <sdake_> nice!
20:31:32 <sdake_> libvirt
20:31:35 <sdake_> in progress
20:31:38 <sdake_> just started
20:31:42 <sdake_> goign to be painful
20:31:56 <rhallisey> sdake_, where you going to do nova-compute?
20:32:00 <rhallisey> were*
20:32:05 <sdake_> rhallisey  mind giving us an update on nova-controller?
20:32:10 <sdake_> yes I'm doing nova compute and libvirt
20:32:13 <rhallisey> ok cool
20:32:32 <rhallisey> just in progress, did a bunch of setup stuff over the weekend
20:32:36 <daneyon> sdake_: I think it will be difficult to get the other neutron services containerized by release.  When I started looking at containerizing neutron agents, it appears that we will need to leverage pipework to support multiple interfaces needed by neutron-openvswitch-agent.
20:32:57 <sdake_> daneyon you mean by the 17th?
20:33:22 <larsks> daneyon: agreed.  using pipework is probably a non-started; we probably need kubernetes to support network interface provisioning.
20:33:40 <sdake_> sounds like neutron just isn't going to make milestone 1
20:33:49 <sdake_> perhaps I should just bounce to milestone 2?
20:33:49 <daneyon> sdake_: Yes. I have yet to do much of anything with pipework.
20:34:23 <sdake_> ok i moved to milestone 2
20:34:45 * larsks has to take off shortly for kid transportation reasons.
20:35:03 <sdake_> kube-rabbitmq-container
20:35:18 <sdake_> jlabocki any status?
20:35:35 <larsks> sdake_: I can help out with that one if jlabocki is busy.
20:35:46 <sdake_> larsks I think jpeeler is goign to tackle that
20:35:51 <larsks> sdake_: Awesome.
20:35:53 <sdake_> if jlabocki is busy
20:35:58 <jpeeler> yes!
20:36:03 <jlabocki> sdake: larks: that would appreciated
20:36:08 <sdake_> cool go ahead and assing yourself jpeeler
20:36:29 <sdake_> larsks can I change image-dev-workflow to "Needs Code Review"?
20:37:32 <sdake_> chmouel around?
20:37:41 <sdake_> json-validate-gate
20:38:22 <sdake_> ok well I'll try to catch up with chmouel later and see where the json gate work is
20:38:35 <sdake_> sounds like we are in really good shape - biggest problem atm is long review queue
20:38:45 <sdake_> and nova needs implementation work
20:39:10 <sdake_> #topic milestone 1 bugs
20:39:21 <sdake_> #link https://bugs.launchpad.net/kolla/milestone-1
20:39:49 <larsks> sdake_: sure.
20:39:56 <larsks> sdake_: re: needs code review
20:40:06 <sdake_> these need triaging, so I'll go ahead and triage after meeting
20:40:15 <sdake_> #action sdake to triage m1 bugs
20:40:28 <sdake_> I think these aer eall fixed btw
20:40:41 <sdake_> anyone run into bugs not in the launchpad tracker?
20:40:49 <larsks> 547064
20:40:57 <sdake_> If so, could folks _please_ submit bug reports in the launchpad tracker?
20:41:06 <daneyon> will do
20:41:29 <sdake_> #topic mordred's DIB docker container work
20:41:35 <sdake_> mordred happen to be ar ound?
20:41:40 <larsks> sdake_: I have to run off.  I will review backlog later this evening.
20:41:47 <sdake_> larsks sounds good thanks!
20:42:18 <sdake_> SpamapS do you know what Mordred has in mind here?  Was hoping to give an info sharing going
20:42:51 <mordred> what did I do?
20:43:04 <mordred> oh - so, real quick
20:43:05 <sdake_> mordred your WIP patch
20:43:23 <mordred> the idea is that the underlying engine/mechanism inside of dib be docker instead of a chroot
20:43:45 <mordred> this gets decent isolatino - and also means that if all you want is a docker container, you can just stop before making cloud images
20:44:14 <mordred> but then, if you want a qcow or somethign else, the additinoal step to export the tarball from docker and turn it into a qcow is easy to wrap the brain around
20:44:21 <mordred> nice potential benefits are:
20:44:33 <mordred> - take advantage of docker hubs being able to slurp image bits around
20:44:49 <mordred> - use the composability of dib elements to put together docker containers
20:45:09 <mordred> - less running of sudo while making an image
20:45:26 <mordred> in fact, sudo access is no longer needed for anything other than docker to qcow conversion
20:45:39 <mordred> how's that fora quick summary?
20:45:44 <sdake_> nice
20:45:58 <SpamapS> less sudo would be fantastic.
20:46:01 <mordred> most of the guts are done - I need to incorporate the static files patch I hadn't noticed
20:46:02 <sdake_> I think you missed our early milestone approach - s o we are targeting m12 for oct 17, m2 for oct 31
20:46:09 <sdake_> maybe this is something we can investigate in milestone 2 dev
20:46:11 <mordred> and I need to rewrite almost every extra-data.d script in elements
20:46:26 <sdake_> mordred sounds like fun :)
20:46:26 <SpamapS> sounds to me like this is something to look at "when it is ready"
20:46:33 <mordred> fwiw, I could almost certainly get it done by oct17
20:46:35 <sdake_> SpamapS sounds good
20:46:36 <mordred> it's really not that far off
20:46:43 <mordred> but I do agree - "when it's ready" is the right time
20:46:45 <SpamapS> it has benefits outside kolla too
20:46:45 <sdake_> ya we just can't use it by oct 17
20:46:50 <sdake_> cool
20:47:03 <mordred> SpamapS: ++
20:47:17 <mordred> I imagine it will have benefits both in and out of openstack - or at least I hope it will
20:47:18 <SpamapS> though it might mean we can't build images on RHEL5
20:47:24 <mordred> meh
20:47:26 * SpamapS REALLY hopes people get that joke.
20:47:26 * mordred don't care
20:47:35 * mordred throws wet joke at SpamapS
20:47:44 * SpamapS squishes
20:47:49 <sdake_> ;-)
20:47:49 <daneyon> What about using Packer for building images?
20:47:58 <sdake_> got a link to pacvker?
20:48:09 <sdake_> so many tools :)
20:48:11 <daneyon> #link http://www.packer.io/
20:48:23 <mordred> honestly, last time I looked at packer I got hives
20:48:27 <mordred> but that's not a real reason
20:49:00 <sdake_> #topic Open Discussion
20:49:00 <mordred> oh - I rmemeber now
20:49:05 <sdake_> Ok folks, time for open discussion
20:49:14 <mordred> packer follows the model that we just moved _away_ from in infra
20:49:27 <mordred> which is spinning up a cloud instance and then remote connecting to it to run commands inside of it
20:50:06 <SpamapS> sdake_: open question: is there a plan for how to update a Kolla installation?
20:50:13 <mspreitz> mordred: because ... ?
20:50:18 <sdake_> kill container
20:50:20 <sdake_> start container
20:50:26 <sdake_> you just updated
20:50:45 <SpamapS> that's mechanical and manual, is there no automated update?
20:50:53 <sdake_> oh it will be automated imo
20:51:06 <sdake_> by kill container , I mean write data to the kube rest api
20:51:49 <sdake_> one way it could work is scan containers on a 5 minute interval - if new update, t hen kill/start
20:52:10 <SpamapS> and what about things like, you need to run a db migration somewhere in there, or update in a particular order?
20:52:17 <sdake_> when you start a container in kube, if there is an update in the docker registry, it pulls the latest bits down
20:52:27 <SpamapS> I'm getting at -> tripleo-ansible :)
20:52:30 <sdake_> ordering updates is a challenge
20:52:38 <sdake_> db migration should be easy
20:52:39 <tsv> how about using etcd for that ?
20:52:47 <sdake_> etcd is part of kubernetes
20:53:04 <tsv> yes, so why can't that be used to know when to update ?
20:53:06 <sdake_> tsv yes, the rest api I am talking about is either etcd or kubernetes's mapping on etcd
20:53:15 <tsv> ah ok. thanks
20:53:58 <SpamapS> Not sure I'd say db migration is easy
20:54:10 <sdake_> maybe not
20:54:15 <SpamapS> Nova, for instance, requires that you update the conductor, then run it, then update everything else.
20:54:18 <sdake_> we have a general problem atm that data is not persistent
20:54:25 <sdake_> kubernetes guys working on this problem
20:54:27 <mspreitz> why did infra move away from the model that packer is using, and how is tripleo-ansible different?
20:54:29 <sdake_> it is their #1 issue atm
20:54:58 <SpamapS> tsv: knowing when to update is pretty easy. Knowing how to update is a workflow control problem and we're solving it in tripleo-ansible already.. so I was wondering if we can just insert awareness in all of your minds that it exists. :)
20:55:16 <SpamapS> mspreitz: tripleo-ansible is agnostic of how images are built
20:55:21 <SpamapS> mspreitz: infra does not use tripleo-ansible
20:55:29 <SpamapS> two different things
20:55:31 <sdake_> cool I caught the reference SpamapS - firehose reading the code basews for all the projects :)
20:55:57 <SpamapS> sdake_: mmk just want to suggest that it be looked at when it comes to to automate updates.
20:55:58 <mordred> mspreitz: infra moved away from it in favor of dib because it allows us to make one image and upload it to all of our cloud regions
20:56:10 <SpamapS> when it comes _time_ to automate I mean
20:56:11 <mordred> mspreitz: we are not doing it yet, but it also allows us to test the image before we upload it
20:56:37 <mordred> mspreitz: the packer model is ... fragile ... although totally workable - I mean, we did use it for the last 2 years (although not with packer)
20:56:39 <sdake_> automate all the things :)
20:57:20 <sdake_> 3 minutes left - any pressing issues?
20:58:16 <sdake_> ok, well folks if your in the review team, please please review
20:58:24 <sdake_> the queues have been running a bit slow
20:58:29 <mordred> mspreitz: one could theoretically model the same thing as dib-docker with packer if you used packer+docker and then did an export/conversion
20:58:46 <SpamapS> whaaaa review queue in openstack running slow!!??
20:58:51 <mordred> but at that point the question woudl be what content can you express in packer and what can you express in dib-elements
20:59:06 <sdake_> SpamapS yes but we only have 5-10 patches outstanding not 10 pages :)
20:59:20 <SpamapS> you could use the instack element-running method inside packer.
20:59:25 <mordred> and the composablity of dib elements on top of docker is quite nice
20:59:39 <sdake_> ok well I'm going to end meeting, we can follow up in tripleo channel
20:59:44 <sdake_> thanks for attending !
20:59:46 <sdake_> #endmeeting