16:00:26 <inc0> #startmeeting kolla
16:00:28 <openstack> Meeting started Wed Dec 14 16:00:26 2016 UTC and is due to finish in 60 minutes.  The chair is inc0. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:32 <openstack> The meeting name has been set to 'kolla'
16:00:36 <GeraldK> DaSchab: I think it could be useful
16:00:47 <inc0> #topic rollcall - w00t...you know the rest
16:00:51 <wirehead_> meow
16:00:53 <sdake> o/
16:00:54 <duonghq> o/
16:00:54 <akwasnie> hi
16:00:54 <inc0> w00t everyone!;)
16:00:55 <hieulq__> o/
16:00:55 <v1k0d3n> o/
16:00:59 <coolsvap> o/
16:01:00 <mliima> \o/
16:01:01 <sp__> o/
16:01:02 <v1k0d3n> hello inc0 welcome back
16:01:02 <berendt> o/
16:01:05 <inc0> duh, you're hard crowd
16:01:05 <zhubingbing> o、
16:01:07 <zhubingbing> 0/
16:01:09 <zhubingbing> o/
16:01:11 <zhubingbing> o/
16:01:11 <Jeffrey4l> 0/
16:01:19 <jascott1> o/
16:01:20 <mliima> õ/
16:01:27 <qwang> o/
16:01:29 <inc0> v1k0d3n, just temporary, writing from sierra nevada;)
16:01:30 <lrensing> o/
16:01:43 <sp__> o/
16:01:45 <egonzalez90> woot o/
16:01:55 <srwilkers> woot o/
16:02:11 <inc0> #topic Announcements
16:02:14 <rhallisey> - /ᐠ。ꞈ。ᐟ\
16:02:26 <inc0> I don't have any since I was away, you guys have anything?
16:02:38 <sdake> yes
16:02:44 <Jeffrey4l> i have one.
16:02:45 <inc0> go ahead
16:02:47 <sdake> http://www.openstack.org/ptg
16:03:00 <sdake> PTG is Feb 20-24th iirc
16:03:02 <v1k0d3n> inc0: not a bad place to take a meeting :)
16:03:06 <sdake> check it out if you want to attend :)
16:03:21 <inc0> yes, we have first part of week
16:03:32 <inc0> still around 200 tickets left afair
16:03:50 <inc0> but they are running out, so if you're going make sure to at least get a ticket soon
16:03:52 <sayantan_> woot
16:04:05 <berendt> i participate in the travel support program, not yet sure if i can attend
16:04:25 <Jeffrey4l> i will make m2 tag tomorrow. also will make next z stream tag for stable branch ( mitaka and newton ).
16:04:52 <egonzalez90> berendt: me too
16:04:53 <inc0> Jeffrey4l? whats on your mind?
16:04:56 <Jeffrey4l> but no idea how to handle liberty branch, since it will be EOL too.
16:05:18 <inc0> Jeffrey4l, I think tonyb handles that part
16:05:18 <sdake> Jeffrey4l the liberty part is a agenda item I think :)
16:05:33 <inc0> it's not sdake
16:05:34 <Jeffrey4l> sdake, hrm not added it.
16:05:47 <Jeffrey4l> just for you information about the tag.
16:06:03 <sdake> cool good work on the release liasing Jeffrey4l :)
16:06:20 <inc0> yeah, thank you for handling this:)
16:06:24 <Jeffrey4l> for libert , i asked dellman, he has no idea no this and recommend me to throw a ML to talk.
16:06:30 <inc0> can we move on?
16:06:33 <Jeffrey4l> yep.
16:07:44 <inc0> Jeffrey4l, when I'm back I can handle that
16:07:44 <inc0> if you'll have issues till then
16:07:44 <inc0> anyway, moving on
16:07:44 <inc0> #topic fixed uid/gid
16:07:45 <inc0> Jeffrey4l, you have the floor
16:08:01 <Jeffrey4l> Sam and i talked this recently.
16:08:09 <Jeffrey4l> we have some different on this.
16:08:16 <Jeffrey4l> but he is not here today ;(
16:08:26 <Jeffrey4l> #link https://review.openstack.org/405647
16:09:14 <pbourke> o/
16:09:18 <kfox1111> o/
16:09:21 <Jeffrey4l> the talk is about:  does the uid/gid changable or not.  how the id is picked up.  picked by kolla? or based on rdo and cloud-archive.
16:09:50 <Jeffrey4l> i prefer to use static uid/gid and picked by kolla.
16:09:52 <inc0> if we would base it on repos, what if it differs in repo?
16:09:57 <kfox1111> that answer depends on if you want to support easy switching between ubuntu and rdo based containers.
16:10:00 <inc0> yeah agree Jeffrey4l
16:10:17 <inc0> kfox1111, or rather between binary versions of it
16:10:17 <kfox1111> if so, then the uid/gid's should be the same.
16:10:28 <sdake> i prefer that approach Jeffrey4l
16:10:28 <kfox1111> inc0: yeah.
16:10:33 <inc0> gid/uid hardcodding only matters in source builds for us
16:10:46 <Jeffrey4l> rdo has static uid. but rdo do not have all service.
16:10:47 <kfox1111> no, it matters for binary builds to.
16:10:55 <inc0> so ubuntu-source -> centos-source would just work
16:11:00 <kfox1111> last I looked rdo didnt have static uid?
16:11:19 <Jeffrey4l> kfox1111, it is. at least in nova package.
16:11:40 <Jeffrey4l> i am not sure wheter all packages have fix uid.
16:11:41 <kfox1111> I thought the uid in centos-binary 2.0.2 was different then 3.0.1?
16:11:49 <kfox1111> maybe I'm misremembering.
16:12:09 <Jeffrey4l> kfox1111, in centos, the uid is the same expect rabbitmq.
16:12:20 <Jeffrey4l> in ubuntu, totally no.
16:12:29 <kfox1111> ah. maybe I'm thinking rabbit then.
16:12:42 <inc0> maybe it's packager thing then
16:12:48 <inc0> well
16:12:54 <Jeffrey4l> ok anyway. seems team like static uid + picked by kolla.
16:12:55 <kfox1111> either way. at very least, it would be nice if it never changed in the same dist.
16:12:56 <Jeffrey4l> thanks.
16:13:18 <Jeffrey4l> inc0, please move on.
16:13:19 <sdake> the key thing there is upgrades need to work
16:13:20 <inc0> yeah let's keep doing what we're doing
16:13:31 <inc0> #topic replace heka with fluentd
16:13:39 <inc0> zhubingbing, you're on
16:13:49 <zhubingbing> hi
16:14:02 <zhubingbing> flunted the current situation,
16:14:52 <zhubingbing> i finish the most service has been synchronized to flunted i  expected  need 3 days to complete the first version;
16:15:11 <zhubingbing> next tuesday
16:15:18 <sdake> sweet
16:15:20 <wirehead_> So, you've got a heka lot of stuff done? :)
16:15:22 <duonghq> nice
16:15:24 <zhubingbing> i can finish first version
16:15:29 <egonzalez90> cool
16:15:34 <mliima> nice
16:15:35 <zhubingbing> yes
16:15:42 <srwilkers> wirehead_, :)
16:16:01 <inc0> cool, thanks zhubingbing
16:16:05 <zhubingbing> some as with  heka
16:16:13 <inc0> we don't need to run logstash right?
16:16:20 <inc0> (please tell me no logstash)
16:16:26 <sdake> ya no logstash plz
16:16:42 <zhubingbing> yes i think we need not log stash
16:16:49 <sdake> sweet
16:16:53 <wirehead_> Log-beard or no-beard.
16:17:09 <sdake> wirehead_ why - I shaved recently :)
16:17:16 <jascott1> Tree-beard?
16:17:18 <inc0> ok, can we move on?
16:17:37 <zhubingbing> agree
16:17:43 <inc0> hate to cut this short (see what I did there?), but we have full agenda
16:17:57 <inc0> #topic Zero-downtime upgrade support in Kolla
16:18:04 <inc0> duonghq, you have floor
16:18:05 <duonghq> thank inc0
16:18:11 * duonghq is landing on the floor
16:18:16 <duonghq> #link https://review.openstack.org/#/c/409598/
16:18:43 <duonghq> quick recap: I and hieulq__ are working on 1st phase of add support for zero-downtime upgrade from kolla side
16:18:58 <duonghq> demo clip: https://review.openstack.org/#/c/409598/
16:19:01 <sdake> duonghq you mean kolla deliverlable?
16:19:09 <duonghq> sdake, yup,
16:19:16 <sdake> duonghq nice :)
16:19:24 <inc0> duonghq, we cant handle any less downtime than services work
16:19:48 <duonghq> I and hieulq__  want to provide zero-downtime capability w/o native support from serviecs itself.
16:20:22 <duonghq> inc0, the spec proposes 1 solution for this: buffering layer
16:20:37 <inc0> duonghq, that's silent downtime tho
16:20:59 <inc0> also is very prone to errors
16:21:11 <duonghq> Just make users see it is only lag, not "down"
16:21:13 <inc0> speaking form my operator hat on
16:21:38 <duonghq> inc0, I thought about this, and tested with Neutron (w/ my patch for rolling upgrade Neutron)
16:21:39 <inc0> I'd rather have explicit maintanence of cloud than implicit lag
16:22:14 <duonghq> hmm
16:22:17 <inc0> I can see it working for most part, it's the edge cases that I'm afraid of
16:22:33 <inc0> also, if we have worst case scenerio - blocking database migration
16:22:41 <inc0> which is the case in certain services still
16:22:49 <inc0> upgrade downtime can take hours
16:22:54 <inc0> just to migrate database
16:23:03 <inc0> if it's sufficiently big
16:23:14 <inc0> and alters moves data around
16:23:24 <inc0> so having hour-long lag is no good.
16:23:41 <duonghq> inc0, sure, in the case you just described, it also may let connection timeout.
16:23:46 <berendt> which services are affected?
16:24:00 <portdirect_away> o/
16:24:02 <duonghq> so we are working on provide some kind of canary for blue-green deployment
16:24:10 <duonghq> which mitigate this issue
16:24:13 <inc0> berendt, can't tell you from top of my head, neutron had issues but I think it's already done
16:24:17 <hieulq__> inc0: yeah, that's why we think about the next step is blue-green or canary upgrade
16:24:35 <inc0> well, that's beyond scope of kolla imho
16:24:51 <duonghq> inc0, I applied the neutron rolling upgrade procedure, but still downtime from HAProxy side,
16:25:00 <duonghq> HAProxy is part of Kolla
16:25:02 <srwilkers> hey portdirect o/
16:25:31 <duonghq> as Sam and egonzalez90  mentioned in their comments, there is some tweak of HAProxy to reduce this,
16:25:35 <egonzalez90> duonghq: because when upgrading the containers, connections are killed
16:25:44 <egonzalez90> yes, there is an admin socket
16:26:11 <egonzalez90> to which can put a node in maintenance mode waiting for end the connections
16:26:15 <inc0> but green-blue upgrade or canary is 2 different installations of openstack
16:26:40 <duonghq> egonzalez90, the buffering layers keeps connection from be killed
16:26:49 <sdake> blue/green and canary upgrades are a bit too much to swallow for kolla-ansible for ocata for me
16:27:16 <kfox1111> sdake: +1. its difficult and there isn't much time left.
16:27:24 <sdake> t-1 month
16:27:40 <duonghq> sdake, kfox1111  I do not expect anybody can make it land for ocata
16:27:55 <duonghq> so it's our next step
16:27:59 <sdake> ah - ok - then we have plenty of time to sort it out - dont need to answer all the q's in this meeting :)
16:28:08 <kfox1111> yeah.
16:28:16 <inc0> let's work on this spec guys, we can provide options/tools for ops to use
16:28:43 <v1k0d3n> spec is a good place
16:28:46 <inc0> can we move on?
16:28:46 <duonghq> I'm very appriciate if you guys can leave suggestion for me on my spec
16:28:46 <egonzalez90> duonghq: my concern is not on the API side that can be buffered, is on rabbit and db connection, when the upgrade finished and buffered connections go in the older version to the worker
16:29:22 <duonghq> egonzalez90, iirc, the current mechanism from service can handle plenty of this
16:29:28 <duonghq> need recheck
16:29:43 <inc0> ok, moving on
16:29:45 <duonghq> egonzalez90, we are just on the 1st phase
16:29:50 <inc0> #topic Is the Nova Bug Dashboard (http://kolla.betacloud.io/bugs-dashboard.html) useful for us?
16:29:53 <duonghq> thank you guys
16:29:56 <berendt> check the URL http://kolla.betacloud.io/bugs-dashboard.html. is this dashboard useful for us or not? the nova team uses it. if it is useful i will activate a cronjob that updates it every hour and send a short mail to openstack-dev.
16:30:26 <Jeffrey4l> i like it ;)
16:30:35 <inc0> me too
16:30:40 <egonzalez90> yup, cool
16:30:41 <inc0> this is cool;)
16:30:43 <srwilkers> at first glance i like it
16:30:56 <srwilkers> yeah, this is pretty friendly
16:31:00 <zhubingbing> cool
16:31:06 <berendt> ok, i will prepare the cron job, will send a mail to openstack-dev and add a note to the docs
16:31:15 <portdirect> yeah thats looks nice :)
16:31:23 <Jeffrey4l> please add [kolla] tag berendt
16:31:34 <inc0> thanks berendt :)
16:31:40 <inc0> can we move on?
16:31:42 <berendt> Jeffrey4l: yes
16:31:45 <berendt> inc0: think so
16:31:52 <Jeffrey4l> thanks.
16:31:57 <duonghq> thank berendt
16:32:03 <inc0> I think I'm going to skip "pod" discussion as it was suggested in agenda;)
16:32:09 <inc0> so we move to k8s topics
16:32:28 <inc0> #topic kolla-kubernetes UX for service layers
16:32:35 <inc0> portdirect you have next 3
16:32:39 <portdirect> o/
16:33:06 <portdirect> so there has been a lot of discussion regarding the way we put kolla-k8s together
16:33:25 <v1k0d3n> alanmeadows
16:33:50 <portdirect> and so I think this is an area that we should look at, as it would let us get a target to aim for
16:33:57 <sdake> portdirect for those watching at home can you define UX plz :)
16:33:59 <alanmeadows> v1k0d3n: ;-)
16:34:06 <portdirect> ah, ok
16:34:09 <alanmeadows> im lurking
16:34:15 <portdirect> UX - is user experience
16:34:28 <sdake> right thanks portdirect :)
16:34:44 <portdirect> which in our case means the way that a human operator will interact with what we produce
16:34:58 <portdirect> so the tools they will use
16:35:00 <kfox1111> yeah.
16:35:10 <kfox1111> and how they are expected to interact with those tools.
16:35:20 <portdirect> how they can change things to make the deplyment fit their needs
16:35:28 <portdirect> and then keep their cloud running
16:35:34 * kfox1111 nods
16:35:42 <inc0> arent helm tool which was meant to help with that?
16:35:42 <portdirect> v1k0d3n, has wriiten a bp
16:35:55 <inc0> isn't*
16:36:02 <srwilkers> inc0, yep
16:36:04 <sdake> inc0 helm is being used of course
16:36:10 <kfox1111> inc0: helms one tool. it will help yes.
16:36:14 <portdirect> I think that using helm is a big part of that, but we need to decide how we are going to use it
16:36:30 <kfox1111> portdirect: link?
16:36:33 <portdirect> so the bp here: https://blueprints.launchpad.net/kolla-kubernetes/+spec/installation-docs-refactor
16:36:39 <sdake> i think the way the microservices layer worked out worked well
16:36:53 <sdake> sa in people submit differnet patchsets and we come to consensus on the patchsets via review
16:36:54 <duonghq> firstly, I think we should make decission from which layer we should expose to user?
16:37:09 <portdirect> I was thinking that we should start a doc that set out how we expect a person use kolla-k8s
16:37:16 <v1k0d3n> basically as portdirect is mentioning, since it was suggested not to write a spec for helm usage...perhaps the docs can define how helm is being used and to what extent.
16:37:18 <sdake> portdirect sounds good
16:37:19 <kfox1111> duonghq: no. al layers. its in the spec.
16:37:22 <portdirect> duonghq: ans you question is a big part of that
16:37:23 <duonghq> portdirect, you mean use case?
16:37:41 <v1k0d3n> partially? as part of a post "something" process? as delivery, upgrades, etc?
16:38:03 <portdirect> so how an operator will interact for vairius use cases
16:38:25 <jascott1> fyi I started upgrade bp here https://blueprints.launchpad.net/kolla-kubernetes/+spec/helm-deployment-upgrade
16:38:33 <v1k0d3n> i didn't realize when helm was brought up...other use cases. the current spec leaves some interpretation on what is first class.
16:38:34 <alanmeadows> the operator usage is really one aspect of the larger spec
16:38:39 <srwilkers> the lack of clarity on this topic has led to some pretty heated/emotional debates, and i dont want to see it fracture the kolla community. as portdirect said, we need to set a target and expectations here for this before it becomes unmanageable
16:38:39 <portdirect> v1k0d3n's questions abouve kinda match the headings i was thinking of
16:39:09 <kfox1111> agreed.
16:39:13 <v1k0d3n> if i'm come from a helm mindset, what needed to consume these charts?
16:39:28 <kfox1111> docs for sure are very lacking.
16:39:35 <v1k0d3n> i think it's important to define that, in case they look different than what i'm used to seeing elsewhere.
16:39:36 <kfox1111> but so are a lot of the layers too.
16:39:40 <portdirect> and once we have it defined what we expect our final goal to be, then i think it will be much easier for us to collectivlye get there :)
16:39:45 <vhosakot> o/  sorry I'm late.. had a conflicting meeting
16:39:50 <duonghq> v1k0d3n, I think we should done this top-down? the helm layer is the middle layer
16:39:57 <duonghq> sup vhosakot
16:39:57 <kfox1111> so what is the focus? on getting something proof concepted at all layers, or docs?
16:40:10 <vhosakot> duonghq: sup :)
16:40:28 <sdake> poc at mid layer wuld be my pref kfox1111
16:40:31 <sdake> to drive consensus
16:40:34 <alanmeadows> well I think more then just docs, I feel like the overarching design and goal of the helm introduction is lacking, and a lot of that discussion is happening in silos on IRC - where it really belongs in a spec thats agreed to and if something comes in that doesn't align with that, its an easy rejection
16:40:36 <sdake> the service layer thta is
16:40:36 <portdirect> so I think this topic/spec should stay away from technical discusstion as much as possible, as once we have the experince that we want our users to have, then we can define the technical route to implement that
16:40:37 <srwilkers> docs are important. but i think its beyond just docs. we need to decide: are we wanting to confirm to our own view of how helm should be used, or do we want to align with how other communities (the helm community especially) expects them to be used
16:40:46 <kfox1111> sdake: yeah. thats what we've been doing so far.
16:40:47 <duonghq> we are working on 2/3 sub-layer in one of middle layers
16:40:52 <v1k0d3n> kfox1111: i think (at least in my mind) that knowing the kolla-kubernetes vision would be helpful to new users.
16:41:06 <v1k0d3n> i need to know if i can consume this as is....or what else needs to happen?
16:41:10 <kfox1111> v1k0d3n: +1. thats in the spec though?
16:41:22 <v1k0d3n> if batteries are included...what batteries? AA, C, D?
16:41:32 <v1k0d3n> perhaps D doesn't fit in my walkie talkie
16:41:35 <sdake> https://blueprints.launchpad.net/kolla-kubernetes/+spec/helm-microservices
16:41:41 <sdake> check out the dependency chart at bottom of that page
16:41:42 <portdirect> cr1280 v1k0d3n
16:42:04 <v1k0d3n> kfox1111: i think there was room for interpretation. this is what caused the discussions over the last couple of weeks.
16:42:13 <v1k0d3n> that should be clear.
16:42:17 <sdake> those were very fruitful
16:42:20 <v1k0d3n> spec didn't do a great job.
16:42:28 <sdake> we produced code that deploys microservices
16:42:31 <sdake> that is why specs are evil v1k0d3n
16:42:35 <kfox1111> v1k0d3n: the vision is to allow the greatest numbers of users to be able to use kolla-kubernetes by allowing the user to make the tradeoff on the specctrum of easy to use vs full customizability
16:42:40 <sdake> and why we dont use them typically in kolla :)
16:42:45 <v1k0d3n> sorry, sdake i like specs
16:43:10 <sdake> specs cause more chaos then code reviews in kolla community :)
16:43:15 <kfox1111> v1k0d3n: agreed, the spec doesn't have some terms defined that are open to misunderstanding.
16:43:23 <sdake> we need PerfectChaos
16:43:27 <portdirect> so beefore we go down the rabbit hole again, can we step away from the tech dicussion and look at what we want at the end of the day
16:43:37 <portdirect> I'd be happy to colate such a process
16:43:39 <kfox1111> and we've arleayd changed temrinology a bit as we started into the design, realizing the terms used in the doc were old kolla-kuberntes terms and didn't quite apply as well in the helm world. :/
16:44:18 <kfox1111> portdirect: +1
16:44:28 <duonghq> portdirect, +1
16:44:42 <portdirect> kfox1111, v1k0d3n: (and any one else!) could we define what we want the end experienec that you have on day0, 1, and 2 of the finished kolla-k8s
16:44:52 <duonghq> but changing spec terms atm is a good idea?
16:44:55 <portdirect> (and I know it's never fnished)
16:44:59 <sdake> lets focus on day 0 imo ;)
16:45:15 <kfox1111> sdake: lets focus on day 2.
16:45:19 <sdake> inc0 indicated goal of ocata was day 0
16:45:21 <kfox1111> sdake: all the rest is easy compared to that.
16:45:27 <portdirect> would the mailing list be the best place for this conversation?
16:45:33 <kfox1111> if we dont focus on day 2 we have an unusable system. :/
16:45:40 <sdake> ok then day 2 it is :)
16:45:43 <portdirect> as i think it would alow us to compose out thoughts more clearly?
16:45:45 <srwilkers> day 2 is important because it helps us understand what to expect at day 0.  are we expecting an actual kubernetes deployment through this project, or just the helm packages required for one?
16:45:46 <sdake> mailing list might work
16:45:46 <inc0_> yeah, I think we'll have plenty on our hands to even deploy by ocata
16:46:00 <v1k0d3n> sdake: yes day 0
16:46:04 <srwilkers> thats where my confusion comes from
16:46:11 <v1k0d3n> this is really important...not for all...but i think for most.
16:46:16 <qwang> +1 for mailing list
16:46:21 <kfox1111> portdirect: it may be, yeah.
16:46:25 <inc0_> with caveat of "let's not burn day2 bridges"
16:46:34 <alanmeadows> The mailing list seems like a widening of the same isolation, why not a spec?
16:46:37 <sdake> inc0_ sounds good
16:46:38 <kfox1111> v1k0d3n: there are pleanty of day 0 solutions, and most don't work for a lot of operators.
16:46:43 <portdirect> I could start a thread after the meeting, and we could each then describe what we want from kolla, and from that I can produce a doc up on gerrit for us to rip apart?
16:46:44 <kfox1111> because they never considerd day 2.
16:46:48 <sdake> alanmeadows specs take weeks
16:47:02 <sdake> alanmeadows we dont want  to block
16:47:03 <inc0_> we don't have weeks if we want to deliver 1.0 for ocata
16:47:10 <kfox1111> portdirect: sounds good. we really need a requirements doc. this could be a start of that.
16:47:19 <inc0_> please let's deliver 1.0 - even without upgrades - for ocata
16:47:29 <kfox1111> inc0_: +1.
16:47:32 <portdirect> +1 (personally to that inc0 )
16:47:33 <sdake> right
16:47:33 <duonghq> inc0_, +1
16:47:40 <inc0_> I'm ok with having bp or multiple bp for later on
16:47:40 <alanmeadows> But why does the delivery requirement negate the spec entirely?
16:47:54 <alanmeadows> The two can be done in parallel, granted some of the work may be in the opposite direction of the spec
16:48:00 <kfox1111> microservcies are something that can be delivered in that timeframe. the upper layers in the next release.
16:48:01 <alanmeadows> but at least the path will be set and clear
16:48:03 <portdirect> alanmeadows is spot on here
16:48:05 <alanmeadows> This is a long road
16:48:06 <v1k0d3n> i thought that kolla-kubernetes was approaching from greenfield...
16:48:14 <v1k0d3n> but community has spoken. i can respect that.
16:48:20 <kfox1111> alanmeadows: +1 for parallel.
16:48:32 <v1k0d3n> just throwing it out there that spec define a very clear path for operators and developers alike.
16:48:44 <duonghq> kfox1111, I think we need service layer too
16:48:48 <kfox1111> v1k0d3n: theres an issue with total greenfield. kolla-kubernetes has compeditors. that has to be weighed.
16:48:53 <alanmeadows> If you want to present this to Ocata, you need to explain some of the deficiencies, and you can't say, go back and read our mailing list for the complete vision
16:48:56 <kfox1111> duonghq: I agree, but not sure that can be done by ocata
16:49:03 <alanmeadows> You need to be able to say, take a look at the refined spec
16:49:10 <alanmeadows> to understand where we are going
16:49:11 <lrensing> alanmeadows: +1
16:49:13 <srwilkers> kfox1111, im glad you mentioned competitors. heres whats likely to happen if we get hamstrung on not defining this soon and acting on it
16:49:17 <sdake> the ocata presentation of this work is in NOVEMBER
16:49:17 <v1k0d3n> alanmeadows: +1
16:49:20 <duonghq> kfox1111, anybody can define what is the end goal of service layer?
16:49:28 <portdirect> duonghq, this is why i raised this subject, the technical implementation of the service layer will acutally define a huge portion of the user expereince of kolla-k8s
16:49:28 <inc0_> alanmeadows, well, don't forget that we have PTG
16:49:39 <inc0_> where we can sort lots of things face to face
16:49:45 <kfox1111> duonghq: services layer is about easy deployment.
16:49:47 <inc0_> but agree, let's draft a spec and not block on it
16:49:49 <duonghq> portdirect, can we narrow it?
16:49:50 <inc0_> just work on it
16:50:03 <inc0_> and use it to plan for Pike
16:50:07 <srwilkers> my worry is that if we dont figure this out and define a clear, meaningful path forward for the long term, that another project is going to swoop in and implement a standard approach for deploying openstack with helm outside of the kolla namespace
16:50:12 <v1k0d3n> ok, so portdirect i think spec in parallel. is that what i hear everyone saying?
16:50:22 <kfox1111> microservices layer is about providing lego building blocks of which you can assemble manually any openstack config you want.
16:50:22 <portdirect> yes i think so
16:50:38 <inc0_> I don't want to talk about other projects tbh
16:50:39 <sdake> kfox1111 agree - and we need to automate that at some point
16:50:52 <v1k0d3n> inc0_: +1 or competition.
16:51:03 <srwilkers> there are a lot of people who are looking to kolla to solve this problem, and i really think it belongs here, whether its through kolla-kubernetes taking a standard approach that aligns with other communities doing the same, or whether its through a kolla-helm project focused on an opinionated way of deploying openstack on kubernetes through the standard helm approach
16:51:04 <kfox1111> sdake: +1. but on the other hand, if we get a system that is 2day managable before anyone else, I think operators will flock to that.
16:51:14 <kfox1111> so we have to carefully balance the two.
16:51:17 <duonghq> sdake, +1 but we need limit how much "automation" we'll deliver in O
16:51:20 <inc0_> yeah, but no matter how well defined specs we have, we'll fail the race if we won't deliver
16:51:21 <sdake> kfox1111 we want everyone to work together not compete ;)
16:51:29 <kfox1111> sdake: +1 on coooperation.
16:51:44 <kfox1111> thats anotherthin g the microsevices allow.
16:51:46 <inc0_> so yes, let's write spec, but keep us focused on "deploy by ocata" please
16:51:51 <v1k0d3n> +1 inc0_ i think that is important to consider, and that is our approach
16:51:52 <kfox1111> sharing at the microservice level, and doing their own service thing.
16:51:56 <v1k0d3n> been there many times before.
16:51:59 <portdirect> these points are why i think we should move this discusstion to the mailing list, as they are all valid, but get llost in the noise of irc
16:52:14 <kfox1111> portdirect: +1
16:52:15 <sdake> portdirect agree - ml is winning for these types of discussions
16:52:18 <alanmeadows> I get the competition concern, and what will set you apart from that is a clear spec with the design approach, how all day-2 facets would be tackled with said design, and articulating clearly what your helm approach is
16:52:18 <duonghq> +1 portdirect
16:52:30 <alanmeadows> lots of people have "stuff", few are providing that complete picture
16:52:37 <v1k0d3n> +1 alanmeadows
16:52:41 <kfox1111> alanmeadows: +1.
16:52:48 <srwilkers> alanmeadows, agreed
16:52:52 <duonghq> 8min left for this meeting :(
16:52:53 <SamYaple> o/
16:52:56 <duonghq> hey SamYaple
16:52:57 <portdirect> alanmeadows for king!
16:52:59 <SamYaple> im new to this
16:53:00 <portdirect> lol
16:53:10 <v1k0d3n> so path? continue?
16:53:34 <sdake> ok we got 7 ins left - what are the actions inc0_ ?
16:53:40 <inc0_> lets start on ML thread
16:53:50 <inc0_> and see where that gets us
16:53:50 <SamYaple> was there anything specific that was being asked of me that i missed?
16:54:00 <srwilkers> SamYaple, just your firstborn
16:54:01 <srwilkers> nbd
16:54:02 <inc0_> as far as discussions go - ML are more efficient than spec
16:54:08 <portdirect> v1k0d3n, i think we will need to contunue, but I'm very hesistant about choosing the path of least technical resistance to our current codebase if it may hurt us in the long run
16:54:08 <inc0_> we can draft a spec from there
16:54:28 <Jeffrey4l> uid/gid SamYaple. but seems we run out of time
16:54:33 <sdake> if we draft a spec, no blocking plz
16:54:42 <v1k0d3n> portdirect: +1 that
16:54:45 <inc0_> portdirect good thing about k8s is that once we deploy, we have abstraction layer
16:54:46 <duonghq> sdake, +1
16:54:56 <sdake> there is always overflow into #openstack-kolla - we do that all the time :)
16:55:20 <inc0_> I'm fairly sure that we can migrate 1.0 -> 2.0 with virtually any changes to k8s codebase
16:55:34 <kfox1111> inc0_: k8s provides a nice abstraction layer, and then helm adds a non abstract layer in some ways.
16:55:48 <portdirect> lets take this to the ml
16:55:49 <duonghq> sorry but can we move on: kolla-kubernetes helm/k8s versioning and compatibility with upstream - portdirect?
16:55:51 <inc0_> agree
16:55:52 <v1k0d3n> 5 imins
16:55:54 <alanmeadows> The goal of the spec wont be to block, although at some point, things need to start shifting to adhere to it.  We need to divorce the proper design and approach from the time constraints that are so clearly visible in whats being created
16:55:54 <inc0_> moving on
16:55:54 <portdirect> yes
16:55:58 <kfox1111> so getting the helm package api right is critical for that.
16:56:05 <inc0_> #topic kolla-k8s Documentation
16:56:13 <sdake> agree lets move forward on upstream compatibility
16:56:15 <kfox1111> alanmeadows: +1
16:56:16 <sdake> that is blocking us atm
16:56:17 <inc0_> portdirect, last topic for you:)
16:56:21 <v1k0d3n> +1 alanmeadows
16:56:22 <portdirect> inc0_: i think we can skip that
16:56:25 <inc0_> we'll move remiaining topics for next week
16:56:26 <v1k0d3n> this is big point
16:56:26 <inc0_> ok
16:56:35 <portdirect> and move to helm/k8s versioning and compatibility with upstream
16:56:39 <inc0_> ok
16:56:53 <inc0_> #topic helm/k8s versioning and compatibility with upstream
16:56:55 <portdirect> so 2 things in one, and we will run out of time :)
16:56:57 <inc0_> 3 minutes
16:57:07 <inc0_> so jsut start disussion and we'll continue next week
16:57:08 <portdirect> what do we track helm or k8s?
16:57:20 <kfox1111> we're heavily invested in helm.
16:57:21 <portdirect> docker inc docker, or distro docker?
16:57:22 <duonghq> guess that we can have some recap on this topic
16:57:23 <duonghq> ?
16:57:25 <kfox1111> and helm is very very green.
16:57:35 <kfox1111> they fixed a critical upgrade bug 7 days ago.
16:57:36 <openstack> bug 7 in Launchpad itself "Need help for novice translators" [High,Fix released] https://launchpad.net/bugs/7 - Assigned to Данило Шеган (danilo)
16:57:39 <kfox1111> so we need to keep on top of helm.
16:57:40 <portdirect> duonghq: its about the version of the software we use
16:57:48 <srwilkers> kfox1111, i agree
16:57:54 <portdirect> me too :)
16:58:09 <portdirect> so we track the latest helm, and whatever is needs?
16:58:13 <kfox1111> so I vote for tracking helm over trackign k8s for now.
16:58:15 <sdake> portdirect wfm
16:58:20 <srwilkers> i agree
16:58:20 <alanmeadows> its moving quickly, suggest life starts at 2.1.0 (supports 1.5) + 1.5 otherwise a lot of pet refactoring
16:58:30 <v1k0d3n> kfox1111: getting involved in their community would help
16:58:37 <v1k0d3n> meetings are thursdays
16:58:40 <portdirect> alanmeadows: I'm currently working on that transistion
16:58:45 <kfox1111> v1k0d3n: +1.
16:58:46 <alanmeadows> portdirect: yay.
16:59:03 <kfox1111> v1k0d3n: I'll try to attend if I have the time.
16:59:06 <v1k0d3n> going to discuss openstack at next meeting btw.
16:59:13 <v1k0d3n> sure. up to your schedule.
16:59:16 <berendt> 1 min left..
16:59:17 <srwilkers> kfox1111, v1k0d3n ill be there
16:59:20 <v1k0d3n> been working directly with those guys.
16:59:24 <kfox1111> yeah. my schedule is not up to me. :(
16:59:26 <inc0_> yeah, lets overflow to next week
16:59:26 <v1k0d3n> awesome srwilkers see you there!
16:59:32 <portdirect> i have reached out to them and am trying to find out if they are up for having a kolla specific meating
16:59:36 <sdake> inc0_ sounds like a plan :)
16:59:36 <v1k0d3n> kfox1111: +1 same here. i have to force a lot of things
16:59:40 <inc0_> thank you all!
16:59:45 <inc0_> #endmeeting kolla
16:59:46 <portdirect> thanks!
16:59:47 <srwilkers> v1k0d3n, understatement
16:59:47 <hieulq__> Thank you
16:59:50 <duonghq> bye
16:59:59 <v1k0d3n> portdirect_zzzzz: "opentack" meeting :)
17:00:05 <v1k0d3n> kolla narrow
17:00:07 <v1k0d3n> later
17:00:13 <mliima> bye
17:00:20 <berendt> endmeeting not working?
17:00:33 <inc0_> I got dc:(
17:00:35 <inc0_> hold on
17:01:05 <inc0> #endmeeting kolla