15:59:08 <inc0> #startmeeting kolla
15:59:09 <openstack> Meeting started Wed Nov  9 15:59:08 2016 UTC and is due to finish in 60 minutes.  The chair is inc0. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:59:13 <openstack> The meeting name has been set to 'kolla'
15:59:31 <inc0> #topic rollcall - woot for Kolla
15:59:38 <inc0> woot everyone please:)
15:59:44 <Jeffrey4l> wppt
15:59:44 <duonghq> woot!!!
15:59:48 <Jeffrey4l> woot ;)
15:59:50 <pbourke> woot
16:00:06 <rhallisey> hi
16:00:07 <inc0> #chair rhallisey
16:00:12 <openstack> Current chairs: inc0 rhallisey
16:00:12 <coolsvap> o/
16:00:20 <inc0> lets give few more minutes
16:00:22 <lrensing> o/
16:00:31 <lrensing> woot
16:00:38 <srwilkers> o/
16:00:40 <portdirect> o/
16:00:44 <srwilkers> woot
16:00:51 <egonzalez90> woot o/
16:00:54 <portdirect> woot
16:01:08 <sdake> o/
16:01:28 <zhubingbing> o/
16:01:33 <inc0> #topic announcements
16:01:49 <inc0> soo, welcome all after summit, it was great one!
16:02:04 <inc0> couple announcements:
16:02:05 <srwilkers> \o/
16:02:24 <inc0> 1. repo split will happen soon - sdake mind talking more about it later in the meeting?
16:02:30 <sdake> sure
16:02:39 <sdake> as long as later is sooner
16:02:45 <sdake> i am at a conf and need to jet a bit early
16:03:16 <inc0> 2. we have tons of etherpads and feedback to parse, I'd encourage everyone to take a look on feedback from etherpads, translate them into blueprints and ofc implement:)
16:03:43 <inc0> 3. kolla-k8s dev is full speed ahead now, but I'll let Ryan talk about this one more
16:03:45 <mandre> o/
16:03:49 <inc0> any other announcements?
16:04:13 <inc0> guess not, let's move on
16:04:20 <inc0> #topic repo split
16:04:24 <inc0> sdake, you're up
16:04:30 <sdake> cool thanks :)
16:04:40 <sdake> so repo split - as many know i am at CNCF this week
16:04:50 <sdake> so I have not had time to do the mechanics of the work
16:04:58 <sdake> however, I have got the ball rolling with infra and release team
16:05:06 <sdake> and they have added invaluable insight in *how* to do the job
16:05:15 <sdake> I'll submit the repo split thursday
16:05:24 <sdake> assuming I'm not swamped by $$DAYJOB$$ :)
16:05:31 <sdake> then we have a whole lot of work to do fter that
16:05:43 <sdake> 1. delete all the stuff from various repos that are not relevant
16:05:47 <inc0> sdake, would you mind adding some list of work after that?
16:05:49 <sdake> 2. make the gate jobs work again
16:05:51 <jmccarthy> o/
16:06:01 <sdake> yes doing that now inc0 :)
16:06:15 <sdake> that is basicallly it
16:06:18 <sdake> key things
16:06:23 <inc0> yeah, we'll need to translate it to blueprints/work items with more granularity
16:06:26 <inc0> but that's later
16:06:49 <inc0> getting gates up will be tricky
16:06:50 <sdake> our branches will remain intact on in kolla-ansible
16:07:01 <sdake> our tags will also remain intact on kolla-ansible
16:07:08 <sdake> i think we should stick with the same version #s
16:07:14 <sdake> but would like feedback on the ml
16:07:15 <inc0> +2 to that
16:07:26 <sdake> i have started  a thread, please chim in there on this point
16:07:28 <sdake> morning pprokop
16:07:31 <pprokop> HI
16:07:37 <DTadrzak> Hi
16:08:13 <duonghq> sdake, I thought that release-team agreed with keep version continue?
16:08:27 <inc0> sdake, when you're back we need to make workable items out of repo split cleanup
16:08:31 <sdake> duonghq that may be right
16:08:37 <inc0> so community will be able to handle that
16:08:37 <sdake> inc0 sounds good
16:08:41 <sdake> inc0 i'll write it down
16:08:43 <inc0> thanks
16:08:44 <sdake> as work items and a blueprint
16:08:46 <sdake> for each repo
16:08:50 <sdake> two blueprints that is
16:08:54 <inc0> appreciate that
16:08:55 <sdake> i was plannign to do the work myself
16:09:01 <sdake> but if we want ot split it out that also wfm :)
16:09:12 <sdake> jeffrey4l was planning to help with the gating refactor
16:09:14 <inc0> I think we should as some of it will be hideous
16:09:44 <inc0> and sooner we're done with split the better - it will affect our dev negatively
16:09:59 <inc0> sdake, anything else or can we move on?
16:10:30 <sdake> we can move on
16:10:31 <inc0> ok, moving on:)
16:10:49 <inc0> #topic post-summit work
16:10:55 <inc0> #link https://etherpad.openstack.org/p/kolla-o-summit-schedule
16:11:05 <inc0> soo, we got tons of feedback on summit
16:11:40 <inc0> some of these items are pretty simple changes, some are full fledged mini-projects
16:12:21 <inc0> #link https://etherpad.openstack.org/p/kolla-o-summit-roadmap <- let's translate this to blueprints
16:12:34 <sdake> inc0 fwiw doing all that stuff is pretty much impossible - too much work :)
16:12:41 <inc0> and leave them unassigned unless somebody would like to assign themselves
16:12:46 <sdake> inc0 sounds good :)
16:12:52 <srwilkers> sounds good
16:12:56 <sdake> inc0 who is writing the blueprints?
16:12:57 <inc0> agree sdake I don't think we'll handle it all in ocata, but thats fine
16:13:17 <portdirect> +1
16:13:20 <inc0> I can do this, but I'd like people to review them and fill up details
16:13:29 <inc0> and maybe assign themselves:)
16:13:48 <inc0> if we won't do it all in Ocata, well, such is life
16:13:53 <sdake> inc0 we have a  large community that doesn't attend this irc meeting, so people will assign themselves outside of this meeting as well :)
16:13:56 <inc0> but we should have record of it for future sake
16:13:57 <srwilkers> if you need any help inc0, lmk
16:14:00 <sdake> inc0 ya we never did all the work we wanted ot do in teh past :)
16:14:41 <inc0> k, thanks, I'll send out ML info afterwards
16:15:23 <inc0> if you guys want to register bp yourself (especially if you know more about the item/are interested in it and can fill up details)
16:15:29 <inc0> make note of it in etherpad and go ahead
16:15:42 <inc0> just make sure to add link to bp back to etherpad afterwards
16:15:54 <inc0> take a look at other etherpads from summit and do the same
16:15:54 <portdirect> will do, I'm also up for any call's to action for things that need att
16:15:56 <coolsvap> inc0: i would just recommend to have around 10 mins each week to track bp status which we think are important, just to ensure they are not blocked
16:16:02 <inc0> I'll keep filling bps
16:16:23 <inc0> appreciate that guys
16:16:32 <inc0> coolsvap, it's not mine to say what's important tho;)
16:16:52 <inc0> but that's different matter
16:17:23 <inc0> #action translate etherpad lines to blueprints and add a link to etherpad
16:18:04 <inc0> anyone wants to add anything to this topic? We'll take a look at these blueprints next week
16:18:14 <inc0> let's make sure that they're filled with knowledge
16:18:15 <pbourke> inc0: sounds like a good plan
16:18:21 <coolsvap> inc0: yes but we need some way to track, we can discuss on channel
16:18:30 <coolsvap> inc0: pbourke +1
16:18:34 <inc0> launchpad is the tracker:)
16:18:44 <inc0> ok, moving on
16:19:01 <inc0> rhallisey, take on kolla-k8s plz
16:19:04 <pbourke> inc0: dont forget to include the k8s work
16:19:11 <rhallisey> #topic kolla-kubernetes spec
16:19:17 <pbourke> assuming that is all part of the same launchpad?
16:19:21 <rhallisey> #link https://review.openstack.org/#/c/392257/5
16:19:32 <inc0> pbourke, kolla-k8s work goes to kolla-k8s launchpad
16:19:34 <sdake> rhallisey nice job on that spec bro
16:19:36 <rhallisey> pbourke, I've got most of it already in the launchpad
16:19:38 <pbourke> inc0: ah thanks
16:19:39 <sdake> rhallisey i think it needs a little fine tuning
16:19:53 <sdake> rhallisey you probablly have an election hangover ;)
16:19:54 <rhallisey> sdake, thx.  Ya still iterating on it
16:20:03 <rhallisey> we're getting some good feedback on the spec
16:20:20 <rhallisey> indeed
16:20:21 <sdake> rhallisey when can you ahve the next iteration ready?
16:20:33 <rhallisey> sdake, uh soon, I just posted a wave of new comments
16:20:42 <sdake> oh cool i'll check that out
16:20:45 <rhallisey> so for everyone that hasn't seen it, check out the spec
16:21:02 <rhallisey> it is meant to outline where the project is going to go
16:21:25 <sdake> rhallisey would you mind yielidng the floor to me when you wrap up :)
16:21:26 <rhallisey> there is a ton to discuss in there, so please leave your feedback
16:21:42 <rhallisey> sdake do you want to comment on the spec or something else?
16:21:50 <rhallisey> I wanted to breifly touch on operators
16:21:59 <pbourke> rhallisey: its essentially to do pocs though right?
16:22:12 <pbourke> rhallisey: the project may go in a different direction based on the outcome
16:22:12 <sdake> rhallisey I just want to also point out this review:
16:22:14 <sdake> https://review.openstack.org/#/c/395636/
16:22:19 <sdake> rhallisey i'd like your +2 on it :)
16:22:24 <rhallisey> pbourke, yes, the first thing we need to do is to get POCs rolling
16:22:25 <sdake> and kevins +2+w
16:22:30 <pprokop> yeah i think helm should be first
16:22:30 <sdake> or visa-versa
16:22:32 <zhubingbing> have break，is kolla-k8s  an independent project , it has no relationship with kolla?
16:22:44 <pbourke> rhallisey: so I would suggest putting a time limit on this spec
16:22:50 <sdake> zhubingbing its a deliverable of the kolla project
16:22:52 <inc0> yeah helm is pretty well defined already and pocs are inprog
16:22:59 <rhallisey> sdake, kk
16:23:02 <pbourke> rhallisey: get the ball rolling as people will talk for weeks on this stuff
16:23:09 <rhallisey> pbourke, agreed, I'll throw something on the ML
16:23:11 <sdake> ya we dont need a full analysis
16:23:13 <inc0> srwilkers any updates on that front?
16:23:15 <sdake> enough people are lined up to do the work
16:23:22 <duonghq> zhubingbing, it's equivalent to kolla-ansible (after repo-split)
16:23:27 <sdake> and i think we have  a clear picture of where we are headed
16:23:30 <sdake> pbourke ++ :)
16:23:31 <rhallisey> so a week from the origion post date
16:23:36 <rhallisey> that was yesterday
16:23:52 <rhallisey> Nov 15th we will close this out
16:23:52 <srwilkers> inc0 not yet from us, should have something soon
16:23:59 <inc0> kk
16:24:30 <rhallisey> sdake, did you have anything else to mention? I'll check out that review
16:24:35 <inc0> one question for broader audience, operators, will they solve following problems: 1. dependency 2. ceph rbd lock pulling for mariadb
16:24:37 <inc0> ?
16:24:45 <rhallisey> inc0, I'll get to that
16:24:51 <pprokop> If you want I can prepare a demo if kubernetes-entrypoint for you
16:24:51 <inc0> kk
16:24:58 <sdake> rhallisey just the review
16:25:03 <rhallisey> sdake, kk
16:25:12 <sdake> inc0 operators will sole deps
16:25:13 <inc0> pprokop, yes please, ideally with readiness probes
16:25:20 <pprokop> Yep
16:25:20 <sdake> inc0 operators will not solve fencing
16:25:26 <sdake> inc0 i think that is a separate thing
16:25:30 <rhallisey> pprokop, hey!  Yes that'd be cool too.  I want to explore all the options here
16:25:43 <rhallisey> # topic Operators
16:25:50 <rhallisey> #topic Operators
16:25:59 <rhallisey> #link https://github.com/coreos/etcd-operator
16:26:05 <rhallisey> looks like sdake answer it
16:26:14 <inc0> so my understanding of what operators are is just oposite - will potentially solve fenicing, will not solve deps
16:26:24 <pprokop> +1
16:26:27 <sdake> let me explain operators in a nutshell
16:26:28 <rhallisey> inc0, for fencing, I think that needs to be solved on the Kube side, but we could solve it here
16:26:44 <inc0> we did kinda solve it with fencing pod
16:26:50 <inc0> and operator is similar to this
16:27:07 <sdake> no
16:27:12 <sdake> so, let me explain plz
16:27:21 <pbourke> sdake: can you explain in the spec?
16:27:31 <sdake> there is a kubernetes pattern called a controller
16:27:39 <sdake> a controller does the following:
16:27:46 <sdake> 1. creates db
16:27:49 <sdake> 2. creates users
16:27:55 <sdake> 3. whatever else is needed fo rthe service
16:28:19 <sdake> 4. spins waiting for dependencies to be met (e.g. mariadb is a dep)
16:28:40 <sdake> 5. launches after 4
16:28:53 <sdake> an operator is a container that runs a daemonized version of a controller
16:29:06 <sdake> the terms come from kubernetes community
16:29:09 <sdake> its not like I made em up
16:29:15 <sdake> at CNCF this model is super hot and talk of the show
16:29:23 <sdake> this is how all kube apps  will be done in the future
16:30:08 <sdake> pbourke oh explain in the spec
16:30:14 <sdake> pbourke sorry i thought you meant explain the spec
16:30:16 <sdake> (misread)
16:30:18 <pbourke> sounds like they're going to reimplement ansible :p
16:30:23 <sdake> pbourke i think the spec explains operators
16:30:24 <vbel> so there will be operator service :) and another operator for passive backup?
16:30:26 <sdake> pbourke right sort of
16:30:26 <inc0> ssshhh
16:30:30 <pbourke> sdake: no worries we can drop your explanation in there
16:30:32 <sdake> vbel right
16:30:37 <rhallisey> I can capture this in my next iteration, but it would be good to commet there
16:31:11 <sdake> vbel operator per microservice, operator per service, one operator for all of openstack
16:31:27 <vbel> sdake, I see, thanks
16:31:31 <inc0> like roles tasks and playbooks
16:31:33 <inc0> yay
16:31:45 <vbel> hierarchy in other words :)
16:31:47 <sdake> vbel we need m0ar minerals, so if you can sign up as a contributor it would be appreciated ;)
16:31:48 <zhubingbing> pool-service
16:32:01 <sdake> asytronauts-as-a-service ;-)
16:32:08 <srwilkers> starcraft references make me so happy
16:32:13 <portdirect> k8s loves controllers - they use this nonclamenture on everything from repcontrollers up i think.
16:32:37 <vbel> sdake, :)))
16:32:38 <sdake> yup controllers are basically kubernetes version of plugins
16:32:50 <rhallisey> ok any more comments? Be sure to follow up in the spec :)
16:33:08 <inc0> looking for volunteers to write a poc of operator
16:33:10 <sdake> and operators are kubernetes version of how the plugin code plugs in for multinode suppport
16:33:10 <zhubingbing> the etcd is the core. in k8s
16:33:16 <sdake> inc0 i'm on that
16:33:23 <rhallisey> I'll join sdake on that
16:33:24 <duonghq> zhubingbing, what is your point?
16:33:29 <sdake> sounds good rhallisey
16:33:41 <sdake> any others want to pile on on the prototype ? :)
16:33:51 <inc0> ok, I'd be interested to see it as my understanding of this matter is clearly lacking
16:34:08 <sdake> inc0 ya i've had a whole lotta conversations with people here at cncf about it
16:34:09 <portdirect> is anyone working on poc's atm? (I assume they are - it would be great to get an overview to make sure we dont come to the take with a bunch of identically skinned cats :) )
16:34:12 <sdake> its not immediately intuitive
16:34:19 <sdake> but once you think it through its really the only way to roll :)
16:34:35 <sdake> portdirect what i'm thinking is we implement a base class
16:34:47 <inc0> so question, pprokop and others, are operators alternative to entrypoint for deps?
16:35:09 <pprokop> at first glance
16:35:16 <sdake> portdirect and then implement a whole lot of code that imports the base
16:35:19 <pprokop> check github.com/mirantis/k8s-appcontroller
16:35:32 <sdake> pprokop i haven't looked at k8s-appcontroller
16:35:36 <portdirect> sdake: +1
16:35:38 <sdake> is it generic in nature, or is it specific to openstack?
16:35:48 <pprokop> generic
16:35:52 <sdake> and is it one operator per microservice, or one operator for the whole schebang
16:35:52 <pprokop> not tied to openstack
16:36:04 <pprokop> you can spin up as many as you want
16:36:08 <sdake> i think we want more flexibility then a generic service may offer
16:36:22 <pprokop> this is just dependency resolver
16:36:34 <pprokop> in future it will be more
16:36:41 <berendt> o/ sorry i am late, i forgot the time changeover
16:36:43 <sdake> cool will take a look
16:36:45 <sdake> sup berendt
16:36:47 <rhallisey> ya same
16:37:31 <rhallisey> k inc0 continue on
16:37:32 <inc0> sdake, since you're on kubecon, ask around how people deal with these issues
16:37:38 <inc0> ok?
16:37:46 <sdake> inc0 i have
16:37:56 <sdake> the answer is microservices shouldn't hae dependencies
16:38:02 <sdake> which is wholy unsatisifying
16:38:05 <sdake> I come up with a simple example
16:38:07 <inc0> that's a perfectly useless answer
16:38:13 <inc0> good answer, but useless
16:38:20 <sdake> and they respond with something like "well microservices are hip!"
16:38:26 <rhallisey> ya there isn't a need to deal with complex apps
16:38:38 <sdake> there isn't at this point in time
16:38:40 <sdake> there will be in the future
16:38:53 <rhallisey> we'll we have mircro services, but they make up a complex app..
16:38:53 <inc0> unless we want to forget having database in k8s
16:38:57 <inc0> I'd say there is
16:39:00 <inc0> but meh
16:39:19 <inc0> who needs persistent data, that's soo 2000's
16:39:20 <sdake> inc0 i was speaking of the pOV of the kubernetes devs
16:39:27 <sdake> they are building "bulding blocks" atm
16:39:30 <sdake> inc0 not applications
16:39:39 <sdake> people that buidl applications have to actually solve these problems
16:39:47 <sdake> we are not building a buidling block, we are building an application
16:40:02 <sdake> hence their opinions don't take into account our requirements
16:40:08 <sdake> they take into account their requirements
16:40:22 <sdake> hence why kubernetes doesn't have built in dependencies
16:40:23 <inc0> which is dangerous on the long run
16:40:30 <sdake> there is a disconnect we can't fix in the short term atm
16:40:40 <sdake> inc0 agree completely (if you mean the disconnect)
16:40:46 <inc0> I do mean disconnect
16:40:50 <rhallisey> interesting
16:41:02 <rhallisey> sdake, glad you went and got to talk to some devs
16:41:05 <inc0> answer "don't do complex stuff" is not an answer
16:41:12 <sdake> rhallisey blame cisco for paying the bill :)
16:41:15 <portdirect> to play devils advocate: what deps do we need to account for? just the db and rabbit?
16:41:15 <sdake> inc0 right
16:41:24 <sdake> inc0 i am mostly listening not arguing with these guys
16:41:32 <sdake> inc0 i can be an asshat in openstack - people will tolerate that
16:41:37 <inc0> portdirect, nova depends on keysone, keystone depends on db
16:42:03 <sdake> inc0 but in a new community best to fly under radar and just listen in :)
16:42:05 <inc0> nova depends on existance of nova database in mariadb, nova user in keystone
16:42:09 <rhallisey> inc0, each service depends on another, which amplifies throughout the entire lifecycle
16:42:17 <sean-k-mooney> portdirect: another exampl the ovs agent depend on the ovs-vswitchd and that depends on the ovsdb
16:42:37 <sdake> portdirect there are hundresd of examples
16:42:40 <portdirect> :)
16:42:48 <sdake> the above is only a sampling ;)
16:42:49 <inc0> world without dependencies is beautiful world that does not exist
16:42:58 <sdake> inc0 lol starwars universe!
16:43:04 <sdake> rather star trek..
16:43:09 * sdake flounders for words
16:43:09 <inc0> all depends on the Force
16:43:13 <portdirect> sounds in space :)
16:43:18 <sdake> i meant star trek
16:43:23 <sdake> where there is no moey
16:43:26 <sdake> and everyone works for free ;)
16:43:27 <duonghq> rhallisey,  we have not addressed deps fully in kolla-ansible. too (IMO)
16:43:28 <srwilkers> independent applications, the final frontier
16:43:29 <rhallisey> there are not the dependencies you're looking for
16:43:39 <DTadrzak> sorry guys but i still don't understand why you dont want to use kubernetes-entrypoint to solve that problem
16:43:41 <inc0> ok, let's move on
16:43:43 <rhallisey> duonghq, how so
16:44:01 <inc0> DTadrzak, it's about what k8s community will do
16:44:03 <rhallisey> duonghq, maybe we can adress that in #openstack-kolla after
16:44:16 <duonghq> rhallisey, I mean cross-project dependency, agreed
16:44:23 <inc0> we don't want to sway for "the k8s way"
16:44:29 <inc0> as it will bite us at the end
16:44:32 <sdake> DTadrzak ithere is more to it
16:44:41 <rhallisey> DTadrzak, here's my opinion.  I don't like baking any dependency logic into the containers
16:44:56 <sdake> DTadrzak kfox (who isnt' here unfortunately) is not keen on entrypoint because it creates a self-assimilating system
16:45:00 <inc0> rhallisey, we don't technically bake it into containers
16:45:00 <rhallisey> super scary
16:45:08 <sdake> DTadrzak so if something goes wrong, it is impossible to diagnose
16:45:12 <sdake> and also impossible to correct
16:45:13 <inc0> we can bake mechanism into containers and pass deps in ENV or whatever
16:45:14 <rhallisey> inc0, the logic would exist in them
16:45:24 <pprokop> Wrong
16:45:31 <inc0> mechanism is fine to be there
16:45:33 <inc0> just a tool
16:45:33 <pbourke> I suppose in a real cloud native app they will manage the dependencies more gracefully
16:45:35 <portdirect> again playing devels advocate, my experience is that a roubust entrypoint mechanism is the solution (via init containers) as this gets round the self-assimilating problem
16:45:47 <portdirect> *a not the
16:45:47 <pbourke> e.g. nova will spin until it's entries in the db are ready
16:45:53 <pbourke> rather than fall over
16:45:56 <pprokop> Via job dependency
16:46:06 <rhallisey> portdirect, but then you need to solve all problem for all scenarios
16:46:09 <inc0> so algorithm with entrypoint is actually very elegant and super distributed
16:46:12 <pprokop> No
16:46:17 <sdake> it is super distributed
16:46:19 <inc0> I wanted to rewrite heat to use something of that sort;)
16:46:23 <sdake> it just doesn't work in practice
16:46:23 <pprokop> one just prepare a configurtion
16:46:25 <sdake> we tried it
16:46:26 <sdake> twice
16:46:28 <sdake> failed both times
16:46:33 <inc0> nah, it will work
16:46:35 <sdake> reference compose, reference kolla-mesos
16:46:40 <sdake> it works 19 time sout of 20
16:46:42 <inc0> if you have single source of truth
16:46:42 <pprokop> Stackanetes and fuel-ccp works that way
16:46:58 <sdake> pprokop ok, well they are not our reference architecture ;)
16:47:00 <pbourke> anyone want to explain entrypoint?
16:47:06 <inc0> neither compose or mesos used this model really
16:47:10 <sdake> and if they do work this way i htink they are probably unrelaible
16:47:19 <pprokop> github.com/stackanetes/kubernetes-entrypoint
16:47:29 <inc0> pbourke, idea is that when we start a pod there will be mechanism inside container
16:47:41 <inc0> that will loop and ask kubectl
16:47:43 <sdake> pprokop i think pbourke was looking for a 90 second elevator ptich not a dig into the repo thing :)
16:47:50 <pprokop> Okay
16:47:58 <pprokop> So entrypoint basically queries an k8s api
16:47:59 <inc0> "my deps are - mariadb pod ready, mariadb-boostrap job finished"
16:48:08 <portdirect> pbourke: essentially an init script that checks sanity before launching the container proper
16:48:11 <inc0> dear k8s, are both of these in state I want them to be
16:48:14 <pbourke> sounds good
16:48:14 <pprokop> to resolve dependencies before execing into proper application
16:48:22 <inc0> no = go to sleep for a moment and reiterate
16:48:26 <inc0> yes = move on with stuff
16:48:33 <portdirect> either using k8s api, or direcly testing the service
16:48:49 <sdake> right, so our model we are proceeding with is to do whatentrypoint does (in the nova-api container for e.g.)
16:48:52 <pbourke> but maybe too primitive?
16:48:52 <sdake> instead in an operator
16:48:52 <pprokop> We mixed it because we rely on k8s to report if something is ready
16:48:57 <inc0> gives you pretty elegant graph resolving mechanism
16:49:00 <pprokop> and we prepared a rediness probes
16:49:00 <sdake> for complete reliability
16:49:25 <sdake> the big issue for operators is diagnostics
16:49:39 <sdake> stuff that magically does magical dependency resolution is not debuggable according to kfox1111
16:49:40 <inc0> sdake, diagnostics is solvable with external toolsed
16:49:41 <inc0> toolset
16:49:43 <sean-k-mooney> entrypoints almost sound like they want to treat a pod like a fat contaienr with an init system like systemd ....
16:49:50 <sdake> inc0 not according to kfox1111
16:49:58 <sdake> sean-k-mooney you got it
16:49:58 <inc0> trust me on that, we can make it work
16:50:02 <pprokop> One just put entrypoint in init container
16:50:17 <pprokop> and you can see whats happening on k8s api
16:50:20 <sdake> the "new" model is operators to do this job with controllers
16:50:31 <sdake> the "last gen model" was to bake it into the container
16:50:37 <inc0> controllers sounds to me like this magical external thing
16:50:43 <sdake> according to the CNCF dudes at this conference
16:50:49 <inc0> which will be prone to race conditions and stuff
16:51:00 <rhallisey> inc0, ya but, entrypoint sounds like magical internal thing
16:51:04 <pprokop> still it introduces another orchestartion levels
16:51:19 <sdake> pprokop a controller is a plugin, we are using that plugin to do orchestration
16:51:20 <inc0> yeah, I agree with pprokop, this is just another abstraction layer
16:51:24 <rhallisey> inc0, it would use the kubeapi
16:51:31 <sdake> entrypoint is a plugin to docker, we arenot using that to do orchestration
16:51:45 <pprokop> i like to call it choreography
16:51:52 <inc0> lmao
16:51:57 <pprokop> each container is self aware of deps
16:51:59 <sdake> pprokop call it what you like its orchestration :)
16:52:03 <inc0> that's a word I've never heard in this context
16:52:03 <pprokop> nope
16:52:33 <DTadrzak> it's not an orchestration it is choreography
16:52:34 <sdake> ok well lets agree to disagree then
16:52:45 <sdake> i have never heard of this term
16:52:47 <inc0> whatever we call it
16:52:49 <sdake> i'll ask around
16:53:01 <rhallisey> ok anyway :)
16:53:07 <inc0> let's do PoC of both ok?
16:53:17 <sdake> here is the deal
16:53:17 <inc0> I'll try to break them and we'll see what breaks
16:53:27 <inc0> I like breaking distributed systems
16:53:47 <sdake> we can make something generic or we can pin ourselves into the back corner
16:53:53 <pbourke> sdake may be absolutely correct, we wont know till we try
16:53:58 <sdake> generic = operators
16:54:09 <sdake> entrypoint = back corner
16:54:14 <inc0> sdake, I disagree
16:54:18 <inc0> but again, PoC
16:54:19 <sdake> that is my opinion based upon 2 years of experience
16:54:50 <sdake> pbourke you have a keen point there
16:54:56 <sdake> pbourke i do know entrypoint model is not reliable
16:55:01 <sdake> i do not know if operator model is reliable
16:55:08 <sdake> that is why I am more keen to try it
16:55:12 <rhallisey> I'm in the same camp as sdake, but for me entrypoint = scary. I don't think ops will like it
16:55:13 <sdake> and back it with resources ;)
16:55:30 <rhallisey> yar
16:55:31 <inc0> and I disagree with it being unreliable:)
16:55:35 <rhallisey> Poc battle
16:55:45 <sdake> lets not fracture our own community guys
16:55:48 <inc0> and I'm operator myself
16:56:01 <inc0> this is good fracture to have for time being
16:56:08 <pprokop> I can give you a demo next week of entrypoint
16:56:09 <inc0> architecture of distributed systems i hard
16:56:14 <rhallisey> ya I find this to be productive
16:56:19 <sdake> pprokop i unerstand entrypoint, as Ie did this model in compose
16:56:20 <portdirect> lol - lets just try each and see which works out :)
16:56:21 <rhallisey> lots of perspectives
16:56:31 <inc0> sdake, it's totally different than what we had in compose
16:56:34 <sdake> there is another proble mwith entyrpoint
16:56:36 <inc0> *totally* different
16:56:40 <sdake> it requires non-generic containers
16:56:45 <rhallisey> ok ok
16:56:56 <rhallisey> let's roll over if we need to folks
16:57:00 <sdake> as in, they wont work with ansible...
16:57:01 <inc0> for one, you have single source of truth here
16:57:04 <rhallisey> we need to hit open discussion
16:57:05 <inc0> that is k8s
16:57:08 <rhallisey> and we have the spec still
16:57:22 <rhallisey> #topic Open Discussion
16:57:37 <inc0> this is *not* a compose and won't suffer from same problems
16:58:02 <inc0> race conditions in compose were caused by lack of reliable source of truth about state of our system
16:58:03 <portdirect> my work was based on the compose stuff you guys did
16:58:05 <sdake> inc0 if you say so :)
16:58:06 <inc0> and k8s will give us that
16:58:12 <rhallisey> ugh guys let's carry this over
16:58:19 <rhallisey> this will go on for dayzz
16:58:24 <inc0> yeah, we need to finish this meeting
16:58:26 <inc0> :)_
16:58:38 <inc0> any last remarks before we kill each other with sharp tools?
16:59:07 <inc0> guess not:) thanks all!
16:59:08 <srwilkers> and silence
16:59:13 <rhallisey> :)
16:59:14 <inc0> #endmeeting kolla