09:58:58 <strigazi> #startmeeting containers
09:58:59 <openstack> Meeting started Tue Jun 12 09:58:58 2018 UTC and is due to finish in 60 minutes.  The chair is strigazi. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:59:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:59:03 <openstack> The meeting name has been set to 'containers'
09:59:04 <strigazi> #topic Roll Call
09:59:15 <strigazi> o/
09:59:19 <brtknr> o/
09:59:56 <flwang1> o/
10:00:49 <strigazi> Thanks for joining the meeting brtknr flwang1 :)
10:00:51 <strigazi> #topic Announcements
10:01:04 <ricolin> 0/
10:01:05 <strigazi> Magnum is on storyboard \m/
10:01:20 <ricolin> Yay
10:01:21 <brtknr> strigazi: Hurrah! Including blueprints>
10:01:34 <brtknr> s/>/?
10:01:48 <strigazi> I also moved the bps. Need to reset some statuses
10:02:06 <strigazi> eg, this was a BP https://storyboard.openstack.org/#!/story/2002210
10:02:08 <ricolin> That way we can setup cross project task cross Heat and magnum
10:02:37 <strigazi> brtknr: the problem is that what did was:
10:03:02 <strigazi> bp_status -> story_status -> task_status
10:03:28 <strigazi> but story_status is implicit and the status info got lost in the way
10:03:46 <ricolin> Here is an Etherpad I build for Heat most information also apply in magnum as well
10:03:50 <ricolin> https://etherpad.openstack.org/p/Heat-StoryBoard-Migration-Info
10:04:12 <strigazi> stotyboards client is pretty sweet so I'm scripting it again
10:04:18 <strigazi> thanks ricolin
10:04:55 <strigazi> questions about story board?
10:05:37 <strigazi> #topic Blueprints/Bugs/Ideas
10:06:46 <strigazi> I pushed a patch for uprgades, you can have a a look in the story above
10:07:19 <strigazi> oh, it is not there, I didn't add the task, but here it is:
10:07:24 <flwang1> strigazi: thanks, but i can see the new api to list the valid versions can be upgraded to
10:07:27 <strigazi> #topic Blueprints/Bugs/Ideas
10:07:30 <strigazi> #topic Blueprints/Bugs/Ideas
10:07:34 <strigazi> https://review.openstack.org/514959
10:08:15 <strigazi> flwang1: which api? list versions?
10:08:34 <flwang1> strigazi: yes
10:09:32 <strigazi> We don't have such thing in the spec, users can see versions in cluster templates
10:10:06 <flwang1> ok, we can discuss it offline
10:10:33 <strigazi> ok, this is the api side
10:10:38 <strigazi> on the driver side,
10:11:01 <strigazi> I have some issues when replacing nodes
10:11:23 <strigazi> We are setting the node name so:
10:12:03 <strigazi> 1. the k8s cloud provider complains that it sees many nodes with the same name
10:12:31 <strigazi> 2. in clouds that the nova name matche dns name, vm creation won't work
10:12:59 <strigazi> does these two make sense?
10:13:06 <strigazi> s/does/do
10:13:43 <brtknr> yes
10:14:23 <flwang1> strigazi: do we have to use the same name?
10:14:27 <strigazi> So, we need to change the name if we want heat to do the rolling replacement magic
10:15:01 <strigazi> flwang1: we don't but right now we do
10:15:08 <flwang1> ok
10:15:11 <strigazi> flwang1: and it is more user friendly
10:15:27 <flwang1> i don't really think it's user friendly
10:15:31 <ricolin> Is that the same thing that we talk about easier?
10:15:33 <flwang1> it could be confusing
10:15:39 <strigazi> for users to see <cluster-name>-some-ids
10:15:47 <strigazi> ricolin: yes
10:17:05 <strigazi> flwang1: you this name is better ku-jamh4gh6zb-0-uwgdrnyx3azd-kube-master-vnzxh43pokl4 than
10:17:09 <ricolin> I’m thinking maybe we can have a Pre-action before  update replace forSD
10:17:38 <strigazi> this one strkube-scanner-ne7at5fdzfhy-master-0
10:17:48 <strigazi> my cluster is named strkube-scanner
10:18:03 <flwang1> no, i mean only change the random id part
10:18:13 <flwang1> we should still use the cluster name as the prefix
10:18:23 <strigazi> we need something random
10:18:39 <flwang1> we can discuss offline
10:18:58 <strigazi> ricolin: there are two things
10:19:56 <strigazi> ricolin: one is the name issue the other is the SD dependency which I think it is not a problem  in the end, I think it was an issue because of the nameing bug
10:20:34 <strigazi> I'll propose something in the storyboard we can take it there
10:21:02 <strigazi> This is it from me, last week was upgrades and storyboard
10:21:03 * ricolin using my phone so can’t really type fast:)
10:21:35 <strigazi> flwang1: go next?
10:21:42 <flwang1> sure
10:21:52 <flwang1> i'm working on many things recently
10:22:05 <strigazi> I saw, that is awesome
10:22:11 <strigazi> thanks :)
10:22:34 <flwang1> 1. the keystone k8s integration, lingxian has done a great job to support configmap for k8s-keystone-auth
10:23:00 <flwang1> with that case, we could be more easier to integrate it, i will add more patch sets later
10:23:49 <flwang1> 2. I'm still working on the FEK stuff, to support logging, but i may hold it a bit due to limited bandwidth recently
10:24:12 <flwang1> 3. the health_status and health_status_reason attributes
10:24:32 <flwang1> it's going well, and Ricardo left some great questoins
10:24:55 <flwang1> i will discuss it with strigazi and ricardo
10:25:20 <strigazi> #link https://review.openstack.org/#/c/570818/
10:25:20 <flwang1> 4. deprecate the send_cluster_metrics, it's ready for review
10:25:53 <flwang1> 5. fix the race condition issue when creating multi masters  https://review.openstack.org/573639
10:26:02 <flwang1> it's ready for review, i have tested it locally, it works fine
10:26:35 <flwang1> 6. make the etcd lb optional, see https://review.openstack.org/574540  it's still working in progress
10:26:45 <flwang1> that's all from my side, thanks
10:27:12 <strigazi> thanks flwang1
10:27:37 <strigazi> brtknr: want to bring up something about cgroups/ docker-ce?
10:29:32 <strigazi> let's move to open discussion then
10:29:38 <strigazi> #topic Open Discussion
10:29:50 <strigazi> Again, the meeting time
10:31:01 <flwang1> i'd like to discuss the naming convention of those lovely scripts https://review.openstack.org/562454
10:31:21 <strigazi> Recently a US company showed some interest and started to contrubute and they try to get involved, should we alternate bi-weekly?
10:31:27 <brtknr> Sorry I was AFK briefly
10:31:58 <flwang1> strigazi: i would prefer to avoid bi-weekly alt
10:32:08 <flwang1> because based on my experience, it doesn't work well
10:32:22 <strigazi> how can we get them though? Two weekly meetings?
10:32:26 <flwang1> people  are always confused
10:32:42 <flwang1> they can popup anytime actually
10:32:47 <flwang1> it's an IRC channel
10:33:20 <flwang1> what's their time based on our current meeting time?
10:33:21 <strigazi> yes, but we are not always online :)
10:33:37 <flwang1> do you know their tz?
10:33:40 <strigazi> california
10:33:58 <brtknr> strigazi: 3:33 am in california right now
10:34:48 <flwang1> ok, for that case, we can try bi-weekly alt
10:35:02 <strigazi> or two meetings?
10:35:12 <flwang1> i don't mind 2 meetings actually
10:35:38 <brtknr> i dont mind 2 meetings either, im probably only going to come to one appropriate to my timezone
10:35:43 <strigazi> with two meetings, no one will show up and there won't be a meeting
10:36:14 <strigazi> we can 1600 ot 1700 UTC for them
10:36:22 <strigazi> we can do 1600 or 1700 UTC for them
10:36:34 <brtknr> flwang1: where are you now?
10:36:46 <flwang1> brtknr: NZ
10:36:49 <strigazi> even 1800 UTC
10:37:00 <brtknr> so its 10pm there?
10:37:09 <flwang1> 10:37PM
10:37:28 <brtknr> wow true dedication!
10:37:50 <brtknr> +1 to 1700 UTC
10:38:05 <flwang1> brtknr: no worries, strigazi will buy me a beer
10:38:13 <strigazi> flwang1: or many
10:38:18 <strigazi> on berloin
10:38:20 <strigazi> on berlin
10:38:30 <flwang1> strigazi: ok, logged
10:38:37 <ricolin> Berlin!!!
10:38:38 <strigazi> flwang1: 1700 utc for you?
10:38:48 <flwang1> strigazi: that works for me
10:39:00 <brtknr> flwang1: thats 5am!
10:39:16 <brtknr> how about sunday?
10:39:26 <flwang1> brtknr: it's true, i generally start up at 5 am
10:39:39 <strigazi> Ok. I can send an email and ask them
10:39:55 <brtknr> whats the company called?
10:39:58 <strigazi> in the ML
10:40:05 <strigazi> Blizzard
10:40:08 <flwang1> brtknr: it doesn't work haha, i need to have time with kids
10:40:35 <flwang1> strigazi: ah, Blizzard
10:40:37 <brtknr> wow! cool! world of worldcraft blizzard?
10:40:44 <flwang1> wow
10:40:58 <flwang1> brtknr: yes, they are using openstack a lot
10:41:00 <ricolin> Yes
10:41:20 <brtknr> i was joking about sunday
10:41:33 <flwang1> brtknr: i know, no worries
10:42:10 <brtknr> maybe friday 5am is best?
10:42:35 <flwang1> Friday sounds good
10:42:41 <strigazi> we can do thursday, friday for flwang1
10:42:48 <brtknr> end of week, enough gap from tuesday
10:42:54 <flwang1> yep
10:43:17 <strigazi> let's see, I'll send an email
10:43:31 <strigazi> brtknr: want to discuss anything?
10:43:43 <brtknr> i'm still waiting for review
10:43:53 <brtknr> on the two things
10:44:07 <brtknr> thanks for the earlier comments
10:44:18 <flwang1> brtknr: your patches on my list, but i need to find a time slot, sorry for that
10:44:21 <strigazi> flwang1: regarding the script name I'll check the patch, standards are good. We can make them SD as well
10:44:28 <strigazi> flwang1: since we touch them
10:45:10 <strigazi> brtknr Do you have time to add docker-ce? is it in your lsit?
10:45:24 <brtknr> strigazi: docker-ce is on my list
10:45:40 <strigazi> brtknr: we can do containerd too
10:46:01 <brtknr> i'll read up on containerd
10:46:01 <strigazi> brtknr: What we need is to setup builds for the containers
10:46:11 <flwang1> strigazi: thanks, pls see my comments in the renaming patch when you have time
10:46:17 <brtknr> at creation?
10:46:31 <brtknr> rather than pull image from a source?
10:46:37 <strigazi> brtknr: no, just a CI
10:46:49 <strigazi> brtknr: to populate the source
10:47:09 <brtknr> strigazi: who will host the source?
10:47:24 <strigazi> I'll see with the infra team how to setup
10:47:27 <brtknr> strigazi: cern? docker.io?
10:47:37 <strigazi> brtknr: now we have docke.io
10:47:48 <flwang1> strigazi: is cern using a private registry?
10:47:49 <strigazi> we can also use quay.io push to both
10:47:55 <strigazi> flwang1: yes
10:48:03 <flwang1> what's it？
10:48:07 <strigazi> gitlan
10:48:10 <strigazi> gitlab
10:48:29 <strigazi> it implement docker registry v2
10:48:31 <brtknr> cern's registry is super fast compared to docker.io
10:48:32 <strigazi> it implements docker registry v2
10:49:10 <strigazi> brtknr: yes but we can't rely on it as a an OS project
10:49:32 <flwang1> we're going to use Harbour
10:49:34 <brtknr> strigazi: i was making an observation!
10:49:36 <flwang1> from vmware
10:49:57 <strigazi> brtknr: let's setup the ci and we can push anywhere we want
10:50:10 <brtknr> sounds good
10:50:45 <strigazi> flwang1: is it docker registry v2?
10:51:15 <flwang1> IIRC, yes
10:51:19 <flwang1> i will double check
10:51:52 <strigazi> ok, last thing about the registry, should we have a repo for container image builds?
10:52:06 <brtknr> i'm probably going to be learning as i go along so i'll have lots of questions probably
10:52:31 <strigazi> flwang1: you think it is complicated?
10:52:36 <brtknr> could you elaborate the question?
10:52:41 <flwang1> strigazi: it would be nice to have a repo
10:52:50 <strigazi> brtknr: have a new repo
10:52:54 <flwang1> or we can hold it magnum repo initially
10:52:58 <strigazi> opestack/magnum-containers
10:53:01 <flwang1> strigazi: it's not complicated
10:53:08 <strigazi> cool
10:53:11 <brtknr> oh okay i see what you mean
10:53:25 <strigazi> let's start in o/m and we see
10:53:40 <ricolin> You can build a periodic job to build it
10:53:43 <flwang1> it would be nice if we can have a CI to public images automatically
10:53:55 <strigazi> flwang1: that is the goal
10:53:55 <brtknr> yeah dont see any immediate need to separate repos
10:54:03 <strigazi> brtknr: +1
10:54:17 <brtknr> strigazi: although i was wondering if fedora atomic elements are still necessary
10:54:28 <brtknr> strigazi: for diskimagebuilder
10:54:42 <brtknr> strigazi: since the image works out of the box now
10:54:45 <strigazi> brtknr: they are not
10:55:35 <brtknr> strigazi: should we drop them?
10:56:16 <strigazi> brtknr: sure
10:56:42 <strigazi> we can add them back if someone  needs them
10:57:05 <brtknr> when i got started with magnum, it was quite a distraction as I started building fa27 image using the elements then later realised it wasn't required at all
10:57:21 <strigazi> anyhting else for the meeting?
10:57:30 <strigazi> brtknr: I have spent quite some time with it
10:57:38 <strigazi> brtknr: it wasn't funny
10:57:46 <flwang1> are you talking about this https://github.com/openstack/magnum/tree/master/magnum/drivers/common/image ?
10:58:03 <strigazi> flwang1: yes /fedora-atomic not the agent
10:58:09 <flwang1> ok, got
10:58:12 <flwang1> we don't need it
10:58:37 <flwang1> we may need better tagging for the heat-container-agent btw
10:59:52 <flwang1> nothing from my side
10:59:58 <brtknr> okay great
11:00:07 <strigazi> flwang1: we can iterate when we have builds
11:00:15 <flwang1> strigazi: cool
11:00:25 <strigazi> cool, thanks guys
11:00:32 <strigazi> #endmeeting