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