16:00:04 <adrian_otto> #startmeeting containers
16:00:05 <openstack> Meeting started Tue Nov 10 16:00:04 2015 UTC and is due to finish in 60 minutes.  The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:09 <openstack> The meeting name has been set to 'containers'
16:00:14 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Containers#Agenda_for_2015-11-10_1600_UTC Our Agenda
16:00:26 <adrian_otto> #topic Roll Call
16:00:29 <vilobhmm> o/
16:00:29 <adrian_otto> Adrian Otto
16:00:30 <Drago> o/
16:00:35 <hongbin> o/
16:00:36 <wanghua> o/
16:00:36 <muralia1> murali allada
16:00:37 <rlrossit> o/
16:00:41 <rpothier> o/
16:00:44 <Kennan> hi /o
16:00:48 <Kennan> o/
16:00:50 <juggler> o/
16:01:21 <sew2> o/
16:01:22 <adrian_otto> hello vilobhmm, Drago, hongbin, wanghua, muralia1, rlrossit, rpothier, Kennan, and juggler
16:01:29 <jasonsb> hi
16:01:31 <muralia1> hi all
16:01:44 <Kennan> hi
16:01:47 <vilobhmm> hello adrian_otto, hello all
16:01:52 <adrian_otto> hello sew2, jasonsb
16:01:54 <wanghua> hi all
16:01:59 <wznoinsk> hi
16:02:25 <juggler> hello all
16:03:02 <adrian_otto> #topic Announcements
16:03:10 <adrian_otto> any announcements form team members?
16:03:46 <eliqiao> o/
16:04:19 <adrian_otto> s/form/from/
16:04:23 <adrian_otto> ok, on to action items.
16:04:48 <adrian_otto> #topic Review Action Items
16:04:49 <adrian_otto> (none)
16:05:04 <adrian_otto> #topic Blueprint/Bug Review
16:05:18 <Kennan> hi adrian_otto
16:05:20 <adrian_otto> so this week I will be arranging all our BP's for Mitaka release
16:05:23 <Kennan> it seems have a review action
16:05:36 <adrian_otto> hi Kennan, which should we look at together?
16:05:59 <Kennan> Add filters support to api https://review.openstack.org/#/c/239362/
16:06:04 <adrian_otto> I'm seeking input from the team for essential BP's for this release cycle
16:06:04 <wanghua> I have one
16:06:07 <Kennan> this is review from wanghua
16:06:07 <wanghua> Yes
16:06:32 <eliqiao> that one need to implyment on api micro-verison
16:06:39 <adrian_otto> ok, Kennan, thanks for raising that. Let's get to that one in just a moment.
16:06:56 <adrian_otto> we'll touch base quickly on blueprints first
16:07:06 <Kennan> sure
16:07:42 <adrian_otto> so the question I'd like everyone's help with is what bp's should be marked as Essential, and tracked every week in our team meetings through completion.
16:08:11 <adrian_otto> if you have ones that you think should be marked in that way, you are welcome to set them accordingly, or identify them for me, and I can set them.
16:08:50 <hongbin> I think we need to identify a list of Mitaka first
16:08:51 <adrian_otto> normally we have our subteams report back, and they tend to hold the highest priority items
16:09:04 <adrian_otto> come to think of it, I did that out of order this time.
16:09:15 <eliqiao> should we put them here? or just set the approver as you adrian_otto.
16:09:39 <hongbin> Correction: I think we need to identify a list of BPs for Mitaka first
16:09:49 <adrian_otto> hongbin: fair enough. So if you have BP's that you are sure should be included in Mitaka, mark me as the approver, and we'll get those scoped over the next few days.
16:09:50 <eliqiao> I would suggest that we create an etherpad to tracking them.
16:10:04 <adrian_otto> eliqiao: ok, I'll make one now One moment.
16:11:06 <Kennan> do we set all Mitaka bps in this meeting ?
16:11:13 <adrian_otto> #link https://etherpad.openstack.org/p/mitaka-magnum-planning Magnum Mitaka Planning
16:11:24 <adrian_otto> no, this will not be a final list today
16:11:36 <adrian_otto> this is a way for us to share input as a team early in the cycle
16:13:20 <adrian_otto> great, so we have that kicked off. You are welcome to add to that bp after we conclude today as well, and we can true it up next time we meet.
16:13:30 <rods> hi all
16:14:05 <adrian_otto> let's go to subteam updates in the mean time, and I'll come back to reviews/bugs after that so we can discuss https://review.openstack.org/239362
16:14:19 <adrian_otto> hi rods
16:15:41 <adrian_otto> daneyon is not here, so I might skip "Container Networking Subteam Update"
16:16:20 <adrian_otto> we did not hold a meeting on Thursday due to confusion between UTC and local time after our recent DST shift
16:16:28 <adrian_otto> we can revisit that next time
16:16:43 <adrian_otto> bradjones|away: seems away
16:16:50 <adrian_otto> anyone have an update for "Magnum UI Subteam Update"
16:16:51 <adrian_otto> ?
16:18:47 <adrian_otto> ok, looks like our planning etherpad is taking form, so let's discuss reviews.
16:18:57 <adrian_otto> Kennan, you're up for this one:
16:18:59 <adrian_otto> #link https://review.openstack.org/239362
16:19:18 <adrian_otto> or that was wanghua's
16:19:27 <Kennan> hi adrian_otto
16:19:32 <Kennan> it is a change from wanghua
16:19:47 <Kennan> he implements feature to allow magnum cli add filters part
16:20:08 <Kennan> the filters mainly work for magnum db objects ,like pod, service etc.
16:20:13 <eliqiao> I think we need this change.
16:20:35 <Kennan> but another feature vilobhmm
16:20:46 <eliqiao> but I am thinking about if it should be implymented based on micro-version(since we have supported it)
16:20:47 <adrian_otto> I see in the comments that you have a concern about the impact on another contribution:
16:20:49 <adrian_otto> #link https://review.openstack.org/213368
16:20:58 <Kennan> implements now is native tool retrieve directly from backends
16:21:23 <Kennan> which can make db features override the two seems conflict to me
16:22:06 <vilobhmm> so the basic question boils down to…do we need to have the information for k8s objects stored in db or fetch directly from k8s backend
16:22:21 <wanghua> I think we need store pod, service in db, too
16:22:34 <vilobhmm> fetch directly from k8s backend - https://review.openstack.org/#/c/213368/
16:22:48 <vilobhmm> information for k8s objects stored in db - https://review.openstack.org/239362
16:22:50 <adrian_otto> vilobhmm: our intent was to have a single source of truth, rather than dealing with synchronization
16:23:00 <vilobhmm> adrian_otto : agree
16:23:03 <adrian_otto> is there a reason this is not practical?
16:23:53 <eghobo> adrian_otto: +1, we agreed don't keep kub state in magnum
16:24:09 <vilobhmm> eghobo : +1
16:24:16 <madhuri> +1
16:24:21 <Kennan> adrian_otto: if that case, seems db filter feaure not needed
16:24:34 <adrian_otto> in general, we should not, but that guidance should not be absolute if there is a very good reason why we should be mirroring something in magnum
16:24:45 <juggler> +1
16:25:11 <adrian_otto> so let's view that as a preference to keep only one copy of relevant state, but to be willing to duplicate it when justified
16:25:37 <adrian_otto> so that's what I'm probing for now
16:25:43 <eghobo> adrian_otto: sorry I was late, but what is the reason?
16:25:55 <adrian_otto> we have not identified one yet
16:25:55 <wanghua> If we don't store some k8s infos in db, the user need to give the bay to show the pod, like magnum pod-show pod-id bay-id
16:26:05 <wanghua> I think  it is wired.
16:26:23 <eghobo> sorry disagree
16:26:27 <vilobhmm> wanghua : but why is that weird ?
16:26:35 <adrian_otto> ok, good. that's what this discussion is for!
16:26:37 <eghobo> in kubctl you have to provide pod name
16:27:06 <eghobo> i think user need to do two commands
16:27:07 <wanghua> but we should know which bay the pod belongs to
16:27:53 <eghobo> magnun get pods bayid and magnun show pod pod_name bayid
16:28:26 <eghobo> wanghua: it's correct but user can have many bays
16:28:39 <eghobo> and many pods with the same name
16:28:59 <wanghua> yes, but pod-id is unique
16:29:00 <adrian_otto> in k8s you just have a single pod list. In magnum, there are multiple lists (by bay)
16:29:36 <Kennan> seems k8s use namespace to separate resources
16:29:47 <vilobhmm> Kennan : yup
16:29:59 <eghobo> adrian_otto: yes, I and I think we should require bayid everywhere
16:30:02 <madhuri> Kennan: Yes
16:30:44 <eghobo> Kennan: typical usecase for namespace for example is environment: PROD, DEV, QA
16:30:46 <hongbin> eghobo: sounds like a candidate to turn into a BP: require bayid everywhere
16:30:58 <adrian_otto> if the concern is simplifying the client… we do have a possible optimization we could make. We could allow the client to fetch the bay_id from a shell env variable. That way the user could set that, and not have to supply it for every command as long as it is set.
16:31:19 <vilobhmm> hongbin : its already in progress
16:31:27 <eghobo> adrian_otto: +1
16:31:41 <Tango> What about call from API?
16:31:47 <Tango> REST API
16:31:48 <madhuri> adrian_otto: +1
16:31:55 <vilobhmm> adrian_otto : +1
16:31:57 <adrian_otto> Tango: in that case it could be placed into the context by the user
16:31:58 <hongbin> Yes, the environmental variables approach sound good.
16:32:07 <Kennan> wanghua: do you have other comments for that ? I think most of your patch fetch info from db part
16:32:16 <adrian_otto> but for API usage I think it's better simply to require the bay-id
16:32:29 <vilobhmm> Tango : API receives both bay_identifier and pod identifier and then makes call to conductor to fetch entries from k8s endpoint
16:32:44 <wanghua> If we can automatically fetch the bay id, I think it is ok
16:33:16 <adrian_otto> wanghua: let's be careful to try to keep the API implementation as stateless as we reasonably can
16:33:18 <Tango> vilobhmm: thanks
16:33:33 <eghobo> wanghua: could you elaborate about it?
16:33:35 <adrian_otto> let's not have "magic" in the API
16:33:44 <vilobhmm> adrian_otto : +1
16:33:47 <Kennan> ok. it seems your bp can be dropped if vilobhmm can implements his bp(fetch from k8s backends)
16:33:52 <adrian_otto> and not hold server side state that will not scale out efficiently
16:34:01 <vilobhmm> stateless api r better
16:34:49 <wanghua> Kennan: I will drop my bp
16:34:59 <adrian_otto> ok, so are we at a consensus point now?
16:35:51 <Kennan> I am ok if finally fetch from k8s endpoints performance not bad. of course, it needs more test :0
16:36:02 <adrian_otto> let's mark the direction in the respective Gerrit reviews to offer guidance to reviewers
16:36:43 <adrian_otto> Kennan: that would be a reasonable justification for mirroring data in Magnum, of we are unable to overcome performance constraints.
16:36:53 <adrian_otto> s/of/if/
16:36:58 <eghobo> Kennan: performance should be fine, Kub folks are very religious about keeping response time under 1 sec ;)
16:37:33 <adrian_otto> as long as we are only making a single connection to k8s to fetch what we need, then performance is unlikely to inhibit us
16:37:39 <vilobhmm> adrian_otto, Kennan : I tried my chnages in devstack for obj-from-bay for rc…and I could not see considerable difference http://paste.openstack.org/show/478215/ I can time the request and update the review with before and after for close inspection
16:37:48 <adrian_otto> if we need to make a whole bunch of requests, then we may need to revisit the approach
16:38:17 <vilobhmm> adrian_otto : we are making a single connection
16:38:22 <adrian_otto> thanks vilobhmm
16:38:24 <Kennan> wanghua thanks for your previous work, I raise your review here just because vilobhmm bp have some conflicts with your bp. :)
16:38:46 <adrian_otto> ok, are we all happy with this for now?
16:38:58 <madhuri> +1
16:39:02 <vilobhmm> +1
16:39:06 <Kennan> +1
16:39:11 <wanghua> +1
16:39:11 <Tango> +1
16:39:20 <adrian_otto> great.
16:39:43 <adrian_otto> so we have time to look at other work together as a team before we proceed to Open Discussion
16:40:02 <adrian_otto> anyone have bugs/reviews/bp's to raise for team discussion today?
16:40:05 <juggler> +1
16:40:23 <eliqiao> adrian_otto: I have issue to create bay on gate.
16:40:34 <eghobo> I have one question about this big renames https://review.openstack.org/#/c/243413/
16:40:46 <hongbin> I have one to discuss (after eliqiao )
16:40:49 <madhuri> eghobo: +1
16:40:53 <eghobo> can somebody provide reason?
16:41:00 <adrian_otto> ok, let's take eliqiao first. Please elaborate.
16:41:07 <eliqiao> okay.
16:41:41 <eliqiao> adrian_otto: 1 for swarm functional testing, bay created failed on gate, debuged into it , found vm failed to start docker service.
16:42:04 <vilobhmm> eliqiao : do you have a link for the failure ?
16:42:05 <adrian_otto> ok
16:42:14 <wanghua> Can it work in your local env
16:42:19 <eliqiao> #link https://review.openstack.org/#/c/226125/
16:42:24 <vilobhmm> thanks!
16:42:27 <eghobo> eliqiao: check volume config
16:42:33 <eliqiao> wanghua: yeah, it works on my local setup.
16:42:45 <adrian_otto> perhaps the available storage is to small?
16:42:51 <adrian_otto> s/to/too/
16:43:22 <hongbin> Yes, I would suggest to ture the cinder volume into 5G and tried again
16:43:23 <wanghua> I find that the gate may fail even if your patch is ok sometimes.
16:43:38 <eliqiao> the docker serivce log #link http://logs.openstack.org/25/226125/27/check/gate-functional-dsvm-magnum-k8s/125998a/logs/bay_nodes/172.24.5.6/docker.txt.gz
16:44:08 <adrian_otto> ok, so let's take that one to #openstack-contaienrs after the team meeting to help understand the cause
16:44:20 <eliqiao> ok.
16:44:34 <hongbin> I have one to disuss
16:44:43 <muralia1> adrian_otto: I have one more thing to talk about. https://review.openstack.org/#/c/232152
16:44:47 <adrian_otto> #link https://review.openstack.org/243413 Renamed the heat-kubernetes and heat-mesos
16:44:50 <hongbin> adrian_otto: I think Magnum has a liberty release? Then this review is wrong https://review.openstack.org/#/c/242068/
16:44:56 <adrian_otto> eliqiao: you had remarks on this one?
16:45:06 <Kennan> eliqiao: I suspect it was because volume size
16:45:23 <Kennan> in our jenkins default volume size is 1GB ?
16:45:26 <eghobo> eliqiao: Daneyon had similar problem, just check it's really latest fedora 5
16:45:32 <eliqiao> okay, thanks guys, will try to make volume size bigger.
16:45:37 <adrian_otto> hongbin: we do have a beta, but I need to release that as a final
16:45:46 <Kennan> for k8s the docker storage has mini requirements 2GB
16:45:47 <hongbin> adrian_otto: ack
16:46:01 <Kennan> you can set 4GB if jenknis have enough storage
16:46:04 <adrian_otto> we had a couple of patches backported on that branch that need to be included.Renamed the heat-kubernetes and heat-mesos
16:46:14 <adrian_otto> s/Renamed the heat-kubernetes and heat-mesos//
16:46:44 <madhuri> adrian_otto: I don't find any good reason to rename it
16:47:07 <wanghua> heat-kubernetes, heat-mesos, docker-swarm
16:47:21 <adrian_otto> is Shravya Gaddam present today?
16:47:21 <wanghua> I think we should add heat to all, or not to all
16:47:50 <wanghua> This bug is proposed by me...
16:48:08 <adrian_otto> ok, it is a heat template
16:48:10 <Kennan> seems heat-docker-swarm ? if consider consistence
16:48:15 <adrian_otto> which is why that's in the filename
16:48:39 <Kennan> or heat-dockerswarm
16:48:57 <adrian_otto> but all of this came from one thing...
16:48:57 <wanghua> They are all under templates dir. So they must be a template.
16:49:04 <adrian_otto> the heat-kubernetes project name
16:49:17 <leecalcote> wanghua: agreed. whether "heat" stays or is removed, it'd be nice to remove "docker" and shorten docker-swarm to "swarm". In this way, each of the COEs are one word references.
16:49:20 <adrian_otto> it probably would have made sense to call that "kebernetes" to begin with
16:49:43 <adrian_otto> and others with heat- in the name are attempt to confirm with that name scheme
16:49:58 <eghobo> i think it's better remove heat prefix, because we have even diskbuilder elements inside
16:50:11 <wanghua> We only use heat, no other methods.
16:50:27 <wanghua> So I think it is not necessary to add heat in the name
16:50:44 <adrian_otto> eghobo: I do agree, and as long as this change is not disruptive I don't see a reason to oppose it.
16:50:50 <madhuri> Make sense
16:51:10 <juggler> did you mean kubernetes not kebernetes above? :)
16:51:10 <hongbin> My concerns is if the renaming will affect the git history
16:51:10 <eliqiao> +1
16:51:33 <adrian_otto> hongbin: this is done with a git rename, so that should not wipe history.
16:51:48 <adrian_otto> but it could cause other patches to need a rebase
16:52:09 <Kennan> I am with rename, as both seems readable for me
16:52:14 <adrian_otto> so it could slow down merge of work on code within these directories
16:52:42 <adrian_otto> I'll open up for Open Discussion now
16:52:52 <adrian_otto> #topic #open-discussion
16:53:02 <vilobhmm> adrian_otto : IMHO security was a priority in liberty (with TLS and other  imp features that went in for liberty) do we have something of that sort which we are planning for mitaka ?
16:53:31 <adrian_otto> seemed that we have a lose consensus to support the rename proposed in https://review.openstack.org/243413
16:53:33 <vilobhmm> asking this so that we can align the blueprints in that direction
16:53:39 <adrian_otto> s/lose/loose/
16:54:05 <hongbin> I am OK for the rename.
16:54:17 <Tango> +1 on rename
16:54:18 <vilobhmm> +1 from me to..
16:54:20 <adrian_otto> vilobhmm: yes. We held a design session on that topic, and decided we'd like to see further progression there.
16:54:39 <leecalcote> yes - +1 on rename. It would be good to consider removing "docker", too.
16:54:48 <adrian_otto> resolving issues with Barbican and allowing for secret storage through an abstraction
16:54:55 <leecalcote> or put "apache" in front of mesos...
16:55:05 <Kennan> seems native featch from backend need to use TLS related vilobhmm: if I get it correctly
16:55:16 <adrian_otto> leecalcote: nah, one word is fine
16:55:41 <juggler> +1 for the rename
16:55:44 <vilobhmm> adrian_otto : thanks! Kennan : Yes it will
16:55:46 <adrian_otto> vilobhmm: we really dislike having passwords in our configuration files, and would really like to avoid that.
16:56:13 <adrian_otto> so any approach that would free us from that requirement would be welcome
16:56:22 <eghobo> +1 for rename, but with proper explanation why in commit message ;)
16:56:39 <Kennan> adrian_otto some passwords like tenant password seems in other openstack projects ?
16:56:45 <vilobhmm> adrian_otto : sure
16:57:03 <adrian_otto> Kennan: no, like the magnum API password on the bay nodes
16:57:18 <eghobo> Kennan: +1, we need to remove passwords
16:57:42 <adrian_otto> so the entire subject of credentials management is something I'd like to mature in Magnum
16:57:51 <juggler> agree eghobo...it seems https://bugs.launchpad.net/magnum/+bug/1514682 could have just a tiny bit more detail about why it's being renamed
16:57:51 <openstack> Launchpad bug 1514682 in Magnum "Rename heat-kubernetes to kubernetes, heat-mesos to mesos" [Undecided,In progress] - Assigned to Hua Wang (humble00)
16:58:26 <adrian_otto> we have just a minute remaining, so let's wrap up
16:58:35 <Kennan> adrian_otto: ok I need check other core projects, seems only we use barbican, so we remove them ?
16:58:46 <adrian_otto> oh, I forgot
16:59:03 <adrian_otto> I will be traveling next week, and would like help to chair the meeting
16:59:08 <adrian_otto> contact me if you can help
16:59:25 <adrian_otto> 50% chance I can attend next week
16:59:27 <hongbin> adrian_otto: I can chair the meeting
16:59:36 <adrian_otto> thanks hongbin!
16:59:49 <juggler> awesome h
17:00:02 <Kennan> adrian_otto: I checked  nova related config still use password in text
17:00:04 <adrian_otto> our next team meeting is 2015-11-17 at 1600 UTC. Hongbin will chair. Thanks!!
17:00:12 <Kennan> ok it maybe barbican related
17:00:13 <adrian_otto> #endmeeting