03:00:14 <hongbin> #startmeeting zun
03:00:15 <openstack> Meeting started Tue Dec 20 03:00:14 2016 UTC and is due to finish in 60 minutes.  The chair is hongbin. Information about MeetBot at http://wiki.debian.org/MeetBot.
03:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:00:18 <openstack> The meeting name has been set to 'zun'
03:00:19 <hongbin> #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2016-12-20_0300_UTC Today's agenda
03:00:24 <hongbin> #topic Roll Call
03:00:31 <mkrai_> Madhuri Kumari
03:00:32 <Namrata> Namrata
03:00:37 <kevinz> kevinz
03:01:06 <pksingh> pksingh
03:01:42 <hongbin> thanks for joining the meeting mkrai_ Namrata kevinz pksingh
03:01:49 <hongbin> let's get started
03:02:02 <hongbin> #topic Announcements
03:02:11 <hongbin> i have no announcement
03:02:21 <hongbin> anyone else has any announcement?
03:02:38 <hongbin> #topic Review Action Items
03:02:43 <hongbin> 1. hongbin split the k8s bp into two (DONE)
03:02:49 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/introduce-pod The Pod BP
03:02:54 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/k8s-integration The k8s BP
03:03:14 <hongbin> The pod bp needs an owner
03:03:27 <hongbin> if anyone interest in the work, feel free to take it
03:03:36 <hongbin> 2. hongbin raise a ML with API WG to discuss the consolidate of actions into single URL (DONE)
03:03:43 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2016-December/109136.html
03:03:46 <pksingh> currently implementing api bp, i can teke that if any body helps me
03:04:15 <hongbin> pksingh: sure, i can help you a bit
03:04:35 <pksingh> hongbin: ok :)
03:04:40 <hongbin> pksingh: feel free to assign it to yourself
03:05:07 <hongbin> ok, back to the ML discussion
03:05:26 <hongbin> there are two replies on the ML
03:05:33 <hongbin> first reply: http://lists.openstack.org/pipermail/openstack-dev/2016-December/109178.html
03:05:55 <mkrai_> First reply seems out of context to me
03:06:00 <hongbin> chris dent seems to suggest to consolidate multiple urls
03:06:22 <mkrai_> I didn't get the response clearly may be
03:06:42 <mkrai_> hongbin: Can you please explain what option he proposed?
03:06:43 <hongbin> mkrai_: i am also not sure exactly what he mean
03:07:06 <hongbin> mkrai_: by looking at the urls, i guess he suggested to consolidate multiple urls
03:07:32 <hongbin> however, the second reply is the meat
03:07:34 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2016-December/109208.html
03:07:45 <mkrai_> Yes Alex's response is clear
03:07:56 <hongbin> alex xu is a nova core, he pointed out the problems of having multple urls
03:08:13 <hongbin> personally, i agree with him
03:08:34 <mkrai_> hongbin: I think he has pointed out problems with single API
03:08:41 <hongbin> mkrai_: yes
03:08:54 <mkrai_> Ok
03:09:09 <hongbin> then, we could leave it as multiple url as is
03:09:18 <hongbin> (if there is no further objection)
03:09:39 <hongbin> Qiming: ping
03:09:45 <mkrai_> I am ok with it
03:09:49 <pksingh> me to
03:09:55 <hongbin> ok
03:10:01 <hongbin> then, move on
03:10:08 <hongbin> #topic Introduce pod
03:10:14 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/introduce-pod The BP
03:10:33 <hongbin> let's skip this one for now, since pksingh just took it
03:10:41 <Qiming> po
03:10:46 <hongbin> Qiming: hey
03:10:56 <hongbin> Qiming: we are discussing the multiple action urls
03:11:01 <Qiming> yes
03:11:23 <hongbin> Qiming: based on the replies in the ML, it seems there are several problems of this design in nova
03:11:44 <Qiming> looking
03:11:51 <hongbin> Qiming: so it seems people lean on the multiple urls options
03:12:07 <hongbin> Qiming: we can get back to it at open discussion if you like
03:12:13 <Qiming> okay
03:12:16 <hongbin> #topic Support multi-host deployment (hongbin)
03:12:23 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/support-multiple-hosts The BP
03:12:34 <hongbin> i am going to start this one next week
03:13:02 <hongbin> the idea is to support deploying multiple zun-compute to hosts (right now, we deploy everyone in a single host)
03:13:03 <mkrai_> cool this will be good to have
03:13:14 <hongbin> yes
03:13:31 <hongbin> i will work on that, and report the status at the next meeting
03:13:39 <hongbin> next one
03:13:41 <hongbin> #topic Support interactive mode (kevinz)
03:13:47 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/support-interactive-mode The BP
03:13:52 <hongbin> #link https://review.openstack.org/#/c/396841/ The design spec
03:13:55 <hongbin> kevinz: ^^
03:14:11 <kevinz> https://github.com/kevin-zhaoshuai/container-interactive-client
03:14:21 <kevinz> Last week I have finished a demo for this
03:14:50 <hongbin> coll
03:14:51 <hongbin> cool
03:14:59 <kevinz> Now the status is we can use the websocket link to do interactive mode to container
03:15:20 <hongbin> #link https://github.com/kevin-zhaoshuai/container-interactive-client
03:15:56 <kevinz> Still two issues I need to fix. One is python packages websocket-client , Websocket-client will need to modify some code when dealing with escape code.
03:16:09 <kevinz> The other is add support to container tty session resize according to current user
03:16:56 <hongbin> could you elaborate what is tty session resize?
03:17:22 <kevinz> Ofcourse
03:18:22 <diga> https://www.irccloud.com/pastebin/Nujli3wo
03:18:27 <kevinz> docker will generated a tty session inside the container,I will find a link
03:18:36 <diga> o/
03:18:41 <kevinz> https://docs.docker.com/engine/reference/api/docker_remote_api_v1.21/#/resize-a-container-tty
03:18:59 <hongbin> diga: thanks for joining
03:19:29 <diga> hongbin: welcome
03:19:36 <kevinz> when we connect to the container, user will get a fixable size tty session
03:19:37 <hongbin> kevinz: i see
03:20:14 <kevinz> we can change it according to users' terminal size.
03:20:20 <hongbin> i see
03:20:45 <hongbin> kevinz: sounds you have a good progress on this one
03:21:01 <hongbin> kevinz: do you need any help from our team member regarding to this bp?
03:22:16 <kevinz> hongbin: Thanks~ If I need I will ask wenzhi for some help :D
03:22:24 <hongbin> anyway, feel free to ping any of us in irc if you need help
03:22:27 <hongbin> ok
03:22:40 <kevinz> When integrate with zun and clis
03:22:51 <hongbin> great
03:22:57 <hongbin> next one
03:23:00 <hongbin> #topic Make Zunclient an OpenStackClient plugin (Namrata)
03:23:05 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/zun-osc-plugin
03:23:09 <hongbin> Namrata: ^^
03:23:14 <Namrata> hey
03:23:23 <Namrata> Have uploaded the initial commit for opensack client support in python - zunclient and it is merged
03:23:34 <Namrata> I have uploaded OSC plugin fo command show but there is a name conflict
03:23:58 <Namrata> so can we discuss what command name should be there
03:24:43 <hongbin> Namrata: i think you can forget about the name conflict for now
03:25:07 <hongbin> Namrata: it is a bigger problem we need to deal with :)
03:25:25 <Namrata> so how would it work with swift ?
03:25:38 <hongbin> for others, we are talking about the keywork "container" was taken in openstackclient by swift
03:25:45 <stevemar> there is a non-voting job you can add to your client to pick up these conflicts when they are proposed, see: http://docs.openstack.org/developer/python-openstackclient/plugins.html#checklist-for-adding-new-openstack-plugins
03:26:33 <hongbin> stevemar: ack
03:27:01 <hongbin> stevemar: is there any way to allow the same keyword (i.e. container) can be taken by multiple project?
03:27:12 <hongbin> #link http://docs.openstack.org/developer/python-openstackclient/plugins.html#checklist-for-adding-new-openstack-plugins
03:27:14 <Namrata> stevemar:thanks
03:27:23 <hongbin> stevemar: e.g. a namespace ?
03:27:26 <stevemar> hongbin: unfortunately not
03:27:43 <hongbin> stevemar: is that a reasonable feature that can be requested for osc?
03:27:45 <stevemar> container is tricky... in swift it's a container / bucket for objects
03:28:09 <hongbin> yes it is
03:28:24 <stevemar> hongbin: we've had discussions on the mailing list before about namespacing comands
03:28:28 <hongbin> i guess what we wanted is a feature to shadow swift container when users are using zun
03:28:31 <mkrai_> barbican also have container concept
03:28:47 <stevemar> mkrai_: i think they are calling it "secret container"
03:29:04 <stevemar> https://github.com/openstack/python-barbicanclient/blob/master/setup.cfg#L45-L48
03:29:08 <mkrai_> stevemar: Yes I saw that
03:29:46 <stevemar> hongbin: Namrata i suggest a note to the mailing list, so dtroyer can give guidance
03:29:53 <diga> hongbin: may be we can initiate conversation with swift team on this ?
03:29:54 <mkrai_> hongbin: There is high possibility that users can use both in future
03:30:09 <hongbin> stevemar: ack
03:30:12 <stevemar> the swift team doesn't own the OSC commands
03:30:25 <hongbin> #action hongbin start a ML to osc team to discus the name collision issue
03:30:42 <stevemar> the OSC team (myself + dtroyer + a few others) owns the commands used in osc
03:31:11 <stevemar> (we deeply regret calling the swift container just "container")
03:31:44 <mkrai_> I suggest to have "object container"
03:31:54 <hongbin> yes, imho, every commands should prefix with a project name (i.e. compute, network , ...)
03:31:55 <mkrai_> But this suggestion would be too early
03:32:01 <hongbin> that is how aws cli works ....
03:32:07 <mkrai_> +1 hongbin
03:32:12 <pksingh_> +1
03:32:19 <hongbin> anyway
03:32:29 <stevemar> heres an old reference: http://lists.openstack.org/pipermail/openstack-dev/2015-October/076354.html
03:32:41 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2015-October/076354.html
03:33:21 <stevemar> hongbin: right, just don't use the project "code name", so don't call it "openstack zun container show" :)
03:33:32 <stevemar> congress did that, and it's ugly
03:33:46 <hongbin> stevemar: yes, that could be an alternative
03:34:26 <stevemar> we could rename the OSC command, but we would need to deprecate it first :\
03:34:37 <stevemar> when will zunclient be released?
03:34:48 <hongbin> possibly a few months after
03:35:12 <stevemar> OK, we can discuss this in the ML, i'll respond there
03:35:19 <stevemar> don't want to take up more time in the meeting
03:35:43 <hongbin> stevemar: thanks for your response and suggestion here :)
03:35:59 <Namrata> stevemar:thanks
03:36:16 <stevemar> np
03:36:26 <hongbin> Namrata: my advice for you is don't worry the namespace problem for now
03:36:35 <hongbin> Namrata: i will help you to deal with that
03:36:44 <hongbin> Namrata: just add commands as you did before
03:36:51 <Namrata> thanks hongbin
03:36:58 <hongbin> Namrata: np
03:37:01 <Namrata> okay i will add
03:37:04 <Namrata> https://etherpad.openstack.org/p/zunclient_openstack-client-cli
03:37:48 <Namrata> these are the osc commmands i will further work on
03:38:06 <hongbin> Namrata: lgtm
03:38:24 <pksingh_> Namrata: +1
03:38:47 <Namrata> thanks hongbin pksingh_
03:38:54 <hongbin> ok, move on
03:38:56 <hongbin> #topic Open Discussion
03:39:07 <hongbin> anyone has a topic to bring up here?
03:39:35 <hongbin> Qiming: want to discuss the action urls?
03:40:29 <hongbin> ok, if there is no topic, let's end the meeting earlier
03:40:33 <mkrai_> Qiming: has replied to email
03:40:44 <pksingh_> hongbin: can we look into https://blueprints.launchpad.net/zun/+spec/auto-select-nova-flavor
03:41:16 <hongbin> pksingh_: sure
03:41:24 <hongbin> pksingh_: go ahead
03:41:38 <pksingh_> how will we finding the exact memory requirement?
03:41:58 <pksingh_> means exact flavour size mey not  be there right?
03:42:16 <pksingh_> wouldn't that be waste of resource
03:43:02 <pksingh_> make sense?
03:43:07 <hongbin> yes, this is a good point
03:43:33 <stevemar> oh, just one more comment on the CLI (now that I see the etherpad) -- the trove team actually made a spec added for it: https://review.openstack.org/#/c/391871/ and asked me + dtroyer to review. They've found it helpful so far :)
03:43:37 <hongbin> pksingh_: do you have an alternative proposal?
03:43:56 <pksingh_> hongbin: i dont have now,
03:44:12 <hongbin> stevemar: ack
03:44:18 <pksingh_> if we go through nova then i think this is the only possible solution
03:44:23 <hongbin> #link  https://review.openstack.org/#/c/391871/
03:45:14 <hongbin> pksingh_: another option is cerating a new flag (i.e. --extra-opts nova.flavor=m1.small)
03:45:38 <pksingh_> hongbin: from cli?
03:45:47 <hongbin> pksingh_: yes
03:45:55 <hongbin> pksingh_: and rest api as well
03:46:21 <hongbin> pksingh_: however, we need to deal with the case that if this flag is not specified
03:46:25 <pksingh_> hongbin: i was thinking sandbox should not be exposed to users, they should just know about containers
03:46:42 <hongbin> sure, that is a valid point
03:47:05 <mkrai_> +1 pksingh_
03:47:05 <hongbin> then, we need to auto-select the sandbox flavor for users somehow
03:47:20 <pksingh_> hongbin: okay lets go with bestfit falvour for time being
03:47:21 <mkrai_> And the logic should reside in zun
03:47:33 <hongbin> pksingh_: wfm
03:47:57 <pksingh_> later we can refine
03:48:10 <hongbin> ok
03:48:10 <prameswar> hi hongbin , you added one bug #link https://bugs.launchpad.net/zun/+bug/1650979 that is related to pulling large image i also tested. it is not ending it keep on showing pulling_image. so you suggested 3 point. anyone want to suggest which is best way to solve that problem?
03:48:11 <openstack> Launchpad bug 1650979 in Zun "Zun run failed when pulling a large image" [Medium,Triaged]
03:48:13 <pksingh_> ok thats all from me
03:48:13 <mkrai_> pksingh_: the extra ram can be used by nova to host new sandboxes
03:49:02 <hongbin> prameswar: sure, we could discuss that here
03:49:14 <pksingh_> mkrai_: sure, we will discuss that, once i propose the bp spec
03:49:23 <mkrai_> pksingh_: Sure
03:49:32 <hongbin> #link https://bugs.launchpad.net/zun/+bug/1650979
03:49:33 <openstack> Launchpad bug 1650979 in Zun "Zun run failed when pulling a large image" [Medium,Triaged]
03:49:50 <mkrai_> prameswar: I feel make it "cast"
03:49:51 <pksingh_> prameswar: for timebeing i am in favour of cast
03:49:57 <hongbin> let's pause a few seconds for everyone to review the bug
03:50:19 <hongbin> ok, sound like we already has a choice
03:50:20 <diga> hongbin: is there anyone working on storage support if not, I will start on
03:50:33 <prameswar> i also think so
03:50:34 <hongbin> diga: sure
03:51:00 <diga> hongbin:  will talk about it on zun channel
03:51:10 <hongbin> prameswar: ok, sounds like you are good to go?
03:51:15 <diga> After the meeting
03:51:17 <prameswar> yes :)
03:51:26 <hongbin> prameswar: great
03:51:50 <hongbin> diga: you wanted to work on this one? https://blueprints.launchpad.net/zun/+spec/cinder-zun-integration
03:52:25 <hongbin> diga: ok, ping me at zun channel about that
03:52:45 <hongbin> any other topic?
03:53:16 <hongbin> all, thanks for joining the meeting. a reminder, there will be no meeting next week. have a happy holiday
03:53:24 <hongbin> #endmeeting