16:01:49 <inc0> #startmeeting kolla
16:01:50 <openstack> Meeting started Wed Jan  4 16:01:49 2017 UTC and is due to finish in 60 minutes.  The chair is inc0. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:54 <openstack> The meeting name has been set to 'kolla'
16:02:28 <inc0> #topic rollcall - w00t for kolla
16:02:30 <duonghq> o/
16:02:34 <srwilkers> o/
16:02:36 <egonzalez90> woot o/
16:02:44 <jascott1> woot
16:02:51 <qwang> o/
16:02:52 <mliima> \ô
16:02:55 <Jeffrey4l> \0/
16:03:06 <lrensing> o/
16:03:08 <vhosakot> o/
16:03:10 <pbourke> w00t
16:03:10 <sbezverk> o/
16:03:13 <lrensing> woot
16:03:14 <portdirect> w00t
16:03:27 <vhosakot> w00t
16:04:26 <britthouser> 0/
16:04:44 <inc0> #topic agenda
16:04:52 <inc0> * Roll-call
16:04:53 <inc0> * Announcements
16:04:53 <inc0> * Documentation
16:04:53 <inc0> * Brainstorming PTG topics (we have 2 days of PTG space) timebox [30 minutes]
16:04:53 <inc0> * Open Discussion
16:04:55 <sdake> o/
16:05:11 <inc0> it's going to be lightweight meeting
16:05:13 <inc0> :)
16:05:17 <inc0> #topic Announcements
16:05:18 <Jeffrey4l> inc0, i added kolla-ansible dependecy ;)
16:05:19 <sdake> note I have to leave in about 20 mins :)
16:05:28 <inc0> happy new year everyone!
16:05:59 <inc0> any other announcements?:)
16:06:45 <inc0> guess not
16:06:48 <portdirect> inc0 returned from the wilderness?
16:06:56 <inc0> no, arrived to one
16:07:00 <portdirect> lol
16:07:12 <inc0> #topic Documentation
16:07:13 <vhosakot> lol
16:07:20 <inc0> Sayantani is not here, she's out sick
16:07:32 <inc0> so we might need to move this one once more
16:07:32 <srwilkers> she's been doing solid work trying to tidy up the docs
16:08:09 <srwilkers> yeah, we should move this one more week. next week should be the last time we move it though. its something we should get to a solid place on because we have quite a few doc fixes sitting in the review queue iirc
16:08:11 <pbourke> inc0: can we be more specific on which aspect of docs we're discussing?
16:08:52 <inc0> pbourke, person who set this up is sick:( so we need to move the topic
16:08:55 <sdake> portdirect oregon is sort of wild - much like arizona :)
16:09:05 <pbourke> inc0: roger
16:09:55 <srwilkers> hey sayantan_
16:10:03 <sayantan_> Hey
16:10:27 <inc0> do you feel well enough to have docs discussion?
16:10:30 <inc0> sayantan_,
16:10:34 <sayantan_> Yes sure
16:10:49 <inc0> go ahead then, you're up:)
16:11:04 <sayantan_> So, I wanted to discuss if we should have separate documents for the operator and developer workflow
16:11:42 <portdirect> which sub-project?
16:11:52 <portdirect> or kolla-*?
16:11:56 <srwilkers> portdirect, for example: https://review.openstack.org/#/c/404993/
16:11:57 <sayantan_> Kolla-*
16:12:01 <sayantan_> yes
16:12:04 <sayantan_> this would mean a lot of duplication which will get difficult to maintain.
16:12:15 <sayantan_> To address the duplication, we can have different rst files for the common sections of the documents and include them in the other docs.
16:12:24 <sdake> portdirect the correct terminology is deliverable :)
16:12:35 <Jeffrey4l> sayantan_, i think we need separate doc for different kolla-* project.
16:13:12 <sayantan_> Do we need to separate it by OS as well
16:13:15 <sdake> sayantan_ so there are three things here - kolla kolla-ansible, and kolla-kubernetes
16:13:15 <Jeffrey4l> put the doc into its owner project. rather put all doc into kolla project.
16:13:17 <sayantan_> as in ubuntu centos etc?
16:13:32 <sdake> sayantan_ i think its best to focus on kolla-ansible documentation since its in teh worst shape
16:13:32 <sayantan_> Jeffrey will do that
16:13:38 <srwilkers> Jeffrey4l, i think the point of discussion is operator vs dev workflow in docs, not so much where the docs are housed
16:14:00 <Jeffrey4l> sdake, inc0 srwilkers will we have operator doc?
16:14:20 <sdake> Jeffrey4l i think that is what sayantan_ is working on iiuc - a document for operators
16:14:27 <Jeffrey4l> sayantan_, it is better to have different OS part.
16:14:33 <sdake> sayantan_ maybe I am confused on who is doing what :)
16:14:57 <pbourke> sayantan_: my vote would be to keep operator and developer docs separate
16:14:58 <Jeffrey4l> oops. i thought we are talking about dev doc :(
16:15:00 <srwilkers> after looking at the docs, i think it's best to streamline as much as we can. a decent amount of the workflow is similar at this point. instead of maintaining two distinct doc sets, i think we should maintain one set and make detailed notes in that workflow where the two scenarios diverge
16:15:03 <sayantan_> So, my point was, in order to do the separation, there will be certain parts common in both the docs. To minimize effort of maintenance, we will need to have different rst files for the common portions of these documents
16:15:06 <srwilkers> this doesnt seem to happen all that often currently
16:15:06 <pbourke> sayantan_: with an emphasis on operator
16:15:18 <sdake> srwilkers what you described is what we have today
16:15:32 <pbourke> do we even need developer docs
16:15:34 <srwilkers> sdake, correct. but see the review i linked. thats the point im discussing
16:15:45 <srwilkers> https://review.openstack.org/#/c/404993/ just incase
16:15:49 <sayantan_> sdake how you had suggested
16:15:52 <inc0> so how about going back
16:15:57 <portdirect> pbourke: yes - these ar hyper important
16:16:06 <inc0> and try to remove this "operator" and "dev" workstreams?
16:16:06 <sayantan_> trove has it that way Trove has it that way Please check https://github.com/openstack/trove/tree/master/install-guide/source for reference
16:16:21 <inc0> I mean, it's really strange to have it
16:16:22 <pbourke> they are essentially the same thing
16:16:32 <inc0> yeah, issue is versioning with pbr afair
16:16:40 <sdake> sayantan_ will you be at the ptg?
16:16:40 <inc0> git clone - not working, pip - working
16:16:52 <sdake> sayantan_ we have made about 10 outlines of documentation in the past
16:16:54 <sdake> maybe 5-8 :)
16:16:56 <sdake> but a bunch
16:16:56 <sayantan_> No, I will not be able to attend it unfortunately
16:16:59 <sdake> and they never get done
16:17:18 <pbourke> if pbr is making things difficult we should vote to drop it
16:17:20 <srwilkers> problem is, they need to get done
16:17:22 <sdake> each time we do an outline they get better ,however, the repo split has made it difficult
16:17:39 <sdake> pbourke reno and pbr are tightly integrated IIUC
16:17:47 <sdake> dhellmann would be able to validate my assumption
16:17:56 <pbourke> pbr is a pos
16:18:08 <sdake> pbourke so dropping pbr makes release notes an impossibility - I htink but not certain
16:18:15 <portdirect> lets let sayantan_ outline their vision.
16:18:18 <sdake> pbourke agree pbr is a pile :)
16:18:39 <sdake> portdirect wfm :)
16:19:18 <sdake> sayantan_ the reason for the pbr discussio nabove is because that is why we have the developer docs at all in kolla and kolla-ansible
16:19:19 <sayantan_> So are we going for both workflows in the same doc?
16:19:25 <sdake> kolla-kubernetes has dev docs for a different reason
16:19:43 <sayantan_> oh
16:20:23 <sdake> i think if your making new docs or improving the ones we have, for kolla and kolla-kubernetes we could drop the workflow and just handhold people through that process if they want to do devvelopment
16:20:34 <sdake> rather kolla-ansible, not kolla-kubernetes
16:20:41 <portdirect> yeah - the developer doc for k8s decribe setting up a non production ready reference cluster, a real cluster is out of scope for kolla-k8s
16:20:46 <sayantan_> okay
16:20:57 <pbourke> even with pbr the differences for dev are minor, they could be described in a separate doc
16:20:59 <sdake> sayantan_ my suggesetion would be to not try to tackle kolla-kubernetes for the moment
16:21:13 <sayantan_> sdake I plan the same
16:21:21 <sayantan_> Will work on the kolla-ansible docs first
16:21:33 <sayantan_> And are we deciding to divide it by OS?
16:21:39 <sayantan_> ubuntu centOS etc?
16:21:47 <Jeffrey4l> pbourke, pbr is not a big issue. and the root cause is how to sync the tag name between kolla and kolla-ansible, not pbr.
16:22:17 <berendt> o/
16:22:18 <inc0> sayantan_, with our playbook it's not any different really
16:22:19 <portdirect> I think divion by os makes sense - as it can get really confising trying to follow a dock that covers both
16:22:20 <Jeffrey4l> s/tag name/tag number
16:22:24 <inc0> ubuntu vs centos
16:22:29 <pbourke> sayantan_: there is a feature used in guides on docs.openstack.org where they have docs generated for centos/ubuntu from the same sources
16:22:33 <sdake> portdirect agree
16:22:39 <pbourke> sayantan_: it would be great if we could use this functionality
16:22:45 <sayantan_> pbrouke
16:22:52 <sdake> sayantan_ ya we dont know how to do that :)
16:22:55 <sayantan_> It can only be used in openstack.org docs
16:23:00 <pbourke> ah
16:23:02 <pbourke> :( !
16:23:04 <sayantan_> I had a discussion with the docs team
16:23:18 <portdirect> (at least for host setup - if by the time the playbooks are run its the same then there is not point having a sperate one for that)
16:23:18 <sayantan_> It can be done on a project level
16:23:36 <sayantan_> check this one check https://github.com/openstack/trove/tree/master/install-guide/source
16:24:18 <sayantan_> The trove guys have done it on a project level by separating the common parts in separate rst files
16:24:36 <sayantan_> But this would mean a little more maintenance
16:25:11 <srwilkers> i dont see a problem with that maintenance. we should expect some associated with docs as the deliverables iterate anyway
16:25:12 <inc0> so my idea would be
16:25:16 <sdake> ok - gotta jet - would like to attend more, but have to go
16:25:20 <sdake> bye folks :)
16:25:23 <sdake> i'll read the logs later
16:25:26 <sdake> (tonight)
16:25:29 <inc0> to get back and figure out *why* do we have 2 different installation processes
16:25:37 <inc0> if it's pbr, just try to fix pbr
16:25:42 <sayantan_> okay
16:25:53 <inc0> and try to squeeze this to one workstream
16:25:58 <sayantan_> that sounds good
16:25:59 <sdake> inc0 there is a log on the ml in [kolla] explaining why that can't be done
16:26:00 <sayantan_> :)
16:26:02 <inc0> that would make docs much clearer
16:26:07 <sdake> inc0 agree
16:26:09 <sdake> gotta jet :)
16:26:43 <inc0> k thanks sdake
16:26:57 <sayantan_> Also, the openstack.org team wants to integrate kolla with the openstack.org docs
16:27:31 <inc0> http://docs.openstack.org/developer/kolla/ <- any more than that?
16:27:32 <sayantan_> So, if we can get this up, we can have the kolla docs in the openstack.org docs, giving us more visibility
16:27:59 <pbourke> I think that sounds great
16:28:07 <portdirect> thats awesome! (as an outside i used to judge that as a lvel of a projects maturity)
16:28:13 <portdirect> *outsider
16:28:20 <inc0> yeah, so guys, let's quickly think about this 2 workstreams
16:28:24 <pbourke> I find the guides on docs.openstack.org to be of good quality
16:28:29 <SamYaple> o/
16:28:29 <sayantan_> They want the doc team involved so that they can maintain it moving forward
16:28:32 <berendt> i think docs team want to include kolla at http://docs.openstack.org/project-deploy-guide/newton/
16:28:38 <inc0> SamYaple, good that you're here, might actually help
16:28:46 <SamYaple> /leave
16:28:50 <inc0> why do we have two workstreams again?
16:29:02 <SamYaple> i need to read scrollback
16:29:09 <inc0> is this only because of pbr incorrectly tagging images if installed from git
16:29:10 <inc0> ?
16:29:30 <inc0> SamYaple, in short, dev installation guide and ops installation guide...why?
16:29:32 <sayantan_> berendt that's how they want it. You are right
16:29:45 <SamYaple> inc0: i said no to that
16:29:51 <SamYaple> i disagreed iwth it
16:30:10 <inc0> I disagree with it too, just trying to figure out why do we even consider it
16:30:11 <sayantan_> Yes, this discussion stems from SamYaple 's concern
16:30:17 <inc0> and only thing that comes to mind is pbr
16:30:26 <SamYaple> the reasoning i got was "well merge them later" but i thought that was bad reasoning
16:30:31 <SamYaple> we never do things later!
16:30:45 <sayantan_> If it only pbr, let us fix it and have one doc
16:31:13 <sayantan_> It will be better if we do not complicate it by having more docs to maintain
16:31:24 <portdirect> +1, lets fix a problem rather than create new ones to work round therm
16:31:52 <sayantan_> Will take up the pbr issue and fix it
16:31:54 <Jeffrey4l> if it is caused by pbr, a note is enough. no need add a extra doc file.
16:31:56 <SamYaple> duplicate docs*
16:32:00 <SamYaple> more docs are fine
16:32:08 <sayantan_> yes
16:32:43 <inc0> I think this is ML thread sdake mentioned http://lists.openstack.org/pipermail/openstack-dev/2016-September/103619.html
16:33:18 <inc0> and yeah, seems to be pbr issue
16:33:26 <inc0> let's fix our versioning and be done with it
16:33:36 <inc0> also another thing about docs
16:33:47 <inc0> I'd really encourage people to use bootstrap-servers more
16:34:15 <SamYaple> idk about that
16:34:15 <sayantan_> I agree. It is much easier. Have added that in the new patch set I have been working on
16:34:46 <inc0> well it boils down installation of kolla to
16:34:51 <egonzalez90> +1
16:34:54 <inc0> pip install kolla-ansible kolla ansible
16:35:05 <inc0> configure globals.yml and build.conf
16:35:26 <inc0> kolla build -> kolla-ansible bootstrap-servers -> kolla-ansible deploy
16:35:41 <pbourke> thats the dream
16:36:04 <SamYaple> sure. should be ok for the docs. i just dont want the option bootstrap-servers role to become a requirement. otherwise kolla-ansible goes in a really different "touch host" direction
16:36:15 <inc0> SamYaple, requirement no
16:36:19 <inc0> it stays the same as now
16:36:22 <berendt> SamYaple:
16:36:23 <SamYaple> fair enough
16:36:25 <berendt> +1
16:36:35 <inc0> just to put more focus on it in docs
16:36:45 <sayantan_> +1
16:36:46 <inc0> as it's really convenient
16:36:50 <pbourke> if we can maintain stable images on dockerhub the build step goes away too
16:37:02 <inc0> thats the dream
16:37:05 <pbourke> ha
16:37:33 <inc0> ok I think we can move on
16:37:43 <portdirect> inc0: can we talk about that (docker hub images in a bit)
16:37:46 <inc0> sayantan_, I'll talk to you later today about what exactly pbr issue was
16:38:02 <inc0> portdirect, we should ahve some time in open discussion
16:38:04 <inc0> or next meeting
16:38:06 <inc0> this is important
16:38:13 <sayantan_> sounds good :
16:38:32 <inc0> ok next topic is about PTG but sdake added it and went out and I really wanted to discuss ptg closer to actual ptg;)
16:38:41 <inc0> so
16:38:44 <inc0> #topic kolla-ansible dependency. ansible version? and third party packages.
16:38:52 <inc0> Jeffrey4l, floor is yours
16:38:57 <berendt> good news, i got accepted for the travel support program for the ptg
16:39:00 <Jeffrey4l> thanks.
16:39:09 <inc0> yay Christian!
16:39:16 <Jeffrey4l> two issue:
16:39:31 <Jeffrey4l> should be bump ansible y stream now?
16:39:47 <Jeffrey4l> because ansible 2.2 has a big change then ansible 2.0
16:40:11 <inc0> hmm, how big for us? can we reasonably tackle it in Ocata?
16:40:21 <Jeffrey4l> for example ansible 2.2 will raise some warning and ansible 2.0 not.
16:40:49 <pbourke> where do you propose bumping this
16:41:15 <inc0> well if it's non-breaking warning, I'd say we can bump and post bug
16:41:25 <Jeffrey4l> the reason is ansible 2.2 and ansible 2.0 is  not compatible in some way.
16:42:00 <Jeffrey4l> we got lots of warning when using ansible 2.2
16:42:09 <duonghq> we have some bug report about this issue
16:42:31 <duonghq> the warning will become error around 2.4
16:42:31 <Jeffrey4l> and can not use some new feature ( like block ) in ansible 2.2
16:42:44 <Jeffrey4l> that's the issue. it is not big, but we need handle.
16:42:45 <Jeffrey4l> duonghq, yep.
16:43:05 <inc0> so that's what I'd do: bump today, post bugs for any error
16:43:11 <inc0> (warning that is)
16:43:14 <egonzalez90> if we move to ansible 2.2 we cannot use prior versions
16:43:19 <inc0> ofc make sure everything works even with warnings
16:43:30 <Jeffrey4l> egonzalez90, yep.
16:43:40 <egonzalez90> some module options in ansible2.2 does not work
16:43:41 <Jeffrey4l> now kolla-ansible require ansible > 2.
16:43:44 <kfox1111> o/
16:43:56 <Jeffrey4l> egonzalez90, details?
16:45:00 <Jeffrey4l> another question is: whether and how to determine the requirments.txt in kolla-ansible.  this is raised by https://review.openstack.org/412101
16:45:06 <Jeffrey4l> this patch ^^
16:45:06 <egonzalez90> #link https://review.openstack.org/#/c/402691/
16:45:27 <Jeffrey4l> i added oslo.config into kolla-ansible requirements.txt.
16:45:40 <egonzalez90> this module does not work with ansible 2.1, they just removed it withour warning
16:45:57 <Jeffrey4l> ( even though oslo.config is already in req.txt file, not it is historical issue )
16:46:33 <Jeffrey4l> should we or can we add more requirements ( especially python packages ) in kolla-ansible projects?
16:46:49 <Jeffrey4l> SamYaple, need your opinion ;)
16:46:53 <inc0> Jeffrey4l, can - sure
16:47:03 <inc0> should - well, if we need them, then yes;)
16:47:35 <Jeffrey4l> egonzalez90, yep that options will be removed in ansible 2.4 ( iirc )
16:47:41 <SamYaple> i just want to make people aware that modules are different than action_plugins
16:48:01 <SamYaple> action_plugin runs on deploy host (we can probably reasonably require requirements.txt)
16:48:07 <SamYaple> modules run on the target host
16:48:18 <SamYaple> oslo.config can't be a import on a target host
16:48:28 <SamYaple> thats not the case here, but i dont want confusion down the road
16:48:35 <Jeffrey4l> SamYaple, merge_config run in deployment node. not target node.
16:48:50 <SamYaple> Jeffrey4l: i know. but everyone else should be aware of that too
16:48:50 <inc0> Jeffrey4l, right
16:49:11 <SamYaple> this isnt open the flood gates and allow external libs in modules
16:49:12 <inc0> so if somethign is required on deploy node - goes to req.txt
16:49:24 <SamYaple> this is 'require thigns on deploy host'
16:49:25 <Jeffrey4l> SamYaple, yep. if we add some requirement which run on target host, we should re-consider that and better not to that.
16:49:26 <inc0> if something is required on target node - goes to docs and bootstap servers
16:49:35 <SamYaple> inc0: nope
16:49:36 <SamYaple> disagree
16:49:44 <SamYaple> that makes bootstrap servers required
16:49:50 <Jeffrey4l> inc0, kolla do not touch host.
16:49:51 <SamYaple> and it adds packages to the host, something we dont do
16:49:52 <inc0> docs and bootstrap servers
16:49:56 <SamYaple> nope
16:50:01 <inc0> that's what we do now
16:50:05 <SamYaple> thats a fundemental shift in philosphy
16:50:10 <Jeffrey4l> so if you add some requirement in target host, better use kolla_toolbox ;)
16:50:15 <inc0> you can always do it manually
16:50:21 <SamYaple> i dont think you understand
16:50:28 <inc0> SamYaple, it was shifted when you were away
16:50:36 <SamYaple> it was not...
16:50:37 <inc0> deploy play does not touch host
16:50:42 <SamYaple> not this
16:50:49 <inc0> bootstap-servers mangles it as it will
16:51:01 <SamYaple> bootstrap servers is optional
16:51:04 <SamYaple> we just discussed this inc0
16:51:08 <inc0> sure
16:51:15 <inc0> we add it to DOCS too
16:51:16 <SamYaple> the only requirements on the host were docker and docker-py
16:51:23 <inc0> so people can install package manually on target node
16:51:27 <inc0> yeah
16:51:31 <inc0> what I'm saying is
16:51:38 <inc0> if we EVER have more reqs on target hosts
16:51:39 <SamYaple> anythign past docker and docker-py certianly hasnt been discussed inc0
16:51:42 <inc0> that's how we handle it
16:51:44 <SamYaple> there was no shift
16:51:59 <inc0> point being, it's much more heavyweight than having deploy node req
16:52:10 <inc0> so let's stick to deploy node req as much as possible
16:52:16 <SamYaple> period
16:52:21 <SamYaple> unless the discussion is opened up
16:52:25 <SamYaple> not as much as possible
16:52:26 <inc0> no, it's not
16:52:44 <inc0> anyway, nothing changes now
16:52:45 <SamYaple> youre making decsions here that no one has agreed to inc0
16:53:03 <inc0> I'm not making any decisions!
16:53:05 <inc0> anyway
16:53:13 <inc0> let's go back to topic
16:53:24 <Jeffrey4l> yep.
16:53:40 <inc0> Jeffrey4l, anything left to say?
16:53:42 <SamYaple> point being, this code runs on deploy host where we can reasonable require oslo_config
16:53:46 <Jeffrey4l> if we need add some other patch in deploy host, re-consider use kolla_toolbox.
16:53:57 <pbourke> Jeffrey4l: +1
16:53:58 <SamYaple> agreed Jeffrey4l
16:54:04 <inc0> yup
16:54:04 <SamYaple> thats what its there for
16:54:22 <Jeffrey4l> if it really can not work, it is acceptable and worth to talk to add requirements in target node.
16:54:30 <Jeffrey4l> that what i want to say. ;)
16:54:40 <inc0> no argument here
16:54:48 <SamYaple> a discussion would be needed to change direction, agreed
16:54:49 <Jeffrey4l> ok. please move on
16:55:07 <inc0> #topic open discussion
16:55:17 <SamYaple> need to talk about the statid uid/gid for a moment
16:55:17 <inc0> portdirect, registry?
16:55:27 <portdirect> can we push images to the hub a little bit more often?
16:55:27 <inc0> SamYaple, portdirect was first:)
16:55:43 <inc0> well, we don't have master build images at all
16:55:55 <inc0> today we push every stable release
16:55:59 <portdirect> as we (kolla-k8s) are needing to work round bugs in release images: https://review.openstack.org/#/c/416366/
16:56:17 <Jeffrey4l> we should not push master tag. it is easily to break.
16:56:40 <portdirect> this is not master - but 3.0.2 i think
16:56:47 <inc0> we technically can create new tag, like develop
16:56:50 <inc0> and push as needed
16:56:52 <kfox1111> 3.0.2 or at least a freshened 3.0.1
16:56:53 <Jeffrey4l> we have this now http://tarballs.openstack.org/kolla/images/
16:56:57 <Jeffrey4l> master registry images.
16:57:09 <kfox1111> really its only one set of packages, kolla-toolbox that has a stale package.
16:57:12 <Jeffrey4l> it is still WIP. but almost done. and it just works.
16:57:23 <berendt> Jeffrey4l: cool
16:57:23 <sbezverk> inc0: would be great to have a separate tag for master
16:57:25 <inc0> that for gates
16:57:27 <Jeffrey4l> 3.0.2 will be release soon. ;)
16:57:45 <inc0> yeah, once 3.0.2 tags, we'll build and push it
16:57:50 <sbezverk> in this case we can experiment with close to master state images
16:58:00 <inc0> we were discussing nightly builds and pushes too
16:58:01 <kfox1111> Jeffrey4l: whats "soon"? :)
16:58:04 <Jeffrey4l> inc0, i am thinking to push tag registry tarball during release.
16:58:13 <inc0> if someone would like to donate server we can crack up cronjob for it;)
16:58:15 <kfox1111> like, before next wednesday?
16:58:16 <Jeffrey4l> kfox1111, 3.0.2 will be release soon.
16:58:20 <Jeffrey4l> ( time ... )
16:58:25 <portdirect> inc0: I can do that for this dev cycle
16:58:44 <kfox1111> like, can we get rid of the workaround before we cut the kolla-kubernetes release?
16:59:03 <inc0> kfox1111, Jeffrey4l I think we can say this week right?
16:59:06 <Jeffrey4l> btw, when kolla-k8s will be release next tag ( 0.4 )
16:59:10 <inc0> for 3.0.2
16:59:12 <Jeffrey4l> inc0, yep
16:59:33 <kfox1111> ok. cool. then we'll just wait for the end of the week, then pull the workaround out.
16:59:39 <Jeffrey4l> the scheduler date we talked last is Jan 4 kfox1111
16:59:48 <kfox1111> Jeffrey4l: slipped one week.
16:59:52 <Jeffrey4l> roger.
17:00:18 <berendt> timeout...
17:00:36 <inc0> yes, thank you all
17:00:43 <inc0> #endmeeting kolla