16:30:45 <inc0> #startmeeting kolla
16:30:46 <openstack> Meeting started Wed Jun  1 16:30:45 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:47 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:30:50 <openstack> The meeting name has been set to 'kolla'
16:30:56 <inc0> hello everyone, show of hands please
16:31:04 <akwasnie> hi
16:31:06 <mandre> o/
16:31:08 <vhosakot> o/
16:31:09 <coolsvap> hello o/
16:31:12 <nihilifer> o/
16:31:14 <rhallisey> #topic rolll-call ?
16:31:25 <pbourke-home> o/
16:31:27 <rhallisey> hi!
16:31:37 <inc0> damn
16:31:40 <sbezverk> o/
16:31:42 <rhallisey> #topic show-hands
16:31:45 <inc0> #topic rollcall
16:31:46 <rhallisey> :)
16:31:52 <masahito> hi
16:31:56 <rhallisey> hi again!
16:32:12 <pbourke-home> hi
16:32:13 <inc0> please re-show of hands;)
16:32:21 <sbezverk> o/
16:32:21 <mandre> \o
16:32:23 <inc0> I'm new to running meetings
16:32:23 <nihilifer> \o
16:32:25 <vhosakot> \o
16:32:27 <jpeeler> hi
16:32:33 <coolsvap> hello |o/ :)
16:32:50 <inc0> #topic agenda
16:33:02 <inc0> agena in wiki is outdated unfortunately
16:33:10 <inc0> but we'll go through usual stuff
16:33:13 <wirehead_> o/
16:33:23 <inc0> #topic Announcements
16:33:32 <inc0> 1. we're past n-1
16:33:39 <inc0> https://launchpad.net/kolla/+milestone/newton-1
16:33:40 <vhosakot> _o_ \o\ /o/ _o| |o_
16:33:58 <inc0> lots and lots of stuff there
16:34:13 <sdake> actually newton 1 releases this week
16:34:29 <inc0> well its May 30 - Jun 3
16:34:35 <sbezverk> vhosakot is it somehitng like YMCA ;-) ??
16:34:41 <vhosakot> :)
16:34:44 <inc0> so yeah, we still have few days
16:34:47 <mliima> hello \o
16:34:56 <inc0> please, let everyone take a bug from n-1 list and try to close it
16:35:10 <inc0> we have tons of bugs confirmed, we need to get this managable
16:35:30 <inc0> any other announcements?
16:35:33 <sdake> yes
16:35:45 <sdake> the most important thing we can do in the next 2 days is make sure mitaka-1 is stable
16:35:59 <sdake> rather newton-1
16:36:09 <sdake> tia :)
16:36:21 <inc0> so "tons of bugs" and "take at least one";)
16:36:30 <pbourke-home> small announcement
16:36:38 <pbourke-home> oraclelinux gates are now active and green :)
16:36:42 <inc0> yay
16:36:44 <mandre> wouhou
16:36:46 <pbourke-home> thanks all for help with that
16:36:47 <vhosakot> cool!
16:37:00 <coolsvap> pbourke-home, (y)
16:37:10 <sdake> than kyou pbourke-home for doing the majority of the work :)
16:37:35 <inc0> anything else? can we move on?
16:37:46 <inc0> #topic DSL
16:38:04 <inc0> since sdake is up and about, let's have quick discussion about it please
16:38:18 <inc0> #link https://review.openstack.org/#/c/323612/5
16:38:44 <sdake> i need to leave on the hour
16:38:45 <wirehead_> I'm going to paste what I said previously: The problem with the DSL is that it requires a certain structure for the generated Dockerfiles but it will be much harder to write inscruitable Elemental.  The problem with jinja2 is that if you aren't carefull, you can cross over into being inscruitable, but you won't worry about things not representable in Elemental down the road.
16:39:07 <inc0> sdake, let's try to get as much discussed as possible
16:39:19 <vhosakot> I will review the PS
16:39:34 * rhallisey needs to also :)
16:39:36 <inc0> so my take on it - imho we can't deprecate jinja2 without at least full cycle of deprecation
16:39:36 <sdake> what i'd like is for people to review it on the patch
16:39:59 <sdake> deprecation policies don't apply to internal implementations
16:40:10 <inc0> it's not internal implementation
16:40:15 <mandre> it's external sdake
16:40:17 <inc0> it's somethign that people use and extend
16:40:33 <sdake> 'people' here being 1 or 2 people
16:40:36 <sdake> or maybe 10
16:40:44 <sdake> the longer we wait the more pain there is in their transition
16:40:46 <inc0> every operator that I heard from and runs kolla on prod either plan or did changes to dockerfiles or created their own
16:40:59 <inc0> sdake, that's not true
16:41:20 <inc0> lots of deployments use things like vendor storage or vendor networking
16:41:29 <sdake> deprecation poliices ONLY apply to external interfaces
16:41:29 <inc0> they will go through pains of writing their dockerfiles
16:41:37 <inc0> and with upgrade we'll break their env
16:41:46 <inc0> this IS external interface
16:42:08 <inc0> so we NEED a deprecation period for it
16:42:33 <inc0> and that's even if we agree that it's good idea at all, which I'm not convinced about tbh
16:42:34 <sdake> i disagree with your assertion that it is an external interface, just because people are using it as such
16:42:34 <pbourke-home> i agree on that tbh
16:42:48 <sdake> you agree on which pbourke-home
16:42:54 <wirehead_> It's an internal 'accidentally external' interface.
16:43:00 <pbourke-home> we are planning to rebase soon and if everything changes to dsl I am pretty certain it will be a blocker
16:43:01 <coolsvap> we are not providing dockerfiles we are providing containers
16:43:13 <inc0> coolsvap, that's a false
16:43:22 <inc0> we provide dockerfiles which can be built
16:43:33 <inc0> and really, practiaclity over philosophyu
16:43:34 <mandre> people use our tools to build their images
16:43:47 <inc0> if we lose deployments "because you shouldn't do this in the first place" we did lose a deployment
16:43:54 <coolsvap> https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml#n2107
16:43:54 <pbourke-home> im not totally against the dsl as you know, but the backwards compatibility/stability argument inc0 makes is ringing true with me
16:44:08 <pbourke-home> are we not a little beyond sweeping architectural changes
16:44:10 <pbourke-home> at this point
16:44:25 <inc0> and we really CANT make this argument because we didn't provide good way to meet use cases of vendor stuff in mitaka
16:44:38 <wirehead_> Being overly afraid of sweeping architectural changes has caused much pain and suffering in the OpenStack world.
16:44:59 <pbourke-home> wirehead_: I would argue the ones made cause more pain
16:45:01 <pbourke-home> for the operators
16:45:16 <inc0> wirehead_, we are operator tool
16:45:20 <inc0> and a deployment tool
16:45:31 <inc0> if we break something, it's not just kolla thats broken
16:45:36 <inc0> its literally everything
16:46:10 <sdake> the only thing that even rings viably in your argument is that operators that have cusotmized their dockerfiles
16:46:11 <coolsvap> i think the argument here should be whether we think DSL is a good way to generate Dockerfiles or not
16:46:12 <inc0> our first and foremost priority should be stability of a deployment
16:46:19 <sdake> wont be able to easily move their customizations to a new implementation of the dsl
16:46:28 <inc0> no sdake that's not only thing
16:46:40 <wirehead_> That still trebles to the pain of realizing we should have done something now a few years down the road.
16:46:43 <inc0> I just don't want to say that you're overly confident in "this is easy" part
16:46:49 <coolsvap> why it is and why it is not, what are the potential blockers
16:47:20 <sdake> ok lets table the deprecation policy now, seems like putting cart before horse
16:47:22 <inc0> let me give you an example of build.py
16:47:27 <sdake> there will be no need for deprecation if we dont do a dsl
16:47:33 <sdake> so lets move on to coolsvap 's lline of  reasoning
16:47:49 <inc0> well, if we agree on doing dsl and add deprecation policy, that means we will support both jinja2
16:47:52 <inc0> and dsl
16:47:54 <inc0> for time being
16:47:59 <inc0> and see if dsl flies
16:48:02 <vhosakot> is there an etherpad for DSL ? where do we write our views ?
16:48:12 <sdake> vhosakot in the review inc0 linked above
16:48:13 <wirehead_> vhosakot, there's a blueprint spec.
16:48:16 <inc0> vhosakot, let's use review
16:48:20 <vhosakot> ah ok cool
16:48:21 <coolsvap> vhosakot, patch 323612
16:48:37 <sdake> there will come a day
16:48:41 <sdake> if we dont do the dsl now
16:48:44 <inc0> blocker for me: maturity of code is important
16:48:56 <sdake> where we will be forced to do it because of the crushing weight of our existing implementation as we scale out the big tent
16:48:57 <inc0> we have fairly mature stuff now, needs refactoring but it's mature
16:49:05 <inc0> (it needs refactoring because it matured)
16:49:29 <sdake> history revisionism
16:49:41 <inc0> I'd call it an experience
16:49:48 <sdake> what really happened is people bolted a bunch of stuff onto builld.py to customize stuff without any concern for consistency
16:50:00 <pbourke-home> right now we have one dockerfile per image, and we will be replacing that with one yaml file per image
16:50:03 <sdake> we need to make the customization step of build.py separate from building the images
16:50:16 <sdake> pbourke-home i was thinking one yaml file per container set
16:50:18 <pbourke-home> the add on files will only be for customisation right
16:50:18 <sdake> but whatever works
16:50:30 <inc0> sdake, agree on that we need to refactor build.py
16:50:35 <sdake> pbourke-home the new dsl will be the way to generate the dsl
16:50:36 <pbourke-home> so are we better off number of file wise
16:50:37 <inc0> but that doesn't mean throwing it away
16:50:41 <wirehead_> Also, providing a superior experience for add-on Kolla functionality is probably going to make the pain of the DSL less, IMHO.
16:50:48 <wirehead_> That seems to be something not well thought out so far.
16:50:50 <sdake> there are 40 container sets
16:50:54 <sdake> there are 115 containers
16:51:00 <inc0> pbourke-home, we can achieve same thing in jinja
16:51:04 <sdake> with the method in the spec, there would be 40 yml files
16:51:13 <inc0> it's a matter of what we want, technologically we can pull off a lot
16:51:25 <pbourke-home> inc0: i know im just addressing the 'we're going to be overwhelmed by big tent' arg
16:51:49 <pbourke-home> there are 40 j2 files now though
16:51:54 <sdake> there are 115 j2 files
16:51:59 <sdake> there woud lbe 40 yml files
16:52:06 <inc0> yeah, we were limited by "only use if"
16:52:09 <sdake> because heat has heat-api, heat-api-cfn, heat-engine, etc
16:52:13 <pbourke-home> ah I see
16:52:13 <sdake> these are a container set
16:52:22 <pbourke-home> you will compress them
16:52:25 <vhosakot> yeah, we have 100+ j2 and 100+ Dockerfiles
16:52:26 <pbourke-home> yeah that's one nice thing
16:52:26 <sdake> the top level directory contains elemental.yml"
16:52:41 <wirehead_> If we're going to make an issue out of this, a non-sdake representative needs to actually determine how hard it is to translate a service from j2 to yml.
16:52:44 <sdake> i could compress them into one file but i think per container set is fine
16:53:03 <sdake> wirehead_ i htink we all think that is trivial
16:53:05 <sdake> ut i could be wrong
16:53:18 <sdake> it takes about 20 minutes per service
16:53:20 <pbourke-home> inc0: how would you feel about using a less specific form of dsl
16:53:21 <inc0> so pbourke-home we can easily refactor our Dockerfiles to make use of full jinja2 potential and compress everything as we like
16:53:38 <inc0> so I just fail to see any real value in DSL in any form
16:53:44 <inc0> since we have perfectly working tool now
16:53:51 <sdake> inc0 in that cae, jinja2 is a dsl, lets throw it out!
16:53:55 <pbourke-home> I think there's value in it
16:54:00 <sdake> inc0 it is perfectly workign for existing  requirements
16:54:00 <pbourke-home> but the question is is it enough
16:54:05 <sdake> not new requirements
16:54:06 <rhallisey> inc0, my opinion is similar
16:54:07 <inc0> it's a dsl that's mature, documented, stable and we already use it
16:54:07 <coolsvap> i think we can always achieve a whole lot technologically but we need to find the best fit of technology and user experience
16:54:27 <wirehead_> Putting on my operator hat, I suspect I'd be able to glean more information faster out of sdake's yaml file than a fully optimized jinja2 template.
16:54:27 <sdake> yes recall kolla is a tool targeted at operators
16:54:36 <sdake> not jinja2 rocket scientists
16:54:36 <sbezverk> when you look at j2 files and yml files, yaml looks more clean, I think operators will appreciate that if in addition they will be provided documentation
16:54:36 <inc0> so let's throw it out and create somethign immature, new, buggy and screw everyone who dared to create their own dockerfiles in the process
16:54:46 <pbourke-home> wirehead_: operators wont want to learn the dsl
16:54:49 <inc0> pbourke-home, correct me if I'm wrong, that includes Oracle too right?
16:54:59 <pbourke-home> inc0: yes
16:55:04 <sdake> inc0 i will address everything bu tthe lat part about people who made their own dockerfiles
16:55:24 <inc0> let me rephrase, is there any operator who has prod deployments who DID not edit any dockerfile?
16:55:33 <sdake> inc0 we will have a full testing period of 6 weeks in repo
16:55:36 <sdake> plus the rest o fthe cycle
16:55:48 <inc0> well, I've put 7 points in total in review
16:55:53 <sdake> 5 months is plenty of time to harden any mistakes we made
16:56:09 <inc0> no, it is not, we have tons of bugs, other prority items and such to address
16:56:14 <wirehead_> pbourke-home, I could say that on the other way around.  Operators wont want to learn our particular set of jinja2 either.
16:56:17 <rhallisey> sdake, ya but you're talking about hardening mistakes and adding new features
16:56:23 <rhallisey> this kinda halts all new features
16:56:25 <sdake> pbourke-home to that argument, you could label the custom plugin shit we have all over build.py
16:56:41 <sdake> pbourke-home yet people learn how to use that stuff - necessity is mother of invention and all that
16:56:43 <wirehead_> There's also creating a concept of an 'external builder'.
16:56:48 <inc0> wirehead_, jinja2 is really close to what Dockerfile looks like
16:56:58 <sdake> rhallisey it doesn't halt any new features
16:57:11 <inc0> well it is how Dockerfile looks like with if statements, for loops and includes
16:57:11 <sdake> i suspect, during development and review, atleast one docker file will get messed up during dev
16:57:14 <inc0> and few other
16:57:15 <sdake> and that will need repair
16:57:21 <wirehead_> The present jinja2 is really close to what Dockerfile looks like.  As the jinja2 complexity increases that may not be the case.
16:57:35 <inc0> it's always just a templating language
16:57:36 <rhallisey> I think it will, because we will be strengthening dsl
16:57:38 <sdake> wirehead_ bingo im right there with you
16:57:39 <inc0> nothing more
16:57:58 <rhallisey> mandre, you here?
16:58:02 <inc0> so sdake let say you start making dsl a mianstream
16:58:02 <wirehead_> PHP is "just" HTML. :)
16:58:17 <rhallisey> did people see what mandre's method for third party plugins was?
16:58:25 <mandre> I'm pretty much of inc0's opinion
16:58:33 <inc0> wirehead_, so let's remove php and write our websites in yaml that will generate html
16:58:53 <wirehead_> There's at least 10 implemtations of that for each popular language in Github.
16:59:13 <inc0> yeah, I don't feel adding another one
16:59:24 <inc0> none of them were really good ideas, we can iterate examples
16:59:44 <sdake> mandre of which opinion, that dsl is a bad idea?
16:59:45 <inc0> so tell me this sdake: let say we agree on DSL
16:59:54 <inc0> how do we add new container until all DSL is ready?
17:00:03 <mandre> I believe we can clean up our code base with advanced jinja2, and implement plugins in a nicer way
17:00:08 <inc0> how do you merge anything without breaking master untill all dsl is ready?
17:00:15 <mandre> that the dsl is overkill and not flexible enouth
17:00:23 <inc0> by all I mean every single container for every single distro and install type
17:00:24 <sdake> mandre its not just plugins, we need customized binaries installed and customized repos PER COTNAINER
17:00:38 <inc0> sdake, doable with jinja
17:00:41 <inc0> easily
17:00:42 <sdake> mandre your reaching at not flexible enough - you haven't provided any example where it can't work
17:00:43 <rhallisey> it's doable
17:00:55 <sdake> either way is doable
17:00:56 <rhallisey> sdake, his third party plugin patch
17:00:59 <inc0> sdake, install a package, run a command, install a package
17:01:02 <inc0> in that order
17:01:06 <sdake> the quetion is what is the best way for operators to engage with the project
17:01:09 <inc0> how do you do it in yaml?
17:01:14 <mandre> exactly what inc0 said
17:01:23 <sdake> mandre higher up a level
17:01:26 <sdake> inc0 higher up a level
17:01:29 <inc0> nop
17:01:33 <sdake> how does the operator  integrate with it
17:01:45 <inc0> install a c compiler, compile requirement lib, install a software needing compiled lib
17:02:04 <inc0> real world example when you might need this order
17:02:17 <sdake> yaml lis ordered
17:02:26 <mandre> sdake, you can't control order in which the instructions are run with your dsl
17:02:28 <sdake> its not a random ordering of things
17:02:32 <inc0> but you group install packages together
17:02:39 <sdake> mandre that is incorrect
17:02:46 <inc0> so unless you want to do command that install stuff, it's impossible
17:02:55 <inc0> and if you do then you'll do yaml that has nested dockerfile
17:03:00 <sdake> i really need to jet soon
17:03:07 <sdake> and this discussion needs to take place on the review
17:03:16 <inc0> sdake, indulge me, how do you do it in your yaml?
17:03:17 <sdake> but, here is the bottom line from my end
17:03:28 <sdake> i gotta go I ontt have time at this point to explain it to you
17:03:33 <sdake> remember, I said I have to leave ont he hour
17:03:36 <sdake> I wrote a spec
17:03:53 <sdake> I expect mandre and inc0 to write a spec  as well that meets all the requirements I sset out in the use casees
17:04:11 <sdake> I expect the core reviewers to review both of these specs and provide voting
17:04:19 <sdake> if no spec wins, then we will have no customization
17:04:19 <pbourke-home> i know sdake has to go but I'll just throw this out and he can read later on
17:04:31 <sdake> if both specs win, well what can I say, I dont know what to do with this
17:04:34 <pbourke-home> I personally would not bother with specs and just do pocs
17:04:41 <nihilifer> pbourke-home: +1
17:04:47 <inc0> pocs are there really
17:04:55 <inc0> well give me a bit to polish jinja2
17:04:56 <pbourke-home> inc0: not enough
17:04:56 <coolsvap> pbourke-home, sdague +1
17:04:59 <sdake> pbourke-home the reason we do specs is to break logjams
17:05:00 <nihilifer> dunno whether doing pocs instead of specs is "openstack way"
17:05:08 <pbourke-home> the dsl is barely functional
17:05:17 <sdake> specs blow donkey
17:05:19 <pbourke-home> so it doesn't offer answers to the questions been asked here
17:05:20 <inc0> nihilifer, whichever works, one poc is better than 100 specs imho
17:05:29 <nihilifer> agree
17:05:29 <sdake> the reason is becaue they add a bunch of tiem and complexity to development
17:05:40 <nihilifer> let's get the pocs in "workable" state
17:05:43 <pbourke-home> I say this as someone who contributed some code to the dsl poc so its nothing personal
17:05:51 <rhallisey> 2 pocs trial by combat?
17:05:55 <pbourke-home> yes
17:05:55 <sdake> in this case, because inc0 and mandre disagree, and possibly some others (its unclear) we require a spec with a majority vote
17:05:57 <inc0> that's why we only do specs if we want to throw out our fundamental architecture
17:06:14 <pbourke-home> let the spec come after
17:06:24 <pbourke-home> or in paralell
17:06:26 <sdake> i want all discussion in one spec
17:06:29 <nihilifer> well, i'd like to have 100% working pocs first, then spec voting
17:06:33 <sdake> or two specs
17:06:37 <sdake> but not all spread out over 20 patches
17:06:44 <pbourke-home> one spec and one poc for each
17:06:45 <pbourke-home> then vote
17:06:52 <nihilifer> hmmm... ok
17:06:53 <inc0> ok, agree
17:07:00 <sdake> wfm
17:07:07 <pbourke-home> they should prob have the same requirements though
17:07:08 <inc0> thanks pbourke-home
17:07:10 <pbourke-home> they need to be listed
17:07:13 <mandre> sounds good
17:07:15 <sdake> as long as use cases are ALL met in the spec i wrote
17:07:16 <pbourke-home> so they aren't solving different problems
17:07:22 <pbourke-home> and then saying theirs is the best :)
17:07:22 <inc0> there is a list in sdake spec
17:07:23 <rhallisey> awesome :)
17:07:27 <coolsvap> agreed
17:07:31 <inc0> I'll add few of my own
17:07:34 <sdake> pbourke-home good thinking
17:07:44 <sdake> inc0 if you want to add stuff thats fine, but lets keep it implementation agnostic
17:07:51 <inc0> ofc
17:07:54 <sdake> i am interested in use cases here
17:08:06 <sdake> these are just hte use cases coming out of "my sales channel"
17:08:06 <inc0> I don't do troyan horses...most of the time
17:08:18 <sdake> ok brainstorm the midcycle
17:08:19 <sdake> sessions
17:08:22 <sdake> I need a list of sessions
17:08:25 <sdake> I have to go now
17:08:29 <sdake> bbi1hr or so
17:08:57 <mliima> lgtm, i agree
17:08:57 <inc0> ok
17:09:06 <inc0> #topic midcycle brainstorm
17:09:12 <inc0> etherpad: https://etherpad.openstack.org/p/kolla-newton-midcycle
17:09:19 <inc0> so, question guys, do we have venue?
17:09:34 <wirehead_> or a date, although I might just be behind the power curve there.
17:09:36 <rhallisey> inc0, I think still unknown
17:10:08 <wirehead_> Are we doing it cohosted with an existing midcycle (c.f. operator?)
17:10:27 <inc0> nothing that I know of
17:10:38 <vhosakot> I thought Boston and Rayleigh, NC were discussed as venues
17:10:43 <inc0> well, let's do a brainstorm for sessions
17:10:44 <rhallisey> I can try for Westford,MA
17:10:52 <rhallisey> vhosakot, ya
17:10:58 <vhosakot> Raleigh*
17:10:59 <vhosakot> cool
17:11:00 <inc0> we also had option for Canada
17:11:09 <inc0> Lyncos is trying to do that
17:11:31 <inc0> so let's explore our options, I'll try Texas;)
17:11:39 <rhallisey> anyone have anything to add to the etherpad for topics :)
17:11:43 <inc0> although TX in the middle of summer might be hard to bear
17:12:08 <wirehead_> Kolla-Kubernetes
17:12:17 <rhallisey> wirehead_, add it :)
17:12:22 <rhallisey> added it*
17:14:18 <wirehead_> I've gone biking in TX in the middle of summer.  I fear nothing except running over armadillos.
17:16:30 <inc0> let's do this till 12.20
17:16:35 <inc0> so 3 more minutes
17:17:45 <wirehead_> So, minor rant: I started using Kolla-Kubernetes and Kolla a week or so ago and there have been a bunch of cases where the mainline was broken.
17:17:46 <inc0> #link https://etherpad.openstack.org/p/kolla-newton-midcycle
17:18:06 <inc0> wirehead_, let's leave it for open discussion 2 minutes from now;)
17:18:12 <inc0> I'd like to hear how it's broken
17:20:06 <inc0> kk, let's leave it for now
17:20:13 <inc0> we can review it again next week
17:20:31 <inc0> #topic Open discussion
17:20:39 <inc0> wirehead_, you have a floor
17:20:54 <wirehead_> K, so two things I observed.  First, ansible 2.0 being changed in mainline but the docs not being changed.
17:21:22 <inc0> I think there was patch upstream
17:21:30 <inc0> not sure tho, but sure, we need to add docs for it
17:21:34 <pbourke-home> the docs will lag behind to some extent
17:21:44 <pbourke-home> as they're not required as part of a change
17:21:46 <inc0> it's a master tho so that's understandable
17:21:50 <rhallisey> https://review.openstack.org/#/c/322361/2
17:22:31 <wirehead_> So, the docs were saying Ansible 1.9.4.  The actual working build at the moment was Ansible 2.0, with a doc patch that said 2.x was OK.
17:23:40 <inc0> yeah, in master it's expected to have some period between api change and doc change
17:23:57 <wirehead_> I would disagree with that assertion.
17:24:05 <inc0> well, that's our policy
17:24:17 <inc0> since we don't do docs and feature in same patch
17:24:17 <rhallisey> well we could be faster
17:24:24 <inc0> that's always true;)
17:24:42 <rhallisey> maybe shouldve required the doc change with the 2.0 change
17:24:50 <inc0> anything else on your mind wirehead_ ?
17:24:57 <wirehead_> 95% of the time, it's OK to lag the docs.  Not for things of the Ansible magnitude.
17:25:15 <inc0> well, special cases are not special enough
17:25:16 <pbourke-home> Ive always wondered about the doc policy tbh
17:25:25 <pbourke-home> as to how much sense it makes
17:25:33 <pbourke-home> if you change something important, you should document it
17:25:33 <inc0> me too, but reason is that we won't hold back code for typos in docs
17:25:37 <pbourke-home> true
17:25:40 <inc0> as code might be blocker for other stuff
17:25:40 <wirehead_> So, second observation was that I had a regression on Kolla-kubernetes over the weekend.  I'm mostly giving it a pass because month-old-project.
17:25:47 <pbourke-home> also I get some people are good devs but just can't document
17:25:53 <pbourke-home> it is what it is
17:26:24 <rhallisey> wirehead_, ya there's no gating yet so it's going to happen here and there
17:26:39 <inc0> well it as, as yhou said, month old project which we still work on architectural level
17:27:00 <wirehead_> Yeah, that's mostly a "we should start working on gating" comment.
17:27:33 <inc0> that is also always true;)
17:27:39 <inc0> and it holds true to kolla ansible too
17:27:43 <inc0> our gates sux
17:27:51 <inc0> not as much as it used to, but still
17:27:52 <wirehead_> Projects that implement gating earlier move faster.
17:28:13 <inc0> well, we have some openstack infra constrains
17:28:25 <pbourke-home> i just added a note to the midcycle to dicuss why we still can't make ours gate vote
17:28:25 <inc0> anyway, 2 minutes left
17:29:23 <inc0> ok, thank you guys!
17:29:35 <inc0> cya all in #openstack-kolla
17:29:40 <inc0> #endmeeting kolla