16:30:10 <inc0> #startmeeting kolla
16:30:11 <openstack> Meeting started Wed May  4 16:30:10 2016 UTC and is due to finish in 60 minutes.  The chair is inc0. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:30:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:30:14 <openstack> The meeting name has been set to 'kolla'
16:30:19 <inc0> #topic rollcall
16:30:27 <inc0> good morning;) show of hands guys!
16:30:38 <mlima> i'm here :)
16:30:44 <Jeffrey4l> \o/
16:30:56 <vhosakot> \o\ /o/ \o\ /o/
16:31:05 <pbourke> hey
16:31:10 <britthouser> 0/
16:31:36 <eghobo> o/
16:31:53 <inc0> #topic Announcements
16:31:59 <schwarzm> .
16:32:29 <inc0> summit last week took it's toll
16:32:39 <britthouser> +1
16:32:49 <sdake> hey folks rq, inc0 is going to organize today's meeting, I have a persoanl conflict - bbi2 hours or so
16:33:05 <inc0> cya sdake
16:33:15 <vhosakot> was great meeting everyone.... sorry missed meeting whoever missed the summit
16:33:15 <inc0> so, kolla-kubernates is being created
16:33:39 <inc0> we decided to run it in separate repo
16:34:02 <vhosakot> inc0: so, the vote was to create a separate repo ?
16:34:14 <Jeffrey4l> vhosakot, yes.
16:34:15 <inc0> let's discuss it at topic
16:34:18 <inc0> as*
16:34:23 <vhosakot> cool
16:34:25 <inc0> so, any other announcements
16:34:26 <inc0> ?
16:34:42 <inc0> #topic kolla-k8s
16:34:53 <inc0> so yes, vote is for separate repo
16:35:01 <vhosakot> cool
16:35:36 <inc0> we still have issues with pip's kolla-kubernates as project like that was already created
16:35:43 <inc0> we can go with kolla-k8s
16:36:05 <mlima> the name will be kolla-k8s or kolla-kubernates?
16:36:07 <britthouser> is kolla-kubernetes the OLD stuff (pre-ansible?)
16:36:08 <vhosakot> inc0: from the emails in   http://paste.openstack.org/show/496099/    this topic includes four threads.. "k8s Core team"     "One repo vs two"     "kolla-kubernetes repository management proposal up for vote"    and   "kolla-kubernetes pm's"
16:36:48 <inc0> well, we already decided that yes, we do kolla-k8s at all and it will be in another repo
16:36:53 <vhosakot> yep
16:36:55 <inc0> we need to discuss core-team setup
16:36:58 <vhosakot> yep
16:37:04 <inc0> so I'd like you guys to comment on my email
16:37:16 <inc0> respond*
16:37:18 <Jeffrey4l> the kolla-kubernets has nothing. https://pypi.python.org/pypi/kolla-kubernetes we can re-use it, i think.
16:37:30 <inc0> Jeffrey4l, but we don't own the project in pip
16:38:09 <inc0> any other comments on this one?
16:38:19 <Jeffrey4l> ops.. could we contact the owner?
16:38:31 <inc0> Jeffrey4l, already done, waiting for answer
16:38:38 <vhosakot> britthouser: kolla-kubernetes is one of the names for the repo... we can go with kolla-k8s.. we need to decide if it needs pre-ansbile stuff or not
16:38:38 <inc0> Ryan will know more about it
16:38:40 <Jeffrey4l> ok. cool
16:38:41 <sdake> on my way out - kolla-kubernetes was created by the sap cats
16:38:49 <sdake> i am taking care of getting ownership of it
16:38:52 <sdake> gott aroll bye ;)
16:38:56 <inc0> bye
16:39:01 <Jeffrey4l> bye
16:39:03 <vhosakot> tc sdake
16:39:45 <inc0> any other questions/comments on k8s? things are rolling, we need to figure out this stuff, but it's all in progress
16:39:59 <Jeffrey4l> no.
16:40:03 <vhosakot> we covered repo creation and core team.. there is one more item
16:40:35 <vhosakot> package manager for kolla k8s using kubespray and helm... somebody brought this up in design meeting.. http://lists.openstack.org/pipermail/openstack-dev/2016-April/093188.html
16:41:57 <inc0> yeah, we need to have this discussion
16:42:11 <inc0> but truth be told, I don't know first thing about this;) anyone can comment on it?
16:42:34 <schwarzm> nope but sounds like premature optimization to me
16:43:03 <inc0> oh schwarzm , Michael?;) nice to have you around
16:43:09 <vhosakot> I think it needs to be handled by the packagaing team...
16:43:10 <schwarzm> lets get stuff into the repo to be packaged before knowing how to package
16:43:29 <vhosakot> schwarzm: agreed :)  there is nothing yet to package now!
16:43:35 <inc0> agree, I think we should discuss that later
16:43:40 <vhosakot> cool
16:43:51 <inc0> also I'd love to have kfox input into this as he started this topic
16:44:01 <inc0> so let's move on
16:44:06 <inc0> #topic stable branches
16:44:19 <inc0> (I'm making up ageda as I go, sorry;))
16:44:30 <inc0> so, we have stable/liberty and stable/mitaka to care about
16:44:55 <inc0> we got at least one critical bug in mitaka, ubuntu:latest != ubuntu:14.04
16:45:06 <vhosakot> yes, both are stable and tested... inc0 I see you filed a bug about Ubuntu in summit... was that for master ?
16:45:19 <inc0> as for liberty, https://review.openstack.org/#/c/308390/
16:45:48 <inc0> all 3 of them really
16:46:26 <inc0> I need eyes, thests and merge on patchset above as we don't have liberty right now
16:47:35 <vhosakot> inc0: is the new approach after the megapatch was abandoned ?
16:47:52 <inc0> stable/liberty is a snapshot of stable/mitaka now
16:47:59 <inc0> so it is actually deploying mitaka
16:48:11 <inc0> yes, this is approach we're taking
16:48:18 <inc0> and it's super important
16:48:18 <vhosakot> inc0: got it...
16:48:38 <inc0> can't stress that enough
16:49:05 <inc0> any other comments on that one?
16:49:27 <Jeffrey4l> there are other bug in the gate now.
16:49:36 <vhosakot> inc0: will the new bug (ubuntu:latest != ubuntu:14.04) affect your PS ?
16:49:39 <Jeffrey4l> the rabbitmq crash in the cento deploy.
16:49:47 <inc0> vhosakot, not really
16:49:55 <vhosakot> inc0: cool
16:50:05 <Jeffrey4l> in the mitaka branch, ubuntu + binary is crash.
16:50:22 <vhosakot> Jeffrey4l: is there a bug ?
16:50:30 <Jeffrey4l> if anyone have time, please fix the gate first. thanks.
16:50:39 <Jeffrey4l> vhosakot, which one you mean.
16:50:50 <Jeffrey4l> there are several bug in the gate.
16:51:00 <Jeffrey4l> may be I can post a mail to list the bugs.
16:51:02 <Jeffrey4l> later.
16:51:11 <huikang_> jeffrey4l, that will be great
16:51:15 <vhosakot> Jeffrey4l: yes please... we need bug for each gate issue
16:51:33 <Jeffrey4l> OK. I will write the email after the meeting.
16:51:43 <Jeffrey4l> no other comment.
16:51:51 <inc0> ok, let's move on
16:51:54 <inc0> #topic ansible 2.0
16:52:05 <inc0> we didn't really have time to discuss it on summit
16:52:23 <inc0> and I don't think we have quorum to discuss it really now
16:52:24 <vhosakot> we need to add work items to the bp Jeffrey4l created...
16:52:49 <vhosakot> I can look into kolla_docker... I see PS for kolla_toolbox.. what else needs to be updated for ansible 2.0 ?
16:52:58 <inc0> I'm digging into it now, let me understand scope of changes and then we'll follow up on that
16:53:02 <Jeffrey4l> I do not think there are much work items to do.
16:53:24 <inc0> it should be easy to make it non-exploding
16:53:31 <inc0> but to make it proper, that's a major refactoring
16:53:42 <inc0> vhosakot, I already got kolla_docker working
16:53:50 <Jeffrey4l> vhosakot, yep. as far as I know. only the kolla_docker need more work.
16:53:50 <vhosakot> does moving to Ansible 2.0 affect just the deploy node or the target nodes as well (like control, compute, network, storage)
16:53:55 <inc0> I hope I can propose patchset to allow deploy with 2.0 this week
16:53:59 <vhosakot> inc0: cool
16:54:16 <britthouser> should be just the deploy node @vhosakot, that is where ansible is installed.
16:54:16 <inc0> deployed node doesn't have ansible at all
16:54:24 <Jeffrey4l> inc0, cool. please push it. even it is wip.
16:54:26 <britthouser> ?
16:54:29 <inc0> just deployment
16:54:34 <britthouser> oh
16:54:41 <inc0> deployed nodes*
16:54:42 <britthouser> I missed the -ed vs -ment
16:54:45 <vhosakot> cool... britthouser inc0 that is what I thought
16:55:05 <inc0> I'll post wip soon
16:55:13 <inc0> any other comments on this one?
16:55:27 <Jeffrey4l> thanks.
16:55:31 <vhosakot> Jeffrey4l: is the rabbitmq crash seen on both Centos source and binary in gate ?
16:55:35 <inc0> #topic Open discussion
16:55:38 <Jeffrey4l> vhosakot, yep.
16:55:41 <mlima> when we begin to support Ubuntu 16.04?
16:55:50 <vhosakot> yes xenial
16:55:59 <Jeffrey4l> vhosakot, see this https://review.openstack.org/304205
16:56:05 <Jeffrey4l> gate is lying now.
16:56:14 <inc0> mlima, could you please add bp for that
16:56:14 <inc0> ?
16:56:20 <inc0> or check if it's already there?
16:56:23 <mlima> yes, i can
16:56:24 <huikang_> If you core have time, I would like hear some comment on compute-kit plugin, like nova-docker and neutron OVN
16:56:32 <vhosakot> mlima: does kolla master out of the box work on xenial ?
16:56:38 <inc0> I'd wait a month or two really
16:57:15 <mlima> vhosakot, i don't know
16:57:24 <vhosakot> huikang_: I wanted to reply to your email... sdake has great views about plugins (like nova-docker,  neutron OVN, ODL, etc)
16:57:27 <mlima> but it should work
16:57:37 <Jeffrey4l> seem we have multi open topic. :D.
16:57:45 <inc0> huikang_, https://github.com/openstack/kolla/blob/master/doc/image-building.rst#plugin-functionality have you seen this one?
16:57:55 <huikang_> vhosakot, great. please email after the meeting
16:58:50 <huikang_> inc0, thanks.
16:58:51 <vhosakot> huikang_: do you have any ideas how to handle neutron plugins ? we need an approach for cinder as well.. sberzerk also has ideas for plugins
16:58:53 <Jeffrey4l> current plugin function only work with source installation.
16:59:23 <huikang_> nova-docker and neutron ovn work perfect with source installation
16:59:24 <vhosakot> should the kolla repo carry all the plugin code ?
16:59:26 <mlima> inc0, https://blueprints.launchpad.net/kolla/+spec/add-xenial-support
16:59:34 <inc0> thanks mlima
16:59:54 <inc0> vhosakot, unrealistic
17:00:11 <inc0> even neutron doesn't want to carry all it's plugins code any more
17:00:19 <vhosakot> yes... then, where should the code exist... ? I hear stackforge is dead..
17:00:22 <vhosakot> cinder carries it
17:00:25 <Jeffrey4l> vhosakot, that's not possible.
17:01:02 <huikang_> vhosakot, I build nova-docker and neutron-ovn image
17:01:03 <inc0> we cannot possibly maintain complexity of all of it
17:01:23 <inc0> all we can do is to enable others to build their containers locally
17:01:37 <pbourke> that is what we do currently
17:01:40 <huikang_> inc0, these are optional, like enable_cinder
17:01:41 <vhosakot> yes.. exactly what huikang_ is doing...
17:01:44 <Jeffrey4l> inc0, yea.  kolla need a plugin mechianism like devstack.
17:01:46 <inc0> huikang_, see if link I gave you fixes your issues
17:02:04 <inc0> if it's not let's revisit this topic
17:02:14 <inc0> we have ideas how to make it fully customizable
17:02:36 <inc0> right now you can do mixture of our plugin mechanism and --include-footer
17:03:15 <vhosakot> inc0: can code in {{ include_footer }} be merged into kolla master ?
17:03:25 <mlima> inc0, which will be the default when kolla begin to support xenial?
17:03:38 <huikang_> inc0, since nova-docker is part of the big tent, it makes sense to provide such container, like nova-libvirt
17:03:40 <inc0> vhosakot, what do you mean?
17:04:10 <inc0> mlima, not sure, could you start a ML thread about that?
17:04:34 <inc0> huikang_, we could, sure, it's just a matter of logistics and who exactly will support it
17:04:40 <vhosakot> inc0: I meant if 3rd party plugin code can be added as include_footer ?
17:04:55 <inc0> vhosakot, yeah...why not?
17:05:09 <inc0> all you need to do is to write chunk of dockerfile to install it
17:05:15 <vhosakot> inc0: then, kolla ends up carrying plugin code
17:05:20 <inc0> no
17:05:24 <huikang_> inc0, I can support nova-docker :). The bp exists for a while https://blueprints.launchpad.net/kolla/+spec/nova-docker-container
17:05:30 <inc0> becasue that's you writting dockerfile
17:05:47 <Jeffrey4l> the include_footer is customized and never be merged into kolla code. vhosakot
17:05:48 <inc0> huikang_, well...commit the code then
17:05:53 <huikang_> we have implemented the nova-docker container and ansible
17:06:01 <huikang_> inc0, sure and will do soon
17:06:03 <vhosakot> Jeffrey4l: right... I think include_footer is pure non-kolla code
17:06:25 <inc0> it's whatever you want it to be really;)
17:06:51 <vhosakot> inc0: ecaxtly... it can be whatever the operator wants other than what kolla offers
17:07:04 <huikang_> vhosakot, agree
17:07:17 <vhosakot> huikang_: can you please link that bp as topic in gerrit...
17:08:01 <pbourke> you actually dont need a footer for most cases
17:08:03 <vhosakot> is nova-docker a big tent project ?
17:08:08 <pbourke> if you look in the neutron-server dockerfile
17:08:15 <pbourke> it will install plugins automatically *if* they are available
17:08:19 <huikang_> vhosakot, yes it is
17:08:33 <huikang_> https://github.com/openstack/nova-docker
17:09:00 <huikang_> vhosakot, nova-docker is under openstack repo
17:09:13 <inc0> huikang_, but if it's big tent;)
17:09:44 <inc0> well it's part of nova
17:10:02 <vhosakot> i thought it was a sister project of nova... like how neutron-fwaas or neutron-vpn-aas for neutron... if it is big tent, then, yes, we dont have to treat it like a plugin
17:10:17 <inc0> nah, it's jsut a compute driver vhosakot
17:10:36 <vhosakot> for docker (sorry for dumb q :))
17:10:44 <huikang_> vhosakot, inc0 is right. nova-docker is a driver liek nova-libvirt
17:10:51 <vhosakot> cool
17:11:06 <inc0> huikang_, we can have it in kolla, no problem, just submit patches
17:11:15 <huikang_> inc0, thanks. I will
17:11:23 <vhosakot> yes, agreed.. we should have/welcome it in kolla
17:11:38 <inc0> so any other topic needing attention?
17:11:55 <Jeffrey4l> http://lists.openstack.org/pipermail/openstack-dev/2016-May/093936.html here
17:12:03 <Jeffrey4l> better solution for the non-ini format	configure file
17:12:05 <vhosakot> 2 more.. "Add a gating check job for precheck"   and  threat analysis (what are we doing about this ?)
17:12:11 <Jeffrey4l> comment iw welcome.
17:12:16 <Jeffrey4l> iw/is
17:12:45 <huikang_> will comment after the meeting, jeffrey4l
17:12:51 <vhosakot> I like Jeffrey4l approach to add precheck for _every_ gate job
17:12:53 <Jeffrey4l> huikang_, thanks.
17:13:01 <huikang_> I think precheck gate job should be part of deploy job
17:13:19 <huikang_> so we need to update that bp
17:13:24 <inc0> Jeffrey4l, how does adding this functionality to out merge_config sounds to you?
17:13:25 <Jeffrey4l> just add the precheck to the deploy_aio.sh script is enough, i think.
17:13:26 <vhosakot> right.. precheck should happen pre-deploy... in every gate job
17:13:27 <inc0> might be tricky tho
17:13:30 <vhosakot> Jeffrey4l: yes
17:14:11 <huikang_> will update that precheck bp after the meeting
17:14:12 <inc0> in any case, it will require meddling with merge_configs.py
17:14:25 <inc0> and I'd rather do that once we move to ansible 2.0 fullt
17:14:28 <inc0> fully
17:14:45 <vhosakot> inc0: that is a good point.. as we need to update mer_configs for 2.0
17:14:53 <Jeffrey4l> inc0, maybe just add a extra field to mark the merge strategy?
17:15:31 <inc0> either way, let's focus on migration to 2.0 and in the meantime figure out best strategy
17:15:36 <Jeffrey4l> remember: overwrite is not ideal either. any better solution is welcome.
17:15:45 <inc0> everyone, please consider this topic and respond to Jeffs mail
17:16:03 <vhosakot> yes... http://lists.openstack.org/pipermail/openstack-dev/2016-May/093936.html
17:16:19 <inc0> we can make use of some of jinja2s magics
17:16:38 <mlima> inc0, thread was started in ml
17:16:50 <Jeffrey4l> inc0, maybe.
17:16:57 <vhosakot> I think we already use jija2 to use variables in non-ini files...
17:17:10 <inc0> yeah, what I mean is to go full jinja2
17:17:20 <inc0> I'll show you what I mean, I'll write an email about it
17:17:27 <Jeffrey4l> cool
17:17:39 <vhosakot> cool
17:17:46 <Jeffrey4l> another question is http://lists.openstack.org/pipermail/openstack-dev/2016-May/093799.html
17:17:50 <Jeffrey4l> http://lists.openstack.org/pipermail/openstack-dev/2016-May/093799.html
17:17:56 <Jeffrey4l> [openstack-dev] [Kolla] lock the distro version in the stable branch
17:18:19 <inc0> Jeffrey4l, ubuntu was already merged
17:18:21 <Jeffrey4l> i am thinking may be we need lock the image tag in the master branch either.
17:18:30 <inc0> that we did
17:19:19 <Jeffrey4l> inc0, but that is not ideal and confused the end-user.
17:19:20 <vhosakot> Jeffrey4l: do you mean this ?   -->  https://github.com/openstack/kolla/blob/master/etc/kolla/globals.yml#L20
17:19:48 <inc0> https://github.com/openstack/kolla/blob/master/kolla/cmd/build.py#L347
17:20:00 <inc0> Jeffrey4l, I agree
17:20:07 <Jeffrey4l> moreover. we do not support other Ubuntu release except for trusty. ( because the sources.list file)
17:20:10 <inc0> we need to find better defaults
17:20:22 <inc0> problem is default on this one is dependant on base_distro
17:20:55 <Jeffrey4l> yep
17:21:19 <Jeffrey4l> vhosakot, no.
17:21:43 <Jeffrey4l> vhosakot, i mean the build image stage.
17:21:44 <vhosakot> Jeffrey4l: so, kolla master does not work with Ubuntu 16, we need a bug for it please
17:21:56 <Jeffrey4l> vhosakot, ther base_image and base_image_tag
17:22:26 <mlima> vhosakot, we have a bp https://blueprints.launchpad.net/kolla/+spec/add-xenial-support
17:22:44 <vhosakot> cool mlima!
17:23:05 <Jeffrey4l> I think we should depend on certain specify tag rather than the latest tag.
17:23:10 <mlima> i did right now hehe
17:23:13 <vhosakot> yes, defaulting to 14.04 for base_tag == 'latest'  should not happen for xenial
17:23:31 <inc0> you can specify 16.06
17:23:37 <inc0> and run xenial this way
17:23:55 <vhosakot> yes... to kolla-build... Jeffrey4l did you pass base_tag for kolla-build ?
17:24:02 <mlima> i started this thread http://lists.openstack.org/pipermail/openstack-dev/2016-May/093956.html
17:24:46 <Jeffrey4l> vhosakot, what i want is changing the default behavior.
17:25:32 <Jeffrey4l> i think it work when change the base_tag by using cli paramter or in the kolla-build.conf file.
17:25:41 <vhosakot> well, default for 14 is different than default for 16... I think it is a matter for adding new code for 16...
17:25:42 <vhosakot> cool
17:26:55 <vhosakot> I think we covered all topics... everyone, please add comments if any in k8s spec.. https://review.openstack.org/#/c/304182/
17:27:03 <Jeffrey4l> I do not think we should support both 14 and 16 in one branch.( for example mitaka branch)
17:27:07 <Jeffrey4l> one is enough.
17:27:12 <vhosakot> I think the spec must be full and solid to start any dev
17:27:24 <Jeffrey4l> in this case, options is not good.
17:27:32 <inc0> agree with Jeffrey4l
17:27:44 <inc0> we can easily make our code unmainainable
17:27:55 <inc0> lets focus on one and make it well
17:27:56 <Jeffrey4l> maybe, liberty is 14, mitaka is 14 and newton is 16
17:28:08 <huikang_> I like this
17:28:14 <vhosakot> inc0: yes, I like that too
17:28:25 <Jeffrey4l> easy and enough. :D
17:28:28 <inc0> ok, we ran out of time
17:28:29 <vhosakot> inc0: kolla must gracefully exit on unsupported distro versions
17:28:33 <inc0> thank you guys!
17:28:39 <Jeffrey4l> vhosakot, yes.
17:28:45 <vhosakot> thanks all!
17:28:47 <inc0> part of our upgrade
17:28:48 <pbourke> thanks
17:28:50 <inc0> plays
17:28:55 <inc0> #endmeeting kolla