Tuesday, 2016-12-06

*** haleyb_ has quit IRC00:01
*** masayukig has quit IRC00:01
*** bobh has quit IRC00:02
*** masayukig has joined #openstack-meeting00:02
*** donghao has quit IRC00:02
*** ljxiash_ has joined #openstack-meeting00:04
*** Swami_ has joined #openstack-meeting00:07
*** ljxiash has quit IRC00:08
*** Swami has quit IRC00:11
*** thorst has joined #openstack-meeting00:12
*** hongbin has quit IRC00:14
*** thorst has quit IRC00:15
*** thorst has joined #openstack-meeting00:16
*** csomerville has quit IRC00:19
*** Patifa has quit IRC00:23
*** shu-mutou has joined #openstack-meeting00:23
*** thorst has quit IRC00:25
*** kenji-i_ has joined #openstack-meeting00:29
*** kenji-i has quit IRC00:30
*** penick has quit IRC00:31
*** rajinir has quit IRC00:36
*** Wenzhi has joined #openstack-meeting00:36
*** VW has joined #openstack-meeting00:41
*** sdake_ has quit IRC00:45
*** ljxiash_ has quit IRC00:46
*** VW has quit IRC00:46
*** sdake has joined #openstack-meeting00:46
*** adiantum has quit IRC00:50
*** Cibo_ has joined #openstack-meeting00:50
*** tovin07 has joined #openstack-meeting00:54
*** tovin07_ has joined #openstack-meeting00:54
*** penick has joined #openstack-meeting00:56
*** haleyb_ has joined #openstack-meeting00:57
*** penick has quit IRC00:59
*** emagana has joined #openstack-meeting00:59
*** penick has joined #openstack-meeting01:01
*** rcernin has quit IRC01:01
*** julim has joined #openstack-meeting01:02
*** haleyb_ has quit IRC01:03
*** julim has quit IRC01:04
*** emagana has quit IRC01:04
*** tovin07_ has quit IRC01:04
*** tovin07_ has joined #openstack-meeting01:04
*** julim has joined #openstack-meeting01:05
*** ljxiash has joined #openstack-meeting01:08
*** ljxiash has quit IRC01:08
*** thorst has joined #openstack-meeting01:09
*** thorst has quit IRC01:09
*** thorst has joined #openstack-meeting01:10
*** zhurong has joined #openstack-meeting01:13
*** thorst has quit IRC01:14
*** doonhammer has quit IRC01:18
*** sdake_ has joined #openstack-meeting01:20
*** sdake has quit IRC01:20
*** sdake has joined #openstack-meeting01:21
*** longxiongqiu has joined #openstack-meeting01:22
*** thorst has joined #openstack-meeting01:23
*** thorst has quit IRC01:24
*** ricolin has joined #openstack-meeting01:24
*** zhurong has quit IRC01:25
*** sdake_ has quit IRC01:25
*** zhhuabj has quit IRC01:25
*** zhurong has joined #openstack-meeting01:25
*** unicell1 has joined #openstack-meeting01:26
*** rfolco has quit IRC01:26
*** unicell has quit IRC01:27
*** rossella_s has quit IRC01:31
*** Apoorva has quit IRC01:31
*** rossella_s has joined #openstack-meeting01:32
*** sdake_ has joined #openstack-meeting01:33
*** sdake has quit IRC01:35
*** unicell has joined #openstack-meeting01:36
*** zhhuabj has joined #openstack-meeting01:38
*** unicell1 has quit IRC01:38
*** kevinz has joined #openstack-meeting01:40
*** gyee has quit IRC01:40
*** shashank_hegde has quit IRC01:42
*** elynn has joined #openstack-meeting01:45
*** elynn has left #openstack-meeting01:46
*** hongbin has joined #openstack-meeting01:47
*** lhx_ has joined #openstack-meeting01:51
*** Swami_ has quit IRC01:53
*** longxiongqiu has quit IRC01:54
*** longxiongqiu has joined #openstack-meeting01:55
*** chrisplo has quit IRC01:56
*** haleyb_ has joined #openstack-meeting01:56
*** penick has quit IRC01:59
*** julim has quit IRC02:04
*** thorst has joined #openstack-meeting02:05
*** Leo_ has quit IRC02:05
*** thorst has quit IRC02:05
*** thorst has joined #openstack-meeting02:06
*** zhhuabj has quit IRC02:07
*** comay has quit IRC02:07
*** thorst has quit IRC02:15
*** sdake has joined #openstack-meeting02:15
*** numans has quit IRC02:16
*** sdake_ has quit IRC02:17
*** numans has joined #openstack-meeting02:17
*** spzala has quit IRC02:18
*** mtanino has quit IRC02:19
*** kenji-i has joined #openstack-meeting02:21
*** guoshan has joined #openstack-meeting02:21
*** zhhuabj has joined #openstack-meeting02:23
*** kenji-i_ has quit IRC02:24
*** gcb has joined #openstack-meeting02:31
*** saisriki__ has joined #openstack-meeting02:35
*** mkrai_ has joined #openstack-meeting02:37
*** dalvarez has quit IRC02:40
*** dalvarez has joined #openstack-meeting02:40
*** s3wong has quit IRC02:45
*** hongbin has quit IRC02:46
*** hongbin has joined #openstack-meeting02:46
*** yuanying has quit IRC02:46
*** zhangjl has joined #openstack-meeting02:47
*** pksingh has joined #openstack-meeting02:50
*** shubhams_ has joined #openstack-meeting02:53
*** woodster_ has quit IRC02:56
*** Namrata has joined #openstack-meeting02:57
*** kaisers__ has joined #openstack-meeting02:58
hongbin#startmeeting zun03:00
openstackMeeting started Tue Dec  6 03:00:09 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.03:00
*** openstack changes topic to " (Meeting topic: zun)"03:00
openstackThe meeting name has been set to 'zun'03:00
hongbin#link https://wiki.openstack.org/wiki/Zun#Agenda_for_2016-12-06_0300_UTC Today's agenda03:00
hongbin#topic Roll Call03:00
*** openstack changes topic to "Roll Call (Meeting topic: zun)"03:00
NamrataNamrata03:00
pksinghpradeep03:00
kevinzkevinz03:00
mkrai_Madhuri Kumari03:00
WenzhiWenzhi03:00
shubhams_shubham03:00
*** sudipto has joined #openstack-meeting03:00
*** sudipto_ has joined #openstack-meeting03:00
hongbinthanks for joining the meeting Namrata pksingh kevinz mkrai_ Wenzhi shubhams_03:01
sudipto_o/03:01
* hongbin is getting code today03:01
hongbins/code/cold/03:01
*** lakerzhou has joined #openstack-meeting03:01
*** kaisers_ has quit IRC03:01
Wenzhitake care03:01
hongbinsudipto: hey03:01
sudipto_hi03:02
kevinztake care hongbin03:02
hongbinWenzhi: thanks, not too bad03:02
hongbin#topic Announcements03:02
*** openstack changes topic to "Announcements (Meeting topic: zun)"03:02
hongbin1. Zun is an official OpenStack project now!03:02
hongbin#link https://review.openstack.org/#/c/402227/03:02
pksinghgreat :)03:02
mkrai_Yay!!! Congrats to all of us.03:02
hongbinthanks everyone for your hard work, this is a recognization of the whole team03:02
kevinz\o/03:02
shubhams_:)03:02
Wenzhibravo03:02
Namratagreat03:02
lakerzhouGreat!!03:02
sudipto_awesome!03:03
hongbinyeah03:03
*** yanyanhu has joined #openstack-meeting03:03
hongbin#topic Review Action Items03:03
*** openstack changes topic to "Review Action Items (Meeting topic: zun)"03:03
hongbinnone03:03
hongbin#topic Should we participant OpenStack Project Team Gathering?03:03
*** openstack changes topic to "Should we participant OpenStack Project Team Gathering? (Meeting topic: zun)"03:03
hongbin#link https://www.openstack.org/ptg/03:03
yanyanhuhi, hongbin, sorry I'm late03:03
mkrai_Yes we should03:03
hongbinyanyanhu: hey, np. thanks for joining03:03
*** brault has quit IRC03:04
lakerzhouI plan to go PTG03:04
hongbinlakerzhou: ack03:04
hongbinanyone else who will go there?03:04
* hongbin should be able to attend but not sure 100%03:04
Namratanot so sure03:05
*** cloud_player has joined #openstack-meeting03:05
mkrai_I can't assure now. Waiting for approval from employers03:05
pksinghneed to talk to my employer03:05
hongbinit looks lakerzhou will go there, mkrai_ Namrata and me is not sure03:05
hongbinpksingh: ack03:06
hongbinok, i asked this because the tc chair asked me if zun will have a session in ptg03:06
hongbinfrom the current response, it looks only a few of us will go there03:06
hongbinok, let's table this topic to next week03:07
hongbin#topic Kubernetes integration (shubhams)03:07
*** openstack changes topic to "Kubernetes integration (shubhams) (Meeting topic: zun)"03:07
hongbin#link https://blueprints.launchpad.net/zun/+spec/k8s-integration The BP03:07
hongbin#link https://etherpad.openstack.org/p/zun-k8s-integration The etherpad03:08
hongbinshubhams_: ^^03:08
shubhams_We discussed about this last week and mostly agreed to have a small set of k8s feature03:08
shubhams_Thats is : start from pod like feature in zun03:08
shubhams_It is mentioned as option#3 in etherpad03:09
shubhams_On top of this, we propose option#503:09
shubhams_Madhuri will explain this03:09
hongbinmkrai_: ^^03:10
mkrai_I have tried to explain it in etherpad.03:10
mkrai_It is basically exposing single API endpoint for each COE03:10
*** sdake_ has joined #openstack-meeting03:11
mkrai_and then have sub controllers to it for handling the resources related to that COE03:11
mkrai_By this zun will not have many resources that we directly replicate from COEs03:11
mkrai_For an example: /v1/k8s/pod etc03:11
hongbinthen, zun will behavior as a proxy to different coe?03:12
mkrai_Yes03:12
*** doonhammer has joined #openstack-meeting03:12
hongbinthis is basically an extension of option #1 (it seems)03:12
mkrai_The implementation at compute side will be same. It will act like proxy03:12
*** thorst has joined #openstack-meeting03:12
hongbinmkrai_: get that03:13
*** sdake has quit IRC03:13
hongbinall, thoughts on this?03:13
Wenzhisounds feasible03:13
shubhams_I and Madhuri had already discussed this , so we are ok on this point03:14
pksinghidea seems great, at least it do not disturbs the existing k8s user03:14
sudipto_mkrai_, the segregation seems like a good proposal. What would happen to the default zun behaviour in this case?03:14
sudipto_i mean a command like "zun list"03:14
pksinghhow about having different api service for different coes?03:14
mkrai_sudipto_: zun k8s pod-create03:15
hongbinpksingh: interesting03:15
sudipto_mkrai_, that's for k8s, that i got.03:15
mkrai_the COE will be the parent command and we can have sub commands related to the specific resource03:15
sudipto_so everything is a COE in zun?03:15
*** dmorita has quit IRC03:16
mkrai_sudipto_: Yes03:16
*** epico has joined #openstack-meeting03:16
*** doonhammer has quit IRC03:16
mkrai_pksingh: I am not sure, will it not add additional complexity03:16
mkrai_Running multiple api services?03:17
sudipto_so there's no longer a command like zun list - it become zun default list or something?03:17
pksinghmkrai_: user can run the service if they use k803:17
sudipto_then zun k8s list and so on...03:17
*** iyamahat has quit IRC03:17
pksinghmkrai_: otherwise they dont need to run it03:17
mkrai_sudipto_: Sorry I  missed the docker part. It should remain as it is03:17
*** darvon has quit IRC03:18
mkrai_pksingh: And what about compute service?03:18
sudipto_ok that sounds fine. Because if you have created a POD from K8s and then do you a docker ps today, it would show us the individual containers. So maybe zun list becomes directly mapped to docker ps03:19
pksinghmkrai_: that can be same i think,03:19
hongbini think zun needs to have a core api that is independent of any coe, although we could have extension api that is compatible with different coes03:19
hongbin2 cents03:19
*** thorst has quit IRC03:20
mkrai_sudipto_: Right03:20
mkrai_pksingh: In that case we will have to have a proxy api service. Right?03:21
pksinghhongbin: every coe have different terms, will it not add overhead for existing coe users to learn the new things?03:21
hongbinpksingh: yes, that is true, but i would argue that zun's users won't be users of coe03:22
hongbinpksingh: because coe users will use the native coe api03:22
sudipto_hongbin, +!03:22
hongbinpksingh: zun's users are really the users of openstack imo03:22
*** r-mibu has quit IRC03:22
shubhams_hongbin: +1 additionally with zun we try to give uniformatiy across coes03:22
pksinghhongbin: yes, i agree with you03:23
hongbinthe openstakc users who are using "nova list", those are the potential zun users03:23
Wenzhiagreed03:23
kevinzagreed03:23
hongbinif we agree on this point, then we need to have a core api that is independent of any coe, and frieldly to openstack users03:23
shubhams_hongbin:  but having our own implementation (core api as you mentioned) involves huge efforts, I think so03:23
sudipto_what is this core api? another COE from openstack?03:24
hongbinshubhams_: yes, might be03:24
*** r-mibu has joined #openstack-meeting03:24
hongbinsudipto_: right now, the core api is /containers03:24
sudipto_hongbin, eventually - a group of containers i presume?03:24
mkrai_sudipto_: Right03:25
hongbinsudipto_: yes03:25
hongbinso, personally, i prefer option #3, adding pod to the core api03:25
sudipto_FWIW, that's the path to choose because eventually a K8s user maybe more than OK with K8s itself.03:25
hongbinhowever, option #5 could be an optional feature03:25
hongbinsudipto_: true03:26
sudipto_but shubhams_ is right that it's a huge effort anyway...03:26
*** rbudden has quit IRC03:27
hongbinanother option is to keep /container only03:27
hongbinno pod03:27
hongbinthen, the grouping of containers need to achieved by compose like feature03:27
sudipto_Can an orchestration service like heat do the composition?03:27
mkrai_hongbin: this is the core API implementation only. Right?03:28
hongbinsudipto_: yes, i think it can03:28
hongbinmkrai_: yes03:28
mkrai_hongbin: What I think now is. We should first integrate k8s with zun(option #3 or option #5) as we have seen huge interest for k8s03:29
mkrai_And then later concentrate/discuss on the core API feature03:29
mkrai_These are two different things IMO03:29
mkrai_Or split the discussion in two topics, k8s and core COE APIs03:30
hongbinok, then it seems we need to choose between #3 and #503:30
mkrai_Yes03:30
*** kevinz has quit IRC03:30
pksinghhongbin: mkrai_ , sorry i ask this, what benifit users will get if they access k8 via zun?03:30
*** kevinz has joined #openstack-meeting03:31
sudipto_pksingh, stole my words03:31
*** fnaval has joined #openstack-meeting03:31
hongbinpksingh: i think they interest to leverage the advanced k8s feature, e.g. replication controller03:31
*** saisriki__ has quit IRC03:31
mkrai_I don't have answer for it now. But may be in future we provide some openstack features like storage and networking to them03:31
hongbinmaybe in general, the self-healing feature03:32
mkrai_Now we are just behaving as proxy03:32
pksinghhongbin: cant we implement it in zun instead of providing it through k8s?03:32
shubhams_pksingh: sudipto_ : I am not sure but may be the user who wants to have container cluster but dont want to explore other options except openstack would use zun and its APIs03:32
hongbinpksingh: yes, we could03:32
mkrai_pksingh: We can and that is different from this k8s integration feature03:33
sudipto_i think when we are talking about k8s being managed by zun - we are talking about 3 abstractions, one by docker, one by kubernetes and one by zun03:33
mkrai_hongbin: I suggest to create a bp/etherpad for it and start discussing about core COE APIs in zun03:33
*** baoli has joined #openstack-meeting03:33
hongbinmkrai_: ok, we could do that03:33
hongbin#action hongbin create a etherpad to discuss the zun core api03:34
mkrai_hongbin: thanks03:34
sudipto_I am not sure if will go to zun to get my kubernetes cluster managed, if i come to openstack, maybe i will just use magnum03:34
hongbinpksingh: to answer your question about why users want to use k8s via zun03:34
pksinghhongbin: i was thinking why user will use k8s api through zun, it will add extra overhead03:34
hongbinpksingh: another important reason is multi-tenancy, neutron, cinder, etc.03:34
pksinghhongbin: ok03:35
hongbinthe key point the users are looking for openstack integration for container technology03:35
mkrai_sudipto_: magnum don't have the k8s APIs.03:35
shubhams_How about splitting this bp itself : 1. integrate k8s 2. Core API implementation and work parallely in 2 teams?03:36
pksinghsudipto_: i agree with u03:36
sudipto_my point is - i wouldn't want a magnum or zun api for kubernetes, i will use the kubernetes api itself.03:36
*** armax has quit IRC03:36
pksinghsudipto_: +1, same here03:36
sudipto_I don't necessarily buy into cinder and neutron points either.03:36
mkrai_sudipto_: Though they can use the native kubectl but openstack user might want the native openstack clis for the same03:37
hongbinsudipto_: then, do you think if k8s integration is the right direction for zun?03:37
sudipto_i am not sure at this point, maybe we need some operator opinion here.03:37
hongbinsudipto_: i see03:38
shubhams_sudipto_: Think about the case for image driver here . We could have used docker pull directly but adding glance driver gave an option to store images inside openstack. Similarly having k8s integrate with zun will give such benefits . just a thought03:38
hongbinsudipto_: actually, back to the beginning when hte zun project is found03:39
pksinghhongbin: :)03:39
sudipto_glance images are pretty inferior in terms of storing docker images if you just think about it.03:39
sudipto_but we need it.03:39
hongbinsudipto_: the zun project is found becaue other openstack projects (i.e. trove) need a api to talk to different coe03:39
sudipto_yeah which means, you maybe talking about removing the headache from the user that it's kubernetes or swarm or mesos underneath03:40
hongbinsudipto_: from their point fo view, it is hard for them to interface with different coe, so they want a single api03:40
sudipto_but with the endpoint API - we we are saying - start becoming aware of kubernetes commands - isn't it?03:40
hongbinmaybe no03:41
hongbinusers should not be aware of k8s under the hook03:41
hongbinlike nova03:41
*** spzala has joined #openstack-meeting03:42
sudipto_hongbin, yup03:42
sudipto_that's what i am saying too.03:42
hongbinlike nova's users are not aware of hypervisor03:42
pksinghhongbin: i agree03:42
sudipto_but a command like zun k8s list --> it becomes k8s aware.03:42
hongbinsudipto_: it is a good or bad idea?03:42
sudipto_hongbin, i mean, that is opposite of our initial discussion.03:43
hongbinok03:43
sudipto_however, during the initial discussion, we couldn't find a way to bring all the COEs under one API (atleast back then)03:43
mkrai_sudipto_: And that's the same today I guess03:43
sudipto_To me an ML discussion sounds right?03:43
hongbinok03:43
mkrai_Every COE has different implementation03:44
hongbin#action hongbin start a ML to discuss the k8s integration bp03:44
hongbinthen, let's advance topic03:44
hongbin#topic Support interactive mode (kevinz)03:44
*** openstack changes topic to "Support interactive mode (kevinz) (Meeting topic: zun)"03:44
hongbin#link https://blueprints.launchpad.net/zun/+spec/support-interactive-mode The BP03:44
hongbin#link https://review.openstack.org/#/c/396841/ The design spec03:44
hongbinkevinz: ^^03:44
kevinzHi03:44
kevinzThis week plan to finish the "attach" workflow and zun-api <-> docker-daemon workflow03:45
*** armax has joined #openstack-meeting03:45
kevinzlast week tweak the design spec and finish the pre-investigation for feasible method03:47
hongbinyes, the spec looks good03:47
hongbin(to me)03:47
kevinzhaha03:47
pksinghkevinz: i will take a look today,03:48
WenzhiLGTM as well03:48
*** efried has quit IRC03:48
kevinzWenzhi: THX03:48
hongbinkevinz: i think you can start the prototype (maybe after the spec is merged ) to see if the implementation is feasible03:49
kevinzpksingh: OK thanks03:50
hongbinkevinz: feel free to upload a wip patch to ping us for early reviews03:50
*** efried has joined #openstack-meeting03:50
kevinzhongbin: Yeah I will do this week for prototype03:50
hongbinkevinz: thanks for your work on this feature, it would be a useful feature03:50
hongbinkevinz: ack03:51
hongbinok, move on to next topic03:51
kevinzhongbin: my pleasure, thanks for your help03:51
hongbin#topic Moving inspect image from containers driver to image driver03:51
*** openstack changes topic to "Moving inspect image from containers driver to image driver (Meeting topic: zun)"03:51
hongbin#link https://review.openstack.org/#/c/404546/03:51
*** shashank_hegde has joined #openstack-meeting03:51
hongbinfor this review, it looks we have different opinion about the location of the inspect image method03:52
hongbinNamrata: you want to drive this one?03:52
*** links has joined #openstack-meeting03:52
Namratayeah sure03:52
pksinghin my openion,  if we can have similar implementation for glance driver, then its fine03:53
NamrataImo inspect_image is sepicfic to image03:53
mkrai_pksingh: +103:53
Namrataso it should be under image driver03:53
Wenzhisounds reasonable03:54
shubhams_pksingh: mkrai_ : yeah currently even glance driver calls inspect_image from docker driver03:54
sudipto_the present patchset looks good to me.03:55
mkrai_me too03:55
shubhams_plus in that case, if we have inspect_image for glance driver then probably we need not run image_load before running inspect_image as it will be handled by driver itself. But for docker only current patch sounds good03:56
pksinghi think it will fail if image driver is glance, am i right?03:56
*** mriedem has quit IRC03:56
NamrataYes03:56
Namratawill implememt for glance also03:56
pksinghNamrata: can we add both implementations and then merge?03:57
hongbinNamrata: maybe you could combine the implementation of glance and docker hub into one patch03:57
hongbinNamrata: then the reviewers can see the big picture clearly03:57
hongbinpksingh: same advice :)03:58
pksinghhongbin: :)03:58
Namrataokay03:58
Namratawill do that03:58
hongbinNamrata: thx03:58
hongbin#topic Open Discussion03:58
*** openstack changes topic to "Open Discussion (Meeting topic: zun)"03:58
pksinghNamrata: thnx03:59
Namratathanks03:59
hongbinlast minute03:59
hongbinok, all thanks for joining the meeting03:59
hongbin#endmeeting03:59
*** zhangjl has quit IRC03:59
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"03:59
openstackMeeting ended Tue Dec  6 03:59:42 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)03:59
openstackMinutes:        http://eavesdrop.openstack.org/meetings/zun/2016/zun.2016-12-06-03.00.html03:59
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/zun/2016/zun.2016-12-06-03.00.txt03:59
openstackLog:            http://eavesdrop.openstack.org/meetings/zun/2016/zun.2016-12-06-03.00.log.html03:59
*** pksingh has quit IRC03:59
*** shubhams_ has quit IRC03:59
*** zhangjl has joined #openstack-meeting04:00
*** longxiongqiu has quit IRC04:00
*** guoshan has quit IRC04:02
*** baoli has quit IRC04:03
*** julim has joined #openstack-meeting04:04
*** julim has quit IRC04:05
*** yamamoto_ has joined #openstack-meeting04:11
*** armax has quit IRC04:12
*** longxiongqiu has joined #openstack-meeting04:12
*** armax has joined #openstack-meeting04:13
*** armax has quit IRC04:13
*** hongbin has quit IRC04:17
*** apetrich has quit IRC04:17
*** longxiongqiu has quit IRC04:17
*** hongbin has joined #openstack-meeting04:18
*** thorst has joined #openstack-meeting04:18
*** numans has quit IRC04:19
*** apetrich has joined #openstack-meeting04:20
*** vishnoianil has quit IRC04:20
*** GB21 has joined #openstack-meeting04:21
*** julim has joined #openstack-meeting04:23
*** thorst has quit IRC04:25
*** sudipto_ has quit IRC04:25
*** sudipto has quit IRC04:25
*** mordred has quit IRC04:26
*** greghaynes has quit IRC04:26
*** afazekas has quit IRC04:26
*** shashank_hegde has quit IRC04:27
*** hongbin has quit IRC04:28
*** spzala has quit IRC04:30
*** GB21 has quit IRC04:33
*** sridharg has joined #openstack-meeting04:34
*** sdake_ has quit IRC04:39
*** cody-somerville has joined #openstack-meeting04:43
*** sdake has joined #openstack-meeting04:44
*** GB21 has joined #openstack-meeting04:49
*** alex_xu has joined #openstack-meeting04:49
*** vishnoianil has joined #openstack-meeting04:49
*** alex_xu has quit IRC04:49
*** Namrata has quit IRC04:50
*** alex_xu has joined #openstack-meeting04:51
*** numans has joined #openstack-meeting04:55
*** yuanying has joined #openstack-meeting04:56
*** csomerville has joined #openstack-meeting04:58
*** afazekas has joined #openstack-meeting04:58
*** haleyb_ has quit IRC05:01
*** cody-somerville has quit IRC05:01
*** Wenzhi has quit IRC05:02
*** Wenzhi has joined #openstack-meeting05:02
*** yamamoto_ has quit IRC05:03
*** guoshan has joined #openstack-meeting05:03
*** mordred has joined #openstack-meeting05:04
*** greghaynes has joined #openstack-meeting05:04
*** HeOS has joined #openstack-meeting05:04
*** shashank_hegde has joined #openstack-meeting05:06
*** Wenzhi has quit IRC05:07
*** guoshan has quit IRC05:08
*** sdake_ has joined #openstack-meeting05:10
*** Wenzhi has joined #openstack-meeting05:12
*** sdake has quit IRC05:13
*** prateek_ has joined #openstack-meeting05:13
*** ayogi has joined #openstack-meeting05:14
*** dmorita has joined #openstack-meeting05:16
*** anteaya has quit IRC05:16
*** mordred has quit IRC05:18
*** sudipto has joined #openstack-meeting05:18
*** sudipto_ has joined #openstack-meeting05:18
*** dmorita has quit IRC05:21
*** cardeois has quit IRC05:22
*** thorst has joined #openstack-meeting05:24
*** cardeois has joined #openstack-meeting05:24
*** yuanying_ has joined #openstack-meeting05:26
*** mordred has joined #openstack-meeting05:26
*** trinaths has joined #openstack-meeting05:27
*** VW has joined #openstack-meeting05:27
*** anteaya has joined #openstack-meeting05:28
*** yuanying has quit IRC05:29
*** thorst has quit IRC05:30
*** anilvenkata has joined #openstack-meeting05:31
*** mkrai_ has quit IRC05:31
*** VW has quit IRC05:32
*** reedip has quit IRC05:33
*** yuanying has joined #openstack-meeting05:36
*** dbecker has quit IRC05:37
*** yuanying_ has quit IRC05:40
*** haleyb_ has joined #openstack-meeting05:41
*** yuanying_ has joined #openstack-meeting05:41
*** yuanying has quit IRC05:44
*** yamamoto_ has joined #openstack-meeting05:44
*** janki has joined #openstack-meeting05:46
*** reedip has joined #openstack-meeting05:46
*** sdake_ has quit IRC05:48
*** penick has joined #openstack-meeting05:50
*** nadya has joined #openstack-meeting05:55
*** e0ne has joined #openstack-meeting05:56
*** haleyb_ has quit IRC06:00
*** GB21 has quit IRC06:01
*** julim has quit IRC06:02
*** julim has joined #openstack-meeting06:04
*** guoshan has joined #openstack-meeting06:04
*** nadya has quit IRC06:07
*** guoshan has quit IRC06:09
*** sdake has joined #openstack-meeting06:09
*** ataraday has joined #openstack-meeting06:11
*** GB21 has joined #openstack-meeting06:14
*** emagana has joined #openstack-meeting06:15
*** enriquetaso has quit IRC06:17
*** emagana has quit IRC06:19
*** guoshan has joined #openstack-meeting06:23
*** julim has quit IRC06:23
*** julim has joined #openstack-meeting06:24
*** aeng has quit IRC06:24
*** sdake_ has joined #openstack-meeting06:28
*** sudipto_ has quit IRC06:28
*** sudipto has quit IRC06:28
*** thorst has joined #openstack-meeting06:29
*** gmann has quit IRC06:30
*** spzala has joined #openstack-meeting06:30
*** sdake has quit IRC06:30
*** rcernin has joined #openstack-meeting06:34
*** thorst has quit IRC06:34
*** spzala has quit IRC06:34
*** csomerville has quit IRC06:35
*** reedip has quit IRC06:39
*** iyamahat has joined #openstack-meeting06:43
*** kaisers__ has quit IRC06:43
*** bvandenh has quit IRC06:47
*** sudipto has joined #openstack-meeting06:51
*** sudipto_ has joined #openstack-meeting06:52
*** reedip has joined #openstack-meeting06:53
*** rbartal has joined #openstack-meeting06:55
*** Kiall has quit IRC06:56
*** reedip has quit IRC07:01
*** reedip has joined #openstack-meeting07:04
*** e0ne has quit IRC07:04
*** trinaths1 has joined #openstack-meeting07:08
*** trinaths1 has quit IRC07:09
*** e0ne has joined #openstack-meeting07:11
*** trinaths has quit IRC07:11
*** rcernin has quit IRC07:12
*** yuanying_ has quit IRC07:13
*** e0ne has quit IRC07:13
*** nkrinner_afk is now known as nkrinner07:18
*** irenab_ has joined #openstack-meeting07:19
*** trinaths has joined #openstack-meeting07:19
*** andreas_s has joined #openstack-meeting07:21
*** megm_ has quit IRC07:23
*** shz has quit IRC07:24
*** megm has joined #openstack-meeting07:25
*** mordred has quit IRC07:25
*** SergeyLukjanov has quit IRC07:25
*** Guest66666 has quit IRC07:27
*** kaisers_ has joined #openstack-meeting07:28
*** cardeois has quit IRC07:29
*** Guest66666 has joined #openstack-meeting07:29
*** alexpilo_ has joined #openstack-meeting07:29
*** castulo has quit IRC07:29
*** alexpilotti has quit IRC07:30
*** SergeyLukjanov has joined #openstack-meeting07:31
*** thorst has joined #openstack-meeting07:32
*** mordred has joined #openstack-meeting07:34
*** castulo has joined #openstack-meeting07:34
*** rcernin has joined #openstack-meeting07:34
*** cardeois has joined #openstack-meeting07:34
*** trinaths has left #openstack-meeting07:34
*** kaisers_ has quit IRC07:36
*** sshnaidm has joined #openstack-meeting07:37
*** GB21 has quit IRC07:39
*** thorst has quit IRC07:40
*** jtomasek has joined #openstack-meeting07:40
*** bvandenh has joined #openstack-meeting07:40
*** pcaruana has joined #openstack-meeting07:42
*** yamahata has quit IRC07:44
*** rasca has joined #openstack-meeting07:49
*** longxiongqiu has joined #openstack-meeting07:56
*** d0ugal has joined #openstack-meeting07:57
*** d0ugal has quit IRC07:57
*** d0ugal has joined #openstack-meeting07:57
*** mrunge_ has quit IRC07:59
*** sdake has joined #openstack-meeting07:59
*** akihito has joined #openstack-meeting08:00
*** julim has quit IRC08:00
*** eranrom has joined #openstack-meeting08:00
eranrom#startmeeting storlets08:00
openstackMeeting started Tue Dec  6 08:00:37 2016 UTC and is due to finish in 60 minutes.  The chair is eranrom. Information about MeetBot at http://wiki.debian.org/MeetBot.08:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.08:00
*** openstack changes topic to " (Meeting topic: storlets)"08:00
openstackThe meeting name has been set to 'storlets'08:00
eranromHi08:00
*** yuanying has joined #openstack-meeting08:01
*** longxiongqiu has quit IRC08:01
akihitoHi08:01
eranromakihito: Hi08:01
*** kota_ has joined #openstack-meeting08:02
kota_hello08:02
eranromkota_: Hi08:02
*** GB21 has joined #openstack-meeting08:02
akihitohi08:02
*** matrohon has joined #openstack-meeting08:02
eranromDo you know if Takashi plans on joining?08:02
*** sdake_ has quit IRC08:03
kota_he was willing to join here08:03
kota_he said when I asked 2 hours ago08:03
kota_eranrom:^^08:04
akihitoHe is absent...08:04
eranromok, We need him for the PTG topic08:04
*** mrunge has joined #openstack-meeting08:04
kota_and just get his response, it looks like he got another troublesome08:04
eranromI see. Hope he is ok.08:05
*** nadya has joined #openstack-meeting08:05
eranromSo lets start with the other topic:08:05
*** pnavarro has joined #openstack-meeting08:05
kota_so please go ahead today's topics08:05
*** bzhao has quit IRC08:06
kota_the other topic?08:06
eranrom#topic Big-Tent08:06
*** openstack changes topic to "Big-Tent (Meeting topic: storlets)"08:06
kota_k08:06
eranromAny comments on the steps I have suggested (https://wiki.openstack.org/wiki/Meetings/Storlets#Agenda:)08:06
eranromlist is on item 308:06
*** Wenzhi has quit IRC08:07
kota_looking08:07
*** shaohe_feng has joined #openstack-meeting08:07
kota_yeah, looks great for the agenda08:07
kota_and now on item3 ok08:08
-kota_- Merge Keystone V3 patch08:08
-kota_- Fix source headers08:08
-kota_- Move out container code to host08:08
-kota_- Port Ansible to devstack08:08
kota_eranrom: do you think of we need to merge all of them?08:08
kota_eranrom: or hope landing part of them and propose to get offical in parallel?08:09
eranromI guess the latter two are not really required08:09
eranromI can get back to Flavio after we merge the first two08:10
eranromand continue from there.08:10
kota_sounds good idea, we would include them as in our load map but not commitments08:11
kota_k08:11
*** adiantum has joined #openstack-meeting08:11
eranromok.08:11
eranrom#agreed08:11
kota_on the v3 patch, probably I have to do that in my homework.08:11
kota_because it looks like takashi has added +2 already, right?08:11
eranromkota_: sure08:11
eranromyep08:12
kota_let me check the patch link..08:12
kota_#link https://review.openstack.org/#/c/394168/08:12
kota_this one?08:12
eranromyes08:12
* eranrom will take care of headers while kota_ does homework :-)08:13
*** lpetrut has joined #openstack-meeting08:13
kota_er, recently, devstack gate has been changed keystone v3 default, we need that due to using devstack, make sense.08:13
*** brault has joined #openstack-meeting08:13
kota_eranrom: thanks for taking care of headers!08:13
eranromkota_: sure. yes we probably need that. Takashi wants it for quite a while now.08:14
kota_eranrom: quick question08:14
kota_eranrom: why do we need to update keystone v3 in *ansible scripts*?08:14
kota_eranrom: is it not used for building testing environment anymore?08:15
*** phil has joined #openstack-meeting08:15
*** phil is now known as Guest7449808:16
kota_I'm just looking at file list modified08:16
eranromThe ansible scripts perform various Swift operations that require a token, and so they need to authenticate using v3 now...08:16
*** shashank_hegde has quit IRC08:16
*** shaohe_feng has quit IRC08:17
eranromSpecifically, there is a role that enables an account for storlets. This requires creating several containers, and setting the storlet enabled attribute on the account08:17
kota_er...08:17
kota_k, getting, getting08:17
*** shaohe_feng has joined #openstack-meeting08:18
eranrom:-)08:18
kota_so the devstack is used just as instration for the gate now and we still need to setup something (e.g. account) via ansible08:18
*** ralonsoh has joined #openstack-meeting08:18
kota_and then, current script uses v2-like so that we need to update them.08:18
kota_right?08:19
*** frasantoro has joined #openstack-meeting08:19
kota_s/instaration/installation/08:19
eranromkota_: yes. The interesting point for me was to discover that although devstack installed Keystone with V3 API the current code was still working with V2 API08:19
eranromFor me it was a surprise.08:19
*** ljxiash has joined #openstack-meeting08:20
kota_eranrom: interesting08:20
eranromkeystone is full of surprises :-)08:20
kota_eranrom: and thanks, that info is *SUPER* helpful for my homework :P08:20
eranromkota_: sure08:20
eranromThis is all I had, so moving to open discussion08:21
eranrom#topic Open Discussion08:21
*** openstack changes topic to "Open Discussion (Meeting topic: storlets)"08:21
*** bvandenh has quit IRC08:21
eranromAnything else?08:21
kota_eranrom: not a big progress right now08:22
*** bvandenh has joined #openstack-meeting08:22
eranromkota_: Saw you posted a long running test patch. I guess you are looking at a long running storlet at the proxy.08:23
kota_not specifically only on the proxy but for now I'm making sure which param should work well on the timeout cases08:23
kota_to describe my co-worker who dosn't know the swift/storlets config in detail :/08:24
*** ljxiash has quit IRC08:24
*** mickeys has quit IRC08:24
kota_since that, he was starting to increase all timeout value up to enough to run the heavy task08:24
kota_but i don't want to do that because w/o knowledge increasing timeout may cause side-effect!08:25
kota_so that, now I'm making sure if storlet_timeout can work as I expected and we could use also node timeout for swift conf in default value.08:26
kota_even if it's heavy task.08:26
eranromkota_: right. Note that when running on an object node you may get different timeouts then when running on the proxy.08:26
kota_it's a08:26
kota_eranrom: exactly08:26
eranromkota_: different code path...08:27
kota_painful :/08:27
*** shaohe_feng has quit IRC08:27
eranromkota_: indeed. Doron and I have investigated this a lot in the past.08:27
kota_eranrom: in older days?08:28
eranromkota_: yes, abut a year ago08:28
eranromWe have mapped the problem, but we did not come up with a solution.08:28
kota_eranrom: i think, with recent work, the refactoring we have done would make a good shape to abstract the path for timeout08:28
kota_oh, maybe?08:28
kota_that problem still be there?08:29
eranromkota_: well, if you do not want to play with node timeout then yes, it is still there.08:29
eranromand may involve swift wsgi and/or eventlet code08:29
kota_eranrom: if you could comment to point out the problem in my patch, it could help me to understand.08:29
*** shaohe_feng has joined #openstack-meeting08:30
eranromkota_: Will do, I will recollect our findings first :-)08:30
kota_eranrom: thanks!08:30
eranromkota_: my pleasure!08:30
kota_that's all from me today.08:31
eranromkota_: thanks08:32
eranromIf there is nothing else we will get back 30 mins :-)08:32
*** julim has joined #openstack-meeting08:32
kota_:-)08:32
kota_that's good because I can use the 30 mins for the review of keystone v3 patch08:33
eranrom:-)08:33
eranromok so in that case:08:33
eranromThank you all for joining.08:33
eranromSee you on #openstack-storlets08:33
eranrom#endmeeting08:33
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"08:33
openstackMeeting ended Tue Dec  6 08:33:53 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)08:33
openstackMinutes:        http://eavesdrop.openstack.org/meetings/storlets/2016/storlets.2016-12-06-08.00.html08:33
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/storlets/2016/storlets.2016-12-06-08.00.txt08:33
openstackLog:            http://eavesdrop.openstack.org/meetings/storlets/2016/storlets.2016-12-06-08.00.log.html08:33
*** shaohe_feng has quit IRC08:37
*** zhangjl has left #openstack-meeting08:38
*** thorst has joined #openstack-meeting08:38
*** shaohe_feng has joined #openstack-meeting08:39
*** toscalix has joined #openstack-meeting08:41
*** emagana has joined #openstack-meeting08:42
*** priteau has joined #openstack-meeting08:42
*** Jizhaoxuan has joined #openstack-meeting08:44
*** Jizhaoxuan has left #openstack-meeting08:44
*** thorst has quit IRC08:44
*** nmagnezi has joined #openstack-meeting08:45
*** pnavarro has quit IRC08:45
*** kota_ has left #openstack-meeting08:46
*** mkoderer has joined #openstack-meeting08:46
*** egallen has joined #openstack-meeting08:46
*** egallen has quit IRC08:46
*** emagana has quit IRC08:46
*** shaohe_feng has quit IRC08:47
*** iyamahat has quit IRC08:48
*** shaohe_feng has joined #openstack-meeting08:50
*** zhonghua2 has joined #openstack-meeting08:53
*** ociuhandu has quit IRC08:53
*** saggi has joined #openstack-meeting08:54
*** oanson has joined #openstack-meeting08:55
*** shaohe_feng has quit IRC08:56
*** shaohe_feng has joined #openstack-meeting08:58
*** longxiongqiu has joined #openstack-meeting08:58
*** leon_wang has joined #openstack-meeting08:59
*** edisonxiang has joined #openstack-meeting08:59
*** chenying_ has joined #openstack-meeting09:00
saggi#startmeeting karbor09:01
openstackMeeting started Tue Dec  6 09:01:04 2016 UTC and is due to finish in 60 minutes.  The chair is saggi. Information about MeetBot at http://wiki.debian.org/MeetBot.09:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.09:01
*** openstack changes topic to " (Meeting topic: karbor)"09:01
openstackThe meeting name has been set to 'karbor'09:01
saggiHi everyone09:01
edisonxiangHello09:01
zhonghua2hi09:01
leon_wanghi09:01
*** dmorita has joined #openstack-meeting09:01
*** zhonghua2 is now known as zhonghua09:01
chenying_hi09:01
saggiyuval is on reserve duty09:02
*** longxiongqiu has quit IRC09:02
chenying_I submit a irc meeting topic rightnow.09:03
saggi#topic About the operation_logs API09:03
*** openstack changes topic to "About the operation_logs API (Meeting topic: karbor)"09:03
*** bvandenh has quit IRC09:03
saggiwho suggested this?09:03
chenying_yes I have a question about status in this API.09:04
*** zhangshuai has joined #openstack-meeting09:04
chenying_◦state in operation_logs have several values (running/finished/failed)09:05
*** GB21 has quit IRC09:05
chenying_◦"finished" means protection restAPI is called successfully or the protection action have been done successfully09:05
*** zengchen has joined #openstack-meeting09:05
saggifinished means that everything was done successfully09:06
*** dmorita has quit IRC09:06
saggithis includes all protect\restore\delete requests relating to the operation09:06
*** longxiongqiu has joined #openstack-meeting09:06
saggiok?09:08
chenying_It means that when we start vloume backup, the status in operation_logs finished means the checkpoint is available09:08
*** ociuhandu has joined #openstack-meeting09:08
saggiyes09:09
chenying_When  protect\restore\delete action is successful, the status of operation_logs must be updated to finished.09:10
chenying_OK I see09:10
edisonxiangsaggi: do you think whether we can reuse the table "scheduled_operation_logs"?09:10
edisonxianghttps://etherpad.openstack.org/p/operationlogs09:10
saggireuse for what?09:10
saggino09:11
*** longxiongqiu has quit IRC09:11
saggisince the operation might include multiple actions09:11
edisonxiangreuse "scheduled_operation_logs" table to show operation logs09:11
saggiand it's only finished when all the actions are over09:11
edisonxiangSo operation logs are none busineess of scheduledoperation and scheduledoperationlogs?09:12
saggiedisonxiang: I don't understand the question09:13
chenying_saggi  Does it mean that the operation_logs is inserted into database table in operationengine service, and the status of it is updated in portection service?09:13
edisonxiangor creat new tables to finish this feature?09:14
*** larainema has quit IRC09:14
*** larainema_ has joined #openstack-meeting09:15
saggiThe Operation Engine needs to track the progress of all the actions it starts.09:15
saggiIt needs to mark the result for each run of an operation.09:15
saggiThe run is successful only if all actions invoked were successful.09:15
*** gmann has joined #openstack-meeting09:15
edisonxiangSo can we reuse scheduledoperationlogs to record operationlogs?09:16
saggiI might be missing something. What is the difference between scheduledoperationlogs and operationlogs.09:17
chenying_saggi xinyong's question is that, Do we use scheduledoperationlogs database table to record thess data, or create a new database table for this api?09:17
edisonxiangsaggi: I am confused with the difference between scheduledoperationlogs and operationlogs.09:18
*** GB21 has joined #openstack-meeting09:18
edisonxiangsaggi: but now scheduedoperationlogs only record the protect workflow09:19
edisonxiangsaggi: perhaps we can take a look at this patch.https://review.openstack.org/#/c/298060/09:19
saggiedisonxiang: This is the log for the scheduled operations.09:21
edisonxiangsaggi: got it09:21
chenying_saggi I am clear about this operationlogs API. My question is that when to create/ update these operationlogs data?  xinyong's question is that where to save the data about operationlogs?09:22
chenying_xinyong plan to get the operationlogs data from scheduledoperationlogs database table, but its status only mean the protect api have been called successfully.09:23
edisonxiangsaggi: do you have some ideas what to show in the "operation logs" module of dashboard?09:24
*** thorst has joined #openstack-meeting09:24
edisonxiangshow scheduled operation logs or operation logs?09:25
*** mickeys has joined #openstack-meeting09:25
edisonxiangI am a little confused about this question09:26
*** amaretskiy has joined #openstack-meeting09:27
chenying_https://review.openstack.org/#/c/298060/ The operationlogs API in this patch only cover the protect action, it doesn't include restore\delete action. At present only protect action is invoked by operationengine service.09:27
*** strigazi_AFK is now known as strigazi09:28
*** adiantum has quit IRC09:28
saggiI don't understand why we even have 2 types of logs.09:29
edisonxiang:)09:29
*** adiantum has joined #openstack-meeting09:29
*** mickeys has quit IRC09:30
saggiAFAIK there should only be a log for scheduled operations runs.09:30
saggiWhen we start a scheduled operation we create a log for it that tracks it's progress.09:30
zhonghuaso do I09:30
saggiWhat is the other log tracking?09:30
*** spzala has joined #openstack-meeting09:30
chenying_saggi the scheduledoperationlogs database table have introduced to karbor with the implementation of operationengine servie. It is internal. It have not been exposed to user.09:31
*** thorst has quit IRC09:31
saggichenying, what are they for?09:31
chenying_saggi It is used for recording the call log of  scheduledoperation.  but its status now mean the protect api have been called successfully.09:33
*** spzala has quit IRC09:35
edisonxiangsaggi: understood. We will show logs which are created by scheduled operations in the Horizon09:36
saggiOK, the original way we planned on doing it was that whenever an scheduled operation is triggered a log is created. That log status is only changed to 'finish' when the whole operation was finished. Everything was done. Each operation can have entries in it. The entries are simple messages. They could notify the user something like: "Protect started on plan", "Protect finished on plan", "Started searching for old checkpoints"09:37
saggiThat way the user can see the stage the operation is at during it's run09:37
*** yanyanhu has quit IRC09:37
*** julim_ has joined #openstack-meeting09:38
saggiThe log is like a log file and the entries are log lines09:38
saggiThe DB schema needs to reflect that.09:38
*** yanyanhu has joined #openstack-meeting09:38
*** ricolin has quit IRC09:38
edisonxiangyeah09:38
edisonxiangIt seems we need to make some changes on the present table stucture09:39
*** julim has quit IRC09:39
saggi👍09:39
chenying_saggi  Yes I see.09:39
edisonxiang:P09:40
saggi#topic weekly meeting wiki page09:40
*** zhhuabj has quit IRC09:40
*** openstack changes topic to "weekly meeting wiki page (Meeting topic: karbor)"09:40
saggiI saw that other projects replace the entire page instead of keeping historic records of the agenda throughout time.09:41
*** bvandenh has joined #openstack-meeting09:41
saggiwhat do you guys think about it09:41
saggiI want to only display the next meeting's agenda and delete the old agendas09:41
zhonghuahow to replace? removement?09:41
saggiJust replace, after each meeting clear the page and change the date.09:42
edisonxiangsaggi: Agree with you09:43
edisonxiang+109:43
zhonghua+109:43
chenying_+109:43
saggiThan it's agreed.09:43
edisonxiangwe can delete the old agendas09:43
saggiI think it's better. Now you need to scroll the page to see the agenda09:44
saggiI'll do it now09:44
edisonxiangThanks saggi09:44
saggi#topic open discussion09:45
*** openstack changes topic to "open discussion (Meeting topic: karbor)"09:45
saggiI saw zengchen gave a +1 on https://review.openstack.org/#/c/397156/09:45
saggichenying if you give a +2 we can merge the spec09:45
saggiSo please see that you agree with it or give comments09:45
chenying_saggi I don't have any comments about yuval's plugins specs.  I have +1 already.09:46
*** sudipto_ has quit IRC09:47
*** sudipto has quit IRC09:47
chenying_But there are some more work to be considered about the implementations patch. I give some comments about it.09:47
saggichenying, sorry it was deleted because of an update09:47
saggichenying, good. Your feedback is much appreciated09:47
chenying_Ok I see. I will review the spec later.09:47
saggiAnything else?09:48
edisonxiangby the way, https://review.openstack.org/#/c/403965/09:48
*** sdake has quit IRC09:49
edisonxiangabout this patch, it seems like yizhihui has some questions09:49
chenying_karbor/services/protection/protectable_plugins/eisoo/oracle.py About the eisoo client module, I think it belong to the vendors's code, it a part of vendor plugins implementation. It could be moved to the directory of vendor plugins. What's your opinion about it?09:49
saggichenying, you mean like `karbor/services/protection/protectable_plugins/vendor/eisoo/oracle.py` ?09:50
chenying_My question is about vendor's client implementation. Put it to where?09:52
*** zhhuabj has joined #openstack-meeting09:52
zhonghuachenying_, what's your suggestion?09:52
saggiYou mean protectable implementation?09:53
saggiThe actual client needs to be a dependency not in out codebase like cinder-client09:53
chenying_I give a comment about the Directory of  vendor's client implementation in this patch. https://review.openstack.org/#/c/403965/09:53
edisonxiangI think the present code structure is very good. "karbor/services/protection/clients/eisoo.py"09:54
*** electrofelix has joined #openstack-meeting09:54
zhonghuachenying_, do you mean the karbor.services.protection.clents should be move out of framework folder into vendor folder?09:55
chenying_The vendor's protectable and protection plugins both need use vendor's client.  So my question is that put it to where?09:55
zhonghuas/move/moved09:55
chenying_vendor's client implementation.09:55
zhonghuaok, the model09:56
saggichenying, I understand. Why should we put it in a different folder?09:56
saggi/karbor/services/protection/clients/<vendor_name> is OK with me09:57
chenying_saggi IMO, the  client  is part of plugins implementation.09:57
*** gmann has quit IRC09:58
edisonxiangsaggi: +109:58
saggichenying what do you suggest?09:58
zhonghuasaggi, +109:58
chenying_+109:58
zhangshuai+109:58
*** akihito has quit IRC09:58
*** e0ne has joined #openstack-meeting09:58
*** amaretskiy has left #openstack-meeting10:01
edisonxiang:)10:01
chenying_#endmeeting karbor\10:01
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"10:01
openstackMeeting ended Tue Dec  6 10:01:47 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)10:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/karbor/2016/karbor.2016-12-06-09.01.html10:01
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/karbor/2016/karbor.2016-12-06-09.01.txt10:01
openstackLog:            http://eavesdrop.openstack.org/meetings/karbor/2016/karbor.2016-12-06-09.01.log.html10:01
edisonxiangbye10:02
saggi😖10:02
saggi😕10:02
chenying_bye10:02
*** zhurong has quit IRC10:03
*** askb has quit IRC10:03
*** tovin07_ has quit IRC10:05
*** nkrinner has quit IRC10:05
*** adiantum has quit IRC10:06
*** nkrinner has joined #openstack-meeting10:06
*** tovin07 has quit IRC10:09
*** zhangshuai has quit IRC10:09
*** Zara_ is now known as Zara10:10
*** zhangshuai has joined #openstack-meeting10:11
*** sambetts|afk is now known as sambetts10:13
*** oanson has quit IRC10:15
*** nkrinner has quit IRC10:15
*** aweeks has quit IRC10:16
*** shaohe_feng has quit IRC10:17
*** nkrinner has joined #openstack-meeting10:17
*** shaohe_feng has joined #openstack-meeting10:17
*** baoli has joined #openstack-meeting10:24
*** mickeys has joined #openstack-meeting10:26
*** VW has joined #openstack-meeting10:27
*** thorst has joined #openstack-meeting10:28
*** baoli has quit IRC10:28
*** VW has quit IRC10:32
*** mickeys has quit IRC10:32
*** guoshan has quit IRC10:34
*** thorst has quit IRC10:36
*** shu-mutou is now known as shu-mutou-AWAY10:42
*** e0ne has quit IRC10:45
*** epico has quit IRC10:46
*** rfolco has joined #openstack-meeting10:49
*** kevinz has quit IRC10:50
*** dfflanders has quit IRC10:53
*** yanyanhu has quit IRC11:01
*** sdague has joined #openstack-meeting11:02
*** e0ne has joined #openstack-meeting11:03
*** chrisplo has joined #openstack-meeting11:10
*** huanxuan has joined #openstack-meeting11:11
*** dimtruck is now known as zz_dimtruck11:13
*** e0ne has quit IRC11:15
*** chrisplo has quit IRC11:15
*** zhangshuai has quit IRC11:21
*** zhangshuai has joined #openstack-meeting11:21
*** claudiub|2 has joined #openstack-meeting11:22
*** kevinz has joined #openstack-meeting11:23
*** mickeys has joined #openstack-meeting11:28
*** longxiongqiu has joined #openstack-meeting11:29
*** julim_ has quit IRC11:32
*** mickeys has quit IRC11:32
*** thorst has joined #openstack-meeting11:34
*** faizy has joined #openstack-meeting11:35
*** alexpilo_ has quit IRC11:36
*** alexpilotti has joined #openstack-meeting11:37
*** ociuhandu has quit IRC11:37
*** GB21 has quit IRC11:38
*** thorst has quit IRC11:41
*** alexpilotti has quit IRC11:41
*** e0ne has joined #openstack-meeting11:43
*** lpetrut has quit IRC11:44
*** prateek_ has quit IRC11:45
*** cdelatte has joined #openstack-meeting11:46
*** alexpilotti has joined #openstack-meeting11:47
*** emagana has joined #openstack-meeting11:49
*** adiantum has joined #openstack-meeting11:50
*** nkrinner has quit IRC11:50
*** alexpilotti has quit IRC11:51
*** faizy has quit IRC11:54
*** GB21 has joined #openstack-meeting11:55
*** nkrinner has joined #openstack-meeting11:58
*** nkrinner has quit IRC12:06
*** nkrinner has joined #openstack-meeting12:06
*** GB21 has quit IRC12:07
*** e0ne has quit IRC12:07
*** e0ne has joined #openstack-meeting12:09
*** lpetrut has joined #openstack-meeting12:11
*** nadya has quit IRC12:14
*** zhangshuai has left #openstack-meeting12:14
*** GB21 has joined #openstack-meeting12:16
*** Cibo_ has quit IRC12:16
*** rtheis has joined #openstack-meeting12:17
*** acoles_ is now known as acoles12:18
*** edisonxiang has left #openstack-meeting12:20
*** lpetrut has quit IRC12:27
*** mickeys has joined #openstack-meeting12:29
*** thorst has joined #openstack-meeting12:30
*** mickeys has quit IRC12:33
*** cdub has joined #openstack-meeting12:35
*** manikanta_tadi has quit IRC12:37
*** nadya has joined #openstack-meeting12:38
*** ociuhandu has joined #openstack-meeting12:41
*** larainema_ has quit IRC12:46
*** larainema_ has joined #openstack-meeting12:46
*** Kevin_Zheng has quit IRC12:46
*** Kevin_Zheng has joined #openstack-meeting12:47
*** cdub has quit IRC12:47
*** nadya has quit IRC12:49
*** nadya has joined #openstack-meeting12:51
*** cdelatte has quit IRC12:51
*** GB21 has quit IRC12:54
*** lvdongbing has joined #openstack-meeting12:56
*** belmoreira has joined #openstack-meeting12:56
*** Ruijie_ has joined #openstack-meeting12:58
*** cdelatte has joined #openstack-meeting12:58
*** XueFeng has joined #openstack-meeting12:58
*** yanyanhu has joined #openstack-meeting12:59
*** ayogi has quit IRC12:59
yanyanhu#startmeeting senlin12:59
openstackMeeting started Tue Dec  6 12:59:50 2016 UTC and is due to finish in 60 minutes.  The chair is yanyanhu. Information about MeetBot at http://wiki.debian.org/MeetBot.12:59
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.12:59
*** openstack changes topic to " (Meeting topic: senlin)"12:59
openstackThe meeting name has been set to 'senlin'12:59
yanyanhuhello, everyone13:00
XueFenghi,all13:00
*** julim has joined #openstack-meeting13:00
yanyanhuhi, XueFeng13:00
lvdongbinghi13:00
yanyanhuhi, lvdongbing13:00
XueFenghi,yanyan,dongbing13:00
lvdongbing:)13:01
Ruijie_evening :)13:01
yanyanhuevening :)13:01
*** yamamoto_ has quit IRC13:01
Qiminghi13:01
yanyanhuhi, Qiming13:01
*** nkrinner has quit IRC13:01
yanyanhuok, lets start13:02
*** nkrinner has joined #openstack-meeting13:02
yanyanhuhere is the agenda, please feel free to add items13:02
yanyanhuhttps://wiki.openstack.org/wiki/Meetings/SenlinAgenda#Agenda_.282016-11-22_1300_UTC.2913:02
yanyanhu#topic ocata workitems13:02
*** openstack changes topic to "ocata workitems (Meeting topic: senlin)"13:02
yanyanhuhttps://etherpad.openstack.org/p/senlin-ocata-workitems13:02
yanyanhuok, lets start from ocata workitems13:02
yanyanhutest13:03
yanyanhuI think Ruijie_ has spent sometime to understand senlin rally plugin?13:03
yanyanhusome time13:03
Ruijie_yes, yanyanhu, working on it13:04
yanyanhurelated workitem has been put back to TODO list, so please feel free to pick it up :)13:04
yanyanhuthanks a lot for working on t13:04
*** elynn has joined #openstack-meeting13:04
yanyanhuplease ping me any time you meet problem13:04
yanyanhuhi, electrofelix13:04
Ruijie_just proposed a patch about cluster_scale_in'13:04
Ruijie_https://review.openstack.org/#/c/407433/13:04
elynnHi sorry I'm late.13:04
Ruijie_sure :)13:04
yanyanhusorry, electrofelix, wrong ping :)13:05
yanyanhuhi, elynn13:05
yanyanhuelynn, no problem :)13:05
elynn;)13:05
yanyanhuok, next one13:05
yanyanhuHealth management13:05
*** lhx_ has quit IRC13:05
yanyanhuxinhui is not here I guess?13:05
yanyanhuI have read the patch xinhui proposed13:06
*** cdub has joined #openstack-meeting13:06
*** lin_yang has quit IRC13:06
*** lin_yang has joined #openstack-meeting13:06
yanyanhuit looks good13:06
yanyanhujust a small question about the detail13:06
yanyanhumay need to confirm with her offline13:07
elynnHave you discuss about it?13:07
yanyanhuno, just left comment there13:07
yanyanhulet me find the patch13:07
yanyanhuhttps://review.openstack.org/#/c/402296/13:07
yanyanhuthis one13:07
yanyanhujust have a question about the location to generate event13:08
*** huanxuan has quit IRC13:09
yanyanhuthe same as the question from Michael13:09
*** huanxuan has joined #openstack-meeting13:09
yanyanhuI recalled xinhui said ocatavia team hope us to join their meeting to discuss this proposal13:10
yanyanhumay need to have further discussion on it13:10
*** haleyb_ has joined #openstack-meeting13:10
*** gouthamr has joined #openstack-meeting13:10
yanyanhuok, lets move on13:10
*** gouthamr has quit IRC13:10
*** xuhaiwei has joined #openstack-meeting13:10
yanyanhuversioned request13:10
*** adiantum has quit IRC13:10
yanyanhuonly receiver_notify and webhook_trigger left I guess13:11
yanyanhuhi, XueFeng, has your part been done?13:11
XueFengaction create/delete need to do13:11
Qimingseems there are still a few left to do13:11
yanyanhuI see13:11
*** sdake has joined #openstack-meeting13:11
yanyanhuwill work on it soon13:11
yanyanhuhope this can be done by this week13:12
XueFengIf senlinclient need add action create/delete?13:12
XueFengOK13:12
XueFengWill do it tomorrow13:12
yanyanhusince next week will be the time for ocata-213:12
yanyanhuXueFeng, thanks a lot :)13:12
Qimingjust search the word 'request_context'13:12
*** gouthamr has joined #openstack-meeting13:12
Qimingif all have changed to 'request_context2', it means we have get the whole thing completed13:13
yanyanhuyes13:13
XueFengok13:13
yanyanhuthan we can remove those old service calls13:13
*** julim_ has joined #openstack-meeting13:13
yanyanhuand switch to new ones13:13
Qimingrename all the xyz2 to xyz13:14
yanyanhuyep13:14
XueFengyes13:14
yanyanhuok, lets move on13:14
yanyanhucontainer profile13:14
yanyanhuhaiwei is also not here I think13:14
xuhaiweiI am here13:14
yanyanhusorry :)13:14
xuhaiweijust get in13:15
*** julim has quit IRC13:15
XueFengAbout container, I used it this week.@xuhaiwei13:15
yanyanhuXueFeng, met any problem?13:15
xuhaiweiXueFeng, you can report bug :)13:15
xuhaiweishall we discuss about the container image?13:16
yanyanhuxuhaiwei, I noticed some change on DB apis13:16
yanyanhuhttps://review.openstack.org/#/c/404547/13:16
yanyanhubut just some user invisible change13:17
XueFengNeed some guideline, I can't  use it smooth:(13:17
XueFengsmoothly13:17
yanyanhuI guess we still don't have a doc or guide for creating container cluster :)13:17
XueFengNeed add13:18
QimingXueFeng, does it work?13:18
yanyanhuthat will be the best if there could be an example13:18
QimingI was only reading the code and doing imagination, aka, day dreaming13:18
XueFengI create a vm cluster13:18
xuhaiweiXueFeng, maybe this can help you a little https://github.com/openstack/senlin/blob/master/doc/specs/approved/container-cluster.rst13:19
*** rbudden has joined #openstack-meeting13:19
*** xionchen_ has joined #openstack-meeting13:19
XueFenguse ubuntu image which installed docker and py-docker13:19
*** lamt has joined #openstack-meeting13:20
xuhaiweiXueFeng, the image doesn't work, I think13:20
xuhaiweiXueFeng, you should make the docker daemon running in the vm when it is started13:20
XueFengI do this13:21
XueFengWe can discuss in #senlin later13:21
xuhaiweiok, I used to test it before, it worked, but didn't test it recently13:21
yanyanhuyes, and I think we need a doc for it finally13:22
xuhaiweiyanyanhu, yes, agree13:22
yanyanhuor at least a simple guide :)13:22
XueFengThe biggest problem maybe the docker network?@xuhaiwei13:22
yanyanhuto help user understand how to set it up13:22
*** pradk has joined #openstack-meeting13:22
xuhaiweiXueFeng, I am not sure, I didn't meet the network problem before13:23
yanyanhuXueFeng, you mean the network connection between senlin engine and docker deamon inside VM?13:23
xuhaiweiI think so13:24
XueFengYes13:24
Qimingwhy is that a problem?13:24
yanyanhuif senlin-engine is not located in network controller, that could be a problem13:24
Qimingthen heat won't be able to do software config, right?13:25
*** Akis_ has quit IRC13:25
xuhaiweiXueFeng, you should confirm if the docker client get the right url to docker daemon13:25
Qimingall os-collect-config ... things will break13:25
yanyanhuum, it's a little different I think13:25
yanyanhubut basically yes13:25
Qimingand ansible won't be usable13:25
yanyanhuright13:25
Qimingalthough I know a lot of people/projects are deploying software into vms using ansible13:26
Qimingansible is just a ssh13:26
xuhaiweiaccording to my test, if docker client gets the right url, it can reach to the docker daemon13:26
yanyanhuso, haiwei, maybe you can share some details abot the deployment progress with XueFeng13:26
xuhaiweisure, yanyanhu13:27
XueFengthanks :)13:27
yanyanhuthanks, xuhaiwei13:27
yanyanhuok, lets talk more about this issue later13:28
yanyanhulets move on13:28
yanyanhuevent/notification13:28
xuhaiweiXueFeng, I think you need to check two things, if docker engine is running, and if docker client got the right url13:28
yanyanhuhi, Qiming, I think most work has been done?13:28
XueFengok. xuhaiwei13:28
yanyanhuthe basic support13:28
Qiminglast patch for notification working poc is there for review13:28
Qimingnext thing is about adding some configuration options13:29
*** julim_ has quit IRC13:29
yanyanhuhttps://review.openstack.org/40659513:29
yanyanhuthis one13:29
Qimingso that users can customize the event types and levels to log, even options for different drivers13:29
yanyanhuok, great13:29
*** julim has joined #openstack-meeting13:29
Qimingthen ... docs13:29
yanyanhuthen we can write some story about it13:30
yanyanhuyes13:30
*** askb has joined #openstack-meeting13:30
*** julim has quit IRC13:30
*** mickeys has joined #openstack-meeting13:30
*** emagana has quit IRC13:30
*** emagana_ has joined #openstack-meeting13:30
*** huanxuan has quit IRC13:30
yanyanhuwill review the patch soon13:30
*** askb has quit IRC13:30
*** spzala has joined #openstack-meeting13:31
*** rossella_s has quit IRC13:31
yanyanhuso those are all items in the list13:31
*** julim has joined #openstack-meeting13:31
*** lhx_ has joined #openstack-meeting13:31
yanyanhuif there is no more question, lets go to next topic13:31
*** julim has quit IRC13:31
Qimingone thing about docker13:31
Qimingjust 1 min13:31
*** rossella_s has joined #openstack-meeting13:31
yanyanhuyes13:32
*** emagana_ has quit IRC13:32
Qimingxuhaiwei, pls review https://review.openstack.org/#/c/407412/13:32
*** julim has joined #openstack-meeting13:32
Qimingit is about a refactoring of the dependency building13:32
*** julim has quit IRC13:32
Qimingthx13:32
*** julim has joined #openstack-meeting13:33
*** nkrinner has quit IRC13:33
*** julim has quit IRC13:33
yanyanhuok, lets move on?13:33
*** julim has joined #openstack-meeting13:33
Qimingsure13:34
yanyanhu#topic Senlin based VDU support in Taker13:34
*** openstack changes topic to "Senlin based VDU support in Taker (Meeting topic: senlin)"13:34
*** julim has quit IRC13:34
yanyanhuhi, xuhaiwei, still there?13:34
*** mickeys has quit IRC13:34
Qiming... Tacker13:34
*** julim has joined #openstack-meeting13:34
yanyanhuah, sorry, misclick13:34
yanyanhuso have you guys reply to the invitation?13:34
yanyanhuto join the meeting in Dec.1413:35
*** julim has quit IRC13:35
Ruijie_what invitation13:35
*** julim has joined #openstack-meeting13:35
yanyanhu0530UTC13:35
QimingI saw haiwei responded13:35
*** julim has quit IRC13:35
yanyanhuRuijie_, tacker team invite us to join their weekly meeting to discuss the senlin based VDU support13:35
*** spzala has quit IRC13:36
yanyanhuQiming, ok13:36
*** nkrinner has joined #openstack-meeting13:36
yanyanhuso maybe we can have a discussion about it before that meeting13:36
Ruijie_thanks yanyanhu, will check13:36
yanyanhuto make everything clear13:36
Qiminggood idea13:37
yanyanhuRuijie_, it's not a public invitation :) but we both can join it13:37
*** emagana has joined #openstack-meeting13:37
*** acabot__ has joined #openstack-meeting13:37
yanyanhuyes, since I think not everyone of the team is clear about the background or the purpose of that proposal13:37
yanyanhuthis is an important use case for us I believe13:37
XueFengok , whis url?13:37
XueFengwhere13:37
*** chrisplo has joined #openstack-meeting13:38
yanyanhuso hope everyone can get better understand on it13:38
Qimingthe major concern, as far as I understand, is about translating TOSCA into policies parsable by Heat (or Senlin)13:38
yanyanhuXueFeng, will ask haiwei and share it with the team13:38
*** emagana_ has joined #openstack-meeting13:38
Qiminghttps://review.openstack.org/#/c/352943/13:38
*** emagana has quit IRC13:39
Qimingin the NFV world, people need to manage resource (their term, VDUs) pools, making them scalable and resilient13:39
Qimingthat is a high-level requirement13:39
yanyanhuactually I didn't quite understand that diagram...13:39
XueFenggreat, will check13:40
yanyanhuespecially about the translation for hot template which will be used as profile spec13:40
QimingTacker is mainly about VNF orchestration, and they don't want to reinvent the wheel, doing everything from scratch13:40
*** fguillot has joined #openstack-meeting13:41
Qimingit is a tosca parser thing, yanyanhu, I asked Sahdev about this, it is a trivial job for them13:41
yanyanhuI see.13:41
Qiminggenerating heat templates or senlin spes means almost the same to them13:41
yanyanhuyes, if the translation can be done between tosca template and senlin profile directly, that will be the best13:41
Qimingjust the Tacker team prefers using heat, which can bundle a lot of things together13:41
*** alraddarla_ has joined #openstack-meeting13:41
yanyanhuQiming, yes, understand that requirement13:42
yanyanhusince vm cluster is not the only resource they need to orchestrate13:42
Qimingwhat I wanted to remind them is about operation13:42
*** peterlisak has quit IRC13:42
*** onovy has quit IRC13:42
*** enriquetaso has joined #openstack-meeting13:42
*** chrisplo has quit IRC13:42
Qimingthey will experience a lot of headaches if sticking to large templates for all use cases13:43
*** nkrinner has quit IRC13:43
yanyanhuyes, that could be a problem13:43
QimingI believe haiwei has some more details, especially regarding the translation and landing workflow13:44
yanyanhuyes, want to listen to his idea13:44
*** xuhaiwei has quit IRC13:44
*** faizy has joined #openstack-meeting13:44
yanyanhuwill talk with him tomorrow to find a time for further discussion13:44
yanyanhuto help the team to understand it13:44
yanyanhuthrough irc or call13:44
Qimingmeeting time: meeting to 0530UTC starting Wed Dec 14th13:44
Qimingsounds great13:45
yanyanhuyes, hope everyone who is interested in this topic can join it13:45
yanyanhuok, any more question about this topic?13:45
yanyanhuok, open discussion13:46
yanyanhu#topic open discussion13:46
*** openstack changes topic to "open discussion (Meeting topic: senlin)"13:46
yanyanhuoh, one thing I want to remind the team is next week will be ocata 213:47
Qiming... what?13:47
yanyanhuyes, Dec 12-1613:47
yanyanhubased on the schedule13:47
yanyanhuthis is a really short cycle...13:48
yanyanhuand ocata3 will be Jan 23-2713:48
yanyanhuthe last week before China spring festival13:48
Qimingokay13:48
yanyanhuso please pay more attention on the timeline :)13:49
Qimingare we gonna make some release plans?13:49
*** yamamoto has joined #openstack-meeting13:49
yanyanhuQiming, yes, definitely13:49
yanyanhuI will try to start a etherpad on it13:49
yanyanhuand hope to have further discussion based on it13:49
Qimingmaybe just using the ocata workitems etherpad?13:50
yanyanhuQiming, yes13:50
Qiminghighlight some work items we want to complete by O2 and O3?13:50
yanyanhuwill list our goals there13:50
yanyanhuthose goals we setup at the beginning of this cycle13:50
Qimingokay13:51
yanyanhu#action yanyanhu list goals of ocata release in etherpad13:51
Qimingguys, I just did some bad things13:51
yanyanhuwhat...13:51
Qimingself approved a patch again13:51
Qiminghttps://review.openstack.org/#/c/407427/13:51
QimingI commited it on master branch13:51
yanyanhuno problem :)13:51
Qimingthen ... dependencys become a mess again13:52
yanyanhu...13:52
Qiminganyway, pls review13:52
yanyanhuthat is a bad news...13:52
yanyanhusure13:52
Qimingdeleted 32 lines of code with that patch, :D13:52
*** tuhv has joined #openstack-meeting13:52
*** irenab_ has quit IRC13:52
yanyanhu:)13:52
*** longxiongqiu has quit IRC13:52
XueFeng:)13:53
yanyanhuwill looks through those opened patches tomorrow13:53
yanyanhutrapped by some other things recently...13:53
*** longxiongqiu has joined #openstack-meeting13:53
yanyanhuok, any more topics for discussion :)13:53
*** hrybacki|l4mG3 is now known as hrybacki13:53
yanyanhuif not, we can release the channel a litte earlier this time :P13:54
XueFengAbout bare metal13:54
Ruijie_no from me :)13:54
yanyanhuXueFeng, yes13:54
Qimingno from me13:55
XueFengDoes it in progress?13:55
yanyanhuXueFeng, nope I think13:55
*** nkrinner has joined #openstack-meeting13:55
yanyanhubut we do need support on baremetal13:55
XueFengok13:56
yanyanhuso very appreciative if anyone can work on it :)13:56
*** baoli has joined #openstack-meeting13:56
XueFengyep13:56
yanyanhuok, I think that's all for this meeting13:56
yanyanhuthanks all you guys for joining13:56
yanyanhuhave a good night :)13:57
XueFengNeed more discuss about it.13:57
yanyanhuXueFeng, sure13:57
elynnthanks and have a good night13:57
yanyanhuwe can discuss it later13:57
XueFenggood night13:57
yanyanhu#endmeeting13:57
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"13:57
openstackMeeting ended Tue Dec  6 13:57:31 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)13:57
openstackMinutes:        http://eavesdrop.openstack.org/meetings/senlin/2016/senlin.2016-12-06-12.59.html13:57
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/senlin/2016/senlin.2016-12-06-12.59.txt13:57
openstackLog:            http://eavesdrop.openstack.org/meetings/senlin/2016/senlin.2016-12-06-12.59.log.html13:57
*** yanyanhu has quit IRC13:57
*** tuhv has quit IRC13:58
*** baoli has quit IRC13:58
*** baoli has joined #openstack-meeting13:58
*** baoli has quit IRC13:59
*** korzen has joined #openstack-meeting13:59
*** baoli has joined #openstack-meeting13:59
*** tuhv_ has joined #openstack-meeting13:59
*** lblanchard has joined #openstack-meeting13:59
*** nadya has quit IRC13:59
*** shintaro has joined #openstack-meeting14:00
*** emagana_ has quit IRC14:00
rossella_stime to start14:00
rossella_s#startmeeting networking14:00
*** prateek has joined #openstack-meeting14:00
openstackMeeting started Tue Dec  6 14:00:19 2016 UTC and is due to finish in 60 minutes.  The chair is rossella_s. Information about MeetBot at http://wiki.debian.org/MeetBot.14:00
*** boden has joined #openstack-meeting14:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:00
*** openstack changes topic to " (Meeting topic: networking)"14:00
openstackThe meeting name has been set to 'networking'14:00
ataradayhi14:01
rossella_sI hope somebody is there for the team meeting or are you all on holidays?14:01
rossella_sataraday, hi14:01
johnsomo/14:01
*** lamt has quit IRC14:01
rossella_s#topic Announcements14:01
*** openstack changes topic to "Announcements (Meeting topic: networking)"14:01
*** elynn has quit IRC14:01
dasmo/14:01
*** liuyulong_ has joined #openstack-meeting14:02
rossella_sjust wanted to reminder reviewers to have a look at the dashboard to identify priorities14:02
rossella_s#link http://status.openstack.org/reviews/14:02
*** lamt has joined #openstack-meeting14:02
*** trevormc has joined #openstack-meeting14:02
rossella_sthe PTG is also approaching14:02
alraddarla_o/14:02
dasmtalking about priorities.14:02
rossella_s#link https://www.openstack.org/ptg/14:02
dasmnext week is O-214:02
dasm#link https://releases.openstack.org/ocata/schedule.html#o-214:03
*** nadya has joined #openstack-meeting14:03
*** nadya has quit IRC14:03
rossella_sdasm indeed14:03
*** nadya has joined #openstack-meeting14:03
rossella_sI don't have any other announcement, let's move on14:04
rossella_s#link https://launchpad.net/neutron/+milestone/ocata-214:04
rossella_s#topic blueprints14:04
*** openstack changes topic to "blueprints (Meeting topic: networking)"14:04
*** nadya has quit IRC14:04
*** magical_bowtie is now known as fdegir14:04
rossella_sI wanted to give an update regarding the sec group logging blueprint14:04
rossella_s#link https://review.openstack.org/#/c/203509/14:05
rossella_sthe spec is in a good shape and I'd like to ask other people to review it14:05
*** Reedip_ has joined #openstack-meeting14:06
rossella_sdoes anybody want to add anything else about blueprints?14:06
ataradayenginefacade is in progress :)14:06
*** nadya has joined #openstack-meeting14:06
*** yamamoto has quit IRC14:07
rossella_sataraday, great!14:07
rossella_s#topic OVO/no API downtime?14:07
*** openstack changes topic to "OVO/no API downtime? (Meeting topic: networking)"14:07
ataradayit will require several refactors which are in progress. I want to ask to take a look at this https://review.openstack.org/#/c/398873/ breaking one :)14:07
*** Ruijie_ has quit IRC14:07
*** ihrachys has joined #openstack-meeting14:08
*** ihrachys has left #openstack-meeting14:08
*** rbartal has quit IRC14:08
korzenHi, so we are progressing with OVO adoption14:08
rossella_sIt seems I have changed topic too early14:08
*** oanson has joined #openstack-meeting14:08
korzen#link https://review.openstack.org/#/q/topic:bp/adopt-oslo-versioned-objects-for-db14:08
korzenI have updated the devref14:09
korzen#link https://review.openstack.org/#/c/336518/ Docs for NeutronDbObject:14:09
rossella_skorzen, cool14:09
korzenIhar has updated the spec:14:09
korzen#link https://review.openstack.org/386685 Plan to support no-downtime upgrade for neutron-server14:09
*** prateek has quit IRC14:09
*** liuyulong_ has quit IRC14:09
korzenplease take a look and review14:09
*** emagana has joined #openstack-meeting14:09
korzenone thing that is still not addressed is that we have db object as property in NeutronDbObject14:10
korzenand it is detached from sesssion14:10
korzenwhich is blocking the integration of OVO with extensions14:10
*** yamamoto has joined #openstack-meeting14:10
korzenbecause extensions that are defining the relationship in DB14:11
*** liuyulong_ has joined #openstack-meeting14:11
korzenare not able to call its extension when extend_<port/subnet/network>_dict is called14:11
*** yamamoto has quit IRC14:11
*** faizy_ has joined #openstack-meeting14:11
ataradaykorzen, I faced the same with new enginefacade14:11
korzenataraday, oh, I wanted to get in touch with you to see if you have the solution...14:12
korzenthe first online data migration will be tried for distributed port binding for LM14:13
korzenwe will see how it will go14:13
*** faizy has quit IRC14:13
*** lindycoder has joined #openstack-meeting14:14
lindycodero/14:14
korzenand I guess that is all14:14
*** longxiongqiu has quit IRC14:14
*** electrocucaracha has joined #openstack-meeting14:14
ataradaykorzen, I and Kevin decided to move call extend_<port/subnet/network>_dict under the same session or do context.session.add(obj) before, you can ping me for details14:14
korzenataraday, ok thanks14:15
*** yangyapeng has joined #openstack-meeting14:15
*** prateek has joined #openstack-meeting14:15
rossella_skorzen, anything else to add?14:16
korzenit is all14:16
*** mriedem has joined #openstack-meeting14:16
rossella_skorzen, thanks14:16
rossella_s#topic Bugs and Gate issues14:16
*** openstack changes topic to "Bugs and Gate issues (Meeting topic: networking)"14:16
rossella_skeep an eye on the CI and let's try to keep the failure rate of the tests under control14:17
rossella_s#link http://grafana.openstack.org/dashboard/db/neutron-failure-rate14:17
johnsomI wanted to mention that I have finished moving the neutron-lbaas bugs out of the neutron launchpad.14:17
johnsomPlease move any future lbaas bugs you see to the octavia project.14:18
*** Reedip_ has left #openstack-meeting14:18
rossella_sthanks johnsom14:18
rossella_sit seems the failure rate of the integrated tempest job has a spike14:19
rossella_sthis week's bug depute is mlavalle, it's probably too early for him14:19
*** rbartal has joined #openstack-meeting14:19
haleyb_rossella_s: the grenade job has a spike, fix for that in progress, https://review.openstack.org/#/c/406428/14:19
haleyb_rossella_s: i'm actually this week, but the week just started :)14:20
rossella_shaleyb_ I was going to ping you next...thanks for the link14:20
haleyb_miguel is moving this week14:20
rossella_sthen the wiki is wrong :D14:20
haleyb_yes, i'll fix it14:20
*** dprince has joined #openstack-meeting14:21
rossella_sno, sorry, it was me, the wiki is right14:21
rossella_shaleyb_, anything else to report this week?14:21
*** yamamoto has joined #openstack-meeting14:21
*** lvdongbing has quit IRC14:22
haleyb_there have not been any critical bugs filed this week (yet)14:22
rossella_scool!14:22
njohnstono/14:22
rossella_sany volunteer for being deputy next week?14:23
haleyb_i don't know about last week, but don't remember much, people have been picking things up14:23
*** emagana has quit IRC14:23
haleyb_i think miguel is next week14:23
*** john-davidge has joined #openstack-meeting14:23
*** yamamoto has quit IRC14:24
rossella_smiguel is week 12/12, right? for me next week should be 19/1214:24
*** donghao has joined #openstack-meeting14:24
*** jamesdenton has joined #openstack-meeting14:24
*** faizy_ has quit IRC14:25
haleyb_i'm starting the 5th, he's the 12th14:25
rossella_sany volunteer for week starting the 19th?14:25
*** yamamoto has joined #openstack-meeting14:25
*** pfallenop has quit IRC14:25
rossella_smaybe korzen ?14:26
korzenrossella_s, I'm planning to have time off next week14:26
john-davidgeI can do it again if there are no other volunteers14:26
rossella_sjohn-davidge, thanks a lot!14:27
*** emagana has joined #openstack-meeting14:27
rossella_sit's going to be a quiet week I think14:27
john-davidgerossella_s: No problem :)14:27
john-davidgeUnless Santa's workshop runs on neutron...14:27
rossella_s#action john-davidge bug deputy for week the 19th14:27
*** yamamoto has quit IRC14:27
rossella_s#topic Docs14:28
*** openstack changes topic to "Docs (Meeting topic: networking)"14:28
rossella_sany update on this?14:28
*** liuyulong_ has quit IRC14:28
*** VW has joined #openstack-meeting14:28
john-davidgeTrunking guide patch is v close to merging https://review.openstack.org/#/c/361776/14:29
rossella_ssweet14:30
john-davidgeCurrently just needs naother docs core, but neutron reviewers always welcome14:30
john-davidge*another14:30
rossella_s:)14:30
*** mickeys has joined #openstack-meeting14:30
rossella_s#topic OSC transition14:31
*** openstack changes topic to "OSC transition (Meeting topic: networking)"14:31
rossella_samotoki is not around14:31
*** yamamoto has joined #openstack-meeting14:32
njohnstonI hope amotoki is feeling better, I had heard he was sick14:32
rossella_sI hope that too14:32
rossella_sduring last team meeting armax was asking for volunteers to work on this front14:33
rossella_splease stand up if you'd like to help14:33
*** XueFeng has quit IRC14:33
*** yamamoto has quit IRC14:34
rossella_s#topic Neutron-lib and planned neutron refactoring14:34
*** openstack changes topic to "Neutron-lib and planned neutron refactoring (Meeting topic: networking)"14:35
*** mickeys has quit IRC14:35
HenryGhi14:35
rossella_sHenryG, hi!14:35
rossella_sHenryG, can you update us on the neutron lib work?14:36
HenryGMost of the impacting patches I proposed and alerted about have merged14:36
rossella_snice14:36
HenryGIt seems the world did not come to an end14:36
HenryGNext up is https://review.openstack.org/39989114:37
sindhurossella_s: a lot of OSC work is being taken by ppl here at OSIC and all the major transitions have patches already https://etherpad.openstack.org/p/osc-neutron-support14:37
*** Cibo_ has joined #openstack-meeting14:37
*** dbecker has joined #openstack-meeting14:37
HenryGI will rebase it shortly14:37
rossella_sHenryG, :)14:37
rossella_ssindhu, thanks !14:37
*** yamamoto has joined #openstack-meeting14:38
*** longxiongqiu has joined #openstack-meeting14:38
lindycoderRegarding the migration to neutron-lib, i know there's the blueprints but it seems to only be listing done items, is there a list somewhere to nice to have stuff i could give a hand with?14:38
HenryGlindycoder: search for "from neutron\." in codesearch.o.o14:39
HenryGhttp://codesearch.openstack.org/?q=from%20neutron%5C.&i=nope&files=&repos=14:39
*** yamamoto has quit IRC14:39
HenryGEvery import from neutron (outside neutron itself) must be addressed14:40
*** links has quit IRC14:40
lindycoderOh that's a good resource, thanks14:40
*** yamamoto has joined #openstack-meeting14:41
*** nadya has quit IRC14:41
HenryGThere's also an etherpad, trying to find it14:41
*** longxiongqiu has quit IRC14:42
*** yamamoto has quit IRC14:42
HenryGhttps://etherpad.openstack.org/p/nl-planning14:42
HenryG^^ needs more TLC14:42
*** nadya has joined #openstack-meeting14:43
*** kaisers has quit IRC14:43
lindycoder(sorry... TLC?)14:44
HenryGtender loving care14:44
lindycoderAh of course :)14:44
*** sdake has quit IRC14:45
HenryGAlso this link:14:45
HenryGhttps://review.openstack.org/#/q/status:open+message:%22NeutronLibImpact%2214:45
HenryG(from the agenda)14:45
*** nadya has quit IRC14:46
*** nadya has joined #openstack-meeting14:46
rossella_sanything else or we can close the meeting?14:47
HenryGthat's all from me14:47
*** lpetrut has joined #openstack-meeting14:47
*** kaisers has joined #openstack-meeting14:47
electrocucarachajust a FYI, the oslo guys are planning to release an oslo.db soon14:48
rossella_sthanks electrocucaracha14:49
rossella_sI think that's all then14:49
rossella_sthanks everybody!14:49
rossella_s#endmeeting14:49
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"14:49
openstackMeeting ended Tue Dec  6 14:49:37 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)14:49
openstackMinutes:        http://eavesdrop.openstack.org/meetings/networking/2016/networking.2016-12-06-14.00.html14:49
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/networking/2016/networking.2016-12-06-14.00.txt14:49
openstackLog:            http://eavesdrop.openstack.org/meetings/networking/2016/networking.2016-12-06-14.00.log.html14:49
electrocucarachathanks rossella_s14:49
*** alraddarla_ has left #openstack-meeting14:49
*** trevormc has left #openstack-meeting14:49
*** electrocucaracha has left #openstack-meeting14:49
*** peterlisak has joined #openstack-meeting14:52
*** onovy has joined #openstack-meeting14:52
*** lpetrut has quit IRC14:54
*** sdake has joined #openstack-meeting14:55
*** emagana has quit IRC14:56
*** rbak has joined #openstack-meeting14:56
*** korzen has quit IRC14:56
*** shintaro has quit IRC14:57
*** HeOS has quit IRC14:58
*** emagana has joined #openstack-meeting14:58
*** emagana has quit IRC14:59
*** yamamoto has joined #openstack-meeting14:59
*** emagana has joined #openstack-meeting14:59
*** sudipto has joined #openstack-meeting14:59
*** sudipto_ has joined #openstack-meeting14:59
*** Julien-zte has joined #openstack-meeting15:00
*** cdub has quit IRC15:00
*** fnaval has quit IRC15:00
*** yamamoto has quit IRC15:00
*** cdelatte has quit IRC15:00
*** fnaval has joined #openstack-meeting15:01
*** cdub has joined #openstack-meeting15:01
*** emagana_ has joined #openstack-meeting15:02
*** SridharP has joined #openstack-meeting15:02
*** emagana_ has quit IRC15:02
*** emagana has quit IRC15:02
*** emagana_ has joined #openstack-meeting15:02
*** cdelatte has joined #openstack-meeting15:03
*** jgregor has joined #openstack-meeting15:03
*** fnaval has quit IRC15:05
*** yamamoto has joined #openstack-meeting15:06
*** penick has quit IRC15:07
*** yamamoto has quit IRC15:07
*** saisriki__ has joined #openstack-meeting15:08
*** cdub has quit IRC15:09
*** prateek_ has joined #openstack-meeting15:10
*** jgregor_ has joined #openstack-meeting15:11
*** yamamoto has joined #openstack-meeting15:11
*** larainema_ is now known as larainema15:11
*** lbeliveau_ is now known as lbeliveau15:11
*** parora has joined #openstack-meeting15:12
*** Julien-zte has quit IRC15:13
*** jgregor has quit IRC15:14
*** prateek has quit IRC15:14
*** fnaval has joined #openstack-meeting15:14
*** Julien-zte has joined #openstack-meeting15:14
*** prateek_ has quit IRC15:15
*** yamamoto has quit IRC15:15
*** yamamoto has joined #openstack-meeting15:15
*** saisriki__ has quit IRC15:15
*** tuhv_ has quit IRC15:16
*** cdub has joined #openstack-meeting15:17
*** parora has quit IRC15:18
*** tuan_luong has joined #openstack-meeting15:19
*** VW_ has joined #openstack-meeting15:19
*** VW_ has quit IRC15:20
*** erlon-airlong has quit IRC15:20
*** VW_ has joined #openstack-meeting15:20
*** erlon-airlong has joined #openstack-meeting15:20
*** VW_ has quit IRC15:20
*** eharney has joined #openstack-meeting15:20
*** VW_ has joined #openstack-meeting15:21
*** VW has quit IRC15:21
*** jgregor has joined #openstack-meeting15:22
*** SridharP has quit IRC15:24
*** xionchen_ has quit IRC15:24
*** tonytan4ever has joined #openstack-meeting15:25
*** jgregor_ has quit IRC15:25
*** reedip_ has joined #openstack-meeting15:28
*** nmagnezi has quit IRC15:30
*** mickeys has joined #openstack-meeting15:31
*** mickeys has quit IRC15:36
*** reedip_ has quit IRC15:37
*** hongbin has joined #openstack-meeting15:39
*** faizy_ has joined #openstack-meeting15:41
*** haleyb_ has quit IRC15:41
*** enriquetaso has quit IRC15:41
*** jgregor_ has joined #openstack-meeting15:42
*** boden has left #openstack-meeting15:43
*** faizy__ has joined #openstack-meeting15:43
*** nmagnezi has joined #openstack-meeting15:44
*** yamamoto has quit IRC15:45
*** jgregor has quit IRC15:45
*** caboucha has joined #openstack-meeting15:45
*** faizy_ has quit IRC15:46
*** mkoderer has quit IRC15:46
*** mkoderer has joined #openstack-meeting15:47
*** asselin_ has joined #openstack-meeting15:48
*** rbartal_ has joined #openstack-meeting15:49
*** reedip_ has joined #openstack-meeting15:49
*** nadya has quit IRC15:50
*** john-davidge has quit IRC15:51
*** asselin has quit IRC15:51
*** zengchen has quit IRC15:51
*** zengchen has joined #openstack-meeting15:51
*** chandankumar is now known as chandankumar|off15:53
*** yamamoto has joined #openstack-meeting15:54
*** tung_doan has joined #openstack-meeting15:56
*** armax has joined #openstack-meeting15:56
*** tbh has joined #openstack-meeting15:56
*** bobh has joined #openstack-meeting15:57
*** mtanino has joined #openstack-meeting15:58
*** iyamahat has joined #openstack-meeting15:58
*** VW has joined #openstack-meeting15:59
*** s3wong has joined #openstack-meeting15:59
*** VW has quit IRC15:59
*** VW__ has joined #openstack-meeting15:59
*** galstrom_zzz is now known as galstrom16:00
sridhar_ram#startmeeting tacker16:00
openstackMeeting started Tue Dec  6 16:00:26 2016 UTC and is due to finish in 60 minutes.  The chair is sridhar_ram. Information about MeetBot at http://wiki.debian.org/MeetBot.16:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:00
*** openstack changes topic to " (Meeting topic: tacker)"16:00
openstackThe meeting name has been set to 'tacker'16:00
sridhar_ram#topic Roll Call16:00
*** openstack changes topic to "Roll Call (Meeting topic: tacker)"16:00
sridhar_ramwho is here for tacker meeting?16:00
s3wongo/16:00
*** KanagarajM has joined #openstack-meeting16:00
tbho/16:00
bobho/16:00
KanagarajMo/16:00
sripriyao/16:01
jankio/16:01
sridhar_ramhowdy all !!16:01
tung_doano/16:01
sridhar_ramlet's start...16:01
sridhar_ram#topic Agenda16:01
*** openstack changes topic to "Agenda (Meeting topic: tacker)"16:01
*** VW_ has quit IRC16:02
sridhar_ram#info https://wiki.openstack.org/wiki/Meetings/Tacker#Meeting_Dec_6th.2C_201616:02
sridhar_ram#chair sripriya s3wong tbh bobh16:02
openstackCurrent chairs: bobh s3wong sridhar_ram sripriya tbh16:02
* sridhar_ram notes that a lots of cores in the table!16:02
sridhar_ram#topic Announcements16:03
*** openstack changes topic to "Announcements (Meeting topic: tacker)"16:03
sridhar_ramthanks for all those who responded to the doodle poll for tacker meeting timeslot..16:03
sridhar_ram#link http://lists.openstack.org/pipermail/openstack-dev/2016-December/108405.html16:03
*** nk2527 has joined #openstack-meeting16:03
sridhar_ramnew time -> Wednesdays 0530 UTC16:03
sridhar_rami understand might be challenge to some of you to attend..16:04
*** cathrichardson has joined #openstack-meeting16:04
* sridhar_ram looks at bobh16:04
* bobh was already sleeping....16:04
sridhar_ram#info new Tacker meeting time starting next week at Wednesdays 0530 UTC16:05
sridhar_ramNext..16:05
*** doonhammer has joined #openstack-meeting16:05
sridhar_ramOcata is a short dev cycle...16:05
*** ayoung-afk is now known as ayoung16:05
sridhar_ram#link https://releases.openstack.org/ocata/schedule.html16:05
*** cathrichardson has left #openstack-meeting16:06
sridhar_ramWe only have 7 weeks left until feature freeze :(16:06
sridhar_ramwe got to rush on things at flight to wrap by then...16:06
sridhar_ramthis also means we need to punt some specs that are too big to fit to Pike (we can continue to the work, but will land only after Pike opens)16:07
sridhar_ramany thoughts / questions on these two annoucements ?16:07
*** longxiongqiu has joined #openstack-meeting16:08
*** kbyrne has quit IRC16:08
*** jaugustine has joined #openstack-meeting16:08
*** sridharg has quit IRC16:08
*** longxiongqiu has quit IRC16:08
sridhar_rambtw, the meeting next week will be in this same channel .. #openstack-meeting16:08
sridhar_rammoving on...16:08
sridhar_ram#topic dsvm gate job update16:08
*** openstack changes topic to "dsvm gate job update (Meeting topic: tacker)"16:08
sridhar_ram#link https://bugs.launchpad.net/tacker/+bug/164680716:09
openstackLaunchpad bug 1646807 in tacker "dsvm failure: devstack plugin is not enabled to reuse multiple times" [High,In progress] - Assigned to Tung Doan (tungdoan)16:09
sridhar_ramtung_doan: any update ?16:09
tung_doantung_doan: my patch: tung_doan16:09
tung_doantung_doan: my patch: https://review.openstack.org/#/c/404797/16:09
tung_doansridhar_ram: we have a bunch of errors with event/functions. I am still figuring out what happened to them.16:09
*** cody-somerville has joined #openstack-meeting16:10
*** cody-somerville has quit IRC16:10
*** cody-somerville has joined #openstack-meeting16:10
tung_doansridhar_ram: I found a bug with unique name issue: http://logs.openstack.org/97/404797/5/check/gate-tacker-dsvm-functional-ubuntu-xenial-nv/a04da3a/console.html#_2016-12-05_03_43_13_1550516:10
tung_doannot sure if it impacts to others...16:10
sridhar_ramtung_doan: I see, good news that it is proceeding further from that enable_plugin issue..16:10
tung_doansridhar_ram: another question...16:10
*** dprince has quit IRC16:11
sridhar_ramKanagarajM: is this something you can help to isolate, the issues related to eventing ?16:11
*** kbyrne has joined #openstack-meeting16:11
*** yamamoto has quit IRC16:12
sridhar_ramtung_doan: what is your question?16:12
tung_doansridhar_ram: can we we keep the same approach?16:12
KanagarajMsridhar_ram, i have checked the logs once and every where the test cases expect an event count 116:12
*** kevinz has quit IRC16:12
KanagarajMand i believe that something wrong on the functionality issues , for example when we create vnfd16:12
tung_doansridhar_ram: actually Murano has the same approach like us: https://review.openstack.org/#/c/404882/16:12
sridhar_ramtung_doan: yes, we can.. no need for the trove solution as you've solved it another way (moving the source openrc line)16:13
KanagarajMcorresponding create count would be 1 but it reports 016:13
sridhar_ramKanagarajM: I see16:13
KanagarajMso i suspect something wrong on the create one, so i have asked tung_doan to test it locally to isolate the issue16:13
KanagarajMtung_doan, any updates ?16:13
tung_doansridhar_ram: KanagarajM: I will test locally today16:14
*** yamahata has joined #openstack-meeting16:14
tung_doansridhar_ram: this is a bgs related to unique name issue16:14
sridhar_ramtung_doan: in case you are not aware, make use of this script .. https://github.com/openstack/tacker/blob/master/tools/prepare_functional_test.sh16:14
sridhar_ramtung_doan: run this before running 'tox -e functional <testcase>' in your local system16:15
tung_doansridhar_ram: I saw that. thanks16:15
*** faizy__ has quit IRC16:15
sridhar_ramtung_doan: thanks a lot for taking this up, it is layers of errors16:15
*** faizy has joined #openstack-meeting16:15
sridhar_rammoving on16:16
tung_doansridhar_ram: np16:16
sridhar_ram#topic Spec: VNF creation without VNFD onboarding16:16
*** sshnaidm has quit IRC16:16
*** openstack changes topic to "Spec: VNF creation without VNFD onboarding (Meeting topic: tacker)"16:16
*** lindycoder has left #openstack-meeting16:16
sridhar_ram#link https://review.openstack.org/#/c/405381/1/specs/ocata/vnf-inline-template.rst16:16
sridhar_ramjanki: can you give an update?16:16
jankisridhar_ram, sure.16:16
jankiThe spec explains almost everything16:16
*** nmagnezi has quit IRC16:17
*** chrisplo has joined #openstack-meeting16:17
jankiSo what I intend to do is add an argument on CLI to specify the type of the template16:17
*** Cibo_ has quit IRC16:17
*** rcernin has quit IRC16:17
janki"inline" in this case and "vnfd" when the template used is onboarded as VNFD16:17
jankiVNF DB will store the template. But the template won't be visibile to everyone16:18
sripriyajanki: why will you need to specify the type?16:18
jankiserver will drop the template from "show vnf" output16:18
*** nkrinner is now known as nkrinner_afk16:18
*** annegentle has joined #openstack-meeting16:18
*** kbyrne has quit IRC16:18
sridhar_ramjanki: okay.. "inline" will carry the whole template as a json attribute ?16:18
jankisripriya, just to differentiate between the 2 methods16:19
*** pcaruana has quit IRC16:19
jankisridhar_ram, yes, as JSON16:19
sridhar_ramI'd like to pause here for a sec...16:19
sridhar_ramquick heads up / poll for the members here, particularly the cores...16:19
jankisripriya, and also to implement the DB logic to drop the template16:19
sridhar_rambobh: s3wong: tbh: KanagarajM: this spec talks about creating a VNF by directly passing a VNFD template as part of the create VNF API16:20
*** acabot__ has quit IRC16:20
*** kbyrne has joined #openstack-meeting16:21
sridhar_ramthis is useful when the VNF / NS catalog is maintained in an NFVO running above tacker (imagine Open-O, Cloudify, etc)16:21
KanagarajMsridhar_ram, i reviewed once and i liked this idea16:21
*** faizy has quit IRC16:21
sridhar_ramKanagarajM: cool , that's exactly what i'm looking for .. whether you all see this as a useful addition16:22
bobhsounds good to me16:22
*** oanson has quit IRC16:22
tbhHow and why we are adding "private" flag to the  template16:22
sridhar_rambobh: thanks16:22
*** zul has quit IRC16:22
*** piet has joined #openstack-meeting16:22
sridhar_ramtbh: fair question, now we can dig a bit on the mechanics..16:22
tbh.. and will the "private" field apply to the templates which are onboarded using vnfd-create too16:22
jankitbh, the flag is to be added to DB so that not authorised user cannot see the template. and no, it wont be applied to onboarded vnfd16:23
jankiI remember talking to sridhar_ram about handling the case where deployers dont want to reveal their template to others and hence the "private" flag16:24
KanagarajMi think we no need to differentiate, from taker point of view, once its posted over POST json, let tacker store it in vnfd table and when it returns the vnf details, it would give reference to vnfd id16:24
sripriyajanki: and this gets applied only for inline template case16:25
tbhjanki, in that case it must apply to onboarded templates too16:25
tbhjanki, because the user can use tacker-nfv or open-o?16:25
*** zul has joined #openstack-meeting16:25
*** saisriki__ has joined #openstack-meeting16:25
sridhar_ramjanki: we still have a pending work item on proper multi-tenancy16:25
KanagarajMmaking vnfd as public or private would be different use case, imo16:25
*** Leo_ has joined #openstack-meeting16:25
*** kbyrne has quit IRC16:25
sridhar_ramjanki: meanwhile, my understanding is, this flag (what we call that is a diff thing) will differentiate VNFD that got onboarded vs vnfd that came in directly through a vnf-create call16:25
*** julim has joined #openstack-meeting16:26
jankiKanagarajM, tbh the whole point here is not storing the template to DB16:26
KanagarajMi think template is required, in case of scaling .16:26
jankibut not storing in DB will create confusion when too many vnfs are deployed and couldnot be matched with the template used. so store it on db but hide it from users16:26
KanagarajMjanki, ^^16:26
sridhar_ramKanagarajM: yes, template in VNFD DB is required for various features to work.. including VNFFG16:27
jankitbh: onboarded means its all available to user to view. here we dont want user to see the template16:27
*** mahesh has joined #openstack-meeting16:27
jankiKanagarajM, sridhar_ram we are storing the template in DB but hiding it from user using "private" flag16:27
janki"private" flag applies to DB.16:28
jankiNOw here, we can have 2 ways:16:28
KanagarajMsridhar_ram, janki IMO, we no need to hide the vnfd from user as part of this blueprint. but we could add that feature to make a given vnfd is available public or only to owner, similar to glance image16:28
sridhar_ramjanki: the intention is not to "hide" from a specific user .. the intention is just to differentiate onboarded VNFD vs inline VNFD16:28
tbhKanagarajM, +116:28
*** kbyrne has joined #openstack-meeting16:28
jankisridhar_ram, sripriya to differentiate between onboarded and inline, its "--template-type" argument on CLI.16:29
*** nmagnezi has joined #openstack-meeting16:29
sridhar_ramKanagarajM: agree we don't need to hide, but the concern is .. if there are tons of inline-VNFs .. your 'show vnfd-list' will be too long16:29
sripriyajanki: even for inline template, you internally invoke the vnfd create and store it in db?16:29
*** yamamoto has joined #openstack-meeting16:29
sridhar_ramKanagarajM: we can introduce a 'show vnf-list --inline' to show them .. there is no need for hiding..16:30
jankisridhar_ram, I remember discussing this hiding feature long time back. so just included it here16:30
*** designbybeck has joined #openstack-meeting16:30
*** mahesh has quit IRC16:31
jankisripriya, for inline, just call the tosca-parser internally. and store the template as is in VNF DB and NOT VNFD DB16:31
sridhar_ramfolks - keep in mind, this inline-vnfd that sneaks into VNFD DB as part of a VNF create and it will also be "removed" after a VNF-delete16:31
KanagarajMsridhar_ram,  let us not hide, but if we want to really filter the vnfd list, we could bring up the tagging concept, and when user post via POST JSON, tacker could tag it internally16:31
sripriyajanki: but i believe vnfd_is in vnf sb is a foreign key of vnfd db16:31
sripriyavnfd_id *16:31
KanagarajMsridhar_ram, i agree with you on not hiding .16:31
sridhar_ramKanagarajM: ack, we can have some sort of a "filter view" to show / not show these types of VNFDs in the VNFD DB16:32
*** mickeys has joined #openstack-meeting16:32
sripriyasridhar_ram: i dont think there is an entry in vnfd db16:32
*** baoli has quit IRC16:32
sridhar_ramsripriya: sorry, what you mean?16:33
tbhjanki, sripriya, yeah so internally we need to invoke vnfd-create?16:33
*** chrisplo has quit IRC16:33
sripriyasridhar_ram: as janki mentioned, there is no vnfd create call internally for inline template16:33
*** fguillot has quit IRC16:33
sripriyasridhar_Ram: so vnfd db is not touched here16:33
* sridhar_ram scanning the spec quickly...16:34
*** reedip_ has quit IRC16:34
sridhar_ramsripriya: ack..16:34
sridhar_ramhmm...16:34
jankisridhar_ram, sripriya I am thinking to store the template in VNF DB and not VNFD DB16:34
*** tuan_luong has quit IRC16:34
*** mickeys has quit IRC16:34
sripriyajanki: my concern is on the design of this spec since the backend has vnfd_id as  a FK constraint in vnf table16:35
sridhar_rammany features in tacker relies on an entry in VNFD template.. they need to intercepted to handle this variation16:35
*** mickeys has joined #openstack-meeting16:35
sripriyajanki: so this will fail on the backend when you create a uuid for vnfd and store in vnf db16:35
jankibut then since we are dropping the hiding thing and there is a foreign key constraint, we can store in vnfd db16:35
jankisripriya, ^16:35
* sridhar_ram notes, we have 5mins left for this topic16:35
tbhsridhar_ram, sripriya , janki I was assuming if we add flag to VNFD in VNFD DB(to mean it is inline template) we can easily use the same procedure as we are using now. And when vnf-delete is carried on we can check the flag and remove the VNFD too16:35
sridhar_ramtbh: i assumed that as well ;-)16:36
KanagarajMif we don't use vnfd table, it leads to affect the tacker model, as tacker already models vnfd and it should be followed across16:36
sripriyatbh: KanagarajM ack16:36
sridhar_ramjanki: any reason a solution that tbh proposes won't work ?16:36
jankisridhar_ram, tbh it will work16:37
jankiI thought the same before, but beacuse of "hiding" thing proposed to use VNF DB16:37
sridhar_ramjanki: now that we are all in the same page, any downsides to such an approach ?16:37
jankinone that I can think of currently16:37
*** haleyb_ has joined #openstack-meeting16:37
sridhar_ramjanki: okay..16:38
sripriyajanki: are we going to show to a user in vnfd list if an entry is inline template or onboarded ?16:38
jankiinfact this will also reduce VNF DB changes16:38
jankisripriya, yes.16:38
*** doonhammer has quit IRC16:38
*** dbecker has quit IRC16:38
sridhar_ramsripriya: we should not by default, unless there is a explicit flag asking to show inline templates16:38
jankisridhar_ram +116:39
*** unicell has quit IRC16:39
sripriyasridhar_ram: so list will NOT contain inline template entries right?16:39
sridhar_ramsripriya: yes16:39
sripriyasridhar_ram: thanks16:40
jankisridhar_ram, sripriya "list" must show the entry but not show the template content16:40
sridhar_ramfolks / cores - please review this spec, particularly with any downsides ..16:40
sridhar_ramjanki: do you think this will fit Ocata dev cycle ?16:40
jankisridhar_ram, yes it will fit16:40
KanagarajMsridhar_ram, sure.16:40
sridhar_ramalright, lets move on to the next topic...16:41
tbhsridhar_ram, ack16:41
sridhar_ram#topic Spec: Containerized VNFs16:41
*** openstack changes topic to "Spec: Containerized VNFs (Meeting topic: tacker)"16:41
jankisridhar_ram, sripriya "vnf list" wont show the template content. "vnf list --flag" will show the content too16:41
sridhar_ram#link https://review.openstack.org/39723316:41
sridhar_ramagain, back to janki :)16:41
sripriyajanki: we can take it up on gerrit16:42
jankiwe discussed this in one of the meetings. Appropriate option is to use Zun16:42
jankiBut I am encouraging on starting the implementation with Magnum/Kuryr and then keep on evolving later on16:42
sridhar_ramfirst - based on Barcelona summit, is there enough interest in this topic ?16:42
*** haleyb_ has quit IRC16:42
sripriyasridhar_ram: yes IMO16:43
jankisridhar_ram, yes there is. Nokia guys discussed this in kuryr design session16:43
sridhar_ramsripriya: okay..16:43
*** absubram has quit IRC16:43
sridhar_ramNow, my suggestion is put away all the technologies and projects names .. zun, magnum, kuryr, etc.. and think what we won't to offer to tacker users16:44
*** anilvenkata has quit IRC16:44
sridhar_ramI'm afraid we are starting backwards by picking the technology first and then working to see what we can do16:44
jankito run VDU as a container instead of VM16:44
sridhar_rami think it shd be the other way around16:44
*** davidsha has joined #openstack-meeting16:45
*** kaisers_ has joined #openstack-meeting16:45
bobhsridhar_ram: seems like that should be an attribute of the VNFD - specify container instead of image16:45
sridhar_ramjanki: then, lets start by imaging a TOSCA template that describes VDUs as Container node types..16:45
jankitacker already supports this sridhar_ram16:45
sridhar_rams/imaging/imagining/16:45
*** nmagnezi has quit IRC16:45
*** tpsilva has joined #openstack-meeting16:46
sridhar_ramjanki: that you mean ? this spec needs to show a sample TOSCA NFV template with containers16:46
*** nadya has joined #openstack-meeting16:46
jankisridhar_ram, done. will do that16:46
sridhar_rambobh: +116:47
*** belmoreira has quit IRC16:47
sridhar_ramanyone know if tosca-parser team is taking up any container node_type work ?16:47
tbhbobh, in the tosca_nfv_profile, can we specify container nodetype?16:47
bobhtbh: I think you could define your own container nodetype - I don't know that there is one pre-defined16:48
bobhsridhar_ram: I don't know of anything specific but I can see if spzala knows of anything16:48
sridhar_rambobh: thanks..16:48
*** MarkAtwood has quit IRC16:49
sridhar_rami think we need to start from there...16:49
sridhar_ramVDU node_type --> map to a container runtime definition16:49
*** Julien-zte has quit IRC16:49
*** MarkAtwood has joined #openstack-meeting16:49
*** Julien-zte has joined #openstack-meeting16:49
sridhar_ramimage artifact -> map to some sort of a container registry like dockerhub16:49
*** Julien-zte has quit IRC16:50
tbhbobh, we have customed defined type like this https://github.com/openstack/tosca-parser/blob/d59e1503cc9d3fa524f2209fdc645459f98e181a/toscaparser/tests/data/containers/test_container_docker_mysql.yaml#L2016:50
sridhar_ramCP -> map to perhaps kuryr ports ?16:50
*** kaisers_ has quit IRC16:50
*** Julien-zte has joined #openstack-meeting16:50
*** Julien-zte has quit IRC16:51
bobhtbh: right - custom type will work but there is nothing native at this point16:51
tbhbobh, got it, thanks16:51
*** Julien-zte has joined #openstack-meeting16:51
sridhar_ramjanki: my suggestion is to first flush out the "top half" of this feature first .. the TOSCA parser, the usage flow, etc...16:51
*** Julien-zte has quit IRC16:51
jankisridhar_ram, got it...16:52
sridhar_ramjanki: for this exercise, don't worry what magnum / zun can or cannot do16:52
*** Julien-zte has joined #openstack-meeting16:52
jankisridhar_ram, yes16:52
*** Julien-zte has quit IRC16:52
sridhar_ramjanki: sounds good..16:52
*** Julien-zte has joined #openstack-meeting16:53
*** Patifa has joined #openstack-meeting16:53
sridhar_ramlet's cook this spec a bit more... !16:53
*** Julien-zte has quit IRC16:53
sridhar_ramit is an interesting area to indulge...16:53
*** shashank_hegde has joined #openstack-meeting16:54
sridhar_ramanything else in this container-vnf topic ?16:54
*** Julien-zte has joined #openstack-meeting16:54
*** Julien-zte has quit IRC16:54
sridhar_ram#topic Open Discussion16:54
*** openstack changes topic to "Open Discussion (Meeting topic: tacker)"16:54
*** Julien-zte has joined #openstack-meeting16:54
jankisridhar_ram, I will update both the specs based on the discussion tomorrow morning16:54
sridhar_ramjanki: sounds good16:54
*** Julien-zte has quit IRC16:55
jankisridhar_ram, sripriya I also want to disucss the removal of mgmt_driver from CLI bug16:55
sridhar_ramjanki: we have few mins, go ahead16:55
*** LamT__ has joined #openstack-meeting16:55
sripriyajanki: gerrit patch link?16:55
jankiso we remove passing mgmt_driver from the client and it will be fetched from the template itself right16:55
jankisripriya, server patch is WIP not ready for review16:55
tung_doansridhar_ram: it will be good if we can support container life-cycle managemnt16:55
tung_doansridhar_ram: i am standing for that :)16:55
*** nadya has quit IRC16:56
sridhar_ramtung_doan: ack! thanks for the input, it helps16:56
sripriyajanki: okay.yes, we need to remove sending that from cli parser as well as the API arg in vnfd16:56
jankinow, if we are getting the value from template, mgmt_driver must be a compulsory attribute in the vnfd16:56
*** rasca has quit IRC16:56
jankisripriya, got it. we will get it from template. and there are few templates that dont mention mgmt_driver AFAIK16:57
jankiso in case cases, the server should put "noop" by default16:57
janki??16:57
jankisridhar_ram, sripriya ^16:57
sripriyajanki: it should not be exposed as an API param16:57
sridhar_ramsripriya: +116:57
jankisripriya, yes. I have removed it on the client side. it wont be in API anymore.16:58
sridhar_rammgmt_driver should be removed en masse from the API / CLI16:58
sripriyajanki: cool16:58
sridhar_rami was deprecated in newton16:58
jankimy query is it will be fetched internally from the template right?16:59
sripriyasridhar_ram: you were deprecated? :P16:59
sridhar_ramsripriya: that will happen in the next cycle ;-)16:59
sripriyajanki : yes16:59
sridhar_ramalright times up...16:59
sridhar_rami think we will miss US East coast folks in the Tacker meetings good forward..17:00
jankisripriya, so when the template doesnot have mgmt_driver, server should default it to noop?17:00
sridhar_ramparticularly miss bobh :(17:00
sridhar_ramtimes up17:00
jankisripriya, sridhar_ram link to the patch https://review.openstack.org/#/c/396245/17:00
jankibye guys17:00
sridhar_ramjanki: lets take in the channel17:00
jankisridhar_ram, yes17:00
sridhar_ram#endmeeting17:00
s3wongbye17:00
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"17:00
openstackMeeting ended Tue Dec  6 17:00:52 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/tacker/2016/tacker.2016-12-06-16.00.html17:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/tacker/2016/tacker.2016-12-06-16.00.txt17:00
openstackLog:            http://eavesdrop.openstack.org/meetings/tacker/2016/tacker.2016-12-06-16.00.log.html17:00
KanagarajMbye17:01
igordcard#startmeeting network_common_flow_classifier17:01
openstackMeeting started Tue Dec  6 17:01:00 2016 UTC and is due to finish in 60 minutes.  The chair is igordcard. Information about MeetBot at http://wiki.debian.org/MeetBot.17:01
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:01
*** openstack changes topic to " (Meeting topic: network_common_flow_classifier)"17:01
openstackThe meeting name has been set to 'network_common_flow_classifier'17:01
igordcardhi all17:01
*** nadya has joined #openstack-meeting17:01
davidshaHi17:01
igordcardlet's wait 3 minutes to improve the chances of everyone being around17:01
*** KanagarajM has left #openstack-meeting17:01
davidshakk17:01
*** s3wong has quit IRC17:02
*** janki has quit IRC17:04
igordcardagenda:17:04
igordcard#link https://wiki.openstack.org/wiki/Neutron/CommonFlowClassifier#Discussion_Topic_6_December_201617:04
*** tbh has left #openstack-meeting17:04
igordcard#topic Continue discussion on user-facing API vs. Classification mixins.17:04
*** openstack changes topic to "Continue discussion on user-facing API vs. Classification mixins. (Meeting topic: network_common_flow_classifier)"17:04
igordcard#link https://review.openstack.org/#/c/33399317:04
igordcardalright, I am supposed to update the current spec to add more information to the api-based approach and the mixin-based approach17:05
igordcardit's in progress and should get an update soon this week17:05
*** eharney has quit IRC17:05
davidshakk17:06
igordcardmeanwhile I will start working on a PoC for the api-based approach17:06
davidshaKk, I can try and help.17:07
igordcardthanks davidsha17:07
igordcardanyone free feel to join the effort - I'm always on IRC so just ping me17:07
igordcardit would also be interesting to have a PoC for the mixin-based approach, but I am focusing on the api-based approach17:08
igordcardbesides the PoCs, I will try to keep the spec up to date with the latest efforts, both from the IRC discussions and the PoC(s)17:08
*** lhx_ has quit IRC17:08
davidshaIt could be included as well, though it was intended for neutron_lib if I recall, but for testing we could include it in that repo17:09
*** andreas_s has quit IRC17:09
davidshain the neutron_classifier repo I mean17:10
*** shashank_hegde has quit IRC17:10
igordcarddavidsha: +117:10
ralonsohwhich set of protocols are you going to include in this POC?17:10
*** Swami has joined #openstack-meeting17:10
ralonsohhow future new protocols are going to be accepted?17:10
igordcarddavidsha: the models part is already aligned with most of what is common to either the api-based approach or mixin-based approach17:10
*** pnavarro has joined #openstack-meeting17:11
igordcardralonsoh: initially for the PoC I'm thinking about something extremely simple, e.g. a "L1" classification type which would allow us to match on neutron ports or neutron networks17:11
davidshaWill we refer to api/mixin as resource/descriptive? just to stay consistent from last meeting.17:12
igordcardralonsoh: then we could extend QoS to consume these classifications and demonstrate how the classifications are telling the QoS service where the policy should be applied17:12
ralonsohigordcard: thanks!17:12
igordcardralonsoh: or likewise for networking-sfc for example... for logical source ports or logical destination ports17:13
igordcardsomething simple like that17:13
*** cdub has quit IRC17:14
*** matrohon has quit IRC17:14
igordcardadding protocols in the future would be done by adding more types to the list of models underneath the classification framework... and consuming services would become compatible with the new protocols whenever they need (after the protocols are added to the framework/API)17:14
*** nadya has quit IRC17:15
igordcarddavidsha: right david, resource-based and definition-based17:15
*** prateek has joined #openstack-meeting17:15
davidshaigordcard: thats the one!17:16
igordcardso resource-based classification approach is the one where there is a single API for classification resources (api-based as I said earlier)17:16
davidshaAn an extension would consume that resource17:17
davidshaAnd an*17:17
igordcarddefinition-based classification approach is the one where the services inherit the definitions of classifications and expose them in their own API, potentially by the use of mixins in their respective extensions (mixin-based as I said earlier)17:17
igordcarddavidsha: yes, an extension would consume resources from the single, common classifications API in the resource-based approach17:18
*** numans has quit IRC17:18
igordcardany questions or thoughts about the duality of approaches and next-steps around them?17:18
davidshaNo, I'm good17:19
igordcardmoving on...17:19
*** e0ne has quit IRC17:19
igordcard#topic Call for contributors17:20
*** openstack changes topic to "Call for contributors (Meeting topic: network_common_flow_classifier)"17:20
igordcardI guess I've already gone through this topic17:20
davidshaSo do I need to withdraw my earlier application and resubmit it? :P17:20
*** eharney has joined #openstack-meeting17:20
*** zhonghua has quit IRC17:20
igordcardno no, you can officially submit it now, like this: :p17:20
davidsha:O17:21
igordcard#action igordcard will contribute to the resource-based (api-based) approach PoC17:21
*** irenab_ has joined #openstack-meeting17:21
*** zhonghua has joined #openstack-meeting17:21
davidsha:P17:21
igordcardanyone else can just join17:22
igordcardany questions or thoughts?17:22
davidshakk, no I'm good, the neutron_classifier repo already has the database definitions so we just need to make the service plugin.17:23
*** irenab has quit IRC17:23
*** irenab_ is now known as irenab17:23
igordcardexactly17:23
davidshaMaybe make a patch for an extension that could use it to test it out too.17:23
igordcardyeah17:23
*** jgregor has joined #openstack-meeting17:24
igordcardalright team17:24
igordcardmoving on...17:24
igordcard#topic Open discussion17:24
*** openstack changes topic to "Open discussion (Meeting topic: network_common_flow_classifier)"17:24
igordcardanything else we need to discuss?17:24
davidshaI'm good, we have a good Idea what we need to do.17:25
*** annegentle has quit IRC17:25
*** SridharP has joined #openstack-meeting17:25
igordcardalright! I guess it's all for today then17:26
igordcardthank you all17:26
davidshaThanks, cya!17:26
igordcardbye17:26
ralonsohbye17:26
*** rcernin has joined #openstack-meeting17:26
igordcard#endmeeting17:27
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"17:27
openstackMeeting ended Tue Dec  6 17:27:18 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)17:27
openstackMinutes:        http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/2016/network_common_flow_classifier.2016-12-06-17.01.html17:27
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/2016/network_common_flow_classifier.2016-12-06-17.01.txt17:27
openstackLog:            http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/2016/network_common_flow_classifier.2016-12-06-17.01.log.html17:27
*** jgregor_ has quit IRC17:27
*** annakoppad has joined #openstack-meeting17:29
*** yamamoto has quit IRC17:30
*** eharney has quit IRC17:30
annakoppadraildo, hi17:30
annakoppadrodrigods, hi17:31
raildohi annakoppad, can you go on #openstack-opw?17:31
raildoannakoppad, we will do the meeting on that channel17:31
*** comay has joined #openstack-meeting17:31
*** sudipto_ has quit IRC17:32
*** sudipto has quit IRC17:32
*** davidsha has quit IRC17:34
*** aweeks has joined #openstack-meeting17:35
*** baoli has joined #openstack-meeting17:36
*** VW__ has quit IRC17:36
*** pnavarro has quit IRC17:38
*** spilla has joined #openstack-meeting17:41
*** annakoppad has quit IRC17:41
*** dmorita has joined #openstack-meeting17:43
*** VW has joined #openstack-meeting17:43
*** numans has joined #openstack-meeting17:44
*** chrisplo has joined #openstack-meeting17:44
*** eharney has joined #openstack-meeting17:45
*** VW_ has joined #openstack-meeting17:45
*** fguillot has joined #openstack-meeting17:46
*** iyamahat has quit IRC17:47
*** VW has quit IRC17:47
*** yamahata has quit IRC17:47
*** frasantoro has quit IRC17:48
*** toscalix has quit IRC17:51
*** abalutoiu_ has joined #openstack-meeting17:51
*** abalutoiu_ has quit IRC17:51
*** jgregor has quit IRC17:52
*** pvaneck has joined #openstack-meeting17:53
*** absubram has joined #openstack-meeting17:54
*** baoli has quit IRC17:56
*** bobh has quit IRC17:56
*** annakoppad_ has joined #openstack-meeting17:57
*** baoli has joined #openstack-meeting17:57
*** gagehugo has joined #openstack-meeting17:57
*** Guest74498 has quit IRC17:58
*** weshay_ has quit IRC17:58
*** browne has joined #openstack-meeting17:58
stevemaro/17:58
*** weshay has joined #openstack-meeting17:59
*** agrebennikov has joined #openstack-meeting18:00
rodrigodso/18:00
stevemarping agrebennikov, amakarov, annakoppad, ayoung, bknudson, breton, browne, chrisplo, crinkle, davechen, dolphm, dstanek, edmondsw, edtubill, gagehugo, gyee, henrynash, hrybacki, jamielennox, jaugustine, jgrassler, knikolla, lbragstad, kbaikov, ktychkova, morgan, nisha, nkinder, notmorgan, raildo, ravelar, rderose, rodrigods, roxanaghe, samueldmq, shaleh, spilla, srwilkers, StefanPaetowJisc, stevemar, topol18:00
lbragstado/18:00
spillao/18:00
brownehi18:00
raildoo/18:00
agrebennikovo/18:00
gagehugoo/18:00
samueldmqhi all, good $(localtime)18:00
stevemar#startmeeting keystone18:00
openstackMeeting started Tue Dec  6 18:00:21 2016 UTC and is due to finish in 60 minutes.  The chair is stevemar. Information about MeetBot at http://wiki.debian.org/MeetBot.18:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.18:00
*** openstack changes topic to " (Meeting topic: keystone)"18:00
openstackThe meeting name has been set to 'keystone'18:00
lamto/18:00
rderoseo/18:01
bknudsonhi18:01
bretono/18:01
stevemar#topic announcements18:01
*** openstack changes topic to "announcements (Meeting topic: keystone)"18:01
stevemarhello all!18:01
stevemarNext week we are cutting Ocata-2 -- Week of Dec 12-16 -- This is also spec freeze week, specs must merge by then.18:01
*** alexpilotti has joined #openstack-meeting18:02
stevemarAny 'contentious' feature already approved, but not completed, will get bumped to Pike if it doesn't merge.18:02
stevemarContentious meaning: touching a critical path (token validation / issuance), affecting many components, potentially changing output of API calls.18:02
*** shashank_hegde has joined #openstack-meeting18:02
dstanekhey18:02
stevemarI don't think theres anything contentious that risks getting bumped (maybe the policy stuff?) but most of it is isolated18:02
stevemarmost approved features* are isolated18:02
ayoungOyez oyez18:03
stevemari think i started too soon? did i lose anyone?18:03
lbragstadstevemar i think you're good18:04
stevemarokie doke18:04
samueldmqstevemar: so 'contentious' features (the impl) must be merged by o-2 ?18:04
*** cbits has joined #openstack-meeting18:04
lbragstadsamueldmq i think the spec needs to be merged18:04
lbragstadby o-218:04
stevemaryes, i don't think there are any, the contentious ones were the token refactoring and the expiry window stuff jamie was working on18:04
ayounglinks?18:04
stevemarthose are all merged18:04
stevemaragenda link: https://etherpad.openstack.org/p/keystone-weekly-meeting18:05
samueldmqstevemar: okay, but we still talking about the specs, right ?18:05
ayoungthat is the link I was looking for18:05
samueldmqlbragstad: kk just confirming, thanks18:05
stevemarsamueldmq: yes. all specs must be approved by EOW next week18:05
* samueldmq nods18:06
stevemarotherwise they get the boot18:06
*** ralonsoh has quit IRC18:06
* stevemar waits for more questions18:06
*** alexpilotti has quit IRC18:06
ayoungTrust Scope Extensions  should not go forward.  It is a good idea, but untenable as written.  It can't be Trust based, needs to be at the token itself...18:06
ayoungExtend user API to support federated attributes  looks pretty good18:07
samueldmqthe ones I am worried the most are the trust ones18:07
samueldmqayoung: ^18:07
ayoungsamueldmq,     Spec: Trust Scope Extensions [jgrassler]18:07
ayoung    https://review.openstack.org/#/c/396331/  you mean?18:07
samueldmq#link https://review.openstack.org/#/c/396331/18:07
samueldmq#link https://review.openstack.org/#/c/396634/18:07
stevemarayoung: there are two trust ones18:08
ayoungsamueldmq, yeah,  I had a long talk with jgrassler this morning.  My position is unchanged18:08
*** iyamahat has joined #openstack-meeting18:08
stevemarayoung: theres also "lightweight" trusts: https://review.openstack.org/#/c/396634/18:08
ayoungstevemar, that is oauth18:08
samueldmqayoung: https://review.openstack.org/#/c/396331/ is solved with our OATH in your opinion?18:09
ayoungwe can do those today but should merge trusts and oauth18:09
ayoungsamueldmq, no the other one is18:09
ayoung396634/ is oauth18:09
samueldmqayoung: ok, and what about "Added trust-scope-extensions"18:09
stevemarsamueldmq: that one also has negative feedback18:10
stevemaranyway, some specs are close, others are not. keep reviewing them18:10
* samueldmq nods18:10
stevemarmoving along18:11
samueldmqstevemar: we might want to have a deeper discussion in next meeting on those that haven't been merged by that time18:11
samueldmqstevemar: ++18:11
stevemarsamueldmq: yep18:11
stevemar#topic Introduce Annapoornima Koppad [annakoppad]18:11
*** openstack changes topic to "Introduce Annapoornima Koppad [annakoppad] (Meeting topic: keystone)"18:11
stevemarraildo, rodrigods ^18:11
raildostevebaker, thanks18:12
ayoungshe have an irc nick?18:12
rodrigodsso... welcome annakoppad_18:12
raildostevemar, *18:12
ayoungah..18:12
chrisploare you saing 396634 we're calling OAUTH instead of calling it trust something?18:12
ayoungwelcome18:12
annakoppad_Thanks, raildo!18:12
ayoungchrisplo, it is already implemented18:12
lbragstadannakoppad_ o/18:12
ayounghas been for years18:12
rodrigodsshe is our new outreachy intern, her project starts today!18:12
samueldmqayoung: chrisplo let's continue that in -keystone, we've changed topic already. thanks18:12
rodrigodsthe idea is to add a new job to our CI to handle LDAP scenarios18:13
stevemarwelcome annakoppad_18:13
*** SridharP has quit IRC18:13
samueldmqthat's great!18:13
raildorodrigods, ++ she will be working with us (at least) march 6 :)18:13
annakoppad_Thanks! stevemar!18:13
samueldmqraildo and rodrigods as mentors ?18:13
rodrigodsyep18:13
stevemarsamueldmq: yep!18:13
raildosamueldmq, yes18:13
samueldmqannakoppad_: welcome aboard!18:13
stevemarannakoppad_: good choice of mentors :)18:13
annakoppad_hopefully, more as well, as I do not intend to stop coding ever at all!18:13
samueldmqnice nice, good to see it continuing, congrats on the initiative rodrigods and raildo18:13
stevemarannakoppad_: :D18:13
annakoppad_at raildo! rodrigods18:13
rodrigodssamueldmq, ++18:14
raildosamueldmq, your welcome.18:14
annakoppad_thanks stevemar and samueldmq18:14
rodrigodsso... her project is to help keystone, but involves lots of devstack, project-config, etc18:14
dstanekannakoppad_: welcome18:14
annakoppad_hello dstanek!18:14
stevemarannakoppad_: looking forward to reviewing your patches, please don't be shy and ask questions in #openstack-keystone if you need a hand18:14
annakoppad_yes stevemar!18:14
rodrigodsstevemar, ++18:15
stevemarthanks rodrigods and raildo for doing this18:15
stevemarmorgan: you around?18:15
raildoannakoppad_, so, any doubts, you can ask for help in the #openstack-keystone, and I know that you will find someone to help :)18:15
raildostevemar, no problem :)18:15
annakoppad_great, raildo!18:15
*** acoles is now known as acoles_18:16
stevemari don't think morgan is around, so we can skip the next topic, taskmanager in keystoneauth18:16
stevemarplus, the work is well under way in https://review.openstack.org/#/c/362473/18:16
rodrigodsthink it is not only my opinion that having the LDAP job is a great advance for us :)18:16
ayoungannakoppad_, BTW, it turns out the devstack LDAP code is not currently working18:16
ayoungjust tried it last week...18:16
stevemarayoung: yeah, its bit rotted a bunch18:16
annakoppad_I was trying out running the devstack..will try it a little bit18:17
raildoayoung, out first step will be fix it18:17
raildoour*18:17
ayoungraildo, we can discuss.  Lets set up a time to talk it through18:17
stevemarayoung: i have no doubt that raildo and rodrigods have a plan ;)18:17
raildoayoung, ++18:17
annakoppad_stevemar, and ayoung, never mind, I will help raildo and rodrigods fix whatever is broken18:17
stevemarthat works too18:17
ayoungstevemar, I['ve been talking with them about it18:17
stevemarayoung: cool cool18:18
stevemartime for our super fun topic18:18
stevemar#topic Custom project IDs18:18
*** openstack changes topic to "Custom project IDs (Meeting topic: keystone)"18:18
ayoungRBAC?18:18
ayoungstevemar, AH18:18
ayoungok so I -2 that18:18
ayoungand here is why18:18
stevemaragrebennikov, ayoung, but on your boxing gloves18:18
ayoungstevemar, so the argument that agrebennikov gave me is he is trying to do multi site18:18
ayoungand syncing stuff at the database layer (Galera) puts a lot of load on him18:19
rodrigodsisn't the intent behind shadow mapping to fix that?18:19
ayoungrodrigods, not quite18:19
ayounglet me go on18:19
agrebennikovand I was very surprizrd to get -2 on the nexd day after we agreed on everything telling the truth18:19
samueldmq#link https://review.openstack.org/#/c/403866/18:19
stevemartheres a good mailing list thread going on: http://lists.openstack.org/pipermail/openstack-dev/2016-December/108466.html18:19
ayoungagrebennikov, that was because we did not think it through18:19
ayoungwhat you are proposing is going to put some very had to debug errors into the system18:19
ayoungwe have an assumption right now that a token has a single project ID in it18:20
ayoungand from that project ID, we deduce the set of roles in a token18:20
ayoungnow, ignoring all the work that everyone else is doing around this, lets thinkg that through18:20
ayoungsay we have 2 sites18:20
ayoungand we add a project to one, and give the user some role assignemtnes there18:20
*** rbak has quit IRC18:20
ayoungthen, we used this approach to create the project on the second site18:20
cbitsayoung- I would like to propose a differnt use case.   Where in I would have many independent keystones but many central reporting, finance and billing apps that only understand one project_Id    I also believe that doing this in the DB would be akin to a hack and the API can and IMHO should support it.   Also if we do DB replication and that gets out of sync the user experance is quite horable as well.  ;)18:21
knikollao/ (i'm late)18:21
ayoungand...we say that tokens issued at one site are valid at the other18:21
ayoungwhich we could do via fernet18:21
ayoungbut...we screwed up on the second site18:21
ayoungand gave the user a different set of roles18:21
ayoungnow, the token validation response will depend on which keystone you go to18:21
ayoungbut the tokens will be valid at all service endpoints18:21
lbragstadayoung that's was a big part of breton's concern18:22
ayounglbragstad, oh, we totally have breton to thank for seeing this issue18:22
stevemarlbragstad: ayoung won't you end up with those error if you choose to create projects with id?18:22
dstanekcbits: so you're saying that you trust hand rolled replication over DB replication?18:22
ayoungwhat agrebennikov is asking for (and is reasonable) is a way to sync multiple Keystones.  But it is a Hard problem18:22
ayoungNP-Hard18:22
lbragstadstevemar well - you can.. it depends on how you create the role assignments in each site18:23
agrebennikovso with this just remove the "one token for all" usecase18:23
bretoni still don't see why federation is not an option18:23
agrebennikovkeys are different18:23
rodrigodsbreton, ++18:23
cbitsdstanek:  I trust the orchestration layer I will put in place to make this work over DB replication18:23
agrebennikovtokens are only valid in one region18:23
*** VW_ has quit IRC18:23
cbitsdb replacation to 30 sites is a problem18:23
cbitsI may only need to place a project in 4 of the 3018:23
ayoungagrebennikov, remove the project ID from the equasion and you have the same solution:  make sure everything matches between two keystone18:23
ayoungs18:23
bretontokens are meant to be valid only inside a single keystone installation18:24
ayoungyou must restrict yourself to using only names, no ids, when requesting tokens18:24
cbitsIn my use case we are talking about > 30 regaions18:24
cbitsNames always change. thats why we love id's18:24
ayoungcbits, then you need IDS, and complete replication forthe entire data store18:25
dstanekcbits: imo partial replication makes it worse. hard to track down bugs and an increased chance of running into collisions18:25
*** faizy has joined #openstack-meeting18:25
agrebennikovbreton, I keep struggling to understand how federation helps over here....18:26
cbitsIf my orchestration creates the ID's and we have basic validation at the API point whow wil these independent keystones colide?18:26
agrebennikovbut lets move it aside, I'll ask you in person18:26
*** rfolco has quit IRC18:26
ayoungcbits, and then when someone makes a change at one site outside of your orchestration?18:26
*** yamahata has joined #openstack-meeting18:26
lbragstadagrebennikov if we're going to talk about federation why no do it here, in the open?18:26
lbragstadnot*18:26
stevemari say we make this a config option disabled by default, and let agrebennikov try it out, if it blows up we deprecate and remove the option -- document the limitations and state it's experimental18:26
cbitsthe orchestration will have the admin creds.18:27
ayoungcbits, and only the admin?18:27
ayoungI mean, and only the orchestration?18:27
ayoungno other admins?18:27
cbitsyes18:27
dstanekstevemar: the problem for me is that it will blow up over time not immediately18:27
ayoungcbits, then make your databse read only on the regions and do it at the replication level18:27
cbitsbecause in a complex system not only do we need to create the project but we need to also bind it to internal budjets, cmdb, etc18:27
ayoungstevemar, its a nightmare18:28
dstanekcbits: how do you keep track of used ids and names?18:28
*** saisriki__ has quit IRC18:28
cbitsAD Grups are used.18:28
cbitsno UID's in openstack.18:28
cbitsjust groups18:28
*** krtaylor has quit IRC18:28
stevemarcbits: and that is replicated (not at the API layer)18:28
stevemartheres a good argument between trying to replicate and sync at the various layers18:28
cbitsno,  If say project X needs access to site 1, 2, and 3 we will simply add the project and role (with ad group there)   Ad is centeralized in the company18:29
stevemarmfisch had a nice reply here: http://lists.openstack.org/pipermail/openstack-dev/2016-December/108499.html18:29
dstanekagrebennikov: federation won't completely help until shadow mapping exists18:29
cbitsDB replication works well with 3 or 4 sites.   it gets really nasty when you have lots of sites.18:30
ayoungstevemar, this is one of the sites that was using Assignment in LDAP18:30
bretondstanek: yes it will18:30
cbitsWe only use AD for auth and autz18:30
agrebennikoveven that... federation is for something else. I don't see any application of federation in my usecase18:30
cbitsuser / password and group membership18:30
dstanekbreton: there's still no way to create projects right?18:30
agrebennikovneither projects nor groups18:30
*** vishnoianil has quit IRC18:30
agrebennikovif I'm not mistaken18:30
*** dmorita has quit IRC18:30
ayoungdstanek, I think what he's saying is they want to have the same kind of behavior with LDAP as you are proposing via Federation:18:31
dstanekagrebennikov: federation is how separate keystone installations collaborate18:31
cbitsI would love to have hte project_ids be unique per site.  But I live in a wold where the cloud is intergrated with many systems.   That does not chage over night.18:31
ayoungfirst time you hit a Keystone, create the resources there.  But they want to make sure the resources match multi-site18:31
*** faizy_ has joined #openstack-meeting18:31
*** alexpilotti has joined #openstack-meeting18:31
bretondstanek: projects will be created the same way agrebennikov is going to do it now. He suggests to create 10 projects, each in every location18:31
dstanekayoung: isn't that the goal of shadow mapping?18:31
*** kaisers_ has joined #openstack-meeting18:31
*** dmorita has joined #openstack-meeting18:31
bretondstanek: just with static id18:31
cbitsJust the project_id needs to be the same so reporting and other systems can see it as one thing.18:31
ayoungdstanek, is that sufficient, though?  It is also the "create the assignment on the fly" part18:32
cbitsnot because its cool.  but because other systems that will use that data and intergrations are not ready for project_id[]18:32
*** rossella_s has quit IRC18:32
*** VW has joined #openstack-meeting18:32
*** faizy_ has quit IRC18:32
bretondstanek: and then manually create assignments in each location18:32
ayoungcbits, what you are saying, I think, is you need a way to correlate projects between multiple deployments?18:32
bretondstanek: which can already be done with federation, but cleaner and more predictable18:32
*** faizy has quit IRC18:33
*** faizy_ has joined #openstack-meeting18:33
*** kaisers_ has quit IRC18:33
samueldmqayoung: ++18:33
stevemaragrebennikov: cbits have you guys tried this already? do you have results? can you use a custom interface?18:33
*** alexpilotti has quit IRC18:33
*** kaisers_ has joined #openstack-meeting18:33
ayoungthey also tried K2K and found it too slow18:33
*** alexpilotti has joined #openstack-meeting18:33
samueldmqayoung: optimize it ?18:33
ayoungMulti-site is going to be a real issue18:33
*** Apoorva has joined #openstack-meeting18:33
cbitsyes for many products,  OpenBook, ceilometer, custom CMDB, etc.18:34
ayoungsamueldmq, perhaps.18:34
bretonhow slow is too slow?18:34
ayoungbreton, "16 times" was the agrebennikov quote18:34
cbitsI have been working with agrebennikov: to find a good way to do this.  That is why I like his patch18:34
dstanekayoung: the assignments should also be part of that or automatically creating a project is useless18:34
ayoungbut..again, not a complete solution anyway18:34
ayoungcbits, it seems to me that what you18:34
dstanek16x for obtaining the initial token?18:35
*** penick has joined #openstack-meeting18:35
ayoung need is a way to syncronize the remote sites and perform "eventually consistent" semantics18:35
ayoungdstanek, ++18:35
samueldmqwow18:35
*** pfallenop has joined #openstack-meeting18:35
agrebennikovplease, lets remove my emotional paragraph from the topic please :/18:35
ayoungIE.  I usually work with region A  but today I am working with region B and I need everything over there to mirror Region A for me18:35
*** penick_ has joined #openstack-meeting18:36
*** haleyb_ has joined #openstack-meeting18:36
*** mkoderer has quit IRC18:36
samueldmqdstanek: I agree with you. user_id must be the same too. assignments must be the same too.18:36
stevemaragrebennikov: if you're referring to the etherpad, you can edit that.18:36
ayoungcbits, are new projects and assignments only every going to be written via your orchestration tool and in a centralized location, and then you need to sync them down to the remote Keystones?18:37
agrebennikovI mean 16x18:37
cbitsayoung: yes18:37
stevemaragrebennikov: cbits what's preventing you from creating a custom interface for create_project?18:37
ayoungcbits, ok...so it sounds like what you need is along these lines:18:37
ayoung1.  disallow local writes on a certain set of tables:18:38
ayoungprojects, assignements, to start18:38
stevemari can't see this landing upstream given the concerns, it's way too contentious. but i don't want to stop you from attempting it yourself18:38
stevemarwe keep going around in circles18:38
lbragstadagrebennikov did you experience a 16x performance degradation in your testing?18:38
ayoung2.  push data from a central orchestration hub (say a keystone server, but that is limited to just accessfrom the orchestration engine) down to the remote keystones for that data18:39
ayoungAD is external and used for authN18:39
dstanekstevemar: agreed... it would be nice to come back with some experience on this being deployed and discuss again in the future18:39
samueldmqstevemar: is the ML discussion still flowing ?18:39
lbragstadsamueldmq yeah18:39
*** penick has quit IRC18:39
*** penick_ is now known as penick18:39
ayoungWith the exception of Token data (which now should be ephemeral) I think you can get away with a completely read-only Keystone everywhere but in the auth Hub18:39
ayoungwill not allow for self service of anything, though18:39
dstanekagrebennikov: how often did you need to do the operation that took 16x?18:40
samueldmqlbragstad: stevemar so perhaps that's the right way to continue the discussion18:40
cbitsWe can patch the code,  thats easy.  however it seems that an optional pram that is validated seems resonable.18:40
ayoungdstanek, he was just saying K2K took a lot longer than getting a token18:40
ayoungand I don't think it solves his needs anyway18:40
agrebennikovI did not of course. But keeping in mind you always have to make inter-services calls between different geo locations, and since I tried it before with one of the external auth system ldap/federation manner I can say for sure that it's way slower18:40
lbragstadagrebennikov so 16x is arbirtrary18:40
stevemarcbits: unfortunately not :(18:41
stevemarcbits: once we open up the possibility, others will start using it18:41
cbitsyes, I get where you are coming from.18:41
agrebennikovyes sir. also another usecase which I described yesterday and nobody pointed an attention - replicated images should be always replicated across zoned into the same projectIDs18:41
cbitsI was hoping to solve my use case and not carry a patch.18:41
agrebennikovand this is not a problem of glance18:41
*** Kiall has joined #openstack-meeting18:41
dstanekayoung: yeah, i was just trying to get a handle on how slow it actually was18:41
*** julim has quit IRC18:42
*** akuznetsov has joined #openstack-meeting18:42
stevemarcbits: i think this is one of the few instances where i'd advocate that you folks try it out first and pass along any results you come up with18:42
ayoungagrebennikov, I really think you need to do this at the database level.  Sorry. There is just too much of a data integrity problem otherwise. It is more than just projects.18:42
samueldmqayoung: +18:43
dstanekagrebennikov: i don't know anything about glance, but from the thread i thought that the image ids were different18:43
lbragstadi meant to follow up with sigmavirus on that18:43
agrebennikovnope. replicator needs to make sure that whenever the image appears in regionA - it moves it to the regionB. Obviously it may only rely on the project18:44
*** rfolco has joined #openstack-meeting18:44
ayoungOK...I don't think we are moving ahead with this one.  Sorry folks.18:44
agrebennikovdstanek, and obviously not the project name18:44
agrebennikovayoung, got for it.... :(18:45
stevemaryeah, we're just going around in circles at this point18:45
dstanekagrebennikov: but you're not comparing apples to apples. if they don't guarantee the ID and we are saying we can't then you already have that ability18:45
stevemar:\18:45
samueldmqagreed, and still have 3 topics :(18:45
cbitsThanks for your help.18:45
samueldmqthink it's better to continue on the ML18:45
samueldmqand review18:45
stevemarsorry agrebennikov and cbits18:45
agrebennikovfor sure we will. Thanks everyone18:45
samueldmqagrebennikov: cbits thanks18:46
*** lpetrut has joined #openstack-meeting18:46
ayoungLast up ... RBAC18:46
stevemarayoung: lol, thats not even on the agenda :P18:46
ayoungstevemar, yes it is18:46
samueldmqehehe18:46
ayoungoh..last weeks18:46
stevemarayoung: ^_^18:46
samueldmqit's on last week's agenda18:47
ayoungquick vote on whether we think it can go in?    RBAC in MIddleware  [ayoung]18:47
ayoung    https://review.openstack.org/#/c/391624/18:47
ayoungsince we are talking specs18:47
lbragstadi need to look at the latest revision18:47
stevemari haven't looked into it enough, abstaining18:47
ayoungIf the group opinion is to support it, I'll push.  If not, I'll back off.18:47
ayoungbiggest difference is naming18:47
*** penick has quit IRC18:48
ayounginstead of URL_PAttern,  calling the main entity: access_rule18:48
samueldmqmaking role checks in middleware is technically possible and I like it18:48
ayoungalso added in a default scheme18:48
samueldmqnot sure about the steps to get there. like splitting the policy etc18:49
ayoung{ pattern: "ANY", verb: "ANY" role: "<role>"}18:49
samueldmqayoung: I also owe you a review18:49
ayoungtimes running out before spec freeze.  I think this moves us ahead a lot.18:49
*** s3wong has joined #openstack-meeting18:49
ayoungIt is based on, quite simply, years of discussions, trial, and feedback18:49
stevemarayoung: so you'll have a bunch of predefined responses for URL patterns ?18:49
*** akuznetsov has quit IRC18:50
*** spzala has joined #openstack-meeting18:50
ayoungstevemar, I don't quite understand the question18:50
ayoungresponses?18:50
lbragstad10 minute mark18:50
stevemarayoung: i'll talk to you about it after the meeting18:50
ayoungwe can figure out what the URL patterns them selves are from the api-regs18:50
*** lpetrut has quit IRC18:50
ayoungrefs18:50
ayoungok...18:50
ayoungI'll stick around.  surrendering the conch18:51
samueldmqayoung: does it define a brand new syntax for the new RBAC-only policy for the middleware ?18:51
samueldmqok, later on -keystone18:51
stevemarayoung: it looks decent though, and isolated18:51
ayoungyes...like the routes in keuystone: 'pattern': '/v2/images/{image_id}/reactivate',18:51
stevemarayoung: i'm just looking for stuff that doesn't touch critical paths at this point18:51
ayoungwe can default just about everything to "Member" with no loss of security, too18:52
stevemarspilla: around?18:52
spillayup18:52
stevemarayoung: switching to spilla's topic18:52
stevemargotta give the new folks the floor!18:53
stevemar#topic PCI-DSS Query Password Expired Users18:53
*** openstack changes topic to "PCI-DSS Query Password Expired Users (Meeting topic: keystone)"18:53
stevemarspilla: sounds like you're asking advice on an implementation detail18:53
spillacorrect18:53
rderoseI like /v3/users?password_expires_at=gt:{timestamp}, which is what was in the spec and is consistent with the guidelines:18:53
rderosehttp://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html#filtering18:53
*** krtaylor has joined #openstack-meeting18:54
ayoungThat will work18:54
ayoungany driving reason not to do it?18:54
stevemarrderose: well the gt and lt stuff is more for quantity i think?18:54
*** tonytan4ever has quit IRC18:54
samueldmqI am not sure filtering at an exact timestamp is useful for anyone18:54
*** rbartal_ has quit IRC18:55
samueldmq /v3/users?password_expires_at={timestamp}18:55
stevemar /users?pasword_expires_after={some time stamp} seems a bit clearer18:55
ayoungah...18:55
spillathe reason I went with /v3/users?password_expires_before={timestamp} was to make it easier to under stand if you start chaining them, or even in general18:55
spillabut that doesn't make it more right or wrong18:55
*** weshay has quit IRC18:55
ayoungat the API level, let us implement the set of them18:56
spillawanted some input to head the best direction18:56
*** zara_the_lemur__ has joined #openstack-meeting18:56
ayoungif there is a rationale for each, we can give the choice18:56
samueldmqand we can combine them, right ? with ?password_expires_before={timestamp1}&password_expires_after={timestamp0}18:56
ayoung++18:56
stevemarthat makes sense18:56
ayoungexpires AT seems low value, but if there is a need for it, include it as well18:56
spillaayoung ++ both is always an option18:57
samueldmqagain, making a perfect match ?password_expires={timestamp} does not make sense to me18:57
stevemarthis reminds me of http://developer.openstack.org/api-ref/compute/?expanded=list-servers-detailed-detail#list-servers-detailed18:57
dstanekthe gt: is what the api-wg is recommenting18:57
samueldmqnot sure if anyone agree with me on that18:57
rderoseI just think lt gt solves it and it's consistent with other filtering18:57
*** AJaeger has joined #openstack-meeting18:57
*** bobh has joined #openstack-meeting18:57
stevemardstanek: but that's more for quantities18:57
*** rbartal has quit IRC18:57
dstanekstevemar: no according to their examples18:57
ayoungspilla, that enough to go on?18:57
rderosestevemar: no18:57
dstanek"GET /app/items?finished_at=ge:15:30&finished_at=lt:16:00"18:57
rderosedstanek: ++18:58
stevemaroh did i miss that?18:58
dstanekhttp://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html#time-based-filtering-queries18:58
*** weshay has joined #openstack-meeting18:58
lbragstaddstanek i like that18:58
stevemaroh there it is: GET /app/items?finished_at=ge:15:30&finished_at=lt:16:0018:58
dstaneki assume dates would be handled the same way, but that's not explicit18:59
stevemarspilla: there's your answer ^18:59
*** mamitchl has joined #openstack-meeting18:59
spillaso gt lt seems to be it18:59
stevemaryessir18:59
stevemarwrapping up!18:59
stevemar#endmeeting18:59
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"18:59
spillaty all!18:59
openstackMeeting ended Tue Dec  6 18:59:30 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:59
openstackMinutes:        http://eavesdrop.openstack.org/meetings/keystone/2016/keystone.2016-12-06-18.00.html18:59
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/keystone/2016/keystone.2016-12-06-18.00.txt18:59
samueldmqspilla: http://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html#time-based-filtering-queries18:59
stevemarthanks for coming everyone18:59
openstackLog:            http://eavesdrop.openstack.org/meetings/keystone/2016/keystone.2016-12-06-18.00.log.html18:59
* stevemar needs coffee18:59
*** sdake has quit IRC18:59
*** akuznetsov has joined #openstack-meeting18:59
*** gagehugo has left #openstack-meeting19:00
fungiinfra team, assemble!19:00
SotKo/19:00
clarkbits like we are power rangers19:00
*** spilla has left #openstack-meeting19:00
fungithis week's topics proposed by jeblair and clarkb19:00
*** dmorita has quit IRC19:00
* jlvillal lurks in the corner...19:00
zaroo/19:00
*** olaph has joined #openstack-meeting19:01
ianwmorning!19:01
AJaegerevening!19:01
pabelangerrawr19:01
olapho/19:01
zara_the_lemur__o/19:01
*** bobh has quit IRC19:01
*** LamT__ has quit IRC19:02
*** pnavarro has joined #openstack-meeting19:02
jheskethMorning19:02
*** dmorita has joined #openstack-meeting19:02
*** pfalleno1 has joined #openstack-meeting19:02
*** pfalleno1 has quit IRC19:03
fungi#startmeeting infra19:03
openstackMeeting started Tue Dec  6 19:03:33 2016 UTC and is due to finish in 60 minutes.  The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot.19:03
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.19:03
*** openstack changes topic to " (Meeting topic: infra)"19:03
openstackThe meeting name has been set to 'infra'19:03
*** sambetts is now known as sambetts|afk19:03
*** saisriki__ has joined #openstack-meeting19:03
fungi#link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting19:03
*** akuznetsov has quit IRC19:03
fungi#topic Announcements19:03
*** openstack changes topic to "Announcements (Meeting topic: infra)"19:03
jlvillalo/19:03
fungi#info REMINDER: If you want to come hack on Infra things at the PTG a couple months from now in Atlanta, don't forget to sign up!19:03
fungi#link https://pikeptg.eventbrite.com/19:04
fungi#link http://www.openstack.org/ptg19:04
fungii'm told there is plenty of travel assistance available too--if you need it don't be embarassed to ask for it19:04
fungi#link http://www.openstack.org/ptg#tab_travel19:04
fungias always, feel free to hit me up with announcements you want included in future meetings19:04
fungi#topic Actions from last meeting19:04
*** openstack changes topic to "Actions from last meeting (Meeting topic: infra)"19:04
fungi#link http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-11-29-19.03.html19:04
fungifungi send summit session summary to infra ml19:04
fungi#link http://lists.openstack.org/pipermail/openstack-dev/2016-December/108536.html Ocata Summit Infra Sessions Recap19:05
fungiFINALLY!19:05
zara_the_lemur__\o/19:05
fungiand reply to that with any corrections/additions, of course19:05
fungipabelanger add openstackci::zuul_launcher puppet class19:05
fungido we have a change for that yet?19:05
*** Shrews has joined #openstack-meeting19:05
*** sdake has joined #openstack-meeting19:05
pabelangersadly no19:06
pabelangeron my plate to do19:06
*** iyamahat has quit IRC19:06
*** iyamahat_ has joined #openstack-meeting19:06
fungiokay, cool--thanks!19:06
pabelangerI'll make time this week to finish it up19:06
fungi#action pabelanger add openstackci::zuul_launcher puppet class19:06
fungiand that's it for the action items from last week, i think19:06
*** e0ne has joined #openstack-meeting19:07
fungi#topic Specs approval: PROPOSED Zuul v3: use Zookeeper for Nodepool-Zuul protocol (jeblair)19:07
*** openstack changes topic to "Specs approval: PROPOSED Zuul v3: use Zookeeper for Nodepool-Zuul protocol (jeblair) (Meeting topic: infra)"19:07
jeblairi think this is ready19:07
fungi#link https://review.openstack.org/305506 Zuul v3: use Zookeeper for Nodepool-Zuul protocol19:08
jeblairit's gone through some revision and should be fairly well vetted now19:08
fungi#info Council voting is open on the "Zuul v3: use Zookeeper for Nodepool-Zuul protocol" change until 19:00 UTC on Thursday, December 8.19:08
jeblairjhesketh caught some typos, i suggest we vote on this version and i'll fix in a followup19:08
fungisounds good to me19:08
jhesketh+119:08
jeblairand incidentally, i think we'll be about ready to start on this shortly after it lands19:09
fungigreat timing19:09
*** electrofelix has quit IRC19:10
jheskethAwesome :-)19:10
jeblair[eot from me]19:11
fungithanks jeblair19:11
fungianybody else have any concerns before we move on?19:12
fungi#topic Priority Efforts: Nodepool: Use Zookeeper for Workers (jeblair)19:12
*** openstack changes topic to "Priority Efforts: Nodepool: Use Zookeeper for Workers (jeblair) (Meeting topic: infra)"19:12
*** Apoorva has quit IRC19:12
fungitalked about this in the zuul meeting yesterday, right?19:13
jeblairyes --19:13
*** Apoorva has joined #openstack-meeting19:13
jeblair#link zk blockers from zuul meeting http://eavesdrop.openstack.org/meetings/zuul/2016/zuul.2016-12-05-22.02.html19:13
jeblairif you look at the action items there, we identified some things that we want to see happen before we think we're ready to start using the new zk nodepool builder in production19:14
*** bapalm_ has quit IRC19:14
*** haleyb_ has quit IRC19:14
jeblairit's a pretty short and simple list19:14
jeblairso there's a good chance we'll have it done late this week, early next week19:14
pabelangernb02.o.o is already online, thanks to Shrews help19:15
jeblairwhen that's accomplished, i'd like to switch nodepool.o.o to use the zuulv3 branch (which will cause the nodepoold there to use the builds from the zk builder)19:15
jeblairand if that goes well, merge feature/zuulv3 into master shortly thereafter19:15
*** nadya has joined #openstack-meeting19:15
jeblairand switch all the nodepool hosts back to running master19:15
fungireview focus on project:openstack-infra/nodepool branch:feature/zuulv3 is appreciated to get this in place in a timely fashion?19:16
*** noslzzp has quit IRC19:16
jeblairdoes that sound good to folks?  any concerns?  additional blockers we should add to the punch list?19:16
*** jgregor has joined #openstack-meeting19:16
clarkbare there no changes on master that we need in v3 first? eg should the merge come first?19:16
jeblairfungi: yep19:16
*** noslzzp has joined #openstack-meeting19:16
jeblairclarkb: jhesketh merged master into v3 recently19:16
jeblairso i think we're set19:17
clarkbah ok19:17
*** nk2527 has quit IRC19:17
jeblairwe could merge first, but this lets us quickly revert without making a mess of the git tree :)19:17
clarkbya19:17
fungilooks like maybe there's been one change on master since then?19:17
jheskethIf it's shifted I can merge into v3 again19:17
*** jgregor_ has joined #openstack-meeting19:18
fungiMerge "Have an ending line-feed on the generated id_rsa.pub file" is a day newer19:18
*** bapalm has joined #openstack-meeting19:18
*** jgregor_ has quit IRC19:18
* jlvillal spots his commit19:18
jeblairjhesketh: if you could do another merge, that would be swell.  should be easy.  :)19:18
*** jgregor_ has joined #openstack-meeting19:18
clarkbfungi: don't think that one affects us19:18
clarkbbut getting up to syncage would be good19:19
fungiyeah, it was https://review.openstack.org/38349619:19
*** haleyb_ has joined #openstack-meeting19:19
jheskethYep. Is it worth waiting until we're close to deploy v3 though19:19
*** faizy_ has quit IRC19:19
fungiagreed, that's more just let's make sure it doesn't get lost/conflict19:19
mordredo/19:19
jeblairjhesketh: i think we're pretty close; i say we do it now, and hopefully master won't move too much in the next week or two.19:20
fungii think that's a fine plan19:20
*** jgregor has quit IRC19:20
jheskethOkay19:20
fungi#agreed We're on track to switch to ZK-based nodepool builders in roughly a week's time.19:21
*** nadya has quit IRC19:22
fungiit's a sweet spot between holidays, so there's hopefully a fair number of people around to work out any kinks but not such high volume of activity that the impact will be dreadful should something go sideways19:22
mordred++19:22
jeblairyeah, and there should only be a momentary outage when we restart nodepoold19:22
*** e0ne has quit IRC19:23
dhellmannthat's all coming before the 2nd milestone?19:23
*** vishnoianil has joined #openstack-meeting19:23
*** Sukhdev has joined #openstack-meeting19:23
*** spzala has quit IRC19:23
Shrewswhy not create a stable-2.5 branch, just in case?19:23
fungidhellmann: yeah, we should shoot to not have this impact your... thursday activities next week?19:24
dhellmannthe milestone is on the 15th, so next week should be fine19:24
fungidhellmann: any specific days we need to blacklist for disruptive changes?19:24
dhellmannwait, what's today?19:24
dhellmannyeah, as long as it's before thursday it should be ok19:24
fungitoday's the 6th19:24
*** pnavarro has quit IRC19:24
dhellmannyeah, my calendar was on the wrong page :-)19:25
jeblairShrews: well, it would be a stable 0.0 branch if we did.  and i don't believe we intend to support it.  we made a tag for the last version of nodepool people should use if they want to avoid zk.19:25
dhellmannso avoiding thursday and friday would be good, but it sounds like that's the plan19:25
*** nadya has joined #openstack-meeting19:25
jeblairdhellmann: yeah, i'm thinking *this* thursday or friday, or if not, early next week.19:25
dhellmannsounds good19:26
fungi#info Coordinate any potential disruptions late next week with the Release team.19:26
*** nadya has quit IRC19:26
clarkbthis week si fine right?19:26
fungiyeah, it's a dead week on https://releases.openstack.org/ocata/schedule.html19:26
clarkbpretty sure when we decided to do the xenial stuff this week it was to avoid release things19:26
clarkbkk19:26
jeblaironce we merge v3 into master, i think we should issue another release and suggest early adopters may want to try using it along with us.19:26
mordredjeblair: ++19:26
dhellmannyeah, mainly just trying to avoid changes *on* deadline days, so it sounds like your plans are fine19:26
fungithanks for jumping in dhellmann!19:27
* dhellmann goes back to lurking19:27
fungiyour constant lurkiness is always appreciated19:27
jeblaireveryone should lurk so well19:27
fungii definitely want to make sure we keep release activity disruptions to a minimum, in particular19:28
fungithere are even fewer of them than there are of us19:28
*** haleyb_ has quit IRC19:28
fungiokay, so additional release. minor bump, or major prerelease?19:29
clarkbit would have to be major prerelase I think if we wanted to semver right?19:29
clarkbthese changes aren't entirely backward compatible19:29
fungiwell, we're at a 0.x release still19:30
clarkb(though for the most part your old config will work with new stuff with small changes19:30
mordredclarkb: yes - but we've never released a supported version of nodepool19:30
clarkbah19:30
*** jgregor_ has quit IRC19:30
jeblairwell, depending on how you read this with semver, it might actually could be a micro, because it is backwards compatibleish19:30
fungiso 0.4.0 would be reasonable, but i could also get behind 1.0.0.0b119:30
fungii guess depends on how ish the ish part is19:31
*** annegentle has joined #openstack-meeting19:31
clarkbthe ish part is you need new config for zk and need to have a zk server19:31
*** Sukhdev has quit IRC19:31
clarkbeverything else is compat I think19:31
fungii'm assuming nodepool 1.0.0 is targeted roughly coincident with zuul 3.0.019:31
mordredyah.19:31
*** gyee has joined #openstack-meeting19:31
*** claudiub has joined #openstack-meeting19:32
*** Sukhdev has joined #openstack-meeting19:32
jeblairat any rate, i lean toward 0.4.0 with a slightly generous interpretation of semver19:32
*** jgregor has joined #openstack-meeting19:32
fungii think we agreed to pre-announce any nodepool backward incompatibilities on the infra ml in advance too? or was nibalizer satisfied if we just told people to pin to something a while back?19:33
*** spzala has joined #openstack-meeting19:33
*** jgregor has quit IRC19:33
*** mmotiani has quit IRC19:33
*** mrmartin has quit IRC19:33
fungii mean, i know we pretty thoroughly announced the zk addition was in the pipeline19:33
clarkbya I think we told people to pin. maybe double check we didn't say pin to <1.019:33
clarkbbecause that could influence this version picking19:33
jeblairi'm still happy to pre-announce both the merge and the release.19:33
*** pleia2 has quit IRC19:34
jeblairgood opportunity to let people know what's happening, and in the case of the release, let people know how to start using it19:34
*** morgabra has quit IRC19:34
*** pleia2 has joined #openstack-meeting19:34
*** morgabra has joined #openstack-meeting19:34
*** claudiub|2 has quit IRC19:35
*** andreaf has quit IRC19:35
*** toabctl has quit IRC19:35
jeblair(but both of those will happen after the v3 branch is in prod, so we have some time)19:35
*** mrmartin has joined #openstack-meeting19:35
fungiawesome19:35
*** jgregor has joined #openstack-meeting19:36
*** nk2527 has joined #openstack-meeting19:36
*** toabctl has joined #openstack-meeting19:36
*** mmotiani has joined #openstack-meeting19:36
*** vgadiraj has joined #openstack-meeting19:36
fungiokay, anything else to discuss right now on the road toward nodepool 1.x?19:36
jeblairnope19:37
*** andreaf has joined #openstack-meeting19:37
fungithanks jeblair!19:37
fungi#topic Priority Efforts: Newton testing on Xenial (clarkb)19:37
*** openstack changes topic to "Priority Efforts: Newton testing on Xenial (clarkb) (Meeting topic: infra)"19:37
clarkbSo this is mostly a heads up that we are moving ahead with the day we picked in Barcelona (today)19:38
fungi#link https://etherpad.openstack.org/p/xenial-work-remaining Work remaining for Newton testing on Xenial19:38
AJaegerplease all help with reviewing: https://review.openstack.org/#/q/topic:st-nicholas-xenial+status:open19:38
clarkbmy rough process has been to go through jenkins/jobs/*.yaml alphabetically and crank out changes19:38
clarkbAJaeger is going through the list in reverse sort order19:38
AJaegerwe've frozen project-config and will only merge these xenial changes for now.19:38
fungi#info Today is the Xenial cut-over flag day; conversion changes are in flight.19:38
AJaegeranybody that wants to help? Reviewing and doing changes, both is needed!19:39
clarkbanyone that cna help review is much appreciated. If you want to help write changes too we can carve you out a chunk of yaml files in the middle of the alphabet19:39
clarkbI have a feeling this work will carry over into tomorrow. Just based on how much progress we have been making19:39
* AJaeger is not sure whether we finish today - I'm at s and will finish that but not sure I can take on much more.19:39
clarkbits not really slow just lots to do19:39
fungi#link https://review.openstack.org/#/q/is:open+topic:st-nicholas-xenial please review remaining job changes for the switch to xenial19:40
*** doonhammer has joined #openstack-meeting19:40
fungii don't think it's crucial that we _finish_ today. we told people we'd start force-converting them today19:40
*** rbak has joined #openstack-meeting19:40
fungiand progress has been great so far (thanks especially to AJaeger and clarkb who have been writing most of them)19:41
AJaegerclarkb: I won't be able to help much tomorrow19:41
clarkbAJaeger: ok I am sure there will be others around. Thanks for all the work you have done its been a big help19:41
clarkbfungi: I do think we want to get done this week to avoid release team conflicts but yes19:41
AJaegerclarkb: thanks for driving this!19:41
fungiclarkb: yep, completely agree19:41
fungialso once it's done, i think we can put the last nails in the coffin for this priority effort/spec?19:42
clarkbyup19:42
fungiwill be nice to scratch one more off the list19:42
clarkbthough I do think it is showing us we have a lot of cleanup that we should push on. Basically there is a lot of cruft in our jobs. Experimental and non voting jobs that in theory don't have anyone caring for them since they haven't been updated19:43
clarkbwe should probably think about clearing that out before we do any zuulv3 transition19:43
fungiyeah, looks like the last work item will be covered:19:43
clarkbreduces the problem set19:43
fungi#link http://specs.openstack.org/openstack-infra/infra-specs/specs/newton-on-xenial.html#work-items Newton testing on Xenial: Implementation Work Items19:43
AJaegeryes, we need some more cleanups - I'm doing minor local ones while changing but we need some more later19:44
clarkb(I don't think this cleanup should be tracked under this priority effort, its just something I am noticing as I do the work and it could make zuulv3 easier to get it done)19:44
fungiSpamapS: ^ that might be a good task to get on one of the planning boards?19:44
*** ianychoi has quit IRC19:45
fungibasically before we convert our corpus of job configs, try to filter out any unused cruft19:45
pabelangerAJaeger: I'll review again shortly19:45
jeblairfungi: we can, but i don't want to set it up as a blocker19:45
jeblairfungi: we're going to end up with tools to convert our jobs mostly automatically19:45
clarkbya not sure its a blocker19:45
jeblairso they should not be a large cost to the conversion -- cleanup can happen both before and afterwords19:46
fungiokay, so more of a "it will be a nice low-hanging fruit task"19:46
*** mamitchl has left #openstack-meeting19:46
clarkbmore of a "we should really do this beacuse its getting gross in there a bit"19:47
fungianyway, in summary: review review review19:47
fungilots of very similar but subtly different changes in flight in project-config, and we've mostly frozen job config changes for any other efforts until we worth these through to inimize merge conflicting19:48
AJaegerwe also need some mroe reviewers - yolanda and myself review a lot on project-config, we could use a third reviewer ;) Especially for our own changes I have to ping quite often ;(19:48
AJaegerwe emptied the open queue before the freeze to an all-time low of 89 open reviews ;)19:48
fungitotally. infra needs more reviewers in general, but the project-config reviews are extremely high-volume. i also hope that zuul19:48
*** ijw has quit IRC19:49
fungiv3 minimizes that some19:49
jeblairyes, i'm focusing less on project-config reviews so i can make zuulv3 so we have fewer project-config reviews19:49
jeblairi'm sorry that makes things worse right now, but i hope it will make things better in the future19:49
ianwi can make an effort to get back to more project-config reviews19:49
AJaegerjeblair: appreciated19:49
AJaegerthanks, ianw19:50
*** claudiub|2 has joined #openstack-meeting19:50
pabelangerI can chip in more too19:50
fungidoesn't look like we have any general topics on the agenda today, so...19:51
fungi#topic Open discussion19:51
*** openstack changes topic to "Open discussion (Meeting topic: infra)"19:51
jlvillalI guilty ask for a review request: devstack-gate https://review.openstack.org/#/c/396717/19:51
ianwi don't really know what happened with the pypi mirror volume the other day.  if anyone with more detailed afs knowledge can glean anything from the logs, that would be cool19:52
jlvillalAnd a meetbot one: https://review.openstack.org/40440719:52
clarkboh good I have alredy reviewed that one19:52
jlvillalheh19:52
fungiand yes, thanks to everyone who finds time to do some reviewing in general. we've lost some key contributors partially or completely in recent months, but our change volume hasn't dropped appreciably19:52
*** claudiub has quit IRC19:53
fungijlvillal: thanks, that also reminds me...19:53
fungi#link http://lists.openstack.org/pipermail/openstack-infra/2016-December/004951.html the fedora community wants to collaborate with us on our meetbot fork, and possibly on the errbot-based rewrite19:53
mordred\o/19:54
fungii'm always happy when we get opportunities like this to collaborate on community infrastructure projects with others outside openstack19:54
jeblair++19:55
flaper87fungi: collaboration on meetbot sounds awesome indeed19:55
*** Rocky_g has joined #openstack-meeting19:55
fungibkero: harlowja: ^ i think both of you had maybe looked into some of our ircbot stuff, so that thread might interest you?19:55
fungiflaper87: yeah, it's dead upstream, and our fork seems to be the only active one around. so i guess we're upstream now :/19:56
clarkbfungi: funny how that happens19:57
clarkb"you are crazy enough to be using that software I wrote? tag you're it!"19:57
jlvillalYeah. Last commit upstream seems to be 2010 or something like that.19:57
SpamapSfungi: regarding cleaning up jobs, I don't think we've defined the set of jobs that have to run reliably to get to operational zuulv3. The capabilities have been the focus. But it's a good point that as we get closer, we'll want to cut the fat.19:58
bkerofungi: Sounds good to me19:58
bkeroThanks for the mention19:58
*** bobh has joined #openstack-meeting19:58
*** dmorita has quit IRC19:58
fungiaaaaand... we're just about out of time. thanks everyone!19:59
*** dmorita has joined #openstack-meeting19:59
fungisee you next week, same bat time, same bat channel20:00
fungi#endmeeting20:00
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"20:00
openstackMeeting ended Tue Dec  6 20:00:02 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)20:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-12-06-19.03.html20:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-12-06-19.03.txt20:00
openstackLog:            http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-12-06-19.03.log.html20:00
stevemaro/20:00
*** cdent has joined #openstack-meeting20:00
ttxholà20:00
fungistay tuned for the lovable hijinks of the openstack technical committee, up next!20:00
*** olaph has left #openstack-meeting20:00
ttxdhellmann, dims, dtroyer, EmilienM, flaper87, johnthetubaguy, mordred, mtreinish: around ?20:00
EmilienMbonsoir :-)20:00
dtroyero/20:00
dhellmanno/20:00
ttxsdague and thingee are excused20:01
* edleafe lurks behind a tree20:01
sdagueo/20:01
mordredo/20:01
mordredlook it's an sdague20:01
flaper87o/20:01
ttxah, sdague is back20:01
fungijohnthetubaguy e-mailed saying he's gone today20:01
*** rfolco has quit IRC20:01
ttxHow was hiatus?20:01
* mordred hands sdague a pie20:01
sdaguemmmm pie20:01
stevemarfungi: hijnks yes, loveable, nope20:01
* jroll lurks20:01
sdaguettx: very refreshing20:01
*** tpsilva has quit IRC20:01
ttxfungi: I think he hasd a reason based on honeymoon or such20:01
flaper87sdague: welcome back20:02
*** rwsu has quit IRC20:02
fungiyup20:02
sdagueflaper87: thanks20:02
ttx#startmeeting tc20:02
jrollyeah, john is on honeymoon, congrats to him \o/20:02
openstackMeeting started Tue Dec  6 20:02:06 2016 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.20:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.20:02
*** openstack changes topic to " (Meeting topic: tc)"20:02
openstackThe meeting name has been set to 'tc'20:02
dhellmannttx: dims just contacted me that he won't be able to make it20:02
ttxalright noted20:02
ttxHi everyone!20:02
ttxOur agenda for today:20:02
ttx#link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee20:02
ttx(remember to use #info #idea and #link liberally to make for a more readable summary)20:02
* Rocky_g just crept under the table with popcorn20:02
ttx#topic Driver teams: discuss various options20:02
*** openstack changes topic to "Driver teams: discuss various options (Meeting topic: tc)"20:02
*** AJaeger has left #openstack-meeting20:02
ttx#link http://lists.openstack.org/pipermail/openstack-dev/2016-November/thread.html#10807420:02
ttxI'll let dhellmann introduce the topic, then we'll likely take turns talking so that it's not too messy20:02
dhellmannthanks, ttx20:03
*** bobh has quit IRC20:03
dhellmannTo prepare for some upcoming big tent team proposals, I reviewed our current policies and found that they could be interpreted to not allow a team to build something focused on a single vendor's product line, as a driver would be in a lot of cases.20:03
dhellmannWe need to address that, because as things stand we will end up turning away contributors to the community.20:03
dhellmannBoth in terms of the people contributing, and in terms of the companies funding much of our work.20:03
dhellmannGiven the other recent cutbacks that were beyond our control, I think we should avoid encouraging companies to disengage from the community.20:03
mordred++20:03
dhellmannTogether ttx, fungi, and I identified 6 potential courses of action, represented by the various patches we've posted for review.20:03
dhellmannI'm going to just paste these all at once, stand by20:03
dhellmann#info option 1. Say that we prefer having a level playing field to allowing standalone driver teams. (Identified as the "hard black" option)20:03
dhellmann#link https://review.openstack.org/#/c/403834/20:03
dhellmann#info option 2. Say that the level playing field policy doesn't apply to driver teams, if the resources needed to work on the driver are open. (Identified as the "soft black" option)20:03
dhellmann#link https://review.openstack.org/#/c/403836/20:03
dhellmann#info 3. Remove the level playing field statement from the project team policies. (Identified as the "hard white" option)20:03
dhellmann#link https://review.openstack.org/#/c/403838/20:04
dhellmann#info 4. Loosen the level playing field statement to exempt driver teams completely. (Identified as the "soft white" option)20:04
dhellmann#link https://review.openstack.org/#/c/403839/20:04
dhellmann#info 5. Define a new type of team with different rules based on different expectations for driver teams. (Identified as the "grey" option)20:04
dhellmann#link https://review.openstack.org/#/c/403829/20:04
dhellmann#info 6. Require project teams with driver abstractions to host drivers in one of their official repos, as long as they meet some community standards. (Identified as the "red" option)20:04
dhellmann#link https://review.openstack.org/#/c/403830/20:04
dhellmannAs well as a general resolution that might be mixed in with one of the other changes to provide more detail.20:04
dhellmann#link https://review.openstack.org/#/c/403826/20:04
dhellmannSo far most of the discussion for the topic has been on the mailing list20:04
dhellmann#link start of thread http://lists.openstack.org/pipermail/openstack-dev/2016-November/thread.html#10807420:04
dhellmann#link continuation of thread http://lists.openstack.org/pipermail/openstack-dev/2016-December/thread.html#10841020:04
dhellmanndone20:04
ttxI propose we take turns exposing our position, if we have one. Raise your hand (using o/) and wait until I give you voice20:04
dhellmanno/20:04
ttxI can start20:04
*** tonytan4ever has joined #openstack-meeting20:04
ttxah no, dhellmann20:04
fungithe ml discussion was disappointingly sparse. i was hoping we'd drum up more interest in weighing pros and cons20:04
dhellmannoh, that's fine, go ahead20:04
ttxok20:04
ttxMy personal view on this is that we should not dilute our open collaboration principles20:05
ttxwhich is why I am against the hard white option, and am not a fan of the soft white option20:05
flaper87o/20:05
ttxI think it's unhealthy to require teams to adopt code they don't want, so I'm against the red option20:05
mtreinisho/20:05
ttxAt the same time I think it would be better if we could include driver development as a part of our community rather than force it outside20:05
*** browne has left #openstack-meeting20:05
ttxwhich is why I'm not a fan of the hard or soft black options.20:05
ttxI like the grey option, because it enables driver teams to be part of the community, without compromising on our principles.20:05
ttxIt *clearly* defines a narrow and limited case where it benefits OpenStack to be more flexible, and keeps track of it separately20:05
ttxSo in summary: my preference goes to grey, I could live with soft white / hard black / soft black if there is a majority for it, and I'm against hard white / red.20:06
*** snuffkin_ has quit IRC20:06
ttxvoice goes to dhellmann20:06
dhellmannI know there have been scaling and social issues within the Neutron team that have led to the current situation (best summed up by Armando and Kevin's posts in the thread).20:06
ttxthen flaper87 then mtreinish20:06
dhellmannThe other major projects that have drivers have had less trouble with this, which makes it seem that with some adjustments we could adopt a community standard practice.20:06
dhellmannI would prefer to have teams work things out internally so they can scale, rather than forcing scaling to happen by creating multiple teams.20:06
dhellmannIf some of our other policies and standards need to be reviewed to allow teams to scale “vertically", we should do that because the alternative is asking more teams to somehow scale “horizontally”.20:06
dhellmannContinuing with drivers within the existing projects also recognizes drivers as important contributions to and features of the services that consume them20:06
dhellmannand encourages the contributors to collaborate with the folks working on the abstraction layers within projects.20:07
mtreinishoh, I was just saying I showed up :)20:07
dhellmannThat's the outcome of option 6, without making it a hard requirement.20:07
ttxmtreinish: noted :)20:07
*** Shrews has left #openstack-meeting20:07
dhellmannWhich, I admit, isn't on the list of proposals and would need work.20:07
dhellmannThat said, it's possible that there is not a one-size-fits all solution.20:07
dhellmannIf the neutron team is committed to its current course, then I think we need to do something at the TC level, and adopt one of the other proposals.20:07
dhellmannI would prefer to simplify our rules, rather than add new ones, so I lean in favor of either interpreting "level" as meaning anyone can contribute so the teams are ok or removing the phrase entirely.20:08
dhellmannlet me convert those to colors...20:08
dhellmannsoft black, hard white, or soft white20:08
dhellmannI wrote up the red option, but I agree we don't want to set that precedent20:08
dhellmanndone20:09
ttxthat is your preference, or the list you can live up with ?20:09
mordredyah. I agree about not liking red20:09
dhellmannI can live with that list20:09
dhellmannoh, I can live with grey, too20:09
dhellmannI just prefer the options that seem simpler20:09
ttxdhellmann: and any preference ?20:09
dhellmannhard or soft white, I guess20:09
mordredI agree with ttx's list and preference except I'm not in favor of hard black20:10
ttxok so dhellmann says preference hard/soft white, can live with softblack or grey.20:10
*** askb has joined #openstack-meeting20:10
ttxflaper87: voice goes to you20:10
flaper87So, as I mentioned in the email I like the fact that option #5 acknowledges that drivers are somewhat different from other projects but I like the sense of inclusion that #6 gives. I'd like for #6 to be more explicit about it. I like that #6 gives the opportunity for drivers maintainers t ovote on the PTL election and it gives them also more voice (or the sense of mor voice) to these folks on the20:10
flaper87team choices. It feels more welcoming and inclusive than #5.That said, I think I'm leaning more towards #5 even though it adds more complexity. It is more explicit and helps with organizing teams better20:10
fungio/20:10
mordredttx: it might be worth spinning up a non-binding condorcet to help us sort through TC preference20:10
flaper87so, I guess my preference goes to grey20:10
sdagueo/ (queuing)20:10
ttxmordred: on it20:10
ttxqueue has fungi and sdague next20:11
sdaguemordred: why don't we see how close to concensus we are first20:11
mordredsdague: ++20:11
ttxsdague: ++20:11
ttxflaper87: preference to grey, and could live with... ?20:11
dtroyero/20:11
*** kaisers_ has quit IRC20:11
flaper87I could live with soft black and red20:12
flaper87I think I did the colors right20:12
*** sdake has quit IRC20:12
mugsieo/20:12
ttxmordred is: preference to grey, could live with soft white soft black20:12
ttxvoice goes to fungi20:12
fungii drafted the black and white options as i'd much prefer to find minimal policy solutions, or effective interpretations of current policy. the grey option strikes me as giving up on welcoming driver teams into the big tent, and making a smaller exceptions-based tent off to the side they can go sit in20:12
ttxqueue gas sdague, dtroyer next20:13
ttxhas*20:13
*** kaisers_ has joined #openstack-meeting20:13
fungiif we want to welcome them into our community, to me that means finding ways to have one consistent policy which covers them in the same ways as our other teams20:13
*** snuffkin has joined #openstack-meeting20:14
*** sdake has joined #openstack-meeting20:14
*** gordc has joined #openstack-meeting20:14
ttxfungi: do you have a preference ?20:14
fungion the other hand, i definitely want to make sure this doesn't simply become another place to get your driver/product listed to make it look better-supported20:14
fungiso i think my order of preference is soft black, hard white, soft white, hard black, grey, red20:15
ttxare there options you would rather not live with ?20:15
* EmilienM voted for hard black but actually would prefer soft black now, after re-reading the policies.20:15
fungiwell, i don't really like red at all since i'm not a fan of telling projects what to do20:15
*** sdake_ has joined #openstack-meeting20:16
ttxfungi: ok20:16
smcginnisHopefully I'm not derailing anything. Just another data point from me. I would be fine having drivers completely separate if adding a new driver was just a procedural rubber stamp by the core team. But I have yet to see a new driver submission that has not had to go through 20+ patch revs before it's in a decent shape to be accepted.20:16
*** rhagarty has joined #openstack-meeting20:16
smcginnisMy concern would be someone would run Cinder and an out of tree driver that has issues and have a bad experience.20:16
smcginnisThat would reflect badly on OpenStack and Cinder, even if it was entirely on the vendor for having issues.20:16
ttxthat is a fair point20:17
ttxvoice goes to sdague20:17
sdagueok, I feel like red is a no go entirely, that just turns into a friction level that won't work20:17
ttxqueue has dtroyer next, amybe mugsie if I interpreted the o/ right and no other TC member wants voice20:17
ttxsdague: ++20:18
sdaguemy preference is to grey, because while drivers are a contribution to openstack, they tend to be a much more self serving contribution for a particular piece of vendor hardware / software20:18
*** kaisers_ has quit IRC20:18
sdagueand I want to distinguish things that are purely that from working on the common base20:19
*** sdake has quit IRC20:19
sdagueespecially in our over analyticized community20:19
ttxsdague: are you done ?20:19
ttx(I completely agree)20:19
sdagueyeh, that's probably good enough for now20:19
ttxdtroyer; you're up20:20
dtroyerI agree with the desire for driver inclusion by the project teams, basically how dhellmann described it but not forced like the red option ( as written, red it not an option for me).  I recognize that is not always going to work out.  I do think that recognizing the specifics of these kinds of teams may be necessary.  It is a bit of a side-test as fungi put it, but I see that as part carrot, part stick to try and make the20:20
dtroyerWe are talking about code that by its very nature can not be tested the same way as the majority of OpenStack so we are already making exceptions for them.  I believe recognizing that and guiding it will improve the situation.20:21
dtroyerMy preference is for grey, soft white20:21
dtroyerfini20:21
ttxmugsie: did you want voice ?20:21
fungio/20:21
mugsieyeah  -I just had one thought20:21
sdaguejust a side comment, nothing here says that projects can't have drivers in tree, its for the case in which they choose not to for a particular driver / driver team20:21
ttxyeah, I would still encourage drivers to be in-tree, dhellmann has a complementary resolution for that20:22
dtroyersdague: ++, we should encourage that by default20:22
flaper87sdague: yeah, this is specific for vendor specific drivers, I think. but you phrased it better20:22
mugsiefor the softs, and the grey option, should something like 3rd party testing be a requirement ?20:22
*** rwsu has joined #openstack-meeting20:22
ttxmugsie: there could be20:22
Rocky_go/ two side comments20:22
flaper87mugsie: yeah, I think that's part of the proposal (probably not explicit)20:22
mugsie(I have been out ofr a while, and I did not see it in the ML thread - but if this has been answered, I appologise)20:22
sdaguemeaning option pink (the thing dtroyer / dhellman hint towards) is kind of already in our DNA.20:22
mugsieI think that there should be a way of a random dev knoing that this change should work20:23
dhellmannmugsie : inclusion requirements would still be up to each team, imo20:23
ttxqueue has fungi, Rocky_g20:23
dhellmannsdague, the resolution in https://review.openstack.org/#/c/403826/1/resolutions/20161128-driver-teams.rst ends with a statement encouraging drivers to stay in projects20:24
mugsiefrom my perspective, if I have to make a change to the driver interface, I would like to be able to send a patch to the repo, and see if it breaks20:24
*** askb has quit IRC20:24
ttxmugsie: I think we could formalize that whatever the chosen option is20:24
ttxfungi: you're up20:24
fungii should have probably clarified that my biggest concern with grey is that we're effectively developing what could be seen as a registry of drivers, and it turns into a means of indicating that your driver is approved by the openstack technical committee (rather than just a place to recognize teams working on something we can't count as being on the same level as other projects in the tent)20:24
fungimugsie's comments reinforce that concern for me20:24
dhellmann++20:24
*** sshnaidm has joined #openstack-meeting20:24
dhellmanno/20:25
*** haleyb_ has joined #openstack-meeting20:25
sdaguelike, I wouldn't see Nova dumping hyperv or xenapi while there were still notable users of those. If it turned out all the users of these things we knew about went away (or all the people maintaining it), we might want to put it out of tree. Basically that's what happened with the docker driver.20:25
ttxI don't really see how the other options help with that though20:25
fungithird-party testing requirements, code quality, et cetera are things service teams would want to require of drivers to determine how well they're supported, independent of how they're governed20:25
*** rajinir has joined #openstack-meeting20:25
EmilienMfungi: +120:25
Rocky_g++20:25
fungithe other options besides grey don't involve the tc maintaining an approved list of drivers20:25
sdaguefungi: I think you address that with reporting on 3rd party CI status20:26
ttxWell, that's not what grey is -- it's just keeping track of teams20:26
sdaguebut, I think that's true for any approach20:26
fungii think the tc shouldn't have a stake in third-party testing20:26
sdaguefungi: who should have that stake?20:26
fungii think with the less-is-more governance approach, that's something that ought to be up to the individual service teams20:26
jrollo/ quick question20:26
ttxRocky_g: you're up, then dhellmann, jroll20:27
Rocky_gK.  Firs, I want to say this mode of discussion is great and I encourage its use whenever there are invitees to discuss topics.  I can easily follow it.20:28
mordred++20:28
Rocky_gSecond.  Just want to remind everyone of Poppy and say that you may want to consider how it might become part of the big tent based on the outcome of this dicision20:28
Rocky_gDone20:28
ttx(fungi: I'm interested in ways we could tweak grey to reduce that potential side-effect)20:29
ttxdhellmann: you're up20:29
dhellmannWhatever solution we pick, I think we’ll also need to address the driver support documentation question.20:29
dhellmannI know there’s a site managed by the foundation, but I’m not sure project teams have the input into that data to make them comfortable enough with these “official” drivers living out of tree.20:29
dhellmannBecause although we’re talking about a governance change and teams, it’s clear to me from the discussions I’ve had with other folks that they don’t always make the distinction between code and teams, so a list of “driver teams” is going to look a lot like a list of “supported drivers” to some.20:29
dhellmannover20:29
mordred++20:29
*** haleyb_ has quit IRC20:30
Rocky_go/20:30
dtroyerWe've fallen short of these special driver teams are indistinguishable from in-tree drivers20:30
ttxI think that's unescapable though... you can bury the information in a larger yaml, won't make it less official20:30
ttxjroll: you're up20:30
dhellmannright, I'm suggesting that we need to actually document the level of support for all drivers20:30
jrollthanks20:30
jrollwith the red option, does that allow any choice at all for the project teams? e.g. a driver that works but the project team fundamentally disagrees with (not-so-real example: a network switch provisioning driver for ironic, if ironic decides it doesn't want to provision switches). or allowing the project team to have requirements like third party CI to accept the driver repo into the project.20:31
Rocky_g++ dhellmann20:31
ttxdhellmann: agree that the driver marketplace or whatever the name is needs to be revved up20:31
sdaguejroll: I think those conflicts are going to be frequent, which is why most people voicing opinions here have put the red option as not viable20:32
jrollor is it a hard "project teams must allow any driver"20:32
jrolleven sillier example, a coffeepot driver for ironic (this exists!)20:32
ttxjroll: it's called red for a reason. Lots of blood20:32
* ttx lags a bit, so lets switch to normal open discussion20:32
fungithe red option was a bit more of a straw-man than the others, i think. if it were a serious contender it would almost certainly need a lot more detail20:32
jrollokay, cool, I may have missed some things, thanks20:33
Rocky_gSo, ttx calling it "driver marketplace" gets to my next comment.   Make it a driver store so customers can rate them and leave comments20:33
ttxIt feels like grey is promising but the devil is in the details. The one person that ranked it very low was fungi20:33
mtreinishjroll: I want to use that driver :)20:33
dhellmannjroll : teams could have rules like third-party ci20:33
dhellmannit would be weird for someone to write a switch driver that met ironic's API, but if that came up I think you could say it doesn't follow the mission of the team so it's out of scope20:33
dhellmannjroll : does that answer your questions?20:33
fungii still feel like grey is a lot of bureaucracy and red tape for something we could accomplish in other ways20:33
sdagueRocky_g: I feel like customers rating things only works at statistically high volume of ratings20:33
smcginnisjroll: https://www.ietf.org/rfc/rfc2324.txt20:33
jrolldhellmann: yes, it does, thanks20:33
ttxfungi: we could talk it through. I fear that not red-taping it would add a lot of confusion20:34
ttxincluding tainting our principles in a bad light20:34
fungialso, some of these aren't entirely mutually exclusive20:34
flaper87so, I assume normal voting will happen over reviews, right ?20:35
flaper87sdague: ++20:35
ttxBasically I think people will have a hard time considering open collaboration to be an important tenet if they can't spot one team from another20:35
fungihard black was meant to represent the status quo assumption that no driver could ever be independently developed and still meet our community's standards20:35
*** spzala has quit IRC20:35
fungisoft black addresses teh question of what happens if a driver is developed by a normal (to us) team outside the vendor who makes that product (it happens in lots of other communities)20:35
ttxsoft black to me is the status quo20:36
ttx(the way I interpret the current rules)20:36
EmilienMflaper87: I hope so :)20:36
ttxlike dhellmann said, if we just keep the same those driver teams would get rejected today20:36
fungifair enough, it was my interpretation as well, but the grey option seems to assume that you can't write a driver as a "normal" project team without also developing other things20:37
dhellmannttx: that's interesting, I saw the status quo as hard black unless the driver is for an open source project of some sort, and those aren't having any trouble staying in-tree20:37
*** doonhammer has quit IRC20:37
sdaguefungi: in what way?20:37
fungii personally don't want to lose the possibility to encourage drivers to be developed openly and independent of their vendors, and for vendors to release good specs for their hardware to make that possible20:37
sdaguedhellmann: maybe with neutron, but not with other projects20:37
ttxdhellmann: why ? we always said that if a driver team somehow magically provided the same resources to every contributor, it would be a level playing field20:38
flaper87I want to welcome drivers so, I really hope the voting will be done around how we can achieve this20:38
dhellmannttx: right, but that isn't a realistic situation, which is why we're effectively hard-black now20:38
dhellmannsdague : yes, true20:38
fungii also feel like if we make concessions to driver teams, we reduce the incentive for them to become more open and just accept that it will never happen20:38
flaper87dhellmann: ++20:38
sdaguegrey feels like a way we can give drivers space here in the community, but still distinguish that they are different20:38
*** ijw_ has joined #openstack-meeting20:39
*** ijw_ has quit IRC20:39
*** ijw_ has joined #openstack-meeting20:39
*** gouthamr has quit IRC20:39
fungigrey feels like defining a second community which is almost like ours but in a twilight-zone parallel dimension20:39
dhellmanngrey still blocks a project like poppy, right?20:39
sdaguefungi: maybe, but we also need to figure out what other efficiencies and costs are we going to trade for building that incentive structure for driver teams20:39
ttxyeah, I feel like anything less would create a lot of confusion. Like "why are you rejecting my project ? That team over there is doing this and that"20:39
dtroyerI don't think the poppy conclusion changes with this discussion20:39
ttxdhellmann: no20:40
ttxpoppy actually is OK with hard black :)20:40
ttxsince it does not benefit a single party20:40
*** prateek has quit IRC20:40
dhellmannyes, well, that was my position when we voted, too. I'm trying to understand if any of these options allow poppy to join.20:40
ttxI'd say all of them. But that's a separate discussion20:41
ttxSo... next actions20:41
dhellmannin the minds of those who voted against it20:41
ttxshould we just vote on the proposal, or take some of them through an iterative improvement process ?20:41
*** Sukhdev has quit IRC20:41
dhellmannare there any others than the red option we can eliminate from further discussion?20:41
dtroyerI think we should identify the two or three realistic ones and work on them20:41
flaper87can we just abandon the ones didn't get a vote?20:41
* dims just barely made it home20:41
*** saisrikiran has joined #openstack-meeting20:41
EmilienM+1 for iterative improvement process20:42
ttxI consider grey promising, but would not consider it perfect or final20:42
sdaguettx: ++20:42
*** kaisers_ has joined #openstack-meeting20:42
dhellmanndims : did you want to say anything about the driver team stuff before we start dropping options and moving to next steps?20:42
sdagueit just seems like the starting point of what reality is20:42
ttxthere might be ways to improve it that would reduce fungi's concerns about it20:42
flaper87ttx: we have some votings/preferences. Let's get those and abandon the rest20:42
flaper87I think grey is promising and I think we could improve it20:42
ttxOK, I'll go through them and propose an outcome based on that discussion20:42
*** kashyap has joined #openstack-meeting20:42
dimsdhellmann : gotta read scroll back, but will respond on the reviews (grey(20:42
flaper87++20:42
flaper87thanks, ttx20:42
dhellmannI will happily yield ownership of the grey patch to someone who wants to work on updates20:42
stevemarmakes sense to remove the ones that didn't get any positive feedback20:43
ttxstevemar: yes20:43
EmilienMstevemar: +120:43
ttxand then see if we can improve any of the ones we seem to be able to "live with"20:43
*** kashyap has quit IRC20:43
*** nk2527 has quit IRC20:43
ttxLet's move on to next topic ?20:43
flaper87I'd be happy to help wih grey but I'm working on the languages ref doc so I'll let that to someone else20:43
dhellmanns/with/by/20:43
*** kashyap has joined #openstack-meeting20:43
ttxlive by, that's the one20:43
*** zengchen has quit IRC20:43
ttxI confuse them20:43
flaper87ttx: you and me both20:43
dhellmannmaybe someone slightly less invested wants to moderate the updates?20:44
dhellmannstevemar?20:44
*** VW has quit IRC20:44
*** zengchen has joined #openstack-meeting20:44
*** saisriki__ has quit IRC20:44
stevemardhellmann: happy to20:44
dhellmanncool, thanks20:44
flaper87dhellmann: stevemar ++20:44
fungii've been trying to think of ways to mitigate my concern with grey... but it's similar to why the vmt doesn't publish the list of vendors who subscribe for advance notifications. as soon as the openstack community opens another place for companies to list their names, they'll flock to it in droves20:44
stevemarkeystone has no stake here20:44
ttxstevemar: cool, if you lack rights to abandon, just let me know20:44
stevemarttx: ack20:45
ttx#action stevemar to summarize outcomes for each proposal and propose abandons20:45
ttx#topic Amend reference/PTI with supported distros20:45
*** openstack changes topic to "Amend reference/PTI with supported distros (Meeting topic: tc)"20:45
ttx#link https://review.openstack.org/40294020:45
ttxEmilienM: want to introduce that one ?20:45
EmilienMmaybe :)20:45
mtreinishfungi: yeah, that's kinda what I was wondering. What does the community (and the project teams) get out of this?20:45
mtreinishs/project/driver20:45
EmilienMso I want to be quick, I noticed some projects don't gate functional tests on centos720:45
dimsmtreinish : access to vertical teams (docs, translation)20:46
ttx(fungi: we can still have pretty high requirements, like 3rd party testing)20:46
EmilienMand it might seem important to us to consider is, as some of our users are deploying on this platform20:46
EmilienMI found useful to share this feedback and propose this change20:46
dhellmannEmilienM : is the issue mainly that there are differences in dependencies on those platforms? or other configuration issues?20:46
EmilienMdhellmann: dependencies20:47
mtreinishdhellmann: well centos devstack is often broken because of config differences too20:47
*** fguillot has quit IRC20:47
mtreinishand no one ever looks at it20:47
mordredI think that's my biggest concern20:47
mtreinishwhich I think is the actual issue on that20:47
ttxthe way it's phrased, it's just encouraging tests to use more of CentOs, right ?20:47
mordreddevstack centos is frequently broken20:47
EmilienMplease keep in mind my idea was not about blocking any feature because this feature wouldn't work on centos720:47
sdagueright, it's pretty much only ianw keeping that working20:47
flaper87mtreinish: yeah, I was going to say that it's probably mainly dependencies but there's also something about configs20:47
fungithere are projects interested in gating on dependencies too new to be present in lts releases of either ubuntu or centos20:47
mordredand until thats' more solid, having other things depending on it seems scary20:47
sdaguemordred: ++20:47
mordredotoh ...20:47
mordredif more projects depended on it - it would potentially get more people caring20:48
fungiit's one thing if they want to develop features that can _never_ work on a platform we intend to support20:48
dhellmannthis is all phrased as encouraging teams to do it voluntarily, right?20:48
dhellmannEmilienM : ^^20:48
mordreddoes devstack gate itself on centos?20:48
EmilienMdhellmann: exactly20:48
dimsyes, it is dhellmann20:48
mtreinishmordred: it's nv (or experimental) because it doesn't work20:48
mtreinishI think20:48
* mtreinish checks20:48
sdaguefrom a pragmatic perspective I'd like to get more centos fans contributing in the QA / infra space first to keep things working. It feels like that's a foundation we are missing before telling teams to do more of it20:48
flaper87I think the first step is to encourage folks to voluntarily depend on it and then improve support20:49
*** matrohon has joined #openstack-meeting20:49
mordredsdague: ++20:49
clarkbmtreinish: correct20:49
funginv last a looked, and seemed to be passing regularly recently20:49
clarkbdevstack too20:49
EmilienMand I know people here like devstack but I've been also working on making tripleo jobs usable outside TripleO projects (eg: you can run them in Ceilometer's gate, and it uses Centos7)20:49
flaper87but I'm not too much into infra20:49
mtreinishclarkb wins :)20:49
ttxsdague: yeah, if the support is shaky right now maybe adding more tests on that platform is a recipe for more fail20:49
mordredyah - I think we need to encourage that to be in good shape as a baseline - otherwise we're recommending something to project teams that will not work20:49
EmilienMthe jobs take less than 50 minutes and have pretty good coverage and are maintained by tripleo foks... not sure you like the idea20:49
dhellmanndo we have some sort of objective measure we could use to say "when X is done then we can approve this"?20:50
flaper87a.k.a I think this is a good first step20:50
jeblairas a reminder, here is the existing distro support policy: http://lists.openstack.org/pipermail/openstack-dev/2012-December/004052.html20:50
EmilienManyway, beside the tools, the idea was really about documenting our official platforms we like to support in our tests20:50
mordreddhellmann: for me I think it would be that devstack itself has a gating job running on centos20:50
sdagueEmilienM: I think thrusting not only a second OS, but a second install & dev model on development teams is really burdensome20:50
JayFIf this is desirable, I wonder if it'd be a good target for a cross-project Pike goal, in the vein of the oslo-incubator stuff from Ocata.20:50
mordredwhich I think would be a good thing to exist ... but is under-resourced20:50
JayFRather than simply being a policy change.20:50
ttxjeblair: nice history dive20:50
dhellmannmordred : will the QA team accept that job, if there's someone working on it? it seems like it would be easier to keep support if they put the job in place.20:51
clarkbas the person currently trying to force all of openstack to use xenial (eg update from trusty) even getting projects to do that is almost impossible20:51
sdaguemordred: it breaks a bit too often for that to be the case right now20:51
fungigate-tempest-dsvm-platform-centos7-nv ran successfully against https://review.openstack.org/404476 in <50 minutes20:51
clarkbso as a reality check I don't think the proposed change is going to help anything project side20:51
sdaguedhellmann: centos breaks for quite odd reasons20:51
EmilienMsdague: i don't disagree20:51
jeblairactually, i think the thing voted on is: https://etherpad.openstack.org/p/python-support-motion20:51
jeblairhttp://eavesdrop.openstack.org/meetings/tc/2013/tc.2013-01-08-20.02.html20:51
dhellmannsdague : not related to changes in devstack itself?20:51
mordredsdague: yes - I agree - mostly saying that if that is the goal then people can talk about resourcing it20:51
mordredjeblair, ttx: we should maybe get that into the governance repo?20:51
mtreinishfungi: but it's not running exactl the same thing, like ssl is disabled there20:51
sdaguedhellmann: nope. A bunch of things take more kernel memory on centos that cause issues20:51
sdaguethere have been a number of odd bugs20:52
clarkbya wecan't ssl on centos because apache doesn't work20:52
ttxok, so it sounds like it's a bit early for even suggesting ?20:52
fungimtreinish: exciting, so there's stuff we've disabled to get it to run on centos?20:52
mtreinishyep20:52
ttxmordred: propose and you should get it20:52
stevemarclarkb: that seems rather limiting20:52
sdagueplus, the cadence is so much slower that we get drive away from the tooling that people want to be using20:52
dhellmannsdague : ok. we're going to have a hard time coming up with resources to address it if there's not a general sense that the devstack team would welcome it.20:52
mordredttx: k. I guess I just walked in to that20:52
ttxkind of20:52
clarkbstevemar: I am sure it can be made to work but no one is doing the work20:52
ttxI would blame jeblair for pushing you into it20:52
sdaguedhellmann: if there were more people on top of it so that the existing team didn't have to drop everything to go figure it out, it would help20:53
jeblairplonk20:53
fungipresumably we then need a reasonably similar configuration and to have it running the same tempest tests as we currently run against ubuntu 16.0420:53
dims++ sdague20:53
dhellmannsdague : yeah, so we need both "sides" to agree it's a reasonable goal :-)20:53
dims++ dhellmann :)20:53
sdagueright now it's mostly ianw, and he's in .au tz. It's too much to ask him to own it all 24 hours a day20:53
dhellmannof course20:53
*** VW has joined #openstack-meeting20:53
dhellmannI'm thinking RH ought to be involved20:54
mtreinishsdague: I have faith in ianw :)20:54
ttxOK, so it sounds like it's a bit early to even suggest this20:54
EmilienMdo you folks have #action ? we're seeing lot of things now20:54
flaper87mtreinish: lol20:54
sdagueianw is great, don't get me wrong20:54
fungiianw is amazing, but yes he should have some more support from his colleagues at rh it sounds like20:54
ttxwhat is the next step ?20:54
EmilienMdhellmann: yes, we have the resources I think20:54
dhellmannEmilienM : you and I should see if we can get some resources working on better centos support for devstack20:54
sdagueit's just that we've got the rest of the core team, plus 20 - 40 other random community members that will show up to fix devstack on ubuntu20:54
flaper87I think getting some action items that would help moving this forward would be great20:54
ttx#info dhellmann and EmilienM  should see if we can get some resources working on better centos support for devstack20:54
EmilienMdhellmann: I volunteer to work on this thing, even if I'm not a devstack fan20:54
dhellmannthen we can try for a voting gate job, and then we can see about getting this change added20:54
*** david-lyle has quit IRC20:55
sdagueand an order of magnitude less on the centos side20:55
EmilienMttx: thx20:55
ttx#info because it's a blocker to larger use of CentOS in test jobs20:55
jrollis the goal to duplicate all devstack jobs to run on both ubuntu and centos? is infra cool with doubling that?20:55
ttxOK, let's move on quickly to next topic20:55
jroll(I assume so but throwing it out there)20:55
mtreinishjroll: nah, I think it's just to have a token centos job20:55
fungijroll: probably not entirely duplicate, no20:55
ttxjroll: I think you would matrix them, some tests on CenTOS, some on Ubuntu20:55
jrollokay cool20:56
mordredI don't think we need to double across the board - just make it possible for _some_ things to opt in to centos stuff if they desire20:56
ttx#topic Do not allow data plane downtime during upgrades20:56
mordredother people are more succinct :)20:56
*** openstack changes topic to "Do not allow data plane downtime during upgrades (Meeting topic: tc)"20:56
ttx#link https://review.openstack.org/40436120:56
ttxWe don't have much time to discuss it20:56
ttxprobably better to put it on next week agenda20:56
stevemardolphm: around?20:56
*** xyang1 has joined #openstack-meeting20:56
dolphmstevemar: yes20:57
stevemarttx: probably for the best20:57
ttxI think we can discuss on the review until then20:57
dolphmi'm good for next week with 2 minutes left on the clock ;)20:57
mordredI agree with dhellmann's comment in the review20:57
stevemardolphm: thanks :)20:57
*** gordc has left #openstack-meeting20:57
ttx#topic Open discussion20:57
*** openstack changes topic to "Open discussion (Meeting topic: tc)"20:57
mordredas much as I'm sure we all want to bikeshed over words - 'data plane' is sufficiently vague that I don't expect everyone to agree what it means20:58
*** piet has quit IRC20:58
ttxIf you have a strong opinion on where to allow meetings to happen (more meeting rooms or opening up project rooms to meetings) please comment on the thread20:58
mordredI know what _I_ would expect from it - but I also expect directly routable IPv4 to VMs as a default and other people don't - so we should be clear20:58
dhellmannI also suspect that given a bunch of existing projects with this tag, a new tag will be easier to implement that a major change in the rules20:58
mordreddhellmann: yah20:58
dimsfyi, i spent the morning talking to folks at massachusetts open cloud (they use openstack a lot) https://info.massopencloud.org/blog/2016-moc-fall-workshop/20:58
*** Patifa has quit IRC20:58
*** bobh has joined #openstack-meeting20:59
dhellmanndims : nice, thanks for the link20:59
fungimass o' cloud ;)20:59
dolphmdhellmann: that's a good point20:59
*** VW has quit IRC20:59
sdaguedhellmann: honestly, it was kind of implied in the current tag20:59
ttxIRC meetings thread: http://lists.openstack.org/pipermail/openstack-dev/2016-December/108360.html20:59
sdagueand the automated testing that you have to run to get that tag20:59
dims:)20:59
dhellmanndolphm : someone else did make it in the review, so I don't get credit :-)20:59
*** zara_the_lemur__ has left #openstack-meeting20:59
sdaguewe can define data plane, if that's an issue for folks20:59
dtroyerno tag upgrades?21:00
*** Patifa has joined #openstack-meeting21:00
ttxAt the board meeting today they mentioned they might want to do a joint TC/Board meeting around the PTG21:00
ttxThough it's not really an official proposal yet21:00
*** askb has joined #openstack-meeting21:00
ttxbut fair warning21:00
fungiin the same vicinity as the ptg?21:00
flaper87good to know21:00
mordredttx: it would likely be good to communicate that most of the TC is likely to be booked all 5 weekdays21:00
flaper87someone asked me tha recently21:00
flaper87mordred: ++21:01
mordredsince most of the TC is fairly strongly involved in both vertical and horizontal efforts21:01
jeblairyeah, could we please not double book the tc?21:01
mordredand the PTG has been planned for a while21:01
dimsthanks for the heads up ttx, will have to book flights accordingly21:01
ttxWe migth have some time on the Friday21:01
mordredlike, as a TC member, I will not attend that if it's during the week21:01
ttxanyway, more on that when they actually talk to me about it21:01
jeblairor, i guess, if it does happen, maybe i'll just go home a day early or whatever21:01
*** VW has joined #openstack-meeting21:01
ttxand we are offtime21:01
ttxthanks everyone21:01
flaper87o/21:01
ttx#endmeeting21:01
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"21:01
openstackMeeting ended Tue Dec  6 21:01:57 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)21:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-12-06-20.02.html21:02
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-12-06-20.02.txt21:02
EmilienMttx: thx for chairing as usual :)21:02
openstackLog:            http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-12-06-20.02.log.html21:02
ttxsorry for lateness21:02
*** cdent has left #openstack-meeting21:02
*** bobh has quit IRC21:03
*** ociuhandu has quit IRC21:07
*** csomerville has joined #openstack-meeting21:09
*** doonhammer has joined #openstack-meeting21:10
*** cody-somerville has quit IRC21:12
*** rbowen has quit IRC21:13
*** Douhet has quit IRC21:13
*** Douhet has joined #openstack-meeting21:14
*** cdelatte has quit IRC21:18
*** aeng has joined #openstack-meeting21:21
*** haleyb_ has joined #openstack-meeting21:25
*** spzala has joined #openstack-meeting21:26
*** rasca has joined #openstack-meeting21:29
*** haleyb_ has quit IRC21:30
*** Patifa has quit IRC21:31
*** Patifa has joined #openstack-meeting21:34
*** tonytan4ever has quit IRC21:37
*** jgregor has quit IRC21:37
*** jtomasek has quit IRC21:39
*** kbyrne has quit IRC21:41
*** annakoppad_ has left #openstack-meeting21:41
*** rbowen has joined #openstack-meeting21:43
*** VW has quit IRC21:43
*** caboucha has quit IRC21:44
*** VW has joined #openstack-meeting21:46
*** rbowen has quit IRC21:46
*** rbowen has joined #openstack-meeting21:46
*** kbyrne has joined #openstack-meeting21:47
*** zengchen has quit IRC21:50
*** zengchen has joined #openstack-meeting21:50
*** alexpilo_ has joined #openstack-meeting21:51
*** rtheis has quit IRC21:53
*** whenry has quit IRC21:53
*** alexpilotti has quit IRC21:54
*** dtrainor has quit IRC21:55
*** mickeys has quit IRC21:58
*** dtrainor has joined #openstack-meeting21:59
*** Patifa has quit IRC21:59
*** matrohon has quit IRC22:02
*** Patifa has joined #openstack-meeting22:03
*** tinwood has quit IRC22:05
*** tinwood has joined #openstack-meeting22:06
*** rasca has quit IRC22:06
*** whenry has joined #openstack-meeting22:06
*** krtaylor has quit IRC22:07
*** emagana_ has quit IRC22:07
*** thorst has quit IRC22:09
*** lblanchard has quit IRC22:09
*** thorst has joined #openstack-meeting22:09
*** cdub has joined #openstack-meeting22:12
*** Sukhdev has joined #openstack-meeting22:15
*** thorst has quit IRC22:18
*** cdub has quit IRC22:18
*** whenry has quit IRC22:18
*** mickeys has joined #openstack-meeting22:19
*** david-lyle has joined #openstack-meeting22:24
*** myoung is now known as myoung|afk22:25
*** myoung|afk is now known as myoung|bbl22:25
*** VW_ has joined #openstack-meeting22:28
*** emagana has joined #openstack-meeting22:29
*** Patifa has quit IRC22:30
*** lpetrut has joined #openstack-meeting22:30
*** eharney has quit IRC22:31
*** noslzzp_ has joined #openstack-meeting22:31
*** noslzzp has quit IRC22:32
*** ianychoi has joined #openstack-meeting22:32
*** VW has quit IRC22:32
*** VW_ has quit IRC22:32
*** Patifa has joined #openstack-meeting22:33
*** emagana has quit IRC22:33
*** darvon has joined #openstack-meeting22:35
*** ijw_ has quit IRC22:37
*** ijw has joined #openstack-meeting22:37
*** emagana has joined #openstack-meeting22:38
*** thorst_ has joined #openstack-meeting22:38
*** thorst_ has quit IRC22:38
*** enriquetaso has joined #openstack-meeting22:39
*** saisrikiran has quit IRC22:40
*** david-lyle has quit IRC22:41
*** david-lyle has joined #openstack-meeting22:41
*** ijw has quit IRC22:42
*** harlowja has quit IRC22:43
*** mriedem has quit IRC22:43
*** harlowja has joined #openstack-meeting22:43
*** priteau has quit IRC22:45
*** david-lyle has quit IRC22:46
*** designbybeck has quit IRC22:46
*** emagana has quit IRC22:52
*** emagana has joined #openstack-meeting22:53
*** aeng has quit IRC22:56
*** emagana has quit IRC22:57
*** Swami has quit IRC22:57
*** VW has joined #openstack-meeting22:59
*** ijw has joined #openstack-meeting23:01
*** VW has quit IRC23:02
*** VW has joined #openstack-meeting23:02
*** rbudden has quit IRC23:02
*** jamesdenton has quit IRC23:02
*** rcernin has quit IRC23:02
*** cbits has quit IRC23:11
*** sdague has quit IRC23:11
*** xyang1 has quit IRC23:13
*** jtomasek has joined #openstack-meeting23:14
*** wcriswell has left #openstack-meeting23:16
*** jtomasek has quit IRC23:18
*** jklare has quit IRC23:27
*** haleyb_ has joined #openstack-meeting23:27
*** VW has quit IRC23:28
*** krtaylor has joined #openstack-meeting23:30
*** Patifa has quit IRC23:30
*** jklare has joined #openstack-meeting23:30
*** galstrom is now known as galstrom_zzz23:31
*** haleyb_ has quit IRC23:32
*** thorst_ has joined #openstack-meeting23:39
*** agrebennikov has quit IRC23:42
*** absubram has quit IRC23:42
*** lpetrut has quit IRC23:42
*** rbak has quit IRC23:45
*** rbak has joined #openstack-meeting23:45
*** rbak has quit IRC23:46
*** thorst_ has quit IRC23:48
*** jaugustine has quit IRC23:49
*** Patifa has joined #openstack-meeting23:50
*** sdake_ has quit IRC23:51
*** lhx_ has joined #openstack-meeting23:53
*** aeng has joined #openstack-meeting23:54

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!