16:01:24 <Jeffrey4l> #startmeeting kolla
16:01:24 <openstack> Meeting started Wed Dec  7 16:01:24 2016 UTC and is due to finish in 60 minutes.  The chair is Jeffrey4l. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:25 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:28 <openstack> The meeting name has been set to 'kolla'
16:01:29 <zhubingbing> o/
16:01:33 <wirehead_> meow
16:01:37 <berendt> o/
16:01:38 <Jeffrey4l> #topic rollcall
16:01:39 <zhubingbing> o/
16:01:43 <duonghq> o/
16:01:48 <berendt> o/
16:01:52 <Jeffrey4l> \o/
16:01:53 <portdirect> whoo...
16:01:55 <portdirect> ..t
16:01:56 <jascott1> o/
16:02:08 <duonghq> we have many eager kollish here
16:02:22 <Jeffrey4l> lol
16:02:23 <jascott1> :D
16:02:40 <sdake> o/
16:02:41 <qwang> o/
16:02:52 <sdake> kulligans ;)
16:03:12 <Jeffrey4l> ok. let's start. there a lots of topic today. :)
16:03:24 <Jeffrey4l> #topic announcement
16:03:27 <sdake> lots o people too
16:03:28 <sdake> :)
16:03:38 <Jeffrey4l> 1. welcome zhubingbing join the kolla team :)
16:03:45 <Jeffrey4l> nice work zhubingbing
16:04:00 <sdake> grats zhubingbing !!
16:04:01 <zhubingbing> thanks all
16:04:06 <jascott1> welcome!
16:04:09 <qwang> welcome :)
16:04:14 <sdake> nice job on the reviews as well as code sa well as irc particiapation :)
16:04:17 <sbezverk_> o/
16:04:21 <zhubingbing> I will do my best to contribute kolla
16:04:22 <Jeffrey4l> 2. milestone 2 will be tag around Dec 15, and i do not want to break the rule.
16:04:29 <sdake> zhubingbing your already doing that :)
16:04:31 <prameswar> o/
16:04:47 <sdake> Jeffrey4l its more like a deadline not a rule :)
16:04:53 <Jeffrey4l> so next 7 days will be busy on the review and implement.
16:05:01 <zhubingbing> ;)
16:05:12 <Jeffrey4l> sdake, yep. i mean the release model :)
16:05:34 <sdake> Jeffrey4l sweet ;) - not everyone understands that here - so deadline works ;)
16:05:35 <Jeffrey4l> we have lots of patch in queue now. and many of them are bp.
16:05:36 <duonghq> hi sean-k-mooney
16:05:53 <sean-k-mooney> hi
16:05:55 <Jeffrey4l> please update yours .
16:06:13 <Jeffrey4l> and reviews the patches.
16:06:36 <Jeffrey4l> and now we have three repo. kolla kolla-ansible kolla-k8s.
16:07:05 <Jeffrey4l> should make tag at the same time, imo.
16:07:14 <Jeffrey4l> ok. that's all.
16:07:23 <Jeffrey4l> anything else from the community?
16:07:57 <Jeffrey4l> let's move on.
16:08:05 <Jeffrey4l> #topic ask.openstack.org usage
16:08:12 <Jeffrey4l> #link https://ask.openstack.org/en/questions/scope:all/sort:activity-desc/page:1/query:kolla/
16:08:26 <Jeffrey4l> i think you can show us about this? sdake
16:08:27 <srwilkers_> o/
16:08:37 <sdake> Jeffrey4l i am workingo n  getting my child to school
16:08:40 <sdake> he is not cooperating
16:08:46 <sdake> so i will be a partial participate
16:08:49 <berendt> good idea to track this and to work on it
16:08:53 <Jeffrey4l> ok. i will take this.
16:08:56 <sdake> so here is the basic idea
16:09:18 <sdake> instead of answering a million questions in our channel over and over of the same type, lets get folks to build an archive of Qs on ask.openstack.org
16:09:36 <sdake> and then lets respond there once rather then a million times :)
16:09:53 <portdirect> +1
16:09:54 <sdake> ok thats what I got there jeffrey bbiaf :)
16:10:03 <egonzalez90> good point +1
16:10:07 <Jeffrey4l> yep. and we can also move some Q&A to the doc part.
16:10:11 <duonghq> +1
16:10:18 <srwilkers_> yeah, i like that idea
16:10:19 <prameswar> +1
16:10:47 <Jeffrey4l> the we do not need repeat the answer again and again.
16:10:52 <Jeffrey4l> it can also improve our doc.
16:11:11 <Jeffrey4l> so please take some time in the ask.openstack.org site.
16:11:29 <portdirect> yeah - we need to get on it - just looking though theres a depressing number of "lost" queries - I'll try an monitor it on the kolla-k8s side
16:11:31 <egonzalez90> yes, also ask.openstack.org have a good index possition on searches
16:11:41 <Jeffrey4l> most of them are simple. it will not take lots of time.
16:12:09 <Jeffrey4l> next.
16:12:24 <Jeffrey4l> #topic balancing core team karma
16:12:33 <Jeffrey4l> #link https://launchpad.net/kolla-ansible/+topcontributors
16:12:38 <Jeffrey4l> please open the link
16:13:10 <rhallisey> yo
16:13:16 <sdake> sup rhr
16:13:18 <srwilkers_> hey rhallisey :)
16:13:18 <sdake> sup rhallisey
16:13:19 <duonghq> hey rhallisey
16:13:29 <Jeffrey4l> in launchpad , karma number show the activity of one person
16:13:52 <Jeffrey4l> you can get only fewer people are busying on it.
16:14:17 <berendt> activity on launchpad itself, means bug tracking for us
16:14:44 <Jeffrey4l> yep. please take some time on bug management.
16:14:50 <sdake> not just bug management
16:14:55 <sdake> also blueprint mangaement
16:14:56 <Jeffrey4l> it can not be done by one or two person.
16:14:58 <sdake> I have a quick question
16:15:12 <sdake> do people not know how to manage launchpad blueprint status?
16:15:21 <sdake> or another way to put it to the core team is who does?
16:15:25 <sdake> I do
16:15:40 <sdake> Jeffrey4l can you call for a rollcall on do/don't?
16:15:55 <Jeffrey4l> rollcalll? or vote?
16:15:57 <sdake> its ok if you don't btw :)
16:16:12 <sdake> just a rollcall of people who do or dont know how to approve blueprints
16:16:32 <Jeffrey4l> need a topic? hrm?
16:16:32 <rhallisey> if only kollabot were here
16:16:49 <sdake> i think we need to determine if this inbalance problem is solved by a lack of training or a lack of desire
16:17:02 <srwilkers_> kollabot, the hero we need
16:17:03 <portdirect> I'm not that familiar with launchpad - srwilkers has given me a few pointers but I'm aware this a area I need to get up to speed on
16:17:15 <Jeffrey4l> #link https://wiki.openstack.org/wiki/BugTriage
16:17:25 <Jeffrey4l> here is some doc from wiki about how to handle bug.
16:18:14 <Jeffrey4l> i think most of guys can take some triage work, but may haven't idea how sdake
16:18:35 <sdake> if people aren't interested in doing bug triage I get that
16:18:40 <sdake> if people dont know how, we can fix that
16:18:57 <duonghq> we need to define triage too, the meaning we used from last cycle is not the same as launchpad definition or openstack one
16:18:57 <sdake> so can we get a statement from each core as to their position?
16:19:29 <Jeffrey4l> sdake, good idea.
16:19:58 <berendt> i know how to do it, but do not do it at the moment, i try to spend some time on it
16:20:15 <sdake> I am not interested in bug triage for any deliverlable but kolla-kubernetes but know how to do bug triage
16:20:20 <duonghq> bug triaging is highly time and resource consuming
16:20:22 <Jeffrey4l> duonghq, i think openstack one is OK. i do not want be special with other openstack projects.
16:20:29 <sdake> thats my statement ^
16:20:47 <duonghq> Jeffrey4l, maybe last cycle we used somewhat different, or I misunderstood something
16:21:00 <Jeffrey4l> i will take the triage work for kolla and kolla-ansible ;)
16:21:11 <sdake> Jeffrey4l needs to be a team efforrt
16:21:17 <sdake> Jeffrey4l imo we cant do it alone :)
16:21:21 <Jeffrey4l> ^^ that's mean statement ;)
16:21:23 <wirehead_> I know how to do triage, it wasn't really a critical effort for kolla-kubernetes, but I should start having time to at least pitch in there.
16:21:24 <duonghq> from last cycle, we marked bugs as triaged if we are working on it and can deliver before milestone
16:21:26 <sdake> oh roger :)
16:21:28 <Jeffrey4l> mean/my*
16:21:37 <wirehead_> (But that doesn't necessarily help kolla-ansible :) )
16:21:53 <Jeffrey4l> duonghq, we can re-define this. may be need ml ;)
16:22:00 <duonghq> Jeffrey4l, +1
16:22:18 <sdake> we got 4 statements, thats good :)
16:22:29 <sdake> need m0ar
16:22:31 <srwilkers_> ive been looking at kolla-ansible and kolla-kubernetes both recently, although more on the kubernetes side. im not really in a position to help triage, but can certainly help as much as im able to in my current state
16:22:35 <duonghq> or just roll-call vote for which definition is used?
16:22:44 <sdake> duonghq what we got going on now is fine :)
16:23:00 <Jeffrey4l> duonghq, lets talk the details in the mail.
16:23:01 <sdake> i think we are up to 6 statemenets
16:23:02 <Jeffrey4l> ;)
16:23:11 <egonzalez90> Actually I'm more involved in bug triage than ever
16:23:12 <sdake> Jeffrey4l can we use meeting time to gather statements
16:23:16 <Jeffrey4l> sdake, not all cores are here ;)
16:23:27 <sdake> cool there are a buncch here that hane't made a statement yet
16:23:29 <rhallisey> me - it's complicated XD
16:23:36 <duonghq> I can help in triaging, especially in kolla
16:23:39 <sdake> rhallisey right - you always get a pass in our hearts :)
16:24:02 <rhallisey> ya someone try and get to my karma :)
16:24:04 <rhallisey> 30k ftw
16:24:13 <Jeffrey4l> i am say the things need be re-defined
16:24:20 <duonghq> kolla and kolla-k8s (if needed), the kolla-ansible  is lower priority in triaging atm for me
16:24:29 <sdake> Jeffrey4l - ml seems good to collect the rest of the statements from the core reviewer team
16:24:31 <duonghq> rhallisey, congrat
16:24:33 <Jeffrey4l> duonghq, cool.
16:25:04 <sdake> Jeffrey4l can you send out the list of the statements made thus far to the ml and gather the rest on the mail you send to the ml?
16:25:22 <Jeffrey4l> other guys who are not core member can work on launchpad, too.
16:25:43 <Jeffrey4l> if you want, you can apply the permission from the core member.
16:25:46 <Jeffrey4l> sdake, np.
16:25:55 <sdake> ya - we add people to drivers team pretty freely
16:26:06 <berendt> to we already have a gerrit dashboard for gerrit-dash-creator?
16:26:16 <berendt> (this is not related to the bug topic..)
16:26:16 <Jeffrey4l> #action Jeffrey4l send out and collect more statements about launchpad.
16:26:30 <sdake> berendt i've been trying to get reviewday going, however infra hasn't approved my patches
16:26:33 <duonghq> driver team can do bug and spec management :)
16:26:59 <sdake> berendt - if you know how to get a dashboard rolling - that might be helpful :)
16:27:26 <Jeffrey4l> ( do not know what are u talking ;) )
16:27:34 <Jeffrey4l> anyway, next ;)
16:27:43 <Jeffrey4l> #topic kolla-ansible reconfiguration optimize
16:27:57 <Jeffrey4l> kolla-ansible's reconfigure is very slow now.
16:28:05 <Jeffrey4l> some operator complained this.
16:28:33 <Jeffrey4l> he takes 20-30 mins to deploy. but takes more than 1hours to make a small change.
16:28:58 <duonghq> ya, we lack fully CM
16:29:12 <Jeffrey4l> even though it works. But it is critical for operator experince
16:29:13 <zhubingbing> +1
16:29:27 <Jeffrey4l> i made some improve,
16:29:33 <Jeffrey4l> #link https://review.openstack.org/406978
16:29:49 <Jeffrey4l> it is kinda of big change, but make the logical simple.
16:30:13 <Jeffrey4l> this is the initial ps. so need more eyes on it
16:30:18 <Jeffrey4l> #link https://blueprints.launchpad.net/kolla-ansible/+spec/better-reconfigure
16:30:22 <Jeffrey4l> here is the bp link.
16:31:02 <Jeffrey4l> optimal, deploy and reconfigre will be the some. and reconfigure will be removed in the feature.
16:31:31 <duonghq> Jeffrey4l, what is meaning of "the same"?
16:32:00 <Jeffrey4l> deploy works the same with reconfigure.
16:32:21 <Jeffrey4l> i do not see the kinda reconfigure action in other deployment tool.
16:32:28 <rhallisey> Jeffrey4l, is the reason it's slow because it has to run through every task to find the one that needs to be changed?
16:32:32 <duonghq> ok, I need looking more indepth in your ps
16:32:45 <rhallisey> Jeffrey4l, you could merge them but keep cli the same
16:32:47 <Jeffrey4l> normally, what is needed is: prepare configure, start the service.
16:32:50 <duonghq> but I still think we should have some kind of "real" CM
16:32:59 <Jeffrey4l> rhallisey, i didn't change the cli now.
16:33:44 <Jeffrey4l> rhallisey, the reason is: we use run set_config.py --check to detect whether the configuration file is change.
16:33:48 <Jeffrey4l> it is very slow.
16:34:12 <rhallisey> ah we're reading everything
16:34:13 <Jeffrey4l> because ansible already now which file is change, we do not need run set_config.py script anymore.
16:34:24 <Jeffrey4l> ya. it is bad ;)
16:34:37 <Jeffrey4l> could u explain real CM?
16:34:39 <Jeffrey4l> duonghq,
16:35:09 <Jeffrey4l> configuration management?
16:35:24 <duonghq> I just thinking some kind of CM  which can tell us exactly which node and which service on node is updated
16:35:32 <duonghq> yup, configuration management
16:35:34 <duonghq> just idea
16:35:47 <jascott1> is reconfigure in a gate anywhere? is that doable? seems like a great thing to have a watch on
16:35:51 <Jeffrey4l> duonghq, my propose works as your idea.
16:36:04 <duonghq> but need try your approach, if it works, it much easier then whole CM
16:36:12 <Jeffrey4l> jascott1, gate testing reconfigure/upgrade ( even though nothing is change )
16:36:24 <kfox1111> hi.
16:36:28 <Jeffrey4l> ok. move on
16:36:30 <duonghq> Jeffrey4l, got your idea, but still need some hand ons :)
16:36:41 <Jeffrey4l> we have three topics.
16:36:57 <Jeffrey4l> #topic consistent uid and gid
16:37:03 <Jeffrey4l> #link https://review.openstack.org/405647
16:37:17 <Jeffrey4l> this is another issue we found at the end of last cycle.
16:37:27 <Jeffrey4l> hope we can fix it in the cycle.
16:37:46 <kfox1111> +1 for fixing.
16:37:47 <berendt> i have to i have to leave, I will read the backlog later.
16:37:48 <Jeffrey4l> this link is a bp spec, we need catch up how we should do.
16:37:55 <kfox1111> should be fixed for kolla-kubernetes too,
16:37:58 <duonghq> see ya berendt
16:38:08 <kfox1111> so ansible specific solutions are not as good.
16:38:12 <Jeffrey4l> the issue is uid and gid may be changed in docker image.
16:38:27 <Jeffrey4l> because the uid and gid is take by kinda random.
16:38:41 <Jeffrey4l> need fix it and keep it won't break our upgrade.
16:38:45 <kfox1111> then the container api shoudl provide a way to change them.
16:39:01 <kfox1111> as its consumed by both kolla-ansible and kolla-kubernetes.
16:39:31 <Jeffrey4l> kfox1111, change it is danger. we should keep chown the folder owner during upgrade.
16:39:37 <kfox1111> something config setting that kolla_start reads perhaps.
16:39:43 <Jeffrey4l> so i prefer to fix it all the time.
16:40:09 <kfox1111> and make it fixed all the time int he continer?
16:40:14 <Jeffrey4l> kfox1111, we have a workaround , which fix by kolla_start. but it is not optimal.
16:40:20 <portdirect> should we should base the uid/gid on another project (eg RDO) that has already defined a set of values for openstack services?
16:40:23 <Jeffrey4l> kfox1111, yep. i hope so.
16:40:35 <kfox1111> fixed uid/gid in the container, then one time migration job works for me.
16:40:48 <Jeffrey4l> portdirect, uid/gid is not defined in rpm package.
16:40:59 <Jeffrey4l> portdirect, it is choose during run useradd command.
16:41:12 <Jeffrey4l> rpm package  using such command. and it do not fix the uid
16:41:17 <kfox1111> yeah. you have to prepopulate the users/gropus before installing the rpms.
16:41:21 <kfox1111> or the uid/gid can float.
16:41:26 <Jeffrey4l> kfox1111, yep.
16:41:43 <Jeffrey4l> then keep eye on it. it is a critical issue, imo.
16:41:55 <Jeffrey4l> move on.
16:42:04 <portdirect> oh - nevermind then :0
16:42:11 <Jeffrey4l> #topic quick start guide
16:42:20 <Jeffrey4l> can u talk this duonghq ?
16:43:14 <Jeffrey4l> QSG is bad right now.
16:43:15 <duonghq> thank Jeffrey4l
16:43:26 <Jeffrey4l> please ;)
16:43:40 <duonghq> currently, we bundle many things on QSG
16:44:00 <duonghq> as sdake, Jeffrey4l and I (a litte) discuss someday ago
16:44:10 <duonghq> we should make the QSG as simple as posible,
16:44:25 <duonghq> with Kolla from pip, image from docker hub
16:44:28 <duonghq> etc
16:45:01 <duonghq> and in the mean time, every patch on QSG should be defered or go in its own file (which mean its page)
16:45:11 <duonghq> for the QSG writing method
16:45:15 <Jeffrey4l> we can move the difficult think in to another part. like FAQ. like how to create a docker registry and configure the --insecury-registry paramaeter.
16:45:55 <duonghq> We can setup fresh VM and do the step that bring up an AIO configuration OpenStack
16:46:02 <duonghq> keep it is minimal
16:46:12 <kfox1111> duonghq: I like the idea, with the exception that it needs a caviot that the docker hub containers are likely insecure, so can't be used for production.
16:46:16 <duonghq> any comment on the approach?
16:46:30 <kfox1111> but, I think we should be working on making a process to keep them up to date, so that they can be.
16:46:43 <duonghq> kfox1111, we can leave a comment on the issue, due to we are talking about QSG
16:46:48 <duonghq> kfox1111, +1
16:47:14 <duonghq> we need 1-2 people make statement about keep this up to date
16:47:30 <Jeffrey4l> ok. we do not have much time. so let talk this in openstack-kolla later.
16:47:38 <kfox1111> have a link to the review?
16:47:41 <Jeffrey4l> we have a last one topic.
16:47:59 <Jeffrey4l> ryan have a nice work https://review.openstack.org/343224
16:48:17 <kfox1111> thx.
16:48:18 <Jeffrey4l> rhallisey, ^^
16:48:32 <Jeffrey4l> #link https://review.openstack.org/343224
16:48:36 <Jeffrey4l> ok move on
16:48:39 <rhallisey> ya I took at shot at it a while back
16:48:55 <Jeffrey4l> thanks.
16:48:56 <Jeffrey4l> #topic kolla-kubernetes helm versioning
16:49:11 <Jeffrey4l> whose topic?
16:49:14 <duonghq> me
16:49:21 <Jeffrey4l> ya. please duonghq
16:49:58 <duonghq> kfox1111, sbezverk_ I remember that you guys talk about this last one or two week,
16:50:02 <duonghq> do we have any update?
16:50:36 <kfox1111> haven't discussed it to far yet.
16:50:40 <sbezverk_> duonghq: I do not, I think the priority atm is to get microservices
16:50:48 <kfox1111> I can see two ways to version helm packages though.
16:51:11 <Jeffrey4l> about the helm-mircroservice
16:51:13 <kfox1111> one is to version the templates only. include the main container version as a var.
16:51:14 <Jeffrey4l> #link https://blueprints.launchpad.net/kolla-kubernetes/+spec/helm-microservices
16:51:14 <duonghq> Let me recap the issue: helm need version bump to know whether it need to upgrade the release of package,
16:51:33 <kfox1111> the second is to consider the container versions in the package version as well.
16:51:33 <Jeffrey4l> as we will make tag around dec 15.
16:51:55 <kfox1111> this would let us do a helm upgrade neutron-server
16:51:57 <Jeffrey4l> this bp should be done before that day.
16:51:59 <kfox1111> without having to mess with arguments.
16:52:09 <kfox1111> Jeffrey4l: thats very soon. :/
16:52:13 <kfox1111> Jeffrey4l: possibly too soon.
16:52:22 <portdirect> I think it makes most sense to take the approack of linking version with conatiner version - though the former is nicer from a versioning pov - the 2nd fits better with the standard k8s workflows
16:52:26 <Jeffrey4l> kfox1111, we have no choice ;(
16:52:32 <duonghq> kfox1111, the bp should be done on o-2, not o-3 :(
16:52:46 <Jeffrey4l> sdake, hope this pb can be done before that day.
16:52:49 <kfox1111> Jeffrey4l: this is a bootstrapping project. :/
16:52:54 <kfox1111> there's only so much labor.
16:52:59 <sdake> Jeffrey4l sorry what?
16:53:10 <Jeffrey4l> sdake, helm-microservices bp deadline
16:53:28 <sdake> ok - kid ill - dealing with that
16:53:34 <sdake> you ahve my attention now
16:53:37 <sdake> can i get a quick recap
16:54:04 <Jeffrey4l> kfox1111, it is a key bp. it will ensure use release 1.0 kolla-k8s
16:54:06 <sdake> kfox1111 - so 7 days is bsically what we got
16:54:16 <portdirect> Jeffrey4l: we are working as fast as we can :) I think we will meet the deadline but as kfox1111 points out this is a very young project
16:54:27 <Jeffrey4l> kfox1111, then it is not a bootstrap project any more ;)
16:54:29 <sdake> kfox1111 if that is impossible need to know
16:54:30 <sdake> kfox1111 we will have a hard time justifyign a 1.0.0.0b2 tag
16:54:45 <kfox1111> Jeffrey4l: sdake we're going as fast as we can, but I'm just saying, I don't know if we can realisticly have everything converted to helm microservices by that deadline.
16:54:46 <sdake> which means we will have an impossible time releasing 1.0.0 in ocata
16:54:53 <Jeffrey4l> almost all the work items is in WIP progress.
16:55:05 <sdake> kfox1111 ok - well lets play it by ear, more people are coming ever yday
16:55:11 <kfox1111> sdake: we can release a 1.0.0. just not on any predefined schedule. :/
16:55:26 <sdake> if we don't tag 1.0.0b2, we wont be able to tag 1.0.0 iiuc ffrom the release team
16:55:39 <kfox1111> sdake: we're release independent.
16:55:47 <Jeffrey4l> kfox1111, we maybe can delay fews days, but it is not a good idea.
16:55:48 <kfox1111> we should n't be that tightly cuppled.
16:56:09 <sdake> ya - expectation is the tagging happens on teh schedule
16:56:27 <kfox1111> we could have made it without going to helm, I think. but we're redoing a lot of fundimental plumbing.
16:56:29 <sdake> i will double check with the release team re release independent
16:56:29 <sdake> so add an action for me jeffrey4l
16:56:38 <kfox1111> its worth doing for sure.
16:56:47 <Jeffrey4l> just wanna say, if we do not release 1.0 kolla-k8s this cycle. we will release it 10 months later.
16:56:47 <kfox1111> I'd rather get it right then cut a 1.0.0 that is unusable though.
16:56:57 <Jeffrey4l> #action sdake check with the release team re release independent
16:57:02 <sdake> kfox1111 agree we aren't cutting an unsuable release
16:57:05 <kfox1111> Jeffrey4l: why so arbitrary?
16:57:23 <sdake> its not arbitrary - its the ocata schedule
16:57:23 <kfox1111> we should be able to cut 1.0.0 whenever ready, then start with a normal release cycle after that.
16:57:35 <sdake> kfox1111 let me take these questoins to the release team
16:57:36 <Jeffrey4l> no arbitraty.
16:57:37 <sdake> and find out for sure
16:57:45 <Jeffrey4l> but we hope we can release 1.0 this cycle.
16:57:46 <kfox1111> sdake: please do.
16:57:48 <sdake> there are a bunch of rules around this stuff that you may be unaware of
16:57:50 <Jeffrey4l> just a expectation.
16:57:52 <sdake> i am vaguely aware of them
16:57:53 <kfox1111> +1 to a 1.0 this cycle.
16:58:04 <kfox1111> but +1 to a stable 1.0 over abritrary dates.
16:58:17 <kfox1111> then date based after 1.0.
16:58:18 <sdake> its not arbitrary date, its the release schedule set in the openstack schedule
16:58:20 <duonghq> o-2 to o-3 is such a long time? :(
16:58:24 <Jeffrey4l> ( time is almost up  2 mins )
16:58:29 <sdake> Jeffrey4l can you link
16:58:42 <kfox1111> sdake: we're release independent.
16:58:43 <Jeffrey4l> #link https://releases.openstack.org/ocata/schedule.html
16:58:44 <sdake> kfox1111 - i will ask release team today what the story is
16:58:49 <kfox1111> date shuld not matter until we're part of the openstack schedule.
16:59:00 <kfox1111> otherwise, "release independent" is meaningless.
16:59:06 <sdake> kfox1111 i get that, guidance i've been given is that even release independent are expected to cut milestones on the schedule from dham1
16:59:08 <sdake> dhellmann
16:59:22 <kfox1111> we can cut milestones for sure.
16:59:22 <sdake> kfox1111 i'm not sur eif i imagined that or misinterpreted it or what
16:59:26 <sdake> i will find out
16:59:28 <kfox1111> but not a release.
16:59:36 <sdake> we aren't releaisng 1.0.0 on 15th
16:59:43 <kfox1111> it won't be feature complete until its actually feature complate. :/
16:59:45 <sdake> 1.0.0.0b2 is a milestone - o2
16:59:52 <Jeffrey4l> sdake, yes
16:59:59 <kfox1111> I'm oko with beta's. just not rc's.
17:00:00 <Jeffrey4l> Dec 12-16	R-10	Ocata-2 milestone
17:00:05 <Jeffrey4l> OK. time is up.
17:00:06 <dham1> umm you must mean from dhellman, I hope to grow up to be dhellman one day :)
17:00:06 <sdake> ok - i gotta jet - need to get get to school
17:00:13 <kfox1111> and blueprints that get closed before they are done.
17:00:13 <Jeffrey4l> thanks all guys coming.
17:00:16 <sdake> dham1 sorry about that
17:00:19 <dham1> np
17:00:31 <Jeffrey4l> let us move to openstack-kolla for further discuss.
17:00:34 <sdake> kfox1111 right -we aren't breaking the process in any way - just following it
17:00:36 <kfox1111> kk.
17:00:39 <Jeffrey4l> thanks again
17:00:48 <jascott1> thanks Jeffrey4l, all
17:00:57 <Jeffrey4l> #endmeeting kolla