16:00:09 <Jeffrey4l> #startmeeting kolla
16:00:11 <openstack> Meeting started Wed Apr  4 16:00:09 2018 UTC and is due to finish in 60 minutes.  The chair is Jeffrey4l. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:14 <openstack> The meeting name has been set to 'kolla'
16:00:26 <Jeffrey4l> #topic rollcall
16:01:24 <duonghq> o/h
16:01:29 <spsurya__> 0/
16:01:32 <egonzalez> Woo/t
16:01:41 <caoyuan> o/h
16:01:53 <sadasu> hi
16:02:08 <bmace> o/
16:02:15 <pbourke> o/
16:02:44 <Jeffrey4l> #topic Announcements
16:03:07 <Jeffrey4l> kolla ocata 4.0.4 is release this week
16:03:21 <Jeffrey4l> any other announcement from community?
16:04:21 <Jeffrey4l> guess no, move on
16:04:31 <Jeffrey4l> #topic newton branch eol
16:04:55 <Jeffrey4l> openstack newton release is eol at 2017-10-25
16:05:16 <Jeffrey4l> and kolla newton is a little out of maintain. there is no patch recently at all.
16:05:51 <Jeffrey4l> so i propose mark it as eol and delete the branch tool
16:05:53 <Jeffrey4l> any idea on this?
16:07:18 <Jeffrey4l> ok, i will sync with release team and make this happen recently.
16:07:25 <Jeffrey4l> next
16:07:28 <Jeffrey4l> #topic retire kolla-kubernetes
16:07:41 <Jeffrey4l> this is talked on ML.
16:08:27 <Jeffrey4l> the core issue is still no contributor could lead this kolla-k8s.
16:08:48 <Jeffrey4l> so the current plan is still retrie this project now.
16:08:57 <Jeffrey4l> feel free to reply in the mail.
16:09:36 <Jeffrey4l> ok. there is no more agenda items.
16:09:44 <Jeffrey4l> #topic open discussion
16:10:08 <Jeffrey4l> any volunteer?
16:10:08 <pbourke> Jeffrey4l: there is some contention over my spec to move the start scripts to kolla-ansible
16:10:10 <duonghq> Jeffrey4l, iirc, kfox1111 is willing to help in next few months?
16:10:26 <sadasu> I am new to this community, but would it be a good idea to bring this up during the summit before retiring kolla-k8s?
16:10:35 <Jeffrey4l> duonghq, no. him move to other due to the company policy.
16:10:40 <pbourke> Jeffrey4l: I think we may need to propose a vote but Im not 100% on the mechanics of this
16:10:58 <duonghq> Jeffrey4l, got
16:11:21 <Jeffrey4l> pbourke, yeah, this should be well designed.
16:11:28 <duonghq> May I have two topics after Paul
16:11:36 <Jeffrey4l> duonghq, sure
16:11:49 <pbourke> it seems sdake feels very strongly about it, unsure if there's othrs
16:11:49 <Jeffrey4l> #link https://review.openstack.org/550958
16:11:53 <pbourke> *others
16:12:18 <Jeffrey4l> pbourke, i think we should start a ML to talk about this.
16:12:24 <spsurya__> pbourke: +1  for voting mechanism
16:12:32 <Jeffrey4l> what's the image should be , and should contains.
16:12:51 <pbourke> I can start a ML thread
16:13:11 <sdake> pbourke the main reawosn I Afeel strongly about it is - i feel it would lead to API degradation
16:13:21 <Jeffrey4l> one of issue i think is, promise we support other upstream images.
16:13:24 <sdake> but ya, ml better place to discuss
16:13:51 <pbourke> Jeffrey4l: well, its not so much a promise as making it easier to do so
16:14:30 <spsurya__> pbourke: Jeffrey4l what about wait for little more time before start any ML on retire ?
16:14:56 <Jeffrey4l> yeah, api is important. and the image should support some kind of API.
16:15:25 <Jeffrey4l> through all think to orchestration tool is hard to use.
16:15:41 <mgoddard> pbourke: I think most of what you want to do can be done via config.json, rather than bind mounting everything
16:15:45 <Jeffrey4l> spsurya__, what's your throught?
16:16:10 <spsurya__> Jeffrey4l: i discussed all around
16:16:42 <pbourke> mgoddard: only kolla images support config.json, that's the issue
16:16:47 <spsurya__> and i personally feel let it be as it is under kolla umbrella
16:17:03 <Jeffrey4l> but sure, we still have time.
16:17:10 <spsurya__> ans wait for more time
16:17:54 <spsurya__> rwellum: tried to fix the gate but that actually needed more patches in his thought
16:18:09 <pbourke> spsurya__: personally I think we've spent more than enough time talking about it
16:18:32 <Jeffrey4l> rwellum is quiting, too ;/
16:18:35 <sdake> mgoddard i agree
16:18:41 <sdake> pbourke config.json is the API :)
16:19:02 <Jeffrey4l> bare image (without any API) is hard to use.
16:19:11 <pbourke> i disagree, I think its easier
16:19:28 <sdake> easier isn't the issue, whether its a contract and loosley coupled in the issue
16:19:33 <sdake> as raised by the TC thread
16:19:41 <mgoddard> pbourke: I see. Could this be solved via a layer of abstraction? Some driver in k-a that encapsulates how files are placed into a container?
16:19:42 <spsurya__> pbourke: agree, but if gates is up then kolla might be supporting on kubrnetes too
16:19:46 <Jeffrey4l> even lots of upstream officical image support a "entrypoing.sh" file as entrance.
16:19:46 <sdake> we want loosley coupled + contract imo
16:20:14 <pbourke> spsurya__: there is not enough people to support it
16:20:14 <mgoddard> are other deployment tools using the config.json mechanism?
16:20:19 <pbourke> mgoddard: no
16:20:30 <pbourke> which is kind of a big deal imo
16:20:38 <pbourke> kolla is unique in this regard
16:20:49 <mgoddard> perhaps I should rephrase
16:20:50 <egonzalez> mgoddard tripleo does
16:20:55 <mgoddard> is tripleo using it
16:20:58 <mgoddard> ok, thanks
16:21:04 <Jeffrey4l> doesn't triplo use it?
16:21:14 <sdake> tripleo is using config.json
16:21:21 <mgoddard> yeah, I was really asking about users of kolla images
16:21:45 <Jeffrey4l> but they don't use kolla_logs folder.
16:21:50 <spsurya__> pbourke: yeah, we need only one strong contributor like kfox1111 sbezverk
16:22:05 <sdake> if you raad the long thread with the TC, the config.json exists to solve the problem of "how do people integrate with kolla images" without causing a bunch of problems
16:22:22 <sdake> that has worked well as other APIs have worked
16:22:27 <spsurya__> after that more or less we will have 4-5 contributors
16:22:51 <mgoddard> I read through the ML chain, just wasn't sure if all users of kolla images used config.json - it could easily be bypassed
16:22:52 <egonzalez> It needs to be documented for other projects to consume it but wfm
16:23:01 <sdake> egonzalez agreed docs would be good
16:23:04 <mgoddard> +1
16:23:12 <Jeffrey4l> docs +1
16:23:17 <sdake> mandre offered to write them iiuc :)
16:23:18 <pbourke> whats the benefit to this api though
16:23:29 <sdake> pbourke did you read the TC thread?
16:23:40 <sdake> the answer to your queestion is covered there
16:23:59 <pbourke> link?
16:24:19 <sdake> forgive the spam I don't have a link immediately:
16:24:21 <sdake> [...]
16:24:21 <sdake> The problems raised in this thread (tension - tight coupling -
16:24:22 <sdake> second class citizens - stratification) was predicted early on -
16:24:22 <sdake> prior to Kolla 1.0.  That prediction led to the creation of a
16:24:22 <sdake> technical solution - the Kolla API.   This API permits anyone to
16:24:23 <sdake> reuse the containers as they see fit if they conform their
16:24:24 <sdake> implementation to the API.  The API is not specifically tied to
16:24:25 <sdake> the Ansible deployment technology.  Instead the API is tied to the
16:24:26 <sdake> varying requirements that various deployment teams have had in the
16:24:27 <sdake> past around generalized requirements for making container
16:24:28 <sdake> lifecycle management a reality while running OpenStack services
16:24:29 <sdake> and their dependencies inside containers.
16:24:30 <sdake> [...]
16:24:31 <sdake> Thanks! That's where my fuzzy thought process was leading. Existence
16:24:32 <sdake> of a stable API guarantee rather than treating the API as "whatever
16:24:33 <sdake> kolla-ansible does" significantly increases the chances of other
16:24:34 <sdake> projects being able to rely on kolla's images in the long term.
16:24:35 <sdake> --
16:24:36 <sdake> Jeremy Stanley
16:24:48 <pbourke> yes I read that
16:25:05 <sdake> ok - that is why the config.json is needed
16:25:35 <pbourke> the config.json doesn't solve these things
16:25:58 <sdake> i disagree
16:26:12 <sdake> mailing list thread -> you can post  there your thoughts :)
16:26:57 <sdake> what you propose is treating the API as "whatever kolla-0ansible does"
16:26:59 <sdake> (in the spec)
16:27:13 <sdake> that is not highly regarded by the tc, which imo shouldn't be sticking their nose in this business anyway
16:28:08 <mgoddard> if we're looking to support other image types in kolla-ansible than the kolla images, why not add the support there, rather than changing the kolla API?
16:28:15 <pbourke> actually, config.json is making sure people have to follow whatever kolla-ansible does
16:28:25 <pbourke> its the exact opposite effect of what you're describing
16:28:30 <sdake> anyone is free to submit a config.json change
16:28:38 <pbourke> config.json lives in kolla-ansible
16:28:49 <sdake> config.json API lives in containers
16:28:52 <Jeffrey4l> pbourke, if we have doc, people won't care about how kolla-ansible does
16:28:53 <pbourke> wrong!
16:29:12 <sdake> the actual values in config.json are speciied in kolla-ansible, i agree with that
16:29:20 <mgoddard> there needs to be some contract between the image and the tool, config.json or otherwise. This will always be defined by the image
16:29:21 <sdake> the API is within the ontainers - APIs consume the config.json as an input
16:29:51 <sdake> anyway I'm not going to get into a heated debate in irc, use the mailing list if you wish to disagree
16:30:22 <Jeffrey4l> ok, this will be critial spec for kolla. let us continue this on ML. irc is hard to talk ;)
16:30:32 <Jeffrey4l> pbourke, could you start a new ML for this?
16:30:50 <pbourke> Jeffrey4l: will do, I think the current one has a bit too much going on
16:31:34 <Jeffrey4l> thanks.
16:31:38 <Jeffrey4l> next topic,
16:31:40 <pbourke> one last thing before I forget :)
16:31:53 <pbourke> can some core other than myself please approve yankcrime's haproxy review
16:32:03 <pbourke> he's been very patient with it i think :)
16:32:11 <Jeffrey4l> pbourke, i have approved it :D
16:32:15 <pbourke> great!
16:32:17 <pbourke> thanks
16:32:31 <Jeffrey4l> and thanks yankcrime
16:32:48 <Jeffrey4l> duonghq, your turn
16:33:02 <duonghq> Jeffrey4l, thanks
16:33:20 <duonghq> the first and the simple one is in the patch: https://review.openstack.org/#/c/532128/
16:34:09 <duonghq> As I need more variables passed to the extend_start script for rolling upgrade, I think Trinh's suggestion is a good option
16:34:35 <duonghq> but it requires changing quite large code base
16:34:50 <duonghq> so I need other developers' opinion
16:36:01 <Jeffrey4l> this is one place i wanna kolla(image) should be improve through pbourke's spec :)
16:36:15 <Jeffrey4l> need a easier way to run some simple bash script.
16:37:34 <duonghq> but I seem that we need quite long discussion about this topic, I think I'll continue with rolling upgrade with extend_script as it
16:37:41 <duonghq> *it seems
16:38:44 <spsurya__> duonghq: may be atm i have not heavily been able to help on upgrade thing....but very soon i will be there to help
16:38:48 <pbourke> duonghq: will take me some time to get up to speed on that review, will post comments after the meeting
16:39:32 <duonghq> spsurya__, pbourke, thanks
16:39:37 <Jeffrey4l> duonghq, i will review it too.
16:39:49 <duonghq> and I'll the extend script logic untouch
16:40:18 <duonghq> Jeffrey4l, thank, I wish that we can finish to implement rolling upgrade logic for all core services in this cycle
16:40:27 <duonghq> and it'll need much review effort
16:41:04 <duonghq> and much more effort to implement the logic correctly, so I appreciate all comments and help
16:41:22 <Jeffrey4l> yeah
16:41:26 <spsurya__> duonghq: i will start for nova and swift
16:41:41 <duonghq> spsurya__, I pushed 2 patchsets for nova
16:41:52 <duonghq> will add you to reviewers list
16:42:43 <spsurya__> duonghq: ok
16:43:02 <duonghq> so, can we move to the next topic from me?
16:43:25 <Jeffrey4l> sure
16:43:32 <duonghq> #link https://blueprints.launchpad.net/kolla-ansible/+spec/ansible-specific-task-become
16:43:45 <duonghq> last week I posted this bp status to meeting
16:44:01 <duonghq> so if nobody has any comments on it, can we mark it as finished?
16:44:30 <Jeffrey4l> duonghq, should we use "become" for kolla_docker modules?
16:45:15 <Jeffrey4l> as normally user can not connect docker.sock
16:45:29 <Jeffrey4l> it's permission is "root:docker"
16:46:17 <duonghq> let me recheck it tomorrow
16:46:39 <Jeffrey4l> okay
16:46:46 <yankcrime> yeah thanks again to Jeffrey4l and pbourke for being patient with my change also :)
16:46:50 <duonghq> or we just need to add the user to docker group?
16:47:04 <duonghq> which option do your prefer?
16:47:14 <Jeffrey4l> duonghq, no. become should be better.
16:47:36 <Jeffrey4l> we can not ensure the user is a member of docker group.
16:48:23 <duonghq> I think the real question is which is better: we tried to add the user to the docker group, or just leave the user as it and apply "become" on it
16:48:45 <Jeffrey4l> i prefer to use "become" like other tasks.
16:49:40 <duonghq> ok, but how about you, pbourke, spsurya__ ....
16:49:51 <duonghq> "become" seems more secure
16:50:32 <pbourke> become is probably most consistent as there are some operations outside docker that need root regardless
16:50:54 <spsurya__> duonghq: i also see *become* is there for other task
16:51:01 <spsurya__> ans that should be fine
16:51:15 <duonghq> ok, thank you
16:51:39 <duonghq> sorry for rush but I have one more topic, if we can finish on it, I'll  move to the next, about 8mins left
16:52:54 <duonghq> thank Jeffrey4l, pbourke, spsurya__ for comment about ansible-become
16:53:17 <Jeffrey4l> np. next?
16:53:37 <duonghq> my next topic is about kolla-cli, do you want to discuss in this week or push to next meeting?
16:54:19 <pbourke> we can start now and continue next meeting if needed
16:54:22 <bmace> i don't know how much else is on the agenda or how long you expect the discussion to take.  we can talk in the kolla channel after also if you want
16:54:38 <Jeffrey4l> or continue in kolla channel ;D
16:54:41 <duonghq> as we have kolla-cli in official repository, so I think we should make the commands in kolla-cli more usable, for example, add node and remove node
16:55:05 <duonghq> currently, it just manipulate the inventory file
16:55:06 <bmace> so just a nomenclature thing? node instead of host?
16:55:39 <pbourke> maybe we should get a state of the union type thing for kollacli before we discuss changing commands etc?
16:55:51 <duonghq> yeah, node, due to I'm opeing the Jeffrey4l's bp https://blueprints.launchpad.net/kolla-ansible/+spec/remove-node
16:56:23 <pbourke> i.e. is it usable yet with current kolla code right now, what tasks are currently high priority?
16:56:48 <duonghq> pbourke, my point is deployment "topo" can be changed in production, as it real requirement (e.g. remove node, remove service,....)
16:56:59 <duonghq> but remove node is more than just remove the node from inventory file
16:57:01 <bmace> i can add some kolla-cli bp, but right now there are still some "oracleisms" in it that i'm working on removing.  my goal is to have it working in the kolla-ansible vagrant dev environment asap
16:57:06 <pbourke> duonghq: ah I see
16:57:21 <pbourke> bmace: sounds good :)
16:57:45 <bmace> for other stuff, i think we can add kolla-cli blueprints as well, duonghq, and discuss those then?
16:57:46 <duonghq> bmace, thank for it, but in the mean time, should we implement the lacking logic in kolla-ansible?
16:57:54 <Jeffrey4l> duonghq, even though that pb is mine. what i want is just improve current destroy logical.
16:58:11 <Jeffrey4l> remove service or node need more tasks
16:58:32 <duonghq> bmace, sure, we have project kolla-cli in launchpad, just add something there and link back to the related-one in kolla-ansible
16:58:47 <duonghq> Jeffrey4l, that's my point
16:58:55 <duonghq> but it's real requirements from operator
16:59:21 <duonghq> should we try to do something in this cycle, but I don't want to overload our pending bp list
16:59:32 <Jeffrey4l> mostly , shutdown the node works lol
16:59:47 <duonghq> if we can shutdown the node, it's the best case
17:00:12 <Jeffrey4l> at least i'd like to improve current destroy action.
17:00:14 <duonghq> but if the node is turn on accidently, some ghost will walk in our life
17:00:22 <Jeffrey4l> ok. time is up. let us back to openstack-kolla channel.
17:00:27 <duonghq> kk, thanks
17:00:29 <Jeffrey4l> thanks for comming,
17:00:38 <Jeffrey4l> have a nice day&night
17:00:41 <Jeffrey4l> #endmeeting