| *** pcm_ has quit IRC | 00:00 | |
| *** vipul-away is now known as vipul | 00:00 | |
| *** denis_makogon has quit IRC | 00:07 | |
| *** eankutse has quit IRC | 00:08 | |
| *** banix has quit IRC | 00:13 | |
| *** sacharya has joined #openstack-meeting-alt | 00:17 | |
| *** brents has quit IRC | 00:22 | |
| *** alazarev has quit IRC | 00:28 | |
| *** alazarev has joined #openstack-meeting-alt | 00:29 | |
| *** brents has joined #openstack-meeting-alt | 00:31 | |
| *** vipul is now known as vipul-away | 00:39 | |
| *** yidclare has quit IRC | 00:42 | |
| *** NehaV has quit IRC | 00:44 | |
| *** yamahata_ has joined #openstack-meeting-alt | 00:45 | |
| *** yogesh has joined #openstack-meeting-alt | 00:52 | |
| *** brents has quit IRC | 00:57 | |
| *** yamahata_ has quit IRC | 00:59 | |
| *** yamahata_ has joined #openstack-meeting-alt | 01:00 | |
| *** RajeshMohan has quit IRC | 01:00 | |
| *** RajeshMohan has joined #openstack-meeting-alt | 01:01 | |
| *** banix has joined #openstack-meeting-alt | 01:03 | |
| *** brents has joined #openstack-meeting-alt | 01:05 | |
| *** jasonb365 has joined #openstack-meeting-alt | 01:07 | |
| *** vipul-away is now known as vipul | 01:10 | |
| *** jcooley_ has quit IRC | 01:12 | |
| *** jergerber has quit IRC | 01:13 | |
| *** alazarev has quit IRC | 01:16 | |
| *** Barker has joined #openstack-meeting-alt | 01:18 | |
| *** IlyaE has quit IRC | 01:20 | |
| *** jasonb365 has quit IRC | 01:20 | |
| *** IlyaE has joined #openstack-meeting-alt | 01:27 | |
| *** devkulkarni has quit IRC | 01:27 | |
| *** mozawa has joined #openstack-meeting-alt | 01:30 | |
| *** IlyaE has quit IRC | 01:30 | |
| *** stevebaker has left #openstack-meeting-alt | 01:32 | |
| *** jcooley_ has joined #openstack-meeting-alt | 01:33 | |
| *** yogesh has quit IRC | 01:35 | |
| *** nosnos has joined #openstack-meeting-alt | 01:35 | |
| *** jmontemayor has quit IRC | 01:37 | |
| *** brents has quit IRC | 01:41 | |
| *** Barker has quit IRC | 01:47 | |
| *** rongze has joined #openstack-meeting-alt | 01:52 | |
| *** DennyZhang has joined #openstack-meeting-alt | 01:53 | |
| *** demorris has joined #openstack-meeting-alt | 01:55 | |
| *** demorris has quit IRC | 02:01 | |
| *** eankutse has joined #openstack-meeting-alt | 02:07 | |
| *** amcrn has quit IRC | 02:17 | |
| *** amytron has joined #openstack-meeting-alt | 02:20 | |
| *** eankutse has quit IRC | 02:21 | |
| *** jcooley_ has quit IRC | 02:24 | |
| *** eankutse has joined #openstack-meeting-alt | 02:24 | |
| *** jjmb has joined #openstack-meeting-alt | 02:27 | |
| *** rongze has quit IRC | 02:28 | |
| *** rongze has joined #openstack-meeting-alt | 02:29 | |
| *** eankutse has quit IRC | 02:37 | |
| *** vkmc has quit IRC | 02:47 | |
| *** julim has quit IRC | 02:57 | |
| *** brents has joined #openstack-meeting-alt | 03:02 | |
| *** amytron has quit IRC | 03:05 | |
| *** SushilKM has joined #openstack-meeting-alt | 03:06 | |
| *** diakunchikov__ has quit IRC | 03:12 | |
| *** ikhudoshyn has quit IRC | 03:12 | |
| *** yportnova has quit IRC | 03:12 | |
| *** ikhudoshyn has joined #openstack-meeting-alt | 03:12 | |
| *** yportnova has joined #openstack-meeting-alt | 03:12 | |
| *** diakunchikov__ has joined #openstack-meeting-alt | 03:13 | |
| *** esker has joined #openstack-meeting-alt | 03:13 | |
| *** esker has quit IRC | 03:14 | |
| *** eankutse has joined #openstack-meeting-alt | 03:19 | |
| *** jcooley_ has joined #openstack-meeting-alt | 03:20 | |
| *** jcooley_ has quit IRC | 03:26 | |
| *** devkulkarni has joined #openstack-meeting-alt | 03:28 | |
| *** rongze_ has joined #openstack-meeting-alt | 03:33 | |
| *** rongze has quit IRC | 03:36 | |
| *** DennyZhang has quit IRC | 03:37 | |
| *** yogesh has joined #openstack-meeting-alt | 03:45 | |
| *** eankutse has quit IRC | 03:49 | |
| *** brents has quit IRC | 03:52 | |
| *** yogesh has quit IRC | 03:59 | |
| *** sarob has joined #openstack-meeting-alt | 04:03 | |
| *** sarob has quit IRC | 04:05 | |
| *** yogesh has joined #openstack-meeting-alt | 04:06 | |
| *** sarob has joined #openstack-meeting-alt | 04:06 | |
| *** sarob has quit IRC | 04:06 | |
| *** yogesh has quit IRC | 04:07 | |
| *** amytron has joined #openstack-meeting-alt | 04:07 | |
| *** yogesh has joined #openstack-meeting-alt | 04:08 | |
| *** yogesh has quit IRC | 04:11 | |
| *** yogesh has joined #openstack-meeting-alt | 04:13 | |
| *** yogesh has quit IRC | 04:14 | |
| *** SushilKM has quit IRC | 04:17 | |
| *** yogesh has joined #openstack-meeting-alt | 04:18 | |
| *** NehaV has joined #openstack-meeting-alt | 04:19 | |
| *** NehaV has quit IRC | 04:19 | |
| *** yogesh has quit IRC | 04:20 | |
| *** yogesh has joined #openstack-meeting-alt | 04:21 | |
| *** yogesh has quit IRC | 04:21 | |
| *** sarob has joined #openstack-meeting-alt | 04:24 | |
| *** jergerber has joined #openstack-meeting-alt | 04:24 | |
| *** radix_ has quit IRC | 04:25 | |
| *** banix has quit IRC | 04:27 | |
| *** sarob has quit IRC | 04:28 | |
| *** yogesh has joined #openstack-meeting-alt | 04:28 | |
| *** yogesh has quit IRC | 04:30 | |
| *** yogesh_ has joined #openstack-meeting-alt | 04:32 | |
| *** yogesh_ has quit IRC | 04:33 | |
| *** devkulkarni has quit IRC | 04:36 | |
| *** jergerber has quit IRC | 04:39 | |
| *** yogesh has joined #openstack-meeting-alt | 04:44 | |
| *** mitsos has joined #openstack-meeting-alt | 04:44 | |
| *** yogesh has quit IRC | 04:44 | |
| *** yogesh has joined #openstack-meeting-alt | 04:47 | |
| *** yogesh has quit IRC | 04:48 | |
| *** mitsos has quit IRC | 04:49 | |
| *** rongze_ has quit IRC | 04:52 | |
| *** eankutse has joined #openstack-meeting-alt | 04:53 | |
| *** NehaV has joined #openstack-meeting-alt | 04:55 | |
| *** sarob has joined #openstack-meeting-alt | 04:57 | |
| *** nati_ueno has quit IRC | 05:03 | |
| *** sarob has quit IRC | 05:10 | |
| *** sarob has joined #openstack-meeting-alt | 05:10 | |
| *** sarob has quit IRC | 05:11 | |
| *** eankutse has quit IRC | 05:16 | |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 05:17 | |
| *** NehaV has quit IRC | 05:22 | |
| *** rongze has joined #openstack-meeting-alt | 05:22 | |
| *** sarob has joined #openstack-meeting-alt | 05:23 | |
| *** sarob has quit IRC | 05:25 | |
| *** sarob has joined #openstack-meeting-alt | 05:26 | |
| *** sarob has quit IRC | 05:26 | |
| *** rongze has quit IRC | 05:27 | |
| *** SergeyLukjanov is now known as _SergeyLukjanov | 05:33 | |
| *** _SergeyLukjanov has quit IRC | 05:33 | |
| *** dougshelley66 has joined #openstack-meeting-alt | 05:33 | |
| *** enikanorov_ has quit IRC | 05:37 | |
| *** enikanorov has joined #openstack-meeting-alt | 05:37 | |
| *** dougshelley66 has quit IRC | 05:44 | |
| *** coolsvap has joined #openstack-meeting-alt | 05:45 | |
| *** alazarev has joined #openstack-meeting-alt | 05:46 | |
| *** yogesh has joined #openstack-meeting-alt | 05:49 | |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 05:51 | |
| *** arnaud|afk|flu has joined #openstack-meeting-alt | 05:51 | |
| *** coolsvap has left #openstack-meeting-alt | 05:53 | |
| *** coolsvap has joined #openstack-meeting-alt | 05:53 | |
| *** arnaud|afk|flu has quit IRC | 05:54 | |
| *** yogesh has quit IRC | 05:59 | |
| *** sacharya has quit IRC | 06:00 | |
| *** yogesh_ has joined #openstack-meeting-alt | 06:00 | |
| *** radix_ has joined #openstack-meeting-alt | 06:06 | |
| *** jcooley_ has joined #openstack-meeting-alt | 06:06 | |
| *** yogesh has joined #openstack-meeting-alt | 06:08 | |
| *** yogesh_ has quit IRC | 06:10 | |
| *** yogesh_ has joined #openstack-meeting-alt | 06:12 | |
| *** yogesh has quit IRC | 06:12 | |
| *** markvoelker1 has quit IRC | 06:13 | |
| *** SergeyLukjanov has quit IRC | 06:17 | |
| *** rongze has joined #openstack-meeting-alt | 06:20 | |
| *** vipul has quit IRC | 06:22 | |
| *** vipul has joined #openstack-meeting-alt | 06:22 | |
| *** yogesh_ has quit IRC | 06:28 | |
| *** jcooley_ has quit IRC | 06:30 | |
| *** jcooley_ has joined #openstack-meeting-alt | 06:30 | |
| *** jcooley_ has quit IRC | 06:31 | |
| *** jcooley_ has joined #openstack-meeting-alt | 06:31 | |
| *** amytron has quit IRC | 06:33 | |
| *** SushilKM has joined #openstack-meeting-alt | 06:38 | |
| *** nadya_ has joined #openstack-meeting-alt | 06:43 | |
| *** alazarev has quit IRC | 06:45 | |
| *** yogesh has joined #openstack-meeting-alt | 06:46 | |
| *** lifeless has quit IRC | 06:48 | |
| *** dougshelley66 has joined #openstack-meeting-alt | 06:51 | |
| *** yogesh_ has joined #openstack-meeting-alt | 06:51 | |
| *** yogesh has quit IRC | 06:51 | |
| *** yogesh_ has quit IRC | 06:56 | |
| *** yogesh has joined #openstack-meeting-alt | 06:56 | |
| *** nadya_ has quit IRC | 06:58 | |
| *** yogesh_ has joined #openstack-meeting-alt | 06:58 | |
| *** yogesh has quit IRC | 07:02 | |
| *** yogesh_ has quit IRC | 07:08 | |
| *** alazarev has joined #openstack-meeting-alt | 07:13 | |
| *** lifeless has joined #openstack-meeting-alt | 07:15 | |
| *** jcooley_ has quit IRC | 07:18 | |
| *** jcooley_ has joined #openstack-meeting-alt | 07:22 | |
| *** jcoufal has joined #openstack-meeting-alt | 07:27 | |
| *** NikitaKonovalov has joined #openstack-meeting-alt | 07:27 | |
| *** yogesh has joined #openstack-meeting-alt | 07:32 | |
| *** yogesh has quit IRC | 07:40 | |
| *** boris-42 has quit IRC | 07:43 | |
| *** jcooley_ has quit IRC | 07:46 | |
| *** yogesh has joined #openstack-meeting-alt | 07:46 | |
| *** yogesh has quit IRC | 07:48 | |
| *** yogesh has joined #openstack-meeting-alt | 07:48 | |
| *** jcooley_ has joined #openstack-meeting-alt | 07:50 | |
| *** alazarev has quit IRC | 07:52 | |
| *** nati_ueno has joined #openstack-meeting-alt | 07:52 | |
| *** coolsvap has quit IRC | 07:56 | |
| *** jcooley_ has quit IRC | 07:58 | |
| *** yogesh has quit IRC | 08:02 | |
| *** rongze has quit IRC | 08:02 | |
| *** rongze has joined #openstack-meeting-alt | 08:06 | |
| *** rongze has quit IRC | 08:11 | |
| *** enikanorov_ has joined #openstack-meeting-alt | 08:18 | |
| *** dark_knight_ita has joined #openstack-meeting-alt | 08:18 | |
| *** denis_makogon has joined #openstack-meeting-alt | 08:19 | |
| *** yogesh has joined #openstack-meeting-alt | 08:19 | |
| *** igormarnat has joined #openstack-meeting-alt | 08:37 | |
| *** akuznetsov has joined #openstack-meeting-alt | 09:00 | |
| *** derekh has joined #openstack-meeting-alt | 09:05 | |
| *** SumitNaiksatam has joined #openstack-meeting-alt | 09:12 | |
| *** ekarlso has quit IRC | 09:17 | |
| *** ekarlso has joined #openstack-meeting-alt | 09:17 | |
| *** mozawa has quit IRC | 09:19 | |
| *** aignatov has joined #openstack-meeting-alt | 09:22 | |
| *** SushilKM has quit IRC | 09:37 | |
| *** yogesh has quit IRC | 09:39 | |
| *** flaper87|afk is now known as flaper87 | 09:40 | |
| *** SushilKM has joined #openstack-meeting-alt | 09:43 | |
| *** denis_makogon has quit IRC | 09:44 | |
| *** jtomasek has joined #openstack-meeting-alt | 10:05 | |
| *** nosnos_ has joined #openstack-meeting-alt | 10:15 | |
| *** nosnos_ has quit IRC | 10:16 | |
| *** nosnos_ has joined #openstack-meeting-alt | 10:16 | |
| *** nosnos has quit IRC | 10:17 | |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 10:17 | |
| *** nosnos_ has quit IRC | 10:20 | |
| *** diakunchikov__ has quit IRC | 10:28 | |
| *** dmakogon_ is now known as denis_makogon | 10:33 | |
| *** rongze has joined #openstack-meeting-alt | 10:41 | |
| *** NikitaKonovalov has quit IRC | 10:42 | |
| *** rongze has quit IRC | 10:46 | |
| *** heyongli has joined #openstack-meeting-alt | 10:46 | |
| *** yogesh has joined #openstack-meeting-alt | 10:50 | |
| *** igormarnat has left #openstack-meeting-alt | 10:52 | |
| *** yogesh has quit IRC | 10:55 | |
| *** akuznetsov has quit IRC | 10:55 | |
| *** akuznetsov has joined #openstack-meeting-alt | 10:58 | |
| *** yamahata_ has quit IRC | 10:58 | |
| *** boris-42 has joined #openstack-meeting-alt | 11:17 | |
| *** akuznetsov has quit IRC | 11:19 | |
| *** akuznetsov has joined #openstack-meeting-alt | 11:22 | |
| *** rsblendido has joined #openstack-meeting-alt | 11:34 | |
| *** rossella_s has joined #openstack-meeting-alt | 11:34 | |
| *** vkmc has joined #openstack-meeting-alt | 11:38 | |
| *** slagle has joined #openstack-meeting-alt | 11:49 | |
| *** enikanorov has quit IRC | 12:24 | |
| *** enikanorov has joined #openstack-meeting-alt | 12:24 | |
| *** rongze has joined #openstack-meeting-alt | 12:37 | |
| *** bcrochet has quit IRC | 12:38 | |
| *** rongze has quit IRC | 12:41 | |
| *** bcrochet has joined #openstack-meeting-alt | 12:43 | |
| *** SergeyLukjanov is now known as _SergeyLukjanov | 12:54 | |
| *** _SergeyLukjanov has quit IRC | 12:54 | |
| *** yamahata_ has joined #openstack-meeting-alt | 12:55 | |
| *** yamahata_ has quit IRC | 13:02 | |
| *** yamahata_ has joined #openstack-meeting-alt | 13:04 | |
| *** pdmars has joined #openstack-meeting-alt | 13:05 | |
| *** NikitaKonovalov has joined #openstack-meeting-alt | 13:06 | |
| *** pdmars has quit IRC | 13:07 | |
| *** jcoufal_ has joined #openstack-meeting-alt | 13:08 | |
| *** yamahata_ has quit IRC | 13:09 | |
| *** jcoufal has quit IRC | 13:10 | |
| *** pdmars has joined #openstack-meeting-alt | 13:11 | |
| *** rongze has joined #openstack-meeting-alt | 13:12 | |
| *** dark_knight_ita has quit IRC | 13:21 | |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 13:23 | |
| *** yamahata_ has joined #openstack-meeting-alt | 13:24 | |
| *** yamahata_ has quit IRC | 13:35 | |
| *** lblanchard has joined #openstack-meeting-alt | 13:37 | |
| *** jdob has joined #openstack-meeting-alt | 13:40 | |
| *** kevinconway has joined #openstack-meeting-alt | 13:41 | |
| *** jjmb has quit IRC | 13:42 | |
| *** dougshelley66 has quit IRC | 13:53 | |
| *** abramley has joined #openstack-meeting-alt | 13:53 | |
| *** yamahata_ has joined #openstack-meeting-alt | 13:54 | |
| *** venkatesh has joined #openstack-meeting-alt | 13:56 | |
| *** venkatesh_ has joined #openstack-meeting-alt | 13:56 | |
| venkatesh_ | ? | 13:56 |
|---|---|---|
| venkatesh_ | sorry, pressed some wrong keys. | 13:57 |
| *** yamahata_ has quit IRC | 13:57 | |
| *** yamahata_ has joined #openstack-meeting-alt | 13:57 | |
| *** yamahata_ has quit IRC | 13:58 | |
| *** katyafervent has quit IRC | 13:58 | |
| *** yamahata_ has joined #openstack-meeting-alt | 13:59 | |
| *** dprince has joined #openstack-meeting-alt | 14:01 | |
| *** rongze_ has joined #openstack-meeting-alt | 14:01 | |
| *** pcm_ has joined #openstack-meeting-alt | 14:02 | |
| *** pcm_ has left #openstack-meeting-alt | 14:02 | |
| *** rongze has quit IRC | 14:04 | |
| *** zhiyan has joined #openstack-meeting-alt | 14:06 | |
| *** zhiyan has quit IRC | 14:08 | |
| *** julim has joined #openstack-meeting-alt | 14:09 | |
| *** bugsduggan has joined #openstack-meeting-alt | 14:09 | |
| *** zhiyan has joined #openstack-meeting-alt | 14:09 | |
| *** bugsduggan has left #openstack-meeting-alt | 14:10 | |
| *** dougshelley66 has joined #openstack-meeting-alt | 14:11 | |
| *** yamahata_ has quit IRC | 14:12 | |
| *** yamahata_ has joined #openstack-meeting-alt | 14:13 | |
| *** jprovazn has joined #openstack-meeting-alt | 14:16 | |
| *** eankutse has joined #openstack-meeting-alt | 14:16 | |
| *** eankutse has quit IRC | 14:17 | |
| *** eankutse has joined #openstack-meeting-alt | 14:17 | |
| *** rongze has joined #openstack-meeting-alt | 14:20 | |
| *** rongze_ has quit IRC | 14:24 | |
| *** jdob has quit IRC | 14:34 | |
| *** jdob has joined #openstack-meeting-alt | 14:34 | |
| *** SushilKM has quit IRC | 14:35 | |
| *** banix has joined #openstack-meeting-alt | 14:37 | |
| *** heyongli has quit IRC | 14:40 | |
| *** rongze_ has joined #openstack-meeting-alt | 14:43 | |
| *** rongze has quit IRC | 14:44 | |
| *** sergmelikyan has joined #openstack-meeting-alt | 14:48 | |
| *** vponomaryov has joined #openstack-meeting-alt | 14:49 | |
| *** jergerber has joined #openstack-meeting-alt | 14:51 | |
| *** aostapenko has joined #openstack-meeting-alt | 14:51 | |
| *** demorris has joined #openstack-meeting-alt | 14:53 | |
| *** NehaV has joined #openstack-meeting-alt | 14:54 | |
| *** NehaV has quit IRC | 14:55 | |
| *** NehaV has joined #openstack-meeting-alt | 14:56 | |
| *** jecarey has joined #openstack-meeting-alt | 14:58 | |
| *** jvltc has joined #openstack-meeting-alt | 14:58 | |
| *** rraja_ has joined #openstack-meeting-alt | 14:58 | |
| *** achirko has joined #openstack-meeting-alt | 14:58 | |
| *** zhaoqin__ has joined #openstack-meeting-alt | 14:59 | |
| *** bill_az has joined #openstack-meeting-alt | 14:59 | |
| *** xyang1 has joined #openstack-meeting-alt | 15:00 | |
| *** japplewhite has joined #openstack-meeting-alt | 15:00 | |
| *** bswartz has joined #openstack-meeting-alt | 15:00 | |
| bswartz | #startmeeting manila | 15:01 |
| openstack | Meeting started Thu Dec 12 15:01:08 2013 UTC and is due to finish in 60 minutes. The chair is bswartz. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:01 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:01 |
| *** openstack changes topic to " (Meeting topic: manila)" | 15:01 | |
| openstack | The meeting name has been set to 'manila' | 15:01 |
| *** csaba|afk is now known as csaba | 15:01 | |
| bswartz | hey, is anyone here today? | 15:01 |
| *** gregsfortytwo has joined #openstack-meeting-alt | 15:01 | |
| xyang1 | hi | 15:01 |
| vponomaryov | hi | 15:01 |
| bill_az | Hi | 15:01 |
| zhaoqin__ | hello | 15:01 |
| bswartz | ah, so I'm not alone | 15:01 |
| csaba | hi | 15:01 |
| rraja_ | hi | 15:01 |
| gregsfortytwo | hi | 15:02 |
| bswartz | I don't have a specific agenda for this week -- unfortunately I have another meeting right before this one that tends to leave me with no time to prepare :-( | 15:02 |
| bswartz | I'll work on solving that issue though | 15:02 |
| *** amytron has joined #openstack-meeting-alt | 15:02 | |
| bswartz | I think I want to cover the same issues we did last week because I believe we've made some progress on all of them though | 15:03 |
| aostapenko | hi | 15:03 |
| bswartz | #topic gateway-mediated multitenancy | 15:03 |
| *** openstack changes topic to "gateway-mediated multitenancy (Meeting topic: manila)" | 15:03 | |
| bswartz | so first of all, the wiki document is out of date now, due to the many new ideas that have come up in the last 6 weeks or so | 15:04 |
| *** s3wong has joined #openstack-meeting-alt | 15:04 | |
| bswartz | I plan to update the document but first I'll offer a preview and see if anyone thinks this is crazy | 15:04 |
| *** yportnova_ has joined #openstack-meeting-alt | 15:04 | |
| *** shamail has joined #openstack-meeting-alt | 15:05 | |
| bswartz | My thinking is that the manila-share service itself will only understand 2 types of attach calls: | 15:05 |
| *** jcooley_ has joined #openstack-meeting-alt | 15:05 | |
| *** jtomasek has quit IRC | 15:05 | |
| *** hagarth has joined #openstack-meeting-alt | 15:05 | |
| bswartz | 1) Attach directly to tenant network, including support for VLANs, full network connectivity, with a virualized server, etc | 15:05 |
| *** bvandehey has joined #openstack-meeting-alt | 15:06 | |
| bswartz | and 2) Attach to flat network, just like the existing drivers, where an multitenancy support will be handled externally, either in nova or some kind of manila agent | 15:06 |
| bswartz | All of the gateway-mediated multitenancy support could be build on top of (2) I believe | 15:07 |
| *** Dinny has joined #openstack-meeting-alt | 15:07 | |
| bswartz | and all of the VLAN-based multitenancy could be build using (1) which is pretty close to being ready | 15:07 |
| *** NehaV has quit IRC | 15:07 | |
| *** lsmola has quit IRC | 15:08 | |
| bswartz | I need to draw a picture of how this will work and go through all of the use cases and demonstrate how each will be handled | 15:08 |
| *** NehaV has joined #openstack-meeting-alt | 15:08 | |
| bswartz | I think that this should make backend design for things like ceph/gluster/gpfs relatively easy, and the hard work will be done outside the manila-share service | 15:08 |
| *** Barker has joined #openstack-meeting-alt | 15:09 | |
| bswartz | Does anyone think I'm crazy? | 15:09 |
| bswartz | oh caitlin56 isn't here, she would mention something I'm sure | 15:09 |
| *** lsmola has joined #openstack-meeting-alt | 15:09 | |
| shamail | Gateways etc fall in 1 as well? | 15:10 |
| bswartz | no in (1) there is no gateway -- the backend is responsible for virtualizing the server and connecting directly to a tenant network | 15:10 |
| *** s3wong has quit IRC | 15:10 | |
| *** shusya has joined #openstack-meeting-alt | 15:10 | |
| bswartz | that method provides more functionality, and is preferred for those backends that can support iut | 15:11 |
| bswartz | it* | 15:11 |
| hagarth | bswartz: any thoughts on how to handle multi-tenancy support externally for (2) ? | 15:11 |
| shamail | Thanks | 15:11 |
| bswartz | hagarth: absolutely | 15:11 |
| *** anands has joined #openstack-meeting-alt | 15:11 | |
| bswartz | The approach will be more or less the same as the current wiki, but the new thing I'm proposing is that the manila backend doesn't really need to be aware of most of it | 15:12 |
| *** vbellur has joined #openstack-meeting-alt | 15:12 | |
| bswartz | The main thing I realized is that whether the model is "flat"/single tenant, or multitenant with various forms of gateways, the interaction with the actual storage server is pretty much the same | 15:13 |
| bswartz | in the (2) case, when the attach call comes in, the backend just has to share a directory with a client IP, that's it | 15:13 |
| bswartz | implementing only that will allow us to build everything else in a generic and reusable way, I think | 15:14 |
| bswartz | then for multitenant situations, there needs to be code on the hypervisor (either manila agent or nova extensions) which mounts the share and re-exports it into the tenant using one of many approaches | 15:15 |
| bill_az | bswartz: for 2), I would say "attach to network" - the driver may choose to do different network plumbing depending on req'ts | 15:15 |
| bswartz | In particular I'm looking for the gpfs and gluster people to tell me why this is crazy | 15:15 |
| bswartz | bill_az: based on our meeting this week, I understood that gpfs operates in a flat network | 15:16 |
| bill_az | yep - but we may want to use vlan connections from tenant guests to specific cluster node | 15:17 |
| bswartz | bill_az: I realize that gpfs has many different networking options, but semantically I think they all support the concept of "grant access to /a/b/c to host 10.20.30.40" | 15:17 |
| *** caitlin56 has joined #openstack-meeting-alt | 15:18 | |
| bill_az | yes | 15:18 |
| vbellur | bill_az: maybe appropriate drivers can override the attach_share action? | 15:19 |
| bswartz | bill_az: okay I was unaware that gpfs could join a vlan directly -- maybe there's an opportunity for GPFS to implement a VLAN-mediated style of driver aka (1) | 15:19 |
| *** jtomasek has joined #openstack-meeting-alt | 15:19 | |
| bswartz | or maybe the thing that joins the VLAN is just a proxy/gateway itself | 15:20 |
| bill_az | I think there may end up being a hybrid of 1/2 | 15:20 |
| bswartz | that blurs the lines a bit >_< | 15:20 |
| bswartz | okay I'm glad this came up though -- I'll incorporate it into my doc update | 15:21 |
| bswartz | bill_az: one question for you | 15:21 |
| caitlin56 | Doesn't GPFS do pNFS-like direct transfers? That makes a straight server-side proxy tricky, unless you can limit the proxy role to metadata. | 15:21 |
| *** alazarev has joined #openstack-meeting-alt | 15:21 | |
| bill_az | bswartz: we are still discussing design internally - I just want to point out 2) as you described it might not be exactly where we end up | 15:21 |
| bswartz | is the part of the system you would use to export a GPFS filesystem directly into another vlan part of GPFS itself, or some addon that you guys maintain? | 15:22 |
| *** jasonb365 has joined #openstack-meeting-alt | 15:22 | |
| bill_az | initial driver is nfs (ganesha or could be kernel nfs) on top of gpfs | 15:22 |
| bswartz | caitlin56: I think at one layer you're right, but you can always implement a second proxy layer on top of that | 15:22 |
| zhaoqin__ | bill_az: I see your code is sharing gpfs via nfs. do you plan to let vm to mount the shares via gpfs protocol? | 15:23 |
| bswartz | bill_az: is there any reason that the nfs-ganesha layer couldn't sit on top of some other filesystem like cephfs, glusterfs, or another NFS? | 15:23 |
| bill_az | zhaoqin__: not initially - that would be in a future driver | 15:24 |
| anands | bswartz: no, don't there is...that aligns with the proposal last week | 15:24 |
| zhaoqin__ | bill_az: ok | 15:24 |
| bill_az | bswartz: thats' what ganesha brings | 15:24 |
| bill_az | there is fsal for various filesystems | 15:25 |
| bswartz | so to answer hagarth's earlier question, nfs-ganesha is one way we can bridge arbitrary backend filesystems into a tenant network | 15:25 |
| bswartz | it could be the preferred method even, if it work well | 15:26 |
| bswartz | works* | 15:26 |
| *** bvandehey has quit IRC | 15:26 | |
| shamail | Is Manila-agent just in architecture/design phase or has anyone started working on it already? | 15:26 |
| bill_az | btw - ganesha v2 is was released this week | 15:26 |
| *** sacharya has joined #openstack-meeting-alt | 15:26 | |
| caitlin56 | Can NFS-ganesha use NFSv4 or NFSv4.1 tricks? | 15:26 |
| anands | caitlin56: yes it supports v4, v4.1 | 15:26 |
| bswartz | shamail: it doesn't exist -- it's just something we're thinking about | 15:26 |
| vbellur | caitlin56: are you looking at something specific in v4/v4.1? | 15:27 |
| bswartz | caitlin56: I'm pretty sure that ganesha-nfs will sit right in the middle of the data path though -- all traffic will flow through it when it's being used as a gateway | 15:27 |
| zhaoqin__ | bill_az:great, it need to have a try | 15:27 |
| caitlin56 | Our servers support v4, so nfs-ganesha could be a backup method of adding vservers. We will probably use OpenSolaris zones, however. But that has not passed QA yet. | 15:28 |
| bill_az | zhaoqin__: you can ping me if you have trouble building / getting started | 15:28 |
| bswartz | so in that scenario I'm not sure what "tricks" it could take advantage of | 15:28 |
| *** IlyaE has joined #openstack-meeting-alt | 15:28 | |
| zhaoqin__ | bill_az: thank you | 15:29 |
| *** jjmb has joined #openstack-meeting-alt | 15:29 | |
| vbellur | caitlin56: would that mean you would require ganesha to run on OpenSolaris? | 15:29 |
| anands | bswartz: speaking of all traffic being routed through ganesha, do you see it as a bottleneck? | 15:30 |
| bswartz | anands: definitely not | 15:30 |
| caitlin56 | vbellur, not necessarily, we can run Linux inside an OpenSolaris zone. | 15:30 |
| bswartz | anands: ganesha can run on the hypervisor nodes and scale along with them | 15:30 |
| vbellur | caitlin56: ok | 15:30 |
| anands | bswartz: precisely, yes, its what we suggested last week as part of the proposal | 15:31 |
| jvltc | bswartz, yes ganesha can scale well; well 2.0 is just out there could be some issues with it; but yea architecture wise it does | 15:31 |
| jvltc | infact 1.5 we experimented here at IBM and scaled very well | 15:31 |
| bswartz | the important thing is that if we can locate teh ganesha gateways on the same physical hardware as the guest vms that are using them, there will be no fan-in from a network perspective | 15:32 |
| bswartz | the scaling should be as good as cinder | 15:33 |
| caitlin56 | bwartz: with the caveat that distributed proxies imply distributed security. Some customers will want the vserver option. | 15:33 |
| bswartz | caitlin56: the tenants wouldn't know how the clound was built internally | 15:33 |
| gregsfortytwo | I'm having some trouble visualizing how Ganesha would interact with (2) (or maybe just with (2) itself); can somebody spell that out a little more? | 15:34 |
| bswartz | all of this should be invisible to a tenant | 15:34 |
| caitlin56 | bswartz: if the backend servers are NFSv4 then it should actually be better than cinder. Not as good as object storage, but quite good. | 15:34 |
| anands | what about the availability story wrt ganesha? Or is the plan to discuss that separately? | 15:34 |
| bswartz | gregsfortytwo: don't worry you're not alone -- I intend to capture the new design in an updated wiki | 15:34 |
| vbellur | anands: I think we need to have another discussion around HA for NFS-Ganesha. | 15:35 |
| bswartz | anands: again if ganesha runs on the same physical machine where the guest lives, then hardware failures are not a problem because any hardware failure that affects ganesha will affect the guest too | 15:35 |
| bswartz | and we all know that software failure are not a problem because we never write bugs into our software, right? | 15:36 |
| anands | bswartz: if its a ganesha crash? | 15:36 |
| anands | Vijay: sure | 15:36 |
| bswartz | haha | 15:36 |
| caitlin56 | bwartz: yes, there are a number of scenarios where the fact that the NFS proxy and its clients die at the same time allows you some freedom regarding NFS session rules. | 15:36 |
| vbellur | all the code I write is completely free of bugs :) | 15:36 |
| jvltc | anands, bswartz just said no software bugs. :) | 15:36 |
| jvltc | anands, if ganesha is on the hypervisor node; if it crashes all it needs is a restart right? | 15:37 |
| bswartz | okay so we need to move to the next topic | 15:37 |
| jvltc | In this architecture I am guessing ganesha runs as stand alone | 15:37 |
| caitlin56 | ananda: NFSv3 or NFSv4? Any caching done under NFSv3 is risky (but common). NFSv4 has explicit rules. | 15:37 |
| bswartz | I'm sure we'll keep spending time on multitenancy in the coming weeks | 15:37 |
| bswartz | #topic dev status | 15:38 |
| *** openstack changes topic to "dev status (Meeting topic: manila)" | 15:38 | |
| bswartz | okay can we have an update on the new changes for the last week? | 15:38 |
| bswartz | https://review.openstack.org/#/q/manila+status:open,n,z | 15:38 |
| hagarth | bswartz: rraja_ and csaba are adding unit tests for the flat network glusterfs driver | 15:39 |
| bswartz | vponomaryov? yportnova? | 15:39 |
| vponomaryov | We are working on three things: | 15:39 |
| *** vbellur has left #openstack-meeting-alt | 15:39 | |
| vponomaryov | 1) Transfer Manila to Alembic is in progress: https://review.openstack.org/#/c/60788/ | 15:39 |
| *** hagarth has left #openstack-meeting-alt | 15:39 | |
| vponomaryov | 2) NetApp driver (cmode) is in progress: https://review.openstack.org/#/c/59100/ | 15:40 |
| vponomaryov | 3) Implementation of BP https://blueprints.launchpad.net/manila/+spec/join-tenant-network is still in progress. | 15:40 |
| vponomaryov | 3.1) https://review.openstack.org/#/c/60241/ | 15:40 |
| vponomaryov | 3.2) https://review.openstack.org/#/c/59466/ | 15:40 |
| *** vbellur has joined #openstack-meeting-alt | 15:40 | |
| vponomaryov | And have one open item | 15:40 |
| bswartz | vponomaryov: will any of these be ready for merge in the next few days? I've reviewed some but not all of them | 15:41 |
| vponomaryov | alexpec had asked about not clear situation with driver interfaces in manila's chat | 15:41 |
| caitlin56 | yponomaryov: When will you be confident that your interface with Neutron is stable? | 15:41 |
| *** rnirmal has joined #openstack-meeting-alt | 15:41 | |
| vponomaryov | we beleave, can get working ones next week | 15:42 |
| *** sacharya has quit IRC | 15:42 | |
| caitlin56 | yponomaryov: that fits our schedule well, we'll probably start coding early next month on the nexenta driver. | 15:42 |
| bswartz | yeah I need to answer alexpc | 15:42 |
| vponomaryov | So, we think, that driver interfaces should be refactored | 15:43 |
| bswartz | last 2 days I've been stuck in long meetings so sorry for those of you waiting for responses from me by email | 15:43 |
| *** devkulkarni has joined #openstack-meeting-alt | 15:44 | |
| vponomaryov | so, this refactor should be done asap | 15:44 |
| vponomaryov | before hard working on different drivers | 15:44 |
| caitlin56 | yponomaryov: let us know when you'd be starting any refactoring. We'll let you know when we're about ready to start coding. Don't want to start coding 1 week before you change everything. | 15:45 |
| vponomaryov | it means, that lvm driver is the only acceptable for now | 15:45 |
| vponomaryov | and it should be refactored | 15:46 |
| vponomaryov | even for singletenancy | 15:46 |
| bill_az | vponamaryov: is there a blue print / design for the refactoring? what are your thinking of changing? | 15:46 |
| vponomaryov | there is no Bp for now | 15:47 |
| vponomaryov | we think to change 3 existing methods to one | 15:47 |
| vponomaryov | because differnet backends will use different methods | 15:47 |
| caitlin56 | Basically, having 3 entry points only makes sense for certain backends? Therefore just go with one and let each backend map to its implementation? | 15:48 |
| bill_az | vponamaryov: that seems like a good idea | 15:49 |
| vponomaryov | caitlin56: yes | 15:50 |
| vponomaryov | own clear implementation | 15:50 |
| caitlin56 | +1 then, and the best time to refactor is before we have 4 backends. | 15:50 |
| bswartz | I agree, but the best way to get the design right is to have real use cases implemented | 15:51 |
| bill_az | vpononmaryov: one question I brought up last week - I dont see multiple backend support fully implemented - is there work planned to finish that? | 15:51 |
| bswartz | without multiple functioning drivers it will be hard to validate that our design is flexible enough | 15:51 |
| vponomaryov | yes, the idea had popped up exactly after trying to implement | 15:52 |
| bswartz | so it's a bit of a chicken and an egg | 15:52 |
| bswartz | whoever implements first will probably have some pain working through the refactorings as the design settles | 15:52 |
| bswartz | okay thanks vponomaryov | 15:53 |
| caitlin56 | bswartz: we obviously cannot be 100% confident until after multiple backends have been implemented. Still fixing things that already look likely to need fixing makes sense. | 15:53 |
| bswartz | #topic open discussion | 15:53 |
| *** openstack changes topic to "open discussion (Meeting topic: manila)" | 15:53 | |
| bswartz | okay I'll open up the floor to other topics | 15:53 |
| vponomaryov | bill_az: we propose to refactor, and it will affect all of you | 15:53 |
| *** dttocs has joined #openstack-meeting-alt | 15:53 | |
| vponomaryov | who had begun drivers | 15:53 |
| bswartz | btw those of you who have contributed drivers already: thank you! | 15:54 |
| *** katyafervent has joined #openstack-meeting-alt | 15:54 | |
| caitlin56 | yponomaryov: the nexenta resources are booked for at least 3 weeks before we start coding. | 15:54 |
| *** zhiyan has quit IRC | 15:54 | |
| vbellur | bswartz: we plan to go ahead and prototype the ganesha mediated model. I assume that would be fine given the direction we are heading? | 15:54 |
| bswartz | vbellur: yeah I'm looking forward to seeing a prototype | 15:55 |
| vponomaryov | caitlin56: there is not a lot of work, the question about severity | 15:55 |
| bswartz | vbellur: does your team have familiarity with ganesha already? | 15:55 |
| vbellur | bswartz: cool. Yeah, we have a good degree of familiarity with ganesha. | 15:55 |
| bill_az | vpononmaryov: ok on multi-backend. we have initial gpfs driver w/ knfs working - starting on ganesha flavor now | 15:56 |
| bill_az | but no problem if driver interface changes some | 15:56 |
| vponomaryov | so, everyone agree, that we create appropriate BP and do the refactor? | 15:57 |
| *** demorris_ has joined #openstack-meeting-alt | 15:57 | |
| *** thinrichs has joined #openstack-meeting-alt | 15:57 | |
| bswartz | vponomaryov: +1 | 15:57 |
| shamail | vponomaryov: +1 | 15:58 |
| caitlin56 | +1 | 15:58 |
| vbellur | vponomaryov: +1 | 15:58 |
| bswartz | anything else? | 15:58 |
| bswartz | we're near the end of our hour | 15:58 |
| *** s3wong has joined #openstack-meeting-alt | 15:58 | |
| bswartz | I plan to hold this meeting as usual next week | 15:58 |
| *** michsmit has joined #openstack-meeting-alt | 15:59 | |
| bswartz | the following week is a holiday week here | 15:59 |
| *** SushilKM has joined #openstack-meeting-alt | 15:59 | |
| *** alagalah has joined #openstack-meeting-alt | 15:59 | |
| bswartz | we can discuss next week, but probably I'll cancel the 26 Dec meeting | 15:59 |
| vbellur | bswartz: makes sense | 15:59 |
| *** demorris has quit IRC | 15:59 | |
| *** demorris_ is now known as demorris | 15:59 | |
| alagalah | Good morning | 15:59 |
| bswartz | thanks everyone | 15:59 |
| aostapenko | thanks, bye | 16:00 |
| bswartz | #endmeeting | 16:00 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 16:00 | |
| openstack | Meeting ended Thu Dec 12 16:00:11 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:00 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/manila/2013/manila.2013-12-12-15.01.html | 16:00 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/manila/2013/manila.2013-12-12-15.01.txt | 16:00 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/manila/2013/manila.2013-12-12-15.01.log.html | 16:00 |
| *** caitlin56 has quit IRC | 16:00 | |
| *** anands has left #openstack-meeting-alt | 16:00 | |
| *** alazarev has quit IRC | 16:00 | |
| *** achirko has left #openstack-meeting-alt | 16:00 | |
| mestery | hi | 16:00 |
| *** gregsfortytwo has left #openstack-meeting-alt | 16:00 | |
| alagalah | Hi | 16:00 |
| s3wong | hello | 16:00 |
| mestery | banix michsmit: there? | 16:01 |
| banix | Hi | 16:01 |
| michsmit | hi | 16:01 |
| mestery | #startmeeting networking_policy | 16:01 |
| openstack | Meeting started Thu Dec 12 16:01:19 2013 UTC and is due to finish in 60 minutes. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:01 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:01 |
| *** openstack changes topic to " (Meeting topic: networking_policy)" | 16:01 | |
| openstack | The meeting name has been set to 'networking_policy' | 16:01 |
| *** ashaikh has joined #openstack-meeting-alt | 16:01 | |
| mestery | #link https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy Agenda | 16:01 |
| *** shamail has quit IRC | 16:01 | |
| sc68cal | morning | 16:01 |
| mestery | #topic Action Items | 16:01 |
| *** openstack changes topic to "Action Items (Meeting topic: networking_policy)" | 16:01 | |
| SumitNaiksatam | hi | 16:01 |
| mestery | banix and alagalah: You guys have the first action items. Any updates? | 16:01 |
| mestery | These were from last week. | 16:02 |
| *** japplewhite has left #openstack-meeting-alt | 16:02 | |
| *** allyn has joined #openstack-meeting-alt | 16:02 | |
| alagalah | mestery: banix yes, I put together a strawman taxonomy and banix has fleshed it out, its available for comment | 16:02 |
| banix | Aaalagalah, has prepared a resource diagram | 16:02 |
| alagalah | #link https://docs.google.com/drawings/d/1HYGUSnxcx_8wkCAwE4Wtv3a30JstOBPyuknf7UnJMp0/edit | 16:02 |
| mestery | alagalah: Thanks for sharing that. | 16:02 |
| mestery | Have people reviewed this yet? | 16:02 |
| *** xyang1 has quit IRC | 16:03 | |
| *** bswartz has left #openstack-meeting-alt | 16:03 | |
| s3wong | mestery: no, just aware of it now | 16:03 |
| thinrichs | Me neither--looking now. | 16:03 |
| * mestery gives everyone a minute, and then we can discuss it. | 16:03 | |
| alagalah | It was written last night, only shared this morning, so you are still getting "first look" thinrichs s3wong | 16:04 |
| s3wong | alagalah: :-) | 16:04 |
| mestery | Thanks for writing this up alagalah. | 16:04 |
| *** rraja_ has quit IRC | 16:04 | |
| thinrichs | Not so familiar with these diagrams--why are Security, QoS, Redirect not connected to anything? | 16:04 |
| banix | thinrichs: These are not Neutron objects | 16:05 |
| ashaikh | my first question is whether we also need a relation (mapping) from group to network -- i.e., are "endpoints" here just things that can be put in groups? (nested groups may need this though) | 16:05 |
| alagalah | thinrichs: Good observation... yes as to banix's point, the idea is to show linkages to existing neutron objects and net new objects | 16:05 |
| *** dttocs has quit IRC | 16:05 | |
| s3wong | what is the intended meaning of the Policy -> Group arrow? | 16:05 |
| banix | so we were debating whether we put them in the figure tror not | 16:05 |
| thinrichs | And did we settle on only having Networks and ports as endpoints? I thought banix said in the google doc we had other objects. | 16:06 |
| alagalah | ashaikh: Great question, and if that is indeed necessary, we have a problem... imho references to existing neutron objects should really be at the edges (ie pure child nodes) of the taxonomy | 16:06 |
| *** yidclare has joined #openstack-meeting-alt | 16:06 | |
| *** aostapenko has left #openstack-meeting-alt | 16:06 | |
| *** ywu has joined #openstack-meeting-alt | 16:07 | |
| ashaikh | alagalah: it may be ok as is, but it would seem a natural mapping of group to network (as an option) | 16:07 |
| alagalah | thinrichs: I made a comment wrt "networks" and "endpoints" last night... | 16:07 |
| *** yamahata_ has quit IRC | 16:07 | |
| michsmit | I assume that a given endpoint only a single network, correct ? | 16:07 |
| mestery | michsmit: I would agree with that, and thinrichs had commented on that in the google doc as well. | 16:07 |
| banix | michsmit: you mean a group cannot be made of more than one network? or i missed your point? | 16:08 |
| *** mcohen2 has joined #openstack-meeting-alt | 16:08 | |
| *** dttocs has joined #openstack-meeting-alt | 16:08 | |
| *** zhiyan has joined #openstack-meeting-alt | 16:09 | |
| *** gkleiman has joined #openstack-meeting-alt | 16:09 | |
| *** gkleiman_ has joined #openstack-meeting-alt | 16:09 | |
| michsmit | in the diagram, a group references 1 or more EPs which reference 1+ networks | 16:09 |
| *** gkleiman_ has quit IRC | 16:09 | |
| alagalah | ashaikh: My only concern with that is that my understand (as naive as it is) is that group should be a collection of endpoints, and endpoints at this stage, seem to make sense to be ports or networks for ease of integration but I think its short sighted to limit it to that, since the intent is to provide an application centric API | 16:09 |
| banix | ashaikh: we don't have nested groups as is; we need to add if we need it. | 16:09 |
| alagalah | ashaikh: Hence I think it makes sense to not have a network/port reference in group | 16:10 |
| *** dhellmann is now known as dhellmann_ | 16:10 | |
| *** hemanthravi has joined #openstack-meeting-alt | 16:10 | |
| ashaikh | alagalah: i think that is simpler, but we could also think of groups as only collection of endpoints (i.e., ports) and neutron networks being a way to represent groups initially , with option for other mappings | 16:11 |
| mestery | OK, so should we incorporate alagalah's diagram into the document? | 16:11 |
| s3wong | alagalah: we do need some primitives as endpoints assigned to groups, if not network/port, what can these be? | 16:11 |
| *** colinmcnamara has joined #openstack-meeting-alt | 16:12 | |
| *** colinmcn_ has joined #openstack-meeting-alt | 16:12 | |
| *** Barker has quit IRC | 16:13 | |
| alagalah | ashaikh: Yes, that makes sense to me, and hence the diagram reflects that imho, s3wong I think we need to eventually be able to identify application by LXC / some container identified by UUID, but thats a bigger topic, I'm just trying to build that idea into this | 16:13 |
| ashaikh | alagalah: in short, what i think may be missing in the diag is a way to directly map a group to neutron network (i.e., does this say you have to first put it in an endpoint object) | 16:13 |
| banix | ashaikh: Wouldn't a group with one endpoint (which is a network) give you the same? | 16:13 |
| alagalah | ashaikh: yes that is exactly what I'm trying to show here... and to be fair, I'm reflecting the tables but yes it makes sense | 16:13 |
| *** shusya has quit IRC | 16:14 | |
| thinrichs | s3wong: I have the same question. If Neutron doesn't know what an 'app' is, it won't be able to enforce any policy about it. I don't see how we can ask Neutron to enforce policy about objects it doesn't know about. | 16:14 |
| ashaikh | banix: yes, it could, just that having to put a network in an endpoint seems a little superfluous (but i'm ok if it simplifies the imple) | 16:14 |
| *** sacharya has joined #openstack-meeting-alt | 16:14 | |
| *** Barker has joined #openstack-meeting-alt | 16:15 | |
| mestery | thinrichs: I get that point. But won't it focus on the objects it knows about? | 16:15 |
| s3wong | thinrichs: yes, exactly | 16:15 |
| *** markmcclain has joined #openstack-meeting-alt | 16:16 | |
| *** yportnova_ has quit IRC | 16:16 | |
| michsmit | Overall, I like the diagram. My 2 comments : I don't like the pink line there, I think it should be removed. 2nd comment: The reference for network and port should not have + | 16:16 |
| *** zhaoqin__ has quit IRC | 16:16 | |
| banix | michsmith: instead of +, 1? | 16:16 |
| michsmit | banix: yes | 16:16 |
| thinrichs | mestery: Suppose the entire policy just says UUID1 can't send traffic over port 80 to UUID2. But Neutron doesn't know what UUID1 or UUID2 are. It can't enforce the policy. What's the point of writing that policy? | 16:17 |
| s3wong | michsmit: agree there, that pink line is strange; and an endpoint is one object, a group is a collection of endpoints | 16:17 |
| ashaikh | michsmit: IMO the pink line explains how a groups and policies are expressed, so is useful | 16:17 |
| banix | michsmith, s3wong: pink is a placeholder | 16:17 |
| banix | the pink was boack at first :) | 16:17 |
| banix | In the doc, we specify the policy between a source group and a destination group | 16:18 |
| banix | So the pink line is to represent that relationship | 16:18 |
| thinrichs | Do we ever foresee a policy that spans more than 2 groups? Maybe a policy that talks about the need to waypoint communication between a source and a target e.g. through a proxy? | 16:18 |
| thinrichs | If so, maybe we just want a + line from policy to group. | 16:19 |
| ashaikh | banix: another way would be to have groups hang off of policy with a "2" annotation | 16:19 |
| alagalah | thinrichs: IDeally that is EXACTLY a valid policy and how it should be expressed... I think we should confuse how we identify endpoints, with the objects that the Action leverages | 16:19 |
| banix | ashaikh: yes | 16:19 |
| alagalah | thinrichs: sigh, sorry that wasn't right | 16:19 |
| s3wong | ashaikh: a policy is provided by a group A, another group who wants to talk to group A consumes the policy; I don't know if the pink line represents this well | 16:19 |
| thinrichs | I guess I imagined that there were 3 groups in that policy: source, destination, and a collection of proxies. | 16:19 |
| alagalah | s3wong: Agreed, hence why it's pink and see the reference in the key | 16:19 |
| ashaikh | thinrichs: that list of waypoints could be expressed in the redirect action in that case | 16:20 |
| ashaikh | s3wong: this is more a question then of having a policy attached to a group -- i find the produce/consume relation harder to understand | 16:20 |
| thinrichs | ashaikh: but that was just an example off the top of my head. Pick something that requires 3 groups but which doesn't have a pre-defined action built for handling the case. | 16:20 |
| banix | thinrichs: the 3rd collection will be part of the action description | 16:20 |
| michsmit | banix: agreed, we need a relationship of some sort there (pink line). I would think the arrow comes from the group and we can leave out the src/dst group | 16:20 |
| *** alazarev has joined #openstack-meeting-alt | 16:20 | |
| banix | So here is the pink question: | 16:21 |
| *** NikitaKonovalov has quit IRC | 16:21 | |
| *** SergeyLukjanov has quit IRC | 16:21 | |
| ashaikh | thinrichs: in that case, i would express pairwise to be clear which communication the policy is governing | 16:22 |
| banix | whether 1) we express the policy through producer/consumer relationship from groups point of view or 2) define the policy as governing traffic between two groups | 16:22 |
| *** dttocs has quit IRC | 16:22 | |
| s3wong | ashaikh: that's fair, yet the arrow direction + src/dst reference makes it a bit unclear | 16:22 |
| thinrichs | Another example with 3 groups: Suppose we want to prohibit traffic from src to dst from traveling through a specific group; we don't care where the traffic goes as long as it does NOT go through that group. | 16:22 |
| alagalah | banix exactly... I made a comment in the BP last night along those lines | 16:22 |
| banix | I think these are the two models we have been discussing for sometime | 16:22 |
| alagalah | Yes, and making it pink was my hamfisted way of highlighting that the tables etc are kind of dependent on the policy model | 16:23 |
| michsmit | banix: I think those 2 models sum it up correctly | 16:23 |
| s3wong | banix: good two models summary | 16:23 |
| alagalah | michsmit: I was under the impression we had to pick one | 16:23 |
| ashaikh | thinrichs: you would just create a "security" policy that forbid that communication | 16:23 |
| michsmit | We may be able to express both by showing that there can be more than 1 src group and more than 1 dest group | 16:23 |
| *** jtomasek has quit IRC | 16:24 | |
| michsmit | and allow the groups to refer to the policy as a src (provider) or destt (consumer) | 16:24 |
| *** prasadv has joined #openstack-meeting-alt | 16:24 | |
| ashaikh | michsmit: if we can give flexibility to use either approach, it would be great | 16:24 |
| thinrichs | ashaikh: would that policy be written in our policy language or in another? I thought the point was to put such policies within our language. | 16:24 |
| *** SushilKM has quit IRC | 16:25 | |
| alagalah | michsmit: I had that discussion with banix too, which means a table modification but makes sense | 16:25 |
| alagalah | I personally like the consumes/produces model | 16:25 |
| banix | michsmit: so if we allow possibly multiple source and multiple destination groups the two models become equivalent without needing "allow the groups to refer to the policy as a src (provider) or destt (consumer)" No? | 16:25 |
| ashaikh | thinrichs: yes, our security policy, i.e., the one in the diag, which i assume has a deny type rule | 16:25 |
| michsmit | banix: i think so | 16:25 |
| *** SushilKM has joined #openstack-meeting-alt | 16:26 | |
| mestery | OK, so lots of good discussion here around this diagram it appears. | 16:26 |
| mestery | But it's almost halfway through the meeting now. | 16:26 |
| mestery | And there are other items yet to cover. | 16:26 |
| mestery | Any concrete action items we want out of this particular discussion? | 16:26 |
| thinrichs | ashaikh: but I'm not saying src can't talk to that specific group (let's call it G); it's just that we don't want to route traffic between src and dst through G. | 16:26 |
| mestery | I think we should migrate this taxonomy doc into the main google doc. Thoughts alagalah? | 16:26 |
| s3wong | mestery: I guess we should incorporate the diagram into the document, and we can then comment on that diagram directly in the document | 16:27 |
| alagalah | That would make sense... before we do, see that edit I made? | 16:27 |
| banix | mestery: yes for moving to the main doc. LEt's see if we can reach an agreement in the next couple of minutes :) | 16:27 |
| mestery | s3wong: Agreed. | 16:27 |
| mestery | alagalah : Yes | 16:27 |
| ashaikh | thinrichs: then you're back to the waypoint example, and we could handle with the redirect/classifer policy | 16:27 |
| *** brents has joined #openstack-meeting-alt | 16:27 | |
| mestery | #action alagalah to migrate taxonomy diagram into the main document | 16:27 |
| ashaikh | i agree about putting this diag in the main doc with the changes suggested by banix and michsmit to accommodate both approaches | 16:28 |
| banix | So are we going to allow both models by allowing multiple source and destination groups? | 16:28 |
| s3wong | banix: we should | 16:28 |
| banix | do we all agree that is the way forward? | 16:28 |
| michsmit | banix: I think so | 16:29 |
| s3wong | banix: +1 | 16:29 |
| prasadv | banix: +1 | 16:29 |
| thinrichs | banix: sure | 16:29 |
| *** alazarev has quit IRC | 16:29 | |
| banix | Great | 16:29 |
| ekarlso | what's network policy btw if anyone cares for after meeting | 16:29 |
| mestery | OK, thanks banix. | 16:29 |
| *** colinmcn_ is now known as colinmcnamara_ | 16:29 | |
| prasadv | sorry joined alittle late | 16:29 |
| mestery | So, lets move on to the next topic. | 16:30 |
| prasadv | where is the taxanomy in the document | 16:30 |
| mestery | prasadv: See the link from earlier in the meeting (https://docs.google.com/drawings/d/1HYGUSnxcx_8wkCAwE4Wtv3a30JstOBPyuknf7UnJMp0/edit?usp=sharing) | 16:30 |
| s3wong | prasadv: https://docs.google.com/drawings/d/1HYGUSnxcx_8wkCAwE4Wtv3a30JstOBPyuknf7UnJMp0/edit | 16:30 |
| alagalah | prasadv: Its not in yet, I didn't have edit access to the BP | 16:30 |
| mestery | #topic Discussion Items | 16:30 |
| *** openstack changes topic to "Discussion Items (Meeting topic: networking_policy)" | 16:30 | |
| mestery | alagalah: I just added you with edit writes so you're good. | 16:30 |
| *** Dimit has joined #openstack-meeting-alt | 16:30 | |
| mestery | Next item: Endpoints/groups | 16:30 |
| mestery | https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy (For the item on the agenda for those who don't have it open) | 16:31 |
| mestery | The question in the agenda is: Endpoints belonging to multiple groups. | 16:31 |
| mestery | I think thinrichs pointed this out in the gdoc as well. | 16:31 |
| mestery | OR rather, asked about it. | 16:31 |
| banix | mestery: yes. | 16:31 |
| banix | Tried to put the questions on the google doc on the list of things to discuss | 16:32 |
| thinrichs | Somebody else brought it up. But the question is whether we want a classifier to have a broader range of test attributes than what was in the doc. | 16:32 |
| Dimit | its powerfull, but can create confusion | 16:32 |
| thinrichs | And I guess whether a classifier needs to test all of the possible attributes listed in the doc. | 16:32 |
| ashaikh | don't we need to allow this to have different policies apply to the same endpoint? | 16:33 |
| prasadv | i brought this up. I think it is needed | 16:33 |
| banix | So the question is if we allow an endpoint being in multiple groups? Should we not allow it to start? | 16:33 |
| mestery | So, if we allow this, then ordering of policies becomes an issue to solve. | 16:33 |
| michsmit | we likely want to start off with very simple assignment. | 16:33 |
| mestery | banix: Good point. First whether we allow it or not. | 16:33 |
| *** markmcclain has quit IRC | 16:33 | |
| s3wong | My take is the policy is applied from group to group, rather than pointing to an endpoint, therefore subjected to different policy even with a common endpoint in different groups should be fine, right? | 16:33 |
| banix | mestery: yes, and possibly having conflicting policies. | 16:34 |
| thinrichs | mestery: but I think the difficulty in implementation will affect whether or not we allow it. | 16:34 |
| ashaikh | mestery: wsn't there a suggestion to have a priority with policy rules to address that | 16:34 |
| mestery | thinrichs: Agreed, and as michsmit said, we may want to start with the simplest case, likely not allowing this. | 16:34 |
| prasadv | s3wong: how does one resolve conflicts as pointed in the document | 16:34 |
| mestery | ashaikh: That is one way to solve it, yes. | 16:34 |
| Dimit | priority alone doesnt solve it. needs to be global | 16:35 |
| ashaikh | thinrichs: agree, but the impl could check and disallow if it can't support ? | 16:35 |
| banix | ashaikh: that would apply in a policy among policy rules which may not be necessary after all. | 16:35 |
| alagalah | prasadv: yes, the priority thing is more complex than it appears on the surface... think ye old Cisco ACLs | 16:35 |
| s3wong | ashaikh: priority is for having more than one policy rule classifier to match a traffic flow | 16:35 |
| ashaikh | s3wong: yes, a simpler cas then | 16:35 |
| banix | s3wong: still problem may show up if we allow one endpoint in multiple groups; I commented on the doc. | 16:36 |
| thinrichs | It's pretty common to have a conflict resolution scheme for policy languages, e.g. AD uses hierarchies, firewalls use (implicit) priorities. | 16:36 |
| thinrichs | I don't think the need for conflict resolution is a show-stopper. | 16:36 |
| alagalah | thinrichs: Agreed | 16:37 |
| prasadv | thinrichs: Yes I think so too | 16:37 |
| banix | thinrichs: Question is if we need to deal with it now? | 16:37 |
| Dimit | hierarchies driven by users assigning the policy is an option | 16:37 |
| thinrichs | I think it's more a question of how hard is it to write the policy you want and get what you expect. | 16:37 |
| alagalah | thinrichs: But needs to be explicitly called out, rather than implied | 16:37 |
| michsmit | initially, a EP in a single group will be easiest and then we could introduce attribute-based assignment of EP to group | 16:37 |
| alagalah | thinrichs: bingo | 16:37 |
| banix | michsmit: makes sense | 16:38 |
| thinrichs | alagalah: definitely needs to be part of the language spec if conflicts are possible. And I agree that the order that rules were added via API calls is a confusing way to resolve conflicts. So if we go with priorities, they ought to be set explicitly. | 16:38 |
| mestery | thinrichs: Agree with you on that point. | 16:38 |
| banix | There are two different questions here: | 16:38 |
| alagalah | thinrichs: Yes, and to my point in the BP about whether this is a promise theory based implementation or... | 16:39 |
| *** dark_knight_ita has joined #openstack-meeting-alt | 16:39 | |
| banix | 1) establishing order among policy rules in a policy, 2) order among policies | 16:39 |
| *** Izik_Penso has joined #openstack-meeting-alt | 16:40 | |
| banix | Let me correct the last statement | 16:40 |
| Dimit | banix: agreed | 16:40 |
| michsmit | ideally if policy rules can be expressed without ordering, things will be easier to manage | 16:40 |
| alagalah | One way would be that if there is conflict to push it back to the app to work out... rather than partial implementation.. ie ask for something else | 16:40 |
| alagalah | Like the 413 return code | 16:40 |
| thinrichs | banix: agreed those are different. | 16:40 |
| ashaikh | michsmit: the explicit priority handles that case i think, right? i'm less sure about the right way to handle globally | 16:41 |
| prasadv | alagalah: we should do that anyway after the priorities right? | 16:41 |
| banix | 1) establishing order among actions in a policy rule, 2) order among policy rules 3) order among policies | 16:41 |
| thinrichs | banix: 1 is interesting b/c there may be multiple actions that we can apply simultaneously. | 16:41 |
| banix | 1 we know the answer to (ordered list of action) 2, may not be a real issue if we do not allow overlapping classifiers 3) we can leave for later by not allowing an EP being in multiple groups | 16:42 |
| thinrichs | It depends on the actions we have of course. But right we need to resolve conflicts (1) within a policy, (2) across policies. | 16:42 |
| *** jtomasek has joined #openstack-meeting-alt | 16:42 | |
| michsmit | 1 can often be expressed in an order independent manner | 16:42 |
| alagalah | prasadv: Well, it maybe away of ensuring that ordering is irrelevant, ie a more "functional programming" style approach, policy is implemetnted same regardless of ordering | 16:42 |
| Dimit | banix: overlapping classifiers are needed for several expressions | 16:42 |
| thinrichs | banix: I fear that disallowing overlapping classifiers won't be practical. | 16:42 |
| *** flaper87 is now known as flaper87|afk | 16:42 | |
| s3wong | banix: (2) is somewhat difficult to enforce - it implies we have to run through all classifier and reject overlap at API level | 16:43 |
| banix | To narrow down the problem we are discussing, is there agreement that EP belongs to one group for now? | 16:44 |
| s3wong | banix: also (1) action list may not be ordered as different action_type can be executed simultaneously | 16:44 |
| thinrichs | banix: if each EP belongs to a single group, can't we still have multiple policies applied to that group and hence have to deal with conflicts? | 16:45 |
| thinrichs | If we're dealing with conflicts anyway, we might as well allow an EP to belong to multiple groups and apply the same conflict resolution to it. | 16:45 |
| banix | s3wong: then, there won't be a need to establish order | 16:45 |
| alagalah | thinrichs: #agreed | 16:46 |
| s3wong | thinrichs: so in essence you are suggesting that we establish orders across policies? | 16:46 |
| Dimit | thinrichs: different implementations will end up resolving conflicts in a different manner. users will be confused | 16:47 |
| thinrichs | s3wong: I'm not suggesting a conflict resolution strategy yet (though order is typical). I'm just trying to understand if there's anyway to avoid conflicts first. | 16:47 |
| mestery | s3wong thinrichs: Orders == priorities | 16:47 |
| *** venkatesh_ has quit IRC | 16:47 | |
| *** venkatesh has quit IRC | 16:47 | |
| *** jtomasek has quit IRC | 16:47 | |
| *** colinmcnamara has quit IRC | 16:47 | |
| banix | thinrichs: I see your point | 16:47 |
| thinrichs | Dimit: The conflict resolution I'm suggesting will be part of the language spec. So all plugins implement it the same. | 16:47 |
| *** vbellur has left #openstack-meeting-alt | 16:47 | |
| *** boris-42 has quit IRC | 16:48 | |
| *** colinmcnamara_ has quit IRC | 16:48 | |
| *** colinmcnamara has joined #openstack-meeting-alt | 16:48 | |
| banix | mestery: you think we can use a cross-policy priority to solve the problem? | 16:48 |
| *** colinmcnamara has quit IRC | 16:48 | |
| prasadv | thinrichs: I agree it should be part of the spec. | 16:48 |
| ashaikh | mestery: so you mean that we don't want explicit priorities, rather governed by ordering ? | 16:48 |
| *** SumitNaiksatam has quit IRC | 16:48 | |
| *** 77CAAS3HQ has joined #openstack-meeting-alt | 16:48 | |
| *** 65MAAD7S9 has joined #openstack-meeting-alt | 16:48 | |
| Dimit | thinrichs: i cant see a unique answer no matter what. users will not know what happened | 16:48 |
| michsmit | between a given pair of groups, do we expect more than 1 policy to be applied ? | 16:48 |
| mestery | I think thinrichs had suggested using priorities for policies, which may solve the problem ashaikh, right? | 16:49 |
| alagalah | ashaikh: I think his point was that whether you choose ordering or priority, you still end up at the same place | 16:49 |
| *** 65MAAD7S9 is now known as colinmcnamara | 16:49 | |
| mestery | alagalah: ^^^^ That too :) | 16:49 |
| thinrichs | Dimit: suppose we require every policy to be assigned a unique number (via the API call). The language spec says that the policy that applies with the highest priority is the one that applies. Then the user understands what is happening. | 16:49 |
| ashaikh | michsmit: couldn't you have have a redirect + QoS policy, for example between groups? | 16:49 |
| *** ekarlso has quit IRC | 16:50 | |
| ashaikh | alagalah: yes, same place, except not implicit in the ordering | 16:50 |
| banix | ashaikh: but those will be policy rules in a single policy | 16:50 |
| *** jvltc has left #openstack-meeting-alt | 16:50 | |
| *** aveiga has joined #openstack-meeting-alt | 16:50 | |
| michsmit | ashaikh: yes, but couldn't they be combined into a single policy | 16:50 |
| michsmit | banix: your fingers are faster than mine :-) | 16:51 |
| ashaikh | michsmit: yes, as mult policy_rules | 16:51 |
| s3wong | michsmit: more than one policy: sure, a policy for app tier, an another policy for Sharepoint application specifically | 16:51 |
| thinrichs | mestery: I think priorities are one solution, though an absolute priority like I mentioned in the example above is not the only way. We could have a partial order of priorities and a mechanism for combining policies of the same priority into one. | 16:51 |
| *** hajay___ has joined #openstack-meeting-alt | 16:51 | |
| hajay___ | openstack-meeting-alt | 16:51 |
| *** hajay___ has quit IRC | 16:51 | |
| *** tsufiev has quit IRC | 16:51 | |
| prasadv | s3wong: can't you combine that into policy rules if the groups are the same | 16:51 |
| Dimit | thinrichs: so two priorities: policy and classifier. i can still see conflict. for ep1, policy A preffered when talking to Ep2 and B preferred when talking to ep3 | 16:51 |
| *** ekarlso has joined #openstack-meeting-alt | 16:51 | |
| mestery | Just a note folks: We have 9 minutes left, there is another meeting in this channel immediately following this one. | 16:52 |
| banix | then in a single policy, the order can be established more easily. | 16:52 |
| *** hajay__ has joined #openstack-meeting-alt | 16:52 | |
| thinrichs | Dimit: we need 2 levels of conflict resolution: within the policy and across policies. | 16:52 |
| thinrichs | Dimit: I was giving the cross-policy resolution scheme. | 16:52 |
| s3wong | prasadv: I picture that we want policies to be reused, so using it like two separate ones seems to make sense | 16:52 |
| michsmit | s3wong: if we limit an EP to a single group, the policy could be combined as well in the case of app tier/Sharepoint | 16:52 |
| michsmit | s3wong: at least initially | 16:53 |
| thinrichs | Dimit: The resolution scheme within a policy should ensure that we can write a policy that describes both QOs and Security. So a strict ordering there isn't so good either. | 16:53 |
| Dimit | thinrichs: cross policy resolution is different for different end poinds . its possible | 16:53 |
| banix | michsmit: I think that is the way to go | 16:53 |
| s3wong | michsmit: then policy combination become an item we have to support in the framework | 16:53 |
| thinrichs | Dimit: sure--I could see priorities on groups as well. There are a bunch of variations here. The important thing is that the language chooses one. | 16:54 |
| banix | should we continue this discussion on mailing list? | 16:54 |
| thinrichs | I would think we start by figuring out the conflict resolution scheme for an individual policy and then worry about cross-policy conflict resolution. | 16:54 |
| s3wong | then going back to thinrichs' point, at time of combining policies, we would need to resolve conflicts | 16:54 |
| alagalah | thinrichs: yes | 16:54 |
| mestery | banix: +1 to the mailing list discussion | 16:54 |
| s3wong | banix: +1 | 16:55 |
| alagalah | banix: +1 | 16:55 |
| prasadv | +1 | 16:55 |
| mestery | We're almost out of time here. | 16:55 |
| alagalah | What mailing list :) | 16:55 |
| Dimit | thinrichs: exactly. it can get arbitrarily complex. thats why i suggest single group for ebd point and simple resolution | 16:55 |
| mestery | #topic Open Discussion and Next Steps | 16:55 |
| *** openstack changes topic to "Open Discussion and Next Steps (Meeting topic: networking_policy)" | 16:55 | |
| mestery | For the last 5 minutes, lets see what we'd like to accompliush for next week. | 16:55 |
| mestery | And then do open discussion for hte last few minutes. | 16:55 |
| banix | openstack-dev mark with [Neutron][Policy] | 16:55 |
| *** luQAs has joined #openstack-meeting-alt | 16:55 | |
| alagalah | banix: ty | 16:55 |
| s3wong | I did some update on the action_type=='qos' just before the meeting, please take a look | 16:56 |
| mestery | #info Emails for Neutron policy should go to openstack-dev marked as "[neutron] [policy]" | 16:56 |
| mestery | s3wong: Thank you for that. | 16:56 |
| s3wong | Also, I would like the community to converge on the default set of actions we would force all plugins to support | 16:56 |
| mestery | s3wong: Can you send an email with that to the list? | 16:56 |
| *** AlanClark has joined #openstack-meeting-alt | 16:56 | |
| s3wong | mestery: certainly | 16:56 |
| prasadv | s3wong:are you going to put more clarity on redirect policy | 16:56 |
| banix | Let us finalize the object model (with support for combining two model) | 16:57 |
| Izik_Penso | fff | 16:57 |
| s3wong | prasadv: yes, will also send out to ML to enlist community suggestions/opinions | 16:57 |
| banix | s3wong: yes, we need that | 16:57 |
| michsmit | banix: +1 I think there is more thinking we need to do on combining the models | 16:57 |
| alagalah | s3wong: I like it but do we want to mix classification with queueing in the same action ? | 16:57 |
| s3wong | prasadv: also, you mentioned you want some redirect dst list mgmt, we should discuss that on ML as well | 16:58 |
| prasadv | s3wong: yes we do need to do that | 16:58 |
| *** irenab has joined #openstack-meeting-alt | 16:58 | |
| mestery | OK, so lets wrap things up here. | 16:58 |
| mestery | We took a few action items which will appear in the meeting minutes. | 16:58 |
| mestery | I'll add them for next week to followup on. | 16:58 |
| *** demorris has quit IRC | 16:58 | |
| banix | Thanks. | 16:58 |
| mestery | Lets continue discussions on the ML for this week for any items which were not discussed here. | 16:59 |
| mestery | And thanks for attending everyone! | 16:59 |
| mestery | #endmeeting | 16:59 |
| s3wong | Thanks! | 16:59 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 16:59 | |
| openstack | Meeting ended Thu Dec 12 16:59:10 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:59 |
| prasadv | thanks | 16:59 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/networking_policy/2013/networking_policy.2013-12-12-16.01.html | 16:59 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/networking_policy/2013/networking_policy.2013-12-12-16.01.txt | 16:59 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/networking_policy/2013/networking_policy.2013-12-12-16.01.log.html | 16:59 |
| *** prasadv has quit IRC | 16:59 | |
| *** Dimit has quit IRC | 16:59 | |
| *** thinrichs has quit IRC | 16:59 | |
| *** jtomasek has joined #openstack-meeting-alt | 17:00 | |
| mestery | OK, who's here for the Neutron Third-Party Testing IRC meeting? | 17:00 |
| *** Dane_ has joined #openstack-meeting-alt | 17:00 | |
| aveiga | o/ | 17:00 |
| *** alagalah has left #openstack-meeting-alt | 17:00 | |
| *** michsmit has left #openstack-meeting-alt | 17:00 | |
| rossella_s | me! | 17:00 |
| *** woodster has left #openstack-meeting-alt | 17:00 | |
| hajay__ | me too! | 17:00 |
| irenab | me too | 17:00 |
| mestery | Great, looks like we have a solid turnout! | 17:00 |
| luQAs | me too | 17:00 |
| dkehn | hi | 17:00 |
| mestery | #startmeeting networking_third_party_testing | 17:00 |
| openstack | Meeting started Thu Dec 12 17:00:56 2013 UTC and is due to finish in 60 minutes. The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:00 |
| *** openstack changes topic to " (Meeting topic: networking_third_party_testing)" | 17:00 | |
| openstack | The meeting name has been set to 'networking_third_party_testing' | 17:01 |
| *** pcm_ has joined #openstack-meeting-alt | 17:01 | |
| mestery | #link https://etherpad.openstack.org/p/multi-node-neutron-tempest Etherpad masquerading as an agenda | 17:01 |
| mestery | So, I do not have an official meeting setup for this, depending on what we accompliush and how often we have this, I can set that up next. | 17:01 |
| *** BrianB_ has joined #openstack-meeting-alt | 17:01 | |
| *** rongze_ has quit IRC | 17:01 | |
| mestery | For now, have a look at the agenda on the etherpad link at the top. | 17:01 |
| mestery | Please add things to the agenda, as well as the general etherpad. | 17:01 |
| *** Leo_ has joined #openstack-meeting-alt | 17:02 | |
| mestery | OK, so I think we're all here because we are individually looking at how to handle the new third-party testing requirement for Neutron plugins and drivers. | 17:02 |
| *** dukhlov_ has quit IRC | 17:02 | |
| mestery | I'm hoping we can use this meeting to facilitate sharing information, hurdles, and workarounds in getting to that goal. | 17:03 |
| mestery | So, a first question: How are people coming along? Does anyone have this setup and working yet? | 17:03 |
| rossella_s | we are just starting thinking about it | 17:03 |
| aveiga | mestery: we just finished getting our Jenkins setup | 17:04 |
| *** ashaikh has quit IRC | 17:04 | |
| hajay__ | we have a somewhat functional setup where we have our n/w controller running on a separate ssystem and all openstack/devstack-driven projects on a differetn system | 17:04 |
| Izik_Penso | No, we just started working on it | 17:04 |
| mestery | OK, so it looks like people are mostly just starting now. | 17:04 |
| aveiga | however, I was actually interested in using this to help test others' plugins in a different environment, since I doubt many people have a dual-stacked l2-provider setup | 17:04 |
| irenab | we are finalizing the requirements | 17:04 |
| gduan | We are planning | 17:04 |
| *** emagana has joined #openstack-meeting-alt | 17:04 | |
| mestery | aveiga: Interesting, and valid point. | 17:04 |
| emagana | mestery: Hi! | 17:05 |
| mestery | emagana: Howdy :) | 17:05 |
| mestery | Are people using their own Jenkins instances for this with the plugin to read the upstream gerrit stream? | 17:05 |
| mestery | That's what we're going to do on our end. | 17:05 |
| *** SumitNaiksatam has joined #openstack-meeting-alt | 17:05 | |
| *** tsufiev has joined #openstack-meeting-alt | 17:06 | |
| *** clayb has joined #openstack-meeting-alt | 17:06 | |
| anteaya | o/ | 17:06 |
| mestery | I think that approach at least allows for an easier integration with the upstream gerrit for reading and posting +1/-1 back from what I understand. | 17:06 |
| mestery | anteaya: Hi! | 17:06 |
| *** ivar-lazzaro has joined #openstack-meeting-alt | 17:06 | |
| mestery | OK, so how about this: Everyone can carve out a section on the etherpad (maybe at the bottom) to list what they are doing for testing. | 17:07 |
| *** Sukhdev has joined #openstack-meeting-alt | 17:07 | |
| Sukhdev | Hi | 17:07 |
| mestery | With the idea that we can share that info and people can come up with a common model for this, as much as possible | 17:07 |
| mestery | Sukhdev: Hi. | 17:07 |
| mestery | For those who joined late: https://etherpad.openstack.org/p/multi-node-neutron-tempest <--- Etherpad with agenda and information. | 17:07 |
| emagana | mestery: Good Idea! | 17:07 |
| anteaya | Sukhdev: did you get that issue sorted out with you testing nova patches? | 17:08 |
| mestery | Also, the etherpad has a section for multi-node testing, because for the most part, I expect everyone here will be doing multi-node testing, so it made sense to combine things a bit. | 17:08 |
| SumitNaiksatam | hi | 17:08 |
| hajay__ | regarding tempest runs, are there plans to run selective tests against a plugin. for eg. test-extensions today expects all plugins to support all extensions | 17:08 |
| Sukhdev | <anteaya>: yes, thanks | 17:08 |
| anteaya | also regarding etherpad use, please click the top right hand coloured button and input your name beside your colour | 17:09 |
| anteaya | thanks | 17:09 |
| anteaya | Sukhdev: thank you | 17:09 |
| mestery | hajay__: Not that I am aware of. Can you add that under the issues seciont I just added to the etherpad? | 17:09 |
| anteaya | Sukhdev: if you have any suggestions on how others might avoid the same issue in future, that would be nice to share | 17:09 |
| mestery | anteaya: Thank you for reminding folks to identify themselves on the etherpad. | 17:09 |
| anteaya | sure | 17:09 |
| hajay__ | mestery: sure. thanks. out of curiosity do we have any plugin that passes all tempest tests? | 17:09 |
| rossella_s | mestery: will multi-node be required or optional? | 17:09 |
| Sukhdev | I have some specific questions - should I ask here or put it on ehterpad? | 17:10 |
| mestery | rossella_s: Multi-node is up to the vendor I think. | 17:10 |
| *** jcoufal_ has quit IRC | 17:10 | |
| mestery | Since we're talking networking, I just assume multi-node is more interesting. :) | 17:10 |
| mestery | Sukhdev: Ask away, and we can add issues or info into the pad. | 17:10 |
| rossella_s | mestery: I agree but it's harder :) | 17:10 |
| mestery | rossella_s: Agree :) | 17:10 |
| hajay__ | mestery: multi node == multiple network controllers right? | 17:11 |
| Sukhdev | I have basic setup working with Jenkins and Gerrit trigger - have specific questions - here we go: | 17:11 |
| emagana | rossella_s: harder even using devstack? | 17:11 |
| mestery | rossella_s: Although, for the most part, I am thinking we can just spin up a multi-node devstack and run Tempest against that, Is that what you were thinking? | 17:11 |
| mestery | hajay__: Multi-node is multiple compute instances. | 17:11 |
| Sukhdev | 1) What kind of traffic are we expecting - this will determine how many VMs I need to allocate | 17:11 |
| anteaya | rossella_s: also be aware that as of yet -infra has no structure for multi-node testing, though we are aware there is a need | 17:11 |
| mestery | Sukhdev: I think the Tempest tests just use pings for verification that things have spun up correctly. | 17:12 |
| aveiga | mestery: are these tests required to run under devstack? | 17:12 |
| SumitNaiksatam | Sukhdev: in general, isn't this what each vendor will determine? | 17:12 |
| mestery | anteaya rossella_s: Yes, thus my combining the two here. | 17:12 |
| anteaya | right | 17:12 |
| mestery | aveiga: Not required, no, but likely easier for most. | 17:12 |
| emagana | anteaya: so, you mean that in current tempest tests, is all in one node? | 17:12 |
| Sukhdev | 2) I was trying to use the devstack script used for present tempest gate. I can not find it - does any one have any clue?http://ci.openstack.org/devstack-gate.html | 17:12 |
| aveiga | I actually have a few nits to pick with devstack, since it's not a friendly player with v6 | 17:12 |
| mestery | emgana: Yes, there is no multi-node gate testing at this point. | 17:12 |
| mestery | aveiga: I think we should file bugs and fix those issues in devstack :) | 17:13 |
| anteaya | emagana: yes, one node currently for tempest test with -infra check and gate | 17:13 |
| *** amotoki has joined #openstack-meeting-alt | 17:13 | |
| rossella_s | emagana: anyway I think even with devstack, multi node it tough | 17:13 |
| emagana | mestery: No wonder, why we have so many bugs! No complaining just raising a good point to improve! | 17:13 |
| *** rudrarugge has joined #openstack-meeting-alt | 17:13 | |
| mestery | Sukhdev: devstack itself comes from it's own git repo, right? | 17:13 |
| aveiga | mestery: agreed, but stretched too thin at the moment | 17:13 |
| dkehn | Sukhdev: https://github.com/openstack-infra/devstack-gate | 17:13 |
| mestery | emagana: Agreed, it's on the list of things to address soon. | 17:13 |
| mestery | emagana: But multiple-nodes is slightly complicated inthe gate due tothings like IP address needs, and the functionality of hte underlying public cloud these thigns run on, etc. | 17:14 |
| emagana | rossella_s: agree, just try with single node and failed most of the tests :-( | 17:14 |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 17:14 | |
| rossella_s | emagana: I sympathize | 17:14 |
| rossella_s | we should get there anyway | 17:14 |
| mestery | IMHO, and marun and I chatted about this, but running everything on a single node means that node is incredibly CPU starved at different points. | 17:14 |
| *** jtomasek has quit IRC | 17:15 | |
| mestery | Anyways, that's a different point I think, though tangentially related to this discussion of multi-node testing. | 17:15 |
| *** NehaV has quit IRC | 17:15 | |
| *** demorris has joined #openstack-meeting-alt | 17:16 | |
| emagana | mestery: so, recommendation is to use a baremetal node instead of VM? | 17:16 |
| mestery | emagana: That is up to the plugin maintainers who are doing the third-party testing :) | 17:16 |
| Sukhdev | 3) I saw an email from salvatore regarding the patches that we (vendors) are suppose to test - has anybody been able to set up Jekinks to pick patches that impact e.g. neutron.db, neutron.api, etc - how do you create such filter? | 17:16 |
| mestery | For example, we will not use bare metal, we will use VMs for the Cisco plugin testing. | 17:16 |
| mestery | emagana: But our plan is to spinup a multi-node devstack environment and run Tempest against that. | 17:17 |
| aveiga | honestly, I think multi-node should be required. If you can't pass packets between instances, then what's the point? | 17:17 |
| emagana | mestery: got it! | 17:17 |
| mestery | aveiga: Agreed, and it's easier for the third-party stuff for sure, as it's under control of vendors. | 17:17 |
| emagana | aveiga: +1 | 17:17 |
| anteaya | Sukhdev: if your next issue is filtering, make a note in the etherpad and I can try to follow up to get you some answers | 17:17 |
| mestery | Sukhdev: I have not. Can you add that under the issues section? | 17:17 |
| mestery | anteaya: Awesome, thanks for the help there! | 17:17 |
| anteaya | sure | 17:18 |
| *** NikitaKonovalov has joined #openstack-meeting-alt | 17:18 | |
| *** lsmola has quit IRC | 17:18 | |
| *** NehaV has joined #openstack-meeting-alt | 17:18 | |
| rudrarugge | We are starting with a single node to get this going at Contrail | 17:18 |
| Sukhdev | I will - thanks | 17:18 |
| Sukhdev | At Arista, we are also strating with single node first | 17:18 |
| rudrarugge | We have the same question regarding filtering of tests | 17:19 |
| *** dark_knight_ita is now known as marcol | 17:19 | |
| emagana | rudrarugge: I almost ask the same question. | 17:19 |
| emagana | does anyone know how to filter tests? | 17:20 |
| clarkb | infra uses Zuul to communicate between gerrit and jenkins. Jenkins is capable of filtering based on file and branch and so on. Not sure about the gerrit jenkins plugin | 17:20 |
| clarkb | *Zuul is capable of filtering based on file and branch and so on | 17:20 |
| anteaya | also be sure to look at smokestack code: https://github.com/dprince/smokestack | 17:20 |
| rudrarugge | We ran 1100 tempest tests and passed 800. 300 failed but are unrelated to our plugin. We wanted to be able to not run these tests | 17:20 |
| anteaya | that will be my first stop trying to address the filtering question | 17:20 |
| mestery | good data points here rudrarugge! | 17:21 |
| mestery | I just updated the etherpad to add a section around what people's setups look like. | 17:21 |
| rudrarugge | Thanks anteaya | 17:21 |
| *** gkleiman has quit IRC | 17:21 | |
| mestery | Please add your plugin/vendor link there, and we can flesh that out as well. | 17:21 |
| clarkb | rudrarugge: oh filtering in that manner. tempest tests are tagged with attributes, I am sure the qa team can give you answers on filtering those | 17:21 |
| mestery | The idea would be to share this info with others again as datapoints. | 17:21 |
| Sukhdev | Can we all agree to share our knowldge on filtering issue on etherpad, please? | 17:21 |
| anteaya | zuul repo: http://git.openstack.org/cgit/openstack-infra/zuul/tree/ | 17:21 |
| mestery | +1 to that Sukhdev. | 17:21 |
| rossella_s | +1 | 17:21 |
| emagana | +1 | 17:22 |
| rudrarugge | +1 | 17:22 |
| mestery | Sukhdev: Can you drive the filtering discussion on the mailing list? Start a thread for that please, or continue the existing one if it's there. | 17:22 |
| *** itzikb has joined #openstack-meeting-alt | 17:22 | |
| Sukhdev | <mestery>: I will do that | 17:23 |
| *** karthik_ has joined #openstack-meeting-alt | 17:23 | |
| mestery | OK, what to discuss next? | 17:23 |
| Sukhdev | Next issue - | 17:23 |
| emagana | Sukhdev: And please, any data points on the filtering, copy them to the etherpad | 17:23 |
| Sukhdev | baremetal vs VM | 17:23 |
| mestery | emagana: +1 to that too! | 17:23 |
| mestery | Sukhdev: I think that is a question left up to the implementor, right? | 17:23 |
| mestery | Sukhdev: Are you looking for recommendations? | 17:24 |
| Sukhdev | if we are suppose to do devstack for each patch, baremetal will not scale - do you guys agree? | 17:24 |
| mestery | Yes | 17:24 |
| rudrarugge | Yes | 17:24 |
| irenab | yes | 17:24 |
| mestery | VMs can spin up on demand and scale, which is why we're going that route. | 17:24 |
| mestery | Now, if your plugin depends on some special HW, you are likley left with bare metal as your only option. | 17:25 |
| mestery | But for the most part, I would expect everyone to be able to run in virtual environments. | 17:25 |
| mestery | But again, it's really plugin dependent. | 17:25 |
| SumitNaiksatam | folks, i think we should first focus on getting an end to end workflow sorted out | 17:25 |
| amotoki | hi! i think baremetal vs vm is not directly related to testing. it is up to your plugin. | 17:25 |
| SumitNaiksatam | starting from getting the triggers | 17:25 |
| mestery | amotoki: Agree. | 17:25 |
| Sukhdev | This is what I am thinking about doing - create a VM from master branch and everytime there is patch, clone the VM, apply patch, run tests and kill the VM - what do you guys think? | 17:25 |
| jbrendel | Sumit: Agree | 17:26 |
| SumitNaiksatam | to actually voting back | 17:26 |
| mestery | SumitNaiksatam: Also agree. | 17:26 |
| *** zhiyan has quit IRC | 17:26 | |
| SumitNaiksatam | we can then think of how we can scale better, etc. | 17:26 |
| ivar-lazzaro | SumitNaiksatam: +1 | 17:26 |
| SumitNaiksatam | lets first flesh the complete workflow on the etherpad | 17:26 |
| mestery | SumitNaiksatam: I'm hoping we can document that on the etherpad. | 17:26 |
| SumitNaiksatam | i see that some folks are further along than otheres | 17:26 |
| mestery | SumitNaiksatam: I have a rough example of that already on the pad. | 17:26 |
| SumitNaiksatam | for those who are, can you please document up to the point that you have reached? | 17:26 |
| mestery | SumitNaiksatam: I have added a section at the bottom for vendors/open source plugins to document that there. | 17:27 |
| SumitNaiksatam | mestery: it might be beneficial to get the exact stpes | 17:27 |
| SumitNaiksatam | mestery: great | 17:27 |
| mestery | SumitNaiksatam: AGreed. | 17:27 |
| SumitNaiksatam | if we can collectively get to the same point, it will help to make much better progress | 17:27 |
| SumitNaiksatam | and ask better questions | 17:28 |
| SumitNaiksatam | and we will all meet the I2 deadline :-) | 17:28 |
| Sukhdev | I have been playing around with this in a VM - I have it almost working except for devstack and filtering issue - I will try to post what ever I can | 17:28 |
| luQAs | SumitNaiksatam: you mean which tempest test pass and/or fail? | 17:28 |
| *** amytron has quit IRC | 17:28 | |
| SumitNaiksatam | Sukhdev: awesome!! | 17:28 |
| mestery | Yes, lets all document on the etherpad to share information. | 17:28 |
| emagana | Sukhdev: It will be very useful! | 17:28 |
| *** jaypipes has quit IRC | 17:28 | |
| *** amytron has joined #openstack-meeting-alt | 17:29 | |
| mestery | There are two things here: 1) The setup to get the environemt up and running. 2) Ensuring you can get a clean Tempest run with your plugin. | 17:29 |
| rudrarugge | we will also update the document | 17:29 |
| mestery | Both are important. | 17:29 |
| SumitNaiksatam | rudrarugge: great, thanks | 17:29 |
| itzikb | I have a basic question: Should every patch be verified | 17:29 |
| mestery | #2 can be worked on in parallel and in fact may expose bugs in your plugin if you're not already running Tempest tests against it. | 17:29 |
| rudrarugge | mestery: agreed on the 2 things | 17:29 |
| SumitNaiksatam | mestery: the latter part is in paralle | 17:29 |
| emagana | itzikb: I think just your plugin patches! | 17:29 |
| SumitNaiksatam | mestery: you said it | 17:29 |
| mestery | itzikb: Not every patch, there is an email from salv-orlando with what he recommended to filter against, see earlier discussion in the meeting logs for this meeting. | 17:30 |
| mestery | OK, so lets focus on documenting where everyone is at on the etherpad. | 17:30 |
| Sukhdev | <mestry> regarding you point 2, tempest tests are failing in stable/havana, but, they pass on master branch - | 17:30 |
| SumitNaiksatam | emagana: i don't think it will be just your plugin patches | 17:30 |
| *** amcrn has joined #openstack-meeting-alt | 17:30 | |
| SumitNaiksatam | emagana: although you may choose to do that | 17:30 |
| mestery | And sending emails to openstack dev tagged as [neutron] [third-party-testing] when appropriate. | 17:30 |
| SumitNaiksatam | mestery: thats a good suggestion on the "filter" :-) | 17:31 |
| mestery | emagana: You need to run against other patches as well, anything from Jenkins for example. | 17:31 |
| itzikb | @mestery: Just Neutron ? | 17:31 |
| emagana | SumitNaiksatam: I do agree that testing avery patch will be very good for the benefit of the third party plugin but we will end up re-creating the whole Infra set-up which I dont think will be easy! | 17:32 |
| Sukhdev | please read an email from Salvatore regarding what patches should we be testing - it is very clear | 17:32 |
| SumitNaiksatam | emagana: there is middle ground between testing every patch and only your plugin | 17:32 |
| SumitNaiksatam | emagana: but again i think that is the vendor's choice | 17:32 |
| amotoki | we need to run tests for patches which changes at leat your plugin and COMMON tests. | 17:32 |
| *** doug_shelley66 has joined #openstack-meeting-alt | 17:32 | |
| mestery | amotoki: Agreed. | 17:32 |
| *** ashaikh has joined #openstack-meeting-alt | 17:32 | |
| emagana | SumitNaiksatam: Understood! | 17:32 |
| mestery | OK, so is there anything else to discuss today? | 17:33 |
| anteaya | emagana: actually it is very easy to recreate the infra set-up locally | 17:33 |
| anteaya | if you choose to do that it would save you a lot of time | 17:33 |
| mestery | Or should we focus on filling out the etherpad before meeting next week? | 17:33 |
| *** dougshelley66 has quit IRC | 17:33 | |
| anteaya | clarkb: ^ | 17:33 |
| *** aignatov has quit IRC | 17:33 | |
| emagana | anteaya: looking forward to get there! Not sure how much VMs will need | 17:33 |
| anteaya | you can run zuul jenkins and nodepool locally | 17:33 |
| mestery | anteaya: I think that's a good idea actually. | 17:33 |
| anteaya | you can set as many vms as you want | 17:33 |
| clarkb | anteaya: emagana: right there are other folks doing it and it is getting easier all the time. I would actually suggest using the infra toolchain to solve many of these problems. zuul, devstack-gate, and nodepool in particular | 17:34 |
| Sukhdev | <anteaya>: can you post this on etherpad, please? | 17:34 |
| *** nati_ueno has quit IRC | 17:34 | |
| rossella_s | anteaya: is there a page that explains how to do that? | 17:34 |
| emagana | clarkb: Yes, please, If you have already a cookbook, we will just follow it! | 17:34 |
| clarkb | rossella_s: there is! http://ci.openstack.org/running-your-own.html | 17:34 |
| *** hajay__ has left #openstack-meeting-alt | 17:35 | |
| rossella_s | clarkb: thanks! | 17:35 |
| *** beyounn has joined #openstack-meeting-alt | 17:35 | |
| mestery | clarkb: Thanks for that! | 17:35 |
| *** brents has quit IRC | 17:35 | |
| clarkb | that document covers A-Z and you may not need all of hte pieces | 17:35 |
| clarkb | devstack-gate, zuul, and nodepool are individually documented if you want to use parts piecemeal | 17:36 |
| mestery | Thanks for that link clarkb! | 17:36 |
| mestery | I think that will help get people going quickly. | 17:36 |
| marcol | clarkb: thanks for the link | 17:37 |
| anteaya | Sukhdev: posted | 17:38 |
| anteaya | rossella_s: yes, linked to instructions in the etherpad | 17:38 |
| rossella_s | anteaya: thanks | 17:38 |
| anteaya | which is clarkb's link | 17:38 |
| mestery | OK, should we each circle back now, spend some time digesting this, ask questions on-list and in-channel before next week's meeting then? | 17:38 |
| anteaya | :D | 17:38 |
| rossella_s | yees :) | 17:38 |
| mestery | OK, lets do that. | 17:39 |
| emagana | the magic of a link! all is easier! | 17:39 |
| mestery | I'll setup another IRC meeting for next week during an Asian friendly time spot so amotoki and gongysh can join. :) | 17:39 |
| Sukhdev | <anteaya>: thanks | 17:39 |
| mestery | Thanks for joining us this week everyone! | 17:39 |
| anteaya | mestery: great idea | 17:39 |
| anteaya | Sukhdev: :D | 17:39 |
| hemanthravi | thanks | 17:39 |
| amotoki | mestery: really appreciated. | 17:39 |
| mestery | Lets see what progress we can make individually and as a team on this to make the testing coverage better for all of Neutron and it's plugins! | 17:40 |
| mestery | amotoki: No problem, and thanks for joining us this week! | 17:40 |
| mestery | #endmeeting | 17:40 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 17:40 | |
| openstack | Meeting ended Thu Dec 12 17:40:16 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:40 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/networking_third_party_testing/2013/networking_third_party_testing.2013-12-12-17.00.html | 17:40 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/networking_third_party_testing/2013/networking_third_party_testing.2013-12-12-17.00.txt | 17:40 |
| Sukhdev | Thanks a bunch | 17:40 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/networking_third_party_testing/2013/networking_third_party_testing.2013-12-12-17.00.log.html | 17:40 |
| *** hemanthravi has quit IRC | 17:40 | |
| *** Izik_Penso has left #openstack-meeting-alt | 17:41 | |
| *** Dane_ has quit IRC | 17:41 | |
| *** NikitaKonovalov has quit IRC | 17:41 | |
| *** marcol has left #openstack-meeting-alt | 17:41 | |
| *** hajay has joined #openstack-meeting-alt | 17:42 | |
| *** beyounn has quit IRC | 17:42 | |
| *** amotoki has quit IRC | 17:42 | |
| *** aveiga has left #openstack-meeting-alt | 17:42 | |
| *** NikitaKonovalov has joined #openstack-meeting-alt | 17:43 | |
| *** brents has joined #openstack-meeting-alt | 17:44 | |
| *** marcol has joined #openstack-meeting-alt | 17:44 | |
| *** shivh has joined #openstack-meeting-alt | 17:45 | |
| *** emagana has quit IRC | 17:46 | |
| *** hajay has quit IRC | 17:47 | |
| *** irenab has quit IRC | 17:48 | |
| *** pcm_ has left #openstack-meeting-alt | 17:49 | |
| *** alazarev has joined #openstack-meeting-alt | 17:50 | |
| *** allyn has quit IRC | 17:50 | |
| *** IlyaE has quit IRC | 17:51 | |
| *** rossella_s has quit IRC | 17:52 | |
| *** rsblendido has quit IRC | 17:52 | |
| *** NehaV has quit IRC | 17:52 | |
| *** NehaV1 has joined #openstack-meeting-alt | 17:52 | |
| *** s3wong has quit IRC | 17:53 | |
| *** bob_nettleton has joined #openstack-meeting-alt | 17:55 | |
| *** Sukhdev has quit IRC | 17:55 | |
| *** aignatov has joined #openstack-meeting-alt | 17:55 | |
| *** aignatov has quit IRC | 17:55 | |
| *** aignatov has joined #openstack-meeting-alt | 17:57 | |
| *** jbrendel has quit IRC | 17:58 | |
| *** crobertsrh has joined #openstack-meeting-alt | 17:58 | |
| *** mattf has joined #openstack-meeting-alt | 17:58 | |
| *** bdpayne has joined #openstack-meeting-alt | 17:58 | |
| *** derekh has quit IRC | 17:58 | |
| *** marcol has quit IRC | 17:59 | |
| SergeyLukjanov | savanna team meeting will be here in 5 mins | 17:59 |
| *** 77CAAS3HQ has quit IRC | 17:59 | |
| *** colinmcnamara has quit IRC | 17:59 | |
| *** SumitNaiksatam has left #openstack-meeting-alt | 17:59 | |
| *** nati_ueno has joined #openstack-meeting-alt | 18:00 | |
| *** jmaron has joined #openstack-meeting-alt | 18:01 | |
| *** aignatov has quit IRC | 18:01 | |
| *** aignatov has joined #openstack-meeting-alt | 18:01 | |
| *** Dinny has quit IRC | 18:01 | |
| *** aignatov has quit IRC | 18:02 | |
| *** jmaron has quit IRC | 18:02 | |
| *** tmckay has joined #openstack-meeting-alt | 18:02 | |
| *** aignatov has joined #openstack-meeting-alt | 18:02 | |
| *** NikitaKonovalov has quit IRC | 18:03 | |
| *** jmaron has joined #openstack-meeting-alt | 18:03 | |
| *** hajay has joined #openstack-meeting-alt | 18:05 | |
| *** NikitaKonovalov has joined #openstack-meeting-alt | 18:05 | |
| *** karthik_ has quit IRC | 18:05 | |
| *** dmitryme has joined #openstack-meeting-alt | 18:06 | |
| *** ErikB has joined #openstack-meeting-alt | 18:07 | |
| SergeyLukjanov | savanan folks, are you around? | 18:08 |
| aignatov | o/ | 18:09 |
| tmckay | I'm here | 18:09 |
| SergeyLukjanov | HWX folks? | 18:09 |
| akuznetsov | Hi | 18:09 |
| ErikB | Hi | 18:10 |
| bob_nettleton | Hi | 18:10 |
| SergeyLukjanov | #startmeeting savanna | 18:10 |
| openstack | Meeting started Thu Dec 12 18:10:14 2013 UTC and is due to finish in 60 minutes. The chair is SergeyLukjanov. Information about MeetBot at http://wiki.debian.org/MeetBot. | 18:10 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 18:10 |
| *** openstack changes topic to " (Meeting topic: savanna)" | 18:10 | |
| openstack | The meeting name has been set to 'savanna' | 18:10 |
| SergeyLukjanov | #topic Agenda | 18:10 |
| *** ylobankov has joined #openstack-meeting-alt | 18:10 | |
| *** openstack changes topic to "Agenda (Meeting topic: savanna)" | 18:10 | |
| SergeyLukjanov | #link https://wiki.openstack.org/wiki/Meetings/SavannaAgenda#Next_meetings | 18:10 |
| SergeyLukjanov | #topic Action items from the last meeting | 18:10 |
| *** openstack changes topic to "Action items from the last meeting (Meeting topic: savanna)" | 18:10 | |
| SergeyLukjanov | both action items from the last meeting are on me and not yet fully completed | 18:10 |
| *** mozawa has joined #openstack-meeting-alt | 18:11 | |
| SergeyLukjanov | #action SergeyLukjanov to check that all blueprints created and ping guys to make them if not | 18:11 |
| SergeyLukjanov | #action SergeyLukjanov add links to the blueprints to roadmap | 18:11 |
| SergeyLukjanov | #topic News / updates | 18:11 |
| *** openstack changes topic to "News / updates (Meeting topic: savanna)" | 18:11 | |
| SergeyLukjanov | folks, please | 18:11 |
| *** hajay has left #openstack-meeting-alt | 18:11 | |
| SergeyLukjanov | we're completely moved our unit tests to be excecuted by testr | 18:12 |
| SergeyLukjanov | and working on integration tests | 18:12 |
| crobertsrh | I'm currently working on job relaunch from the UI. I'm getting close having something working. | 18:12 |
| mattf | i filed a cr for the foundation of the cli, i'd like lots of feedback before i add more to it - https://review.openstack.org/#/c/61565/ | 18:12 |
| tmckay | I am working on https://blueprints.launchpad.net/savanna/+spec/edp-oozie-java-action to add general jar jobs from oozie (as opposed to mapreduce jobs) | 18:12 |
| SergeyLukjanov | in addition I'm working on tempest tests | 18:12 |
| aignatov | I'm continue working on Heat integration patch, it is opened for review. | 18:12 |
| aignatov | So you are welcome | 18:12 |
| aignatov | basic functionality are implemented | 18:12 |
| SergeyLukjanov | mattf, adding an item about cli before the open discussion | 18:13 |
| aignatov | #link https://review.openstack.org/#/c/55978/ | 18:13 |
| SergeyLukjanov | dmitryme is working on the unified agents proposal | 18:13 |
| NikitaKonovalov | integration tests appeared to dependent on nose and are failing now | 18:13 |
| aignatov | dmitryme is here :) | 18:14 |
| aignatov | I saw him joined recently | 18:14 |
| SergeyLukjanov | NikitaKonovalov, that's because we're using nose.attr in tests, it should be replaced with testr analogue | 18:14 |
| NikitaKonovalov | so need to make some chages to get rid of nose in tests code | 18:14 |
| SergeyLukjanov | NikitaKonovalov, I'll take a look on it after the meeting | 18:14 |
| NikitaKonovalov | ok | 18:14 |
| SergeyLukjanov | any other updates? | 18:15 |
| jmaron | still working on rack awareness for hdp, but now detoured into making EDP work in neutron over private networks | 18:15 |
| ErikB | We have put together a script to install Savanna and are wondering if it makes sense to contribute? | 18:15 |
| ErikB | (Savanna UI and API) | 18:16 |
| mattf | ErikB, is it anything like the puppet module that is under review? | 18:16 |
| jmaron | haven't seen much work/progress on puppet module... | 18:16 |
| SergeyLukjanov | jmaron, great, but I have no ideas for now for the correct approach to solve your problem | 18:16 |
| ErikB | I haven't looked at the puppet piece, so not sure. | 18:16 |
| aignatov | ErikB, how is installation implemented? | 18:16 |
| ErikB | bash script | 18:16 |
| mattf | oh, i've one of those too | 18:17 |
| jmaron | trying to work around the need to build a fully functional remote interface during periodic tasks | 18:17 |
| mattf | i'm hoping to ditch it for the puppet modules | 18:17 |
| aignatov | ok, I think we may add somehing to savanna-extra repo | 18:17 |
| SergeyLukjanov | ErikB, the muppet manifests are under review atm | 18:17 |
| ErikB | OK, I will check it out. | 18:17 |
| SergeyLukjanov | ErikB, and I think it'll be merged soon | 18:17 |
| jmaron | muppet? I like it :) | 18:17 |
| SergeyLukjanov | ErikB, stackforge/puppet-savanna | 18:17 |
| mattf | ErikB, https://review.openstack.org/#/c/61156/ | 18:17 |
| SergeyLukjanov | jmaron, yup :) | 18:17 |
| mattf | SergeyLukjanov, probably today | 18:18 |
| SergeyLukjanov | mattf, my +2 in on it | 18:18 |
| mattf | it's on my queue | 18:18 |
| jmaron | (now we definitely need to create a puppet derivative called muppet) | 18:18 |
| SergeyLukjanov | jmaron, puppet fork called muppet ;) | 18:18 |
| mattf | jmaron, +1 | 18:19 |
| SergeyLukjanov | btw Jenkins was in a list of J release names ;) | 18:19 |
| aignatov | names for openstack? | 18:19 |
| dmitryme | aignatov: names for the release | 18:20 |
| SergeyLukjanov | yep | 18:20 |
| dmitryme | like Grizzly was for G | 18:20 |
| dmitryme | or Havana for H | 18:20 |
| mattf | https://wiki.openstack.org/wiki/Release_Naming | 18:20 |
| SergeyLukjanov | I'll propose Savanna for S release | 18:20 |
| *** mozawa has quit IRC | 18:20 | |
| *** jjmb has quit IRC | 18:20 | |
| dmitryme | :-) | 18:20 |
| mattf | SergeyLukjanov, i've people stumbling over savanna v gnu savannah already! | 18:21 |
| SergeyLukjanov | mattf, yep, I know | 18:21 |
| *** itzikb has quit IRC | 18:21 | |
| dmitryme | they actually have very strict naming convention - use names of places nearby Summit locaiton | 18:21 |
| SergeyLukjanov | dmitryme, maybe the S summit will be somewhere in savanna | 18:21 |
| ErikB | :-) | 18:22 |
| aignatov | but from Russian point of view it looks very good because Savanna is Саванна :) | 18:22 |
| alazarev | or in Savannah :) | 18:22 |
| *** mcohen2 has quit IRC | 18:22 | |
| SergeyLukjanov | funny report - http://stackalytics.com/report/users/slukjanov | 18:23 |
| SergeyLukjanov | ok, looks like there are no more updates | 18:23 |
| SergeyLukjanov | let's move on | 18:23 |
| *** mcohen2 has joined #openstack-meeting-alt | 18:23 | |
| SergeyLukjanov | #topic Roadmap update / cleanup | 18:23 |
| *** openstack changes topic to "Roadmap update / cleanup (Meeting topic: savanna)" | 18:23 | |
| SergeyLukjanov | no updates from the last meeting | 18:23 |
| SergeyLukjanov | action items are still on me | 18:24 |
| SergeyLukjanov | I hope that I do it thos week | 18:24 |
| mattf | SergeyLukjanov, i think that graphic suggests you need a vacation | 18:24 |
| SergeyLukjanov | mattf, planning 2w vacation from end of Dec | 18:24 |
| *** crobertsrh has quit IRC | 18:25 | |
| aignatov | on the next week? | 18:25 |
| aignatov | from | 18:25 |
| alazarev | SergeyLukjanov: this is not vacation, this is just russian holidays, aren't they? | 18:25 |
| SergeyLukjanov | alazarev, yup, but I'm extending it to be full 2w | 18:26 |
| SergeyLukjanov | #topic savanna client cli | 18:26 |
| *** openstack changes topic to "savanna client cli (Meeting topic: savanna)" | 18:26 | |
| SergeyLukjanov | mattf, please, could you please amke a small intro | 18:26 |
| SergeyLukjanov | make* | 18:26 |
| mattf | sure, there's nearly a savanna cli | 18:27 |
| mattf | https://blueprints.launchpad.net/python-savannaclient/+spec/python-savannaclient-cli | 18:27 |
| mattf | initial commit is https://review.openstack.org/#/c/61565/ | 18:27 |
| mattf | the foundation is based on novaclient, with minimal changes | 18:27 |
| mattf | i'd appreciate feedback both on the blueprint (incomplete) and especially on the initial commit. | 18:27 |
| mattf | i don't want to go too far into the cli impl if we aren't agreed on the basics | 18:28 |
| mattf | . | 18:28 |
| SergeyLukjanov | I don't really like it looks like in nova client... have you tried to diff into the some other clients? | 18:28 |
| aignatov | mattf, my first comment - please remove all unused commented code ;) | 18:28 |
| mattf | will you quantify "don't really like it looks like"? | 18:29 |
| SergeyLukjanov | to clarify - mattf, I really appreciate your work on it | 18:29 |
| mattf | aignatov, so i'm purposely keeping that code so we have an idea of how far we've drifted from nova | 18:29 |
| SergeyLukjanov | mattf, I've seen into the neutron client, it looks more object oriented | 18:29 |
| SergeyLukjanov | mattf and testable/supportable | 18:29 |
| SergeyLukjanov | mattf, but of course, a lot of lines of code | 18:30 |
| jmaron | the nova comparison is with regard to command options, code structure, or both? | 18:30 |
| jmaron | command option syntax | 18:30 |
| mattf | SergeyLukjanov, i didn't dig into the neutron code. the keystone folks wanted me to use theirs, but it was only a partial implementation. | 18:30 |
| SergeyLukjanov | and there is a common client in oslo, I don't actually know which projects are using it | 18:30 |
| mattf | SergeyLukjanov, seemed like none | 18:31 |
| SergeyLukjanov | SergeyLukjanov, yep | 18:31 |
| SergeyLukjanov | oh | 18:31 |
| SergeyLukjanov | SergeyLukjanov, how are you? | 18:31 |
| SergeyLukjanov | SergeyLukjanov, fine, thx | 18:31 |
| tmckay | :) | 18:31 |
| mattf | jmaron, code structure. many OS CLIs are based on novaclient. so when they ahve to migrate to something shared, we'll be close to whatever migration path is created. | 18:31 |
| jmaron | mattf, thx | 18:31 |
| mattf | SergeyLukjanov, vacation, definitely vacation | 18:32 |
| SergeyLukjanov | mattf, :) | 18:32 |
| SergeyLukjanov | mattf, in two words I really like to have a cli in our client | 18:32 |
| mattf | SergeyLukjanov, does neutron already have a test harness for their cli? | 18:32 |
| SergeyLukjanov | mattf, I'm not sire | 18:32 |
| SergeyLukjanov | sure* | 18:32 |
| mattf | that'd be a nice reason to jump to another foundation | 18:33 |
| *** crobertsrh has joined #openstack-meeting-alt | 18:33 | |
| SergeyLukjanov | there tons of tests here | 18:33 |
| SergeyLukjanov | https://github.com/openstack/python-neutronclient/tree/master/neutronclient/tests/unit | 18:33 |
| mattf | basically, i'm very happy to steal from other clients for the framing. i'm really just interested in adding savanna specific walls and furniture | 18:33 |
| aignatov | mattf, did you look at heat client, it looks nice and simple | 18:34 |
| aignatov | and contains shell tests :) | 18:34 |
| aignatov | https://github.com/openstack/python-heatclient | 18:34 |
| SergeyLukjanov | mattf, it'll be great if you take a look on 'new' clients | 18:34 |
| mattf | aignatov, i did, the main reason to go w/ nova is migration path | 18:34 |
| mattf | the keystone folks are trying to create a standard client, with security done right | 18:35 |
| mattf | but it's not done | 18:35 |
| SergeyLukjanov | mattf, :( | 18:35 |
| mattf | i imagine that and others will eventually migrate to something in oslo, but it doesn't exist right now | 18:35 |
| mattf | and my aim is to make a savanna cli, not a framework for creating clis | 18:36 |
| *** sarob has joined #openstack-meeting-alt | 18:36 | |
| aignatov | maybe we should create new initiative in OpenStack, CLI as a service ;) | 18:36 |
| mattf | sounds like folks would like me to take a second look at heat and neutron? | 18:36 |
| mattf | aignatov, indeed, you can be ptl | 18:36 |
| mattf | when you have something that works, i'll migrate to it | 18:36 |
| * mattf grins | 18:36 | |
| SergeyLukjanov | aignatov, CLIaaS | 18:37 |
| aignatov | mattf, lol | 18:37 |
| *** NehaV has joined #openstack-meeting-alt | 18:37 | |
| jmaron | without the 'I' would be classier... | 18:37 |
| SergeyLukjanov | jmaron, nice) | 18:37 |
| *** clayb has left #openstack-meeting-alt | 18:37 | |
| mattf | SergeyLukjanov, oh wait | 18:37 |
| SergeyLukjanov | mattf, I'm here, don't worry :) | 18:38 |
| mattf | i remember neutronclient now. instead of having a module system then just do it all in a single shell.py | 18:38 |
| mattf | (forgive me, i reviewed most of the clients back around summit time) | 18:38 |
| mattf | i wasn't too interested in that structure, especially since we'll have to have multiple api versions | 18:39 |
| mattf | we arguably already have 1.0 and 1.1, soon also 2.0 | 18:39 |
| mattf | though we've stuck them together in a single "api" module | 18:39 |
| SergeyLukjanov | mattf, it looks like neutronclient have a file/class per each operation | 18:40 |
| *** NehaV1 has quit IRC | 18:40 | |
| mattf | SergeyLukjanov, so that and the fact no one else i could see was using neutron is why i backed away from it | 18:40 |
| SergeyLukjanov | https://github.com/openstack/python-neutronclient/blob/master/neutronclient/neutron/v2_0/network.py#L114 | 18:40 |
| SergeyLukjanov | mattf :) | 18:40 |
| mattf | SergeyLukjanov, the way they pull it together isn't as flexible as the api version approach | 18:40 |
| SergeyLukjanov | mattf, btw I'm just trying to cover all approaches | 18:41 |
| SergeyLukjanov | mattf, nova client isn't bad approach by default | 18:41 |
| SergeyLukjanov | so if we do something not too bad, it'll be enough to understand what is bad and migrate earlier | 18:42 |
| mattf | aignatov, heatclient is definitely simpler than novaclient. it actually duplicates some of the functionality we provide in our Client() too | 18:42 |
| *** yogesh has joined #openstack-meeting-alt | 18:42 | |
| mattf | SergeyLukjanov, i'm happy for the line of questioning, keeps decisions open and well reasoned | 18:42 |
| mattf | (or at least partially reasoned) | 18:43 |
| mattf | in the end, the impl is pretty simple. there's a shell.py in savannaclient that loads other shell.py from variable api version modules. the api version shell.py implements do_blah() methods that are the cli verbs | 18:43 |
| mattf | so we have savannaclient/shell.py and savannaclient/api/shell.py | 18:44 |
| mattf | the outer one also parses the auth information and creates the Client() for use w/i the do_ methods | 18:44 |
| aignatov | mattf, I'd like this approach | 18:45 |
| mattf | aignatov, how strongly do you feel about heat, because we can debate it some more after the meeting | 18:45 |
| aignatov | mattf, i've just had a quick look during this meeting | 18:45 |
| *** shivh has quit IRC | 18:45 | |
| SergeyLukjanov | mattf, I'll agree with something that'll work ok :) | 18:45 |
| jmaron | curious: do we see a need for savanna-manage client, crossing tenant boundaries for management tasks across cluster instances? | 18:46 |
| *** luQAs has quit IRC | 18:46 | |
| SergeyLukjanov | jmaron, I think it'll be eventually done by using admin role | 18:46 |
| *** nati_uen_ has joined #openstack-meeting-alt | 18:46 | |
| aignatov | and I've compared heatclient and novaclient code in your patch and make a opinion :) | 18:46 |
| mattf | jmaron, the client allows you to change the tenant you're working against via env or arg | 18:47 |
| *** eankutse has quit IRC | 18:47 | |
| mattf | aignatov, you'll render an opinion into the review today? | 18:47 |
| jmaron | understood. Just thought an admin may want to get a full picture rather than iterate across tenants | 18:47 |
| mattf | jmaron, ahhh, that's an interesting idea | 18:48 |
| mattf | i don't think the current api allows that very easily | 18:48 |
| jmaron | true | 18:48 |
| aignatov | mattf, I'll try | 18:48 |
| dmitryme | As for the UI, there is an Admin tab here which allows browsing resources regardless of tenant | 18:49 |
| dmitryme | it might be worth checking how it works | 18:49 |
| *** nati_ueno has quit IRC | 18:49 | |
| mattf | ok, take the rest of this to the review / #savanna ? | 18:49 |
| SergeyLukjanov | jmaron, mattf, current API doesn't allow to do it, but I think that we should add it to v2 | 18:49 |
| jmaron | +1 | 18:49 |
| SergeyLukjanov | looks like a time for open discussion | 18:49 |
| SergeyLukjanov | #topic Open Discussion | 18:49 |
| *** openstack changes topic to "Open Discussion (Meeting topic: savanna)" | 18:49 | |
| tmckay | edp question, we can follow up on #savanna. With the addition of java actions to oozie support, I think we need a name change for job types. Currently we have Hive, Pig, and JAR. | 18:50 |
| tmckay | I think we need Hive, Pig, Mapreduce, and ?? | 18:50 |
| tmckay | Because current JAR really means "mapreduce" | 18:51 |
| *** _ozstacker_ has joined #openstack-meeting-alt | 18:51 | |
| *** ozstacker has quit IRC | 18:51 | |
| tmckay | it will be a different workflow generator, arguments allowed, ect | 18:51 |
| akuznetsov | tmckay JavaAction? | 18:51 |
| dmitryme | tmckay: and what does added java action do? | 18:51 |
| akuznetsov | possible we should add a oozie workflow | 18:52 |
| tmckay | Java actions allow Oozie to run a main(), instead of building a mapreduce job out of the specified mapper and reducer classes | 18:52 |
| dmitryme | aha, I see | 18:52 |
| tmckay | so, the hadoop example pi estimator is a java action | 18:52 |
| tmckay | It can't be run as mapreduce directly without a rewrite | 18:52 |
| dmitryme | indeed it is hard to set a different names | 18:53 |
| tmckay | java action launches a single mapper, which runs main(), which typically launches other mappers and reducers | 18:53 |
| jmaron | I see a HelloWorld example coming down the pipe…. | 18:53 |
| aignatov | tmckay, just Java, but JAR should be renamed to MapReduce defenitely | 18:53 |
| tmckay | Yes, that was my thought.... Hive, Pig, MapReduce, and Java | 18:54 |
| dmitryme | aignatov: makes sense | 18:54 |
| SergeyLukjanov | are there any job types in Oozie? | 18:54 |
| tmckay | that will cause changes in the UI, docs, etc... | 18:54 |
| SergeyLukjanov | we can use them if yes | 18:54 |
| tmckay | I think just the action names | 18:54 |
| *** nati_uen_ has quit IRC | 18:54 | |
| SergeyLukjanov | yep, but looks like we really need i | 18:54 |
| tmckay | oh, agreed, just making a note :) | 18:54 |
| SergeyLukjanov | Hive, Pig, MapReduce, and Java works for me | 18:55 |
| SergeyLukjanov | tmckay :) | 18:55 |
| *** nati_ueno has joined #openstack-meeting-alt | 18:55 | |
| *** eankutse has joined #openstack-meeting-alt | 18:55 | |
| tmckay | crobertsrh, this means you too ^^ :) | 18:55 |
| aignatov | agreed with akusnetsov, Oozie workflow should be supported as well :) but didm;t know how it works :) :) | 18:55 |
| tmckay | akuznetsov, yes, we should add oozie workflow from user too | 18:56 |
| tmckay | first, java. Then, oozie. | 18:56 |
| tmckay | Christmas present for me, heh | 18:56 |
| SergeyLukjanov | and it'll be great to be ablt to configure oozie to take jobs from swift | 18:56 |
| aignatov | Btw, MapReduce action has sub actions streaming and pipe | 18:56 |
| tmckay | yes, also on the roadmap I think | 18:56 |
| akuznetsov | yes oozie is most complicated because it should involve all types of job pig, hive jar etc... | 18:57 |
| aignatov | also, tmckay, you know that right now EDP uses oozie-workflow schema 0.2, but we have 4.0.0 ooze in images which allows to run on schema 0.4 and greater | 18:57 |
| akuznetsov | streaming and pipe will be required some image preparation if for example pipes will use a some specific python | 18:58 |
| aignatov | which Oozie is used in HWX plugin? | 18:58 |
| tmckay | aignatov, didn't know that. Should we switch the schema to 0.4? | 18:58 |
| jmaron | aignatov, not sure about version number. whatever is distributed with HDP 1.3.2 | 18:59 |
| SergeyLukjanov | we're out of time guys, 1 min left | 18:59 |
| tmckay | any need to support both, with a config? | 18:59 |
| aignatov | tmckay: If it have new features allowing you to create workflows in simple manner, why not? :) | 18:59 |
| jmaron | quick note: I've run into an issue with periodic tasks requiring access to a full context (specifically, the service catalog etc). Trying to work around it, but it makes me think there may be a need for defining "privileged" periodic tasks or allowing such access to existing periodic tasks? Will ruminate some more, may send email out to list at some point…. | 18:59 |
| mattf | jmaron, yikes | 19:00 |
| SergeyLukjanov | jmaron, it's needed to query neutron, yes/ | 19:00 |
| aignatov | I only know that 0.3 or 0.4 Oozie version contains <global> tag which allow to apply job tracker and name node definitions in a single place | 19:00 |
| SergeyLukjanov | ? | 19:00 |
| SergeyLukjanov | thank you all! | 19:00 |
| SergeyLukjanov | #endmeeting | 19:00 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 19:00 | |
| openstack | Meeting ended Thu Dec 12 19:00:18 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 19:00 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-12-12-18.10.html | 19:00 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-12-12-18.10.txt | 19:00 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-12-12-18.10.log.html | 19:00 |
| SergeyLukjanov | let's move to the #savanna | 19:00 |
| jmaron | SergeyLukjanov, yes | 19:00 |
| *** bob_nettleton has left #openstack-meeting-alt | 19:01 | |
| *** jbrendel has joined #openstack-meeting-alt | 19:01 | |
| *** mattf has left #openstack-meeting-alt | 19:01 | |
| *** NehaV1 has joined #openstack-meeting-alt | 19:03 | |
| *** tmckay has quit IRC | 19:04 | |
| *** NehaV has quit IRC | 19:06 | |
| *** lblanchard has quit IRC | 19:07 | |
| *** k4n0 has joined #openstack-meeting-alt | 19:08 | |
| *** jbrendel has quit IRC | 19:11 | |
| *** NikitaKonovalov has quit IRC | 19:12 | |
| *** jbrendel has joined #openstack-meeting-alt | 19:13 | |
| *** NikitaKonovalov has joined #openstack-meeting-alt | 19:14 | |
| *** jbrendel has quit IRC | 19:15 | |
| *** NikitaKonovalov has quit IRC | 19:15 | |
| *** crobertsrh has quit IRC | 19:29 | |
| *** vipul is now known as vipul-away | 19:30 | |
| *** NehaV1 has quit IRC | 19:31 | |
| *** NehaV has joined #openstack-meeting-alt | 19:31 | |
| *** jmaron has quit IRC | 19:33 | |
| *** brents has quit IRC | 19:35 | |
| *** electrichead has joined #openstack-meeting-alt | 19:35 | |
| *** gokrokve has joined #openstack-meeting-alt | 19:40 | |
| *** SergeyLukjanov_ has joined #openstack-meeting-alt | 19:40 | |
| *** reaperhulk has joined #openstack-meeting-alt | 19:42 | |
| *** SushilKM__ has joined #openstack-meeting-alt | 19:43 | |
| *** lblanchard has joined #openstack-meeting-alt | 19:44 | |
| *** hemanthravi has joined #openstack-meeting-alt | 19:44 | |
| *** vipul-away is now known as vipul | 19:44 | |
| *** brents has joined #openstack-meeting-alt | 19:45 | |
| *** SushilKM has quit IRC | 19:46 | |
| *** SergeyLukjanov has quit IRC | 19:46 | |
| *** SergeyLukjanov_ is now known as SergeyLukjanov | 19:46 | |
| *** SergeyLukjanov_ has joined #openstack-meeting-alt | 19:47 | |
| *** SergeyLukjanov has quit IRC | 19:47 | |
| *** SergeyLukjanov_ has quit IRC | 19:48 | |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 19:48 | |
| *** akuznetsov has quit IRC | 19:49 | |
| *** zhiyan has joined #openstack-meeting-alt | 19:50 | |
| *** hockeynut has joined #openstack-meeting-alt | 19:55 | |
| *** ativelkov has joined #openstack-meeting-alt | 19:56 | |
| *** igormarnat has joined #openstack-meeting-alt | 19:56 | |
| *** Barker has quit IRC | 19:57 | |
| jraim | #startmeeting barbican | 19:58 |
| openstack | Meeting started Thu Dec 12 19:58:36 2013 UTC and is due to finish in 60 minutes. The chair is jraim. Information about MeetBot at http://wiki.debian.org/MeetBot. | 19:58 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 19:58 |
| *** openstack changes topic to " (Meeting topic: barbican)" | 19:58 | |
| openstack | The meeting name has been set to 'barbican' | 19:58 |
| jraim | #topic incubation tasks | 19:58 |
| *** openstack changes topic to "incubation tasks (Meeting topic: barbican)" | 19:58 | |
| *** jprovazn has quit IRC | 19:58 | |
| *** woodster has joined #openstack-meeting-alt | 19:58 | |
| jraim | alright, who is here for the barbican meeting. Raise the hands | 19:59 |
| jraim | o/ | 19:59 |
| electrichead | o/ | 19:59 |
| reaperhulk | \o/ | 19:59 |
| woodster | \o/ | 19:59 |
| jraim | #agreed reaperhulk is excited to be here | 19:59 |
| *** Weihan has joined #openstack-meeting-alt | 19:59 | |
| reaperhulk | When am I not | 19:59 |
| SheenaG | \o/ | 19:59 |
| hockeynut | present and accounted for | 19:59 |
| jraim | anyone else? | 20:00 |
| jraim | alright, it'll be a short one then | 20:00 |
| *** Barker has joined #openstack-meeting-alt | 20:00 | |
| jraim | let's run down the list on incubation tasks | 20:00 |
| jraim | so python-barbicanclient is in stackforge now, correct? Any more to do on that one? | 20:01 |
| markwash | seems like we maybe have a meeting timeslot conflict? | 20:01 |
| *** arnaud has joined #openstack-meeting-alt | 20:01 | |
| jraim | markwash do we? | 20:01 |
| reaperhulk | uhoh :o | 20:01 |
| jvrbanac | o/ | 20:01 |
| markwash | I could be mistaken, I'm very distracted | 20:01 |
| jraim | I've got us here: https://wiki.openstack.org/wiki/Meetings#Barbican_Meeting | 20:01 |
| *** spredzy has joined #openstack-meeting-alt | 20:01 | |
| markwash | well, its' a wiki, so | 20:01 |
| electrichead | #info yes, python-barbicanclient is in StackForge and also in Launchpad. All development will be done there moving forward | 20:01 |
| jraim | which meeting were you looking for? | 20:01 |
| *** spredzy has quit IRC | 20:02 | |
| markwash | https://wiki.openstack.org/wiki/Meetings#Glance_Team_meeting | 20:02 |
| markwash | 1400 and 2000 UTC thursdays alternating | 20:02 |
| markwash | today's a 2000 UTC day | 20:02 |
| electrichead | looks like glance has the spot every other week :-\ | 20:02 |
| *** stanlagun has joined #openstack-meeting-alt | 20:02 | |
| *** at872kd has joined #openstack-meeting-alt | 20:03 | |
| jraim | weird. it wasn't on the calender thing I downloaded | 20:03 |
| jraim | no problem | 20:03 |
| jraim | I'll close this and we'll reschedule ours | 20:03 |
| jraim | #info Jarret sucks at meetings, story at 11 | 20:03 |
| markwash | sorry for the confusion! | 20:03 |
| jraim | #endmeeting | 20:03 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 20:03 | |
| openstack | Meeting ended Thu Dec 12 20:03:28 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 20:03 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/barbican/2013/barbican.2013-12-12-19.58.html | 20:03 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/barbican/2013/barbican.2013-12-12-19.58.txt | 20:03 |
| zhiyan | thanks jraim | 20:03 |
| jraim | no problem, my fault | 20:03 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/barbican/2013/barbican.2013-12-12-19.58.log.html | 20:03 |
| markwash | jraim: thanks for being so accomodating! | 20:03 |
| markwash | #startmeeting glance | 20:03 |
| openstack | Meeting started Thu Dec 12 20:03:52 2013 UTC and is due to finish in 60 minutes. The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot. | 20:03 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 20:03 |
| *** openstack changes topic to " (Meeting topic: glance)" | 20:03 | |
| openstack | The meeting name has been set to 'glance' | 20:03 |
| markwash | hi glance folks | 20:03 |
| nikhil__ | o/ | 20:04 |
| arnaud | Hi markwash | 20:04 |
| *** hockeynut has left #openstack-meeting-alt | 20:04 | |
| *** at872kd has quit IRC | 20:04 | |
| ameade | hola | 20:04 |
| *** electrichead has left #openstack-meeting-alt | 20:04 | |
| hemanth_ | o/ | 20:04 |
| zhiyan | hi | 20:04 |
| stanlagun | hi | 20:04 |
| *** reaperhulk has left #openstack-meeting-alt | 20:04 | |
| markwash | so folks I've been a bit absent this week, stuff at work and kitty health issues | 20:04 |
| gokrokve | Hi | 20:04 |
| *** jasonb365 has quit IRC | 20:04 | |
| ativelkov | hi | 20:04 |
| *** ashwini has joined #openstack-meeting-alt | 20:04 | |
| markwash | so i really appreciate whoever added stuff to the agenda | 20:04 |
| *** woodster has left #openstack-meeting-alt | 20:05 | |
| markwash | #link https://etherpad.openstack.org/p/glance-team-meeting-agenda | 20:05 |
| *** SheenaG has left #openstack-meeting-alt | 20:05 | |
| markwash | looks like we have some new folks | 20:05 |
| igormarnat | Hi guys! (looking around) is this a glance meeting? | 20:05 |
| arnaud | yes this is | 20:05 |
| markwash | I suspect that is because of the exciting ML threads about glance and scope expansion | 20:05 |
| * markwash looks for links | 20:05 | |
| *** spredzy has joined #openstack-meeting-alt | 20:05 | |
| markwash | #link http://lists.openstack.org/pipermail/openstack-dev/2013-December/021233.html | 20:06 |
| markwash | I propose we start off with some discussion of this | 20:06 |
| markwash | #topic glance and heatr | 20:06 |
| *** openstack changes topic to "glance and heatr (Meeting topic: glance)" | 20:06 | |
| *** spredzy has quit IRC | 20:07 | |
| markwash | for those that aren't familiar, i suggest that you review the email link I posted | 20:07 |
| *** SlickNik has left #openstack-meeting-alt | 20:07 | |
| markwash | but the basic idea is to expand the idea of glance to store things like heat templates, IIUC | 20:07 |
| *** IlyaE has joined #openstack-meeting-alt | 20:07 | |
| rosmaita | i am not opposed to expanding what glance contains, subject to keeping its basic philosophy intact (eg., immutable objects) | 20:07 |
| *** markmcclain has joined #openstack-meeting-alt | 20:07 | |
| *** tsufiev_ has joined #openstack-meeting-alt | 20:07 | |
| markwash | I guess there are some heatr folks here, care to intrroduce yourselves? | 20:08 |
| *** denis_makogon_ has joined #openstack-meeting-alt | 20:08 | |
| ameade | i support a more general catalog service | 20:08 |
| gokrokve | markwash: Hi, I am Georgy Okrokvertskhov form Mirantis | 20:08 |
| gokrokve | We are not from Heater team at all :-) | 20:08 |
| zhiyan | yes, it catalog-generalization to me | 20:08 |
| zhiyan | hello gokrokve | 20:09 |
| igormarnat | Hey guys, I'm Igor Marnat from Murano team (Mirantis) | 20:09 |
| gokrokve | Hi zhiyan | 20:09 |
| ativelkov | Hi, I am Alexander Tivelkov, Murano team | 20:09 |
| markwash | oh I see | 20:09 |
| stanlagun | I'm Stan Lagun - Murano & Mistral | 20:09 |
| markwash | sorry, I was confused, Hi Murano folks | 20:09 |
| nikhil__ | hey folks | 20:09 |
| *** akuznetsov has joined #openstack-meeting-alt | 20:09 | |
| markwash | so, can you bring us up to speed on how Murano might fit into this integration? | 20:09 |
| ativelkov | Murano is not HeatR, but we are really interested in general-purpose metadata repository | 20:10 |
| gokrokve | Murano needs catalog for the same purpose, to store different objects | 20:10 |
| stanlagun | Murano is among those projects that have templates that can be stored in Glance | 20:10 |
| *** denis_makogon has quit IRC | 20:10 | |
| *** denis_makogon_ is now known as denis_makogon | 20:10 | |
| gokrokve | not only templates but scripts, UI definitions and workflows | 20:11 |
| ativelkov | We manipulate complex metadata packages, and we need to store them per-tenantly, index them, add tags, versions, authorships etc - in an immutable form, of course | 20:11 |
| *** dmakogon_ has joined #openstack-meeting-alt | 20:11 | |
| gokrokve | We have an implementation of such catalog\repository in Murano | 20:11 |
| markwash | okay, there might be a little impedance mismatch but I think it doesn't sound like there would be any big problems | 20:11 |
| *** k4n0 has left #openstack-meeting-alt | 20:11 | |
| gokrokve | But Heater revealed that other projects also need repository | 20:11 |
| markwash | the one thing that's a little bit differnt in glance is that some of our metadata is mutable | 20:12 |
| igormarnat | And let's not miss the fact that Solum would also benefit from having the general metadata repo | 20:12 |
| markwash | and some of our metadata is semantically significant to Glance | 20:12 |
| markwash | so, not true metadata really | 20:12 |
| markwash | e.g. you can download images through glance | 20:12 |
| stanlagun | and Mistral too | 20:13 |
| markwash | and it will perform checksum verifications against the checksum attribute of the image | 20:13 |
| *** vipul is now known as vipul-away | 20:13 | |
| zhiyan | markwash: i think what gokrokve thinking is saving those files as our image entry | 20:13 |
| gokrokve | markwash: We need this too | 20:13 |
| *** vipul-away is now known as vipul | 20:13 | |
| markwash | gokrokve: ah okay | 20:13 |
| gokrokve | zhiyan: Kind of. At least in the first implementation. | 20:13 |
| ativelkov | Glance user is not able to modify an Image without changing ints id, right? | 20:14 |
| zhiyan | markwash: and also need a container... iirc, service metadata | 20:14 |
| markwash | ativelkov: it cannot modify the image data, it can modify metadata | 20:14 |
| markwash | *some metadata | 20:14 |
| ativelkov | its perfectly fine for us | 20:14 |
| ameade | markwash: i think if we want to pick this as a solid direction for glance it would make sense, we could start talking about a v3...of course there are more immediate needs we could jam into v2 | 20:14 |
| *** jcoufal has joined #openstack-meeting-alt | 20:14 | |
| ativelkov | Like, add tags, change description etc - right? | 20:15 |
| markwash | so what's our plan of attack? is there any sort of proposal already on the table? | 20:15 |
| gokrokve | markwash: We want to start submit BPs for new features required for genereic catalog | 20:15 |
| markwash | ativelkov: yeah stuff like that | 20:15 |
| stanlagun | I believe what is missing is a reach queriable metadata for all glance object that would allow implementing of catalogization - arranging object into hierarchies, groups etc. based on different criterias | 20:15 |
| gokrokve | markwash: We want to make sure that this is not a surprise for you :-) | 20:15 |
| markwash | heh sensible | 20:15 |
| markwash | ameade: you bring up a good point | 20:16 |
| gokrokve | markwash: Do you see a possibility to start this work in Icehouse? | 20:16 |
| markwash | would it make sense to do this stuff somewhat separtely as part of v2.x? | 20:16 |
| markwash | and try to munge the traditional view of images and these other aspects together in a v3 after Icehouse? | 20:16 |
| *** jmaron has joined #openstack-meeting-alt | 20:17 | |
| nikhil__ | markwash: +1 on that | 20:17 |
| ativelkov | this sounds reasonable | 20:17 |
| gokrokve | markwash: We need this catalog to develop Murano, and Heat probably will be interested as well as they need this for HOT Software components | 20:17 |
| nikhil__ | I kinda understand the complexity of adding stuff in domain layer so would recommed post I | 20:17 |
| markwash | gokrokve: okay cool. . so we shoudl jsut be on the lookout for some blueprints soon? | 20:18 |
| iccha | the domain model should be a separate convo we should def discuss about :) | 20:19 |
| markwash | gokrokve: to answer your question about Icehouse, its a bit scary but I think if we understand the bps well enough we might ahve some hopes | 20:19 |
| *** wyllys_ has joined #openstack-meeting-alt | 20:19 | |
| ashwini | markwash: i kind of sense an agenda forming here for glance mini summit :) | 20:19 |
| zhiyan | gokrokve: is there a clear api definition for the metadata repo now? | 20:19 |
| stanlagun | Are HeatEr guys ok with this? So that there will not be 10 different private repository implementations by Icehouse release | 20:19 |
| ativelkov | I'll have a wiki-page with overall description of what we propose at about tomorrow | 20:19 |
| markwash | gokrokve: I think it may be possible to consider some slightly drastic options to make sure we can make progress | 20:19 |
| gokrokve | zhiyan: There is no final API defined yet. | 20:19 |
| markwash | gokrokve: for example, we could start out in a separate project under the same Glance program | 20:19 |
| ativelkov | Then we will make more detailed blueprints on a per-feature basis | 20:20 |
| iccha | markwash: do u mean, /templates like /images? | 20:20 |
| gokrokve | markwash: We can do this as a separate project. You are right. But are you ok to handle two projects. | 20:20 |
| esheffield | I'm a bit concerned about adding specific code for the different objects that might be stored | 20:21 |
| markwash | iccha: that's one option, but just now I was saying something more like github.com/openstack/glance-template-api.git | 20:21 |
| nikhil__ | markwash: iccha ameade also, more modular sqlaclchemy impl before adding this :) | 20:21 |
| zhiyan | gokrokve: from you old wiki, i can see a very draft define for poc, so i think if there has a clear define, i think it will be good to see the different for common metadata entry and image | 20:21 |
| esheffield | could we think along the lines of a general metadata service with specific schemas defining the object types | 20:21 |
| markwash | gokrokve: handling two projects is a bit of a burden but it might still be an okay option | 20:21 |
| iccha | i see nikhil__ 's concern about strengthing what we currently have | 20:21 |
| gokrokve | zhiyan: Sure. We need Heater guys to contribute too. | 20:21 |
| ameade | esheffield: that makes a lot of sense | 20:21 |
| *** eankutse has quit IRC | 20:21 | |
| ameade | markwash: i'm not opposed to this evolving into maybe a glance replacement project either | 20:22 |
| nikhil__ | esheffield: ameade +1 with a the option of drawing the line of cutomizations upfront | 20:22 |
| rosmaita | esheffield: +1 | 20:22 |
| iccha | +1 | 20:22 |
| markwash | ameade: +1 | 20:22 |
| gokrokve | markwash: Can we discuss a separate project in ML? We will need input from TC on that too. | 20:22 |
| markwash | gokrokve: absolutely | 20:22 |
| nikhil__ | too much customization will slow this down | 20:22 |
| markwash | gokrokve: I think we need a lot of clarity on the final api featureset though to talk about this intelligently | 20:23 |
| markwash | gokrokve: right now I don't know anywhere near enough to know which option would be best | 20:23 |
| gokrokve | markwash: Sure. I know that Randall is working on Heater BPs for Glance too. So we can sync up with him, to speed up the API discussion | 20:24 |
| ameade | there is much discussion to be had, especially about specific use cases...i think additional meetings are in order...or during the glance meetup | 20:24 |
| nikhil__ | +1 | 20:24 |
| gokrokve | ameade: I would rather use separate meeting. | 20:24 |
| nikhil__ | was this just related to Murano or was there anything about Mistral too? | 20:25 |
| markwash | ameade: +1 definitely need additional discussion. gokrokve not sure if any interested folks from your side could manage a physical meetup? or if we should just schedule some separate IRC time | 20:25 |
| gokrokve | ameade: Otherwise we will consume whole glance meeting time. | 20:25 |
| *** Weihan has left #openstack-meeting-alt | 20:25 | |
| markwash | gokrokve: yeah I think we'll wind this topic down for today here in a moment, just want to figure out the major next steps | 20:25 |
| gokrokve | Face 2 face will be very effective + some guys remote via hangout | 20:25 |
| stanlagun | Mistral would also probably need some repository in the future. Nothing specific for now | 20:25 |
| nikhil__ | gotcha | 20:26 |
| gokrokve | We did this in Solum and it was efficient. | 20:26 |
| markwash | gokrokve: so there is a glance meetup in the works for late january near Washington DC. . not sure if that could possibly work? | 20:26 |
| ameade | markwash, gokrokve: i'm definitely interested in staying heavily in the loop on this | 20:26 |
| arnaud | same here | 20:26 |
| *** tsufiev_ has quit IRC | 20:26 | |
| *** eankutse has joined #openstack-meeting-alt | 20:26 | |
| gokrokve | markwash: Should work fine. We can have first meetings in IRC\ hangout and then f2f meeting for final decisions. | 20:27 |
| markwash | ashwini: yeah we might want more than 2 days if this does become part of the summit | 20:27 |
| markwash | gokrokve: okay, when should we meet again? | 20:27 |
| markwash | on irc | 20:27 |
| *** wyllys_ has left #openstack-meeting-alt | 20:27 | |
| gokrokve | markwash: Lets meet on next week, say Tuesday | 20:28 |
| ameade | +1 | 20:28 |
| arnaud | +1 | 20:28 |
| *** vipul is now known as vipul-away | 20:28 | |
| gokrokve | markwash: We will submit some BPs and create etherpads with drafts | 20:28 |
| ashwini | markwash: yes we should have a more confirmed agenda for the mini summit to see how much time can be allocated to this discussion or we should consider 3 day options | 20:28 |
| markwash | gokrokve: okay sounds good | 20:29 |
| gokrokve | markwash: Also Heater team will have time to prepare | 20:29 |
| markwash | gokrokve: so we should look for an invite on the openstack-dev ML? | 20:29 |
| *** colinmcnamara has joined #openstack-meeting-alt | 20:29 | |
| *** colinmcn_ has joined #openstack-meeting-alt | 20:29 | |
| gokrokve | markwash: During next meeting we can also discuss how to do development \ separate project vs. branch | 20:29 |
| gokrokve | markwash: Sure. I will organize that. | 20:30 |
| *** yogesh has quit IRC | 20:30 | |
| markwash | great, thanks! | 20:30 |
| markwash | any other quick thoughts from folks? or should we move on? | 20:30 |
| gokrokve | Nothing from our side :-) | 20:31 |
| markwash | thanks for showing up | 20:31 |
| markwash | this is pretty exciting | 20:31 |
| markwash | #topic common version-agnostic api in glanceclient | 20:31 |
| *** openstack changes topic to "common version-agnostic api in glanceclient (Meeting topic: glance)" | 20:31 | |
| esheffield | that was mine | 20:32 |
| *** krtaylor has quit IRC | 20:32 | |
| markwash | esheffield: go for it | 20:32 |
| markwash | #link https://etherpad.openstack.org/p/glance-client-common-api | 20:32 |
| esheffield | basically wanted to get some more discussion on the idea of something like the image service layer being added to glanceclient | 20:32 |
| esheffield | recall that Ghe had a patch doing some initial work in that direction a while back | 20:33 |
| markwash | is anybody against the idea, assuming we can work out the details of what the api should look liike? | 20:33 |
| esheffield | this is all tied to supporting V2 in Nova as well, along with the requested api autodiscovery | 20:33 |
| *** SushilKM__ has quit IRC | 20:33 | |
| esheffield | I confess that *I'm* not 100% in support of it, but mostly because I was having trouble envisioning a good clean API | 20:34 |
| markwash | yeah, its a little rough | 20:34 |
| esheffield | and what would happen in the case of mismatches (e.g. trying to use tags but only having a V1 backend) | 20:34 |
| markwash | at this point, it might just need to be "whatevers in both v1 and v2" | 20:35 |
| markwash | so probably tags wouldn't be part of v0.0, | 20:35 |
| markwash | image sharing would be really reduced or absent | 20:35 |
| markwash | etc | 20:36 |
| esheffield | I know when we talked about it before it was mentioned that multiple locations was going to be required in Nova soon | 20:36 |
| esheffield | so while I was hopeing on this helping with Nova -> Glance V2, that would be a blocker to this approach right away I think | 20:36 |
| *** igormarnat has quit IRC | 20:37 | |
| markwash | esheffield: I think multiple locations might work | 20:37 |
| esheffield | that would be great then | 20:37 |
| markwash | we just have to treat v1 as having only 1 | 20:37 |
| markwash | there are some ways we can put in some info about whether or not adding locations is supported as well | 20:38 |
| markwash | if that is necessary | 20:38 |
| *** jasonb365 has joined #openstack-meeting-alt | 20:38 | |
| markwash | so I think what we need is someone who has time to commit to proposing an api | 20:38 |
| arnaud | how big is the work on this? | 20:38 |
| * markwash is not sure | 20:39 | |
| iccha | and we would have to maintain it for every feature we add as well | 20:40 |
| markwash | iccha: exactly | 20:40 |
| esheffield | well, I did some work on the images layer in Nova which is kind of what this would be and refactoring that code into something similar to this took a couple of weeks | 20:41 |
| markwash | I think if we do it well, it will reduce support, because we can direct people to a lib api that we actually designed with the intention of supporting cross-version | 20:41 |
| arnaud | esheffield: ok | 20:42 |
| ameade | we still have 2 other topics for this meeting btw :) | 20:42 |
| markwash | esheffield: looking at your quesitons in the etherpad | 20:42 |
| markwash | hmm, well let's try to respond in that etherpad to carry the discussion forward | 20:43 |
| esheffield | I did reuse a lot of what was in Nova already, so it was a bit crufty - I'd want to take more time and do it cleanly with a well designed api this time so probably a bit more time | 20:43 |
| markwash | perhaps we can get to the other topics still, that way | 20:43 |
| esheffield | yes, please add thoughts and comments there! | 20:43 |
| markwash | okay, anyone not ready to move on for now? | 20:43 |
| markwash | #topic glance versioning consistency | 20:44 |
| *** openstack changes topic to "glance versioning consistency (Meeting topic: glance)" | 20:44 | |
| markwash | esheffield: is this also your topic? | 20:44 |
| esheffield | heh, yes | 20:44 |
| esheffield | we can probably hold off on the broader topic there for a bit, but in working on the bug linked there some concerns came up over the verionsing | 20:45 |
| esheffield | and backward compatibility | 20:45 |
| esheffield | the more immediate concern is if fixing that bug causes backward compat problems | 20:45 |
| markwash | ah | 20:45 |
| esheffield | flwang was concerned esp. | 20:46 |
| markwash | well, we got out a little ahead of json patch | 20:46 |
| rosmaita | in draft 4, "add" on an existing member is an error | 20:46 |
| markwash | we were implementing support when it was still in draft form, not sure if that is the culprit here | 20:46 |
| rosmaita | in current standard, it acts like a replace | 20:46 |
| markwash | I think that sounds like it is not a problem for backwards compat | 20:47 |
| esheffield | yes, when we went to api v2.2 we said we support draft 10, but in draft 10 (and current) it's as rosmaita says | 20:47 |
| *** igormarnat_ has joined #openstack-meeting-alt | 20:47 | |
| markwash | well, at first consideration | 20:47 |
| esheffield | but we still raise an error | 20:47 |
| rosmaita | we have already deprecated openstack-images-v2.0-json-patch | 20:47 |
| rosmaita | (or at least i have in the API docs) | 20:47 |
| *** doug_shelley66 has quit IRC | 20:48 | |
| markwash | it sounds like this is just a bugfix | 20:48 |
| *** dougshelley66 has joined #openstack-meeting-alt | 20:48 | |
| markwash | I don't think depending on that erroring out is a behavior the client relies upon | 20:48 |
| *** vipul-away is now known as vipul | 20:49 | |
| rosmaita | flwang was worried about API users expecting that behavior, though | 20:49 |
| esheffield | that was what I thought as well - if anything people would be having to work around it and worst case the workarounds wouldn't be needed now | 20:49 |
| *** jcooley_ has quit IRC | 20:49 | |
| *** yogesh has joined #openstack-meeting-alt | 20:49 | |
| markwash | hmm, flwang is not here to defend himself | 20:50 |
| markwash | so let's all attack! | 20:50 |
| markwash | j/k | 20:50 |
| arnaud | :) | 20:50 |
| esheffield | the glanceclient is unaffected too - it always fetches the image and generates a proper 'replace' or 'add' as needed | 20:50 |
| markwash | so, the only difference is that now if you use add and it already exists, you get an error? | 20:50 |
| rosmaita | yep | 20:51 |
| markwash | is there any chance we could implement so if you use the old content type it does the old behavior, and if you use the normal content type you get the bugfix? | 20:51 |
| markwash | probably a bit hacky, but | 20:51 |
| esheffield | that kind of circles back to the bigger topic of version concistency | 20:52 |
| rosmaita | well, the code right now rewrites the 2.0 request to be like a 2.1 request | 20:52 |
| esheffield | if you get a list of versions you get several, but they're all actually the same thing | 20:52 |
| markwash | esheffield: yeah that always seemed a bit weird to me | 20:52 |
| markwash | based on what we're doing, it would be easier to just say "we use semantic versioning" somewhere in the docs | 20:53 |
| *** aveiga has joined #openstack-meeting-alt | 20:53 | |
| * markwash is starting to worry about time for the next topic | 20:54 | |
| rosmaita | next topic does not need much time | 20:54 |
| nikhil__ | if there is a min time for open discussion I've a quick question | 20:54 |
| esheffield | sorry, didn't mean to dominate things today! :-( | 20:54 |
| esheffield | take this to the ML perhaps? | 20:54 |
| markwash | esheffield: I responded to the bug discussion | 20:55 |
| markwash | esheffield: I think we need a concrete proposal for what changes we want | 20:55 |
| markwash | not just "why is this weird" :-) | 20:55 |
| markwash | "because OpenStack" | 20:55 |
| iccha | lol | 20:55 |
| esheffield | :-) | 20:55 |
| ameade | gotta love the honesty | 20:55 |
| markwash | there's probably lower, weirder fruit | 20:56 |
| markwash | :-) | 20:56 |
| markwash | okay | 20:56 |
| rosmaita | i agree we need a definite proposal for what we want to do before going to the ML | 20:56 |
| ameade | does it bother anyone else that OpenStack is camel case? | 20:56 |
| markwash | #topic image sharing | 20:56 |
| *** openstack changes topic to "image sharing (Meeting topic: glance)" | 20:56 | |
| markwash | (sorry to steamroll) | 20:56 |
| rosmaita | so i promised to put together something to get the discussion going | 20:56 |
| markwash | looks like you got a #linkt here | 20:56 |
| arnaud | ameade: +1 :) | 20:56 |
| markwash | well | 20:56 |
| markwash | s/linkt/link/ | 20:56 |
| rosmaita | #link https://etherpad.openstack.org/p/glance-image-sharing-discussion | 20:57 |
| rosmaita | anyway, we can discuss at next meeting | 20:57 |
| rosmaita | after everyone who's interested has looked over the etherpad | 20:58 |
| *** ijw has joined #openstack-meeting-alt | 20:58 | |
| markwash | #topic open discussion | 20:58 |
| *** openstack changes topic to "open discussion (Meeting topic: glance)" | 20:58 | |
| nikhil__ | can I ask? | 20:58 |
| ameade | It seems a number of people did indeed follow my email about abandoned patches | 20:58 |
| ameade | i'm going to gather more stats on bugs and things that have been in progress for ages | 20:59 |
| ameade | then send another reminder email and later I will laser triage patches and bugs that nobody updates | 20:59 |
| markwash | nikhil__: did you have a note? | 20:59 |
| nikhil__ | currently tasks response is of the form {<task_attrs>} vs. openstack common usage {'task': <task_attrs>} ? | 20:59 |
| markwash | let's be glance-consistent | 21:00 |
| ameade | +1 | 21:00 |
| *** igormarnat_ has quit IRC | 21:00 | |
| *** baoli has joined #openstack-meeting-alt | 21:00 | |
| nikhil__ | same as images then | 21:00 |
| nikhil__ | cool, thanks | 21:00 |
| *** eankutse has quit IRC | 21:00 | |
| markwash | okay, thanks everybody! | 21:00 |
| markwash | wish me luck | 21:00 |
| *** eankutse has joined #openstack-meeting-alt | 21:00 | |
| markwash | (no reason) | 21:00 |
| *** BrianB__ has joined #openstack-meeting-alt | 21:00 | |
| rosmaita | good luck | 21:00 |
| iccha | good luck markwash ! (not sure for what though) | 21:00 |
| markwash | #endmeeting | 21:00 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 21:00 | |
| openstack | Meeting ended Thu Dec 12 21:00:58 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:00 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/glance/2013/glance.2013-12-12-20.03.html | 21:01 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/glance/2013/glance.2013-12-12-20.03.txt | 21:01 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/glance/2013/glance.2013-12-12-20.03.log.html | 21:01 |
| zhiyan | good luck | 21:01 |
| *** drake_ has joined #openstack-meeting-alt | 21:01 | |
| sc68cal | Alright - straight into the next meeting | 21:01 |
| sc68cal | ijw: hello there | 21:01 |
| *** ashwini has left #openstack-meeting-alt | 21:01 | |
| ijw | yo | 21:01 |
| sc68cal | aveiga: howdy | 21:01 |
| aveiga | o/ | 21:01 |
| *** BrianB__ has quit IRC | 21:01 | |
| sc68cal | #startmeeting neutron_ipv6 | 21:02 |
| openstack | Meeting started Thu Dec 12 21:02:07 2013 UTC and is due to finish in 60 minutes. The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot. | 21:02 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 21:02 |
| *** openstack changes topic to " (Meeting topic: neutron_ipv6)" | 21:02 | |
| openstack | The meeting name has been set to 'neutron_ipv6' | 21:02 |
| sc68cal | Agenda for today is a bit light - so I'd like to get through it quick and then do a big open discussion | 21:02 |
| sc68cal | #topic recap previous meeting | 21:02 |
| *** openstack changes topic to "recap previous meeting (Meeting topic: neutron_ipv6)" | 21:02 | |
| sc68cal | So we're still working through what we want to do with the subnet_mode review | 21:03 |
| *** boris-42 has joined #openstack-meeting-alt | 21:03 | |
| sc68cal | aveiga: IJW made a good point during a convo about some of the provider networking w/ ipv6 we want to do | 21:04 |
| *** Dane has joined #openstack-meeting-alt | 21:04 | |
| sc68cal | we should be setting enable_dhcp to false when we create a v6 subnet that is announced upstream | 21:04 |
| aveiga | is this wrt disabling instead of setting SLAAC mode? I agree | 21:04 |
| *** Barker has quit IRC | 21:04 | |
| ijw | Yeah, there's two things. Firstly, I don't really mind if we want slaac and dhcpv6 both working, that's fine, but I don't think we should tie ourselves forever to dnsmasq | 21:04 |
| ijw | Second, I wanted to understand why people like slaac (other than on provider networks where it's an external router's problem, which totally makes sense) | 21:05 |
| *** zhiyan has quit IRC | 21:05 | |
| *** rwsu has quit IRC | 21:05 | |
| *** brents has quit IRC | 21:05 | |
| aveiga | ijw: I think there's issues on both modes. SLAAC has RA problems with a lot of distributions (see RHEL bugs on RA priorities) | 21:06 |
| ijw | Yup | 21:06 |
| aveiga | DHCP has problems with client implementations | 21:06 |
| aveiga | it also has RA issues, too | 21:06 |
| *** mcohen2 has quit IRC | 21:06 | |
| sc68cal | aveiga: but that's if there are multiple RA packets flying around, right? | 21:06 |
| ijw | I'm thinking mainly about comes up on non-provider (i.e. totally internal) networks | 21:06 |
| aveiga | basically if you do DHCPv6, you either have to make the DHCP server a router, or have the RA come from an l3 gateway separately | 21:07 |
| aveiga | and coordinate | 21:07 |
| ijw | Yup, I don't think co-ordination is a problem particularly but we have to deal with networks with no routers | 21:07 |
| aveiga | right, tenant private networks are irksome when it comes to this | 21:07 |
| ijw | I also have no problem with being in the router namespace, but there's nothing in Neutron that forces you to have a single Neutron router either | 21:07 |
| *** ichihara has joined #openstack-meeting-alt | 21:07 | |
| ijw | It's just a nightmare, that's the problem | 21:08 |
| aveiga | and that's the real kicker | 21:08 |
| aveiga | if there are multiple rotuers, where does the RA come from? | 21:08 |
| sc68cal | is Randy Tuttle on? | 21:08 |
| sc68cal | or Shixiong Shang | 21:08 |
| ijw | So, first things first. In ipv4 you get to choose your network's subnet and your port's address. Do we still want to do either of those things? | 21:08 |
| sc68cal | I think their design addressed some of this in depth | 21:08 |
| aveiga | ijw: are you referring to neutron network creation on the subnet side? | 21:09 |
| aveiga | or do you mean selecting potential networks at instance creation? | 21:09 |
| *** Barker has joined #openstack-meeting-alt | 21:09 | |
| ijw | I mean that in v4 you get (as tenant) to choose your subnet and you get to choose your address if you create a port manually (rather than letting the system do it on nova boot) if you keep it in that subnet | 21:09 |
| aveiga | I'm not fully familiar, but doesn't choosing your subnet mean the same thing as selecting a neutron network? | 21:10 |
| ijw | No, subnet is the address range rather than the network (which is l2) | 21:11 |
| aveiga | oh, I think I know what you mean | 21:11 |
| ijw | Reason I raise it is that I can imagine you'd want to stick with routeable addresses, or at least have routeable addresses chosen for your network automatically, in v6 | 21:11 |
| *** arnaud has quit IRC | 21:11 | |
| aveiga | yes | 21:11 |
| ijw | In v4, the world is your oyster, cos v4 is evil and must die | 21:11 |
| aveiga | the problem is going to be having dhcpv6 and slaac in the same l2 | 21:12 |
| aveiga | they would be separate subnets | 21:12 |
| aveiga | but same l2 domain | 21:12 |
| aveiga | so the RAs would be wonky | 21:12 |
| ijw | We get to choose, we don't have to allow just everything | 21:12 |
| aveiga | we could make them mutually exclusive | 21:12 |
| *** dmitryme has quit IRC | 21:12 | |
| sc68cal | should we make an action item to review how neutron behaves when you have a network with multiple subnets? | 21:12 |
| sc68cal | on v4 side, and compare what would happen on v6 side with multiple subnets? | 21:13 |
| aveiga | or force DHCOPv6 allocation to not use EUI-64 collision space | 21:13 |
| ijw | My choice there would be that we allow precisely one v6 subnet per network (the v4 multiple subnet thing is a solution to address sparsity which isn't a problem we have) and use DHCPv6 so that we assign specific addrs to machine | 21:13 |
| ijw | sc68cal: I think how it works is you get an address from one of the subnets, at least in v4. Good chance no-one has tried it in v6, though certainly you can set it up, I tried | 21:14 |
| sc68cal | ijw: So you'd force DHCPv6 as the only option on v6 side? | 21:14 |
| sc68cal | meaning no slaac | 21:14 |
| ijw | For internal networks, and if we could get away with it, that's my preference. Tenant networks: DHCPv6 or off | 21:14 |
| ijw | To be fair, even in v4 you can turn off DHCP if you like. | 21:14 |
| aveiga | I actually don't see why non-routing tenant networks need addressing | 21:15 |
| *** brents has joined #openstack-meeting-alt | 21:15 | |
| aveiga | you get LLA for free | 21:15 |
| ijw | yup | 21:15 |
| ijw | Tenant networks don't have to be non-routing, mind | 21:15 |
| aveiga | yeah, but then I don't think I'd want to force DHCPO on them either | 21:15 |
| ijw | (Sorry, I have an evil mind and at the moment it sees problems and not answers) | 21:15 |
| sc68cal | ijw: do you want to write up a blueprint for what you're thinking? | 21:16 |
| aveiga | ijw: someone has to play devil's advocatel; nodding heads don't make good solutions | 21:16 |
| aveiga | sc68cal: ijw: blueprint sounds liek a good idea | 21:16 |
| ijw | Yeah, let me do that. Problem is that (like a lot of other blueprints in this space) it excludes options whatever we implement, but I can do that | 21:16 |
| aveiga | at least we can all discuss it with a model in front of us | 21:16 |
| sc68cal | #action ijw write up blueprint discussing his preferred model for tenant networking | 21:17 |
| aveiga | I'm just finidng it difficult to understand why we'd exclude slaac or static? | 21:17 |
| *** ativelkov has left #openstack-meeting-alt | 21:17 | |
| aveiga | because keep in mind, some folks want config-drive or metadata static injection as well | 21:17 |
| aveiga | and I can think of good use cases for it | 21:17 |
| ijw | What do you mean by static? Remember DHCP here is 1 MAC, 1 IP | 21:17 |
| sc68cal | OK - let's go ahead and move on from this - keep to the agenda | 21:17 |
| aveiga | I mean that the IP is injected into the guest config | 21:18 |
| sc68cal | let's hold this until open discussion | 21:18 |
| ijw | yup | 21:18 |
| aveiga | ok | 21:18 |
| sc68cal | #topic Nova IPv6 hairpin bug | 21:18 |
| *** openstack changes topic to "Nova IPv6 hairpin bug (Meeting topic: neutron_ipv6)" | 21:18 | |
| *** drake_ has quit IRC | 21:18 | |
| sc68cal | Promise if we get through these quick we can let you guys go at it | 21:18 |
| *** drake__ has joined #openstack-meeting-alt | 21:18 | |
| sc68cal | So - we're getting some pushback on the hairpin issue | 21:19 |
| ijw | I like the proposed solution for hairpinning and I don't think any Neutron module needs it but should we have a quick code review? | 21:19 |
| ijw | (the solution being the one where VIF plugging requests it if required)( | 21:19 |
| sc68cal | #link https://review.openstack.org/#/c/56381/ nova ipv6 hairpin bug review | 21:19 |
| sc68cal | ijw: agreed | 21:19 |
| aveiga | was there an issue with that from anyone else? | 21:19 |
| sc68cal | aveiga: one of the core devs from nova wants it to be a per VIF attribute | 21:20 |
| sc68cal | I think we agree - provided the default is off | 21:20 |
| *** stanlagun has left #openstack-meeting-alt | 21:20 | |
| sc68cal | and if someone wants it, just pass in an attribute to turn it on, from Neutron | 21:20 |
| ijw | Daniel is being cautious, though I think a bit too cautious. Still. | 21:20 |
| aveiga | I don't fully grasp the consequences here | 21:20 |
| aveiga | what is lost by defaulting to off? | 21:21 |
| baoli | Question, why hairpin has to be turned off with neutron? | 21:21 |
| aveiga | baoli: DAD failure | 21:21 |
| ijw | nova-network's usually on because the floating IP rewrite rules live between the switch and the port in nova-network | 21:21 |
| ijw | Neutron doesn't put them there. | 21:21 |
| aveiga | you see your own Neighbor Solicit, and eimmediately detect a duplicate address | 21:21 |
| sc68cal | The problem is nova is adding patches to their firewall drivers to block traffic from coming back and breaking ipv6 | 21:21 |
| baoli | where does neutron put it? | 21:21 |
| aveiga | ah, so unless it hairpinned NAT wouldn't apply? | 21:22 |
| ijw | In the router | 21:22 |
| ijw | Yup, you can't ping your own public address iirc | 21:22 |
| aveiga | right | 21:22 |
| sc68cal | There's a big chunk of code that Nachi has been working on, to have Neutron pass in VIF attributes for firewalling | 21:22 |
| aveiga | so we should push this back on nova-network to have them set the hairpin option | 21:22 |
| ijw | We also need to check all the other drivers - libvirt is not the world. | 21:23 |
| sc68cal | So it wouldn't be too hard to add another attribute to the VIF stuff to make it turn on hairpinning | 21:23 |
| aveiga | unless you think it's better to make it a negative case? Assume it's on, request it to be disabled per VIF? | 21:23 |
| sc68cal | aveiga: I'd assume the inverse - always off, unless requested | 21:23 |
| *** ErikB has quit IRC | 21:23 | |
| ijw | There's an argument for either but it's so slight let's just pick one. | 21:23 |
| aveiga | ok, but expect an argument from the embedded parties there | 21:24 |
| *** IlyaE has quit IRC | 21:24 | |
| sc68cal | I'm picking off by default | 21:24 |
| sc68cal | and vif attribute turns it on when requested | 21:24 |
| aveiga | ok, propose it on the ML then | 21:24 |
| sc68cal | aveiga: I did - I asked if anyone needed it | 21:24 |
| sc68cal | no responses | 21:24 |
| ijw | OK, so we have to check all the virt drivers for this and we also need to check the plugins | 21:25 |
| ijw | Neutron plugins | 21:25 |
| *** krtaylor has joined #openstack-meeting-alt | 21:25 | |
| aveiga | is than AI for another code review? | 21:25 |
| *** IlyaE has joined #openstack-meeting-alt | 21:25 | |
| ijw | The virt drivers need changes, the neutron plugins only review | 21:25 |
| *** ErikB has joined #openstack-meeting-alt | 21:25 | |
| sc68cal | I hope that it's only libvirt that enables hairpinning | 21:26 |
| aveiga | how should we approach that? Setup the new VIF definition, then file bugs against the virt drivers? | 21:26 |
| ijw | guess so | 21:26 |
| sc68cal | aveiga: I think so, if we start sending the attribute, drivers should honor it and enable hairpin | 21:26 |
| ijw | More to the point, have to honour its absence and not enable hairpin. | 21:27 |
| sc68cal | ijw: agreed - which the review currently makes libvirt do | 21:27 |
| aveiga | which is where the default on or off argument comes in | 21:27 |
| sc68cal | OK - if nobody else objects I'll file a blueprint in nova to make hairpin a configurable setting | 21:28 |
| aveiga | +1 | 21:28 |
| sc68cal | then people can make sub blueprints to link to specific drivers | 21:28 |
| ijw | yup | 21:28 |
| sc68cal | #action sc68cal create blueprint in nova for hairpinning via VIF attributes | 21:28 |
| *** colinmcn_ has quit IRC | 21:28 | |
| *** colinmcnamara has quit IRC | 21:28 | |
| sc68cal | OK we're through | 21:29 |
| sc68cal | #topic open discussion | 21:29 |
| *** openstack changes topic to "open discussion (Meeting topic: neutron_ipv6)" | 21:29 | |
| ijw | aviega: the point I wa ma | 21:29 |
| ijw | was making earlier was that 'static' is not exclusive with the others | 21:29 |
| ijw | You get that regardless of if DHCP is on or off | 21:29 |
| aveiga | sorta | 21:30 |
| ijw | so really we're only talking about flags that change the network address handing-out service | 21:30 |
| aveiga | I can think of a scenario where having DHCP on would be detrimental to a static config | 21:30 |
| *** sarob_ has joined #openstack-meeting-alt | 21:30 | |
| ijw | Yep, that's fine, so you turn it off | 21:30 |
| aveiga | ah, that's where I agree with you | 21:30 |
| ijw | on/off is already available | 21:30 |
| *** banix has quit IRC | 21:31 | |
| aveiga | so are we leaving it to the operator then? | 21:31 |
| ijw | DHCP on/off should remain an option | 21:31 |
| ijw | *but* | 21:31 |
| aveiga | they have to know enough to disable DHCP | 21:31 |
| *** SergeyLukjanov is now known as _SergeyLukjanov | 21:31 | |
| ijw | Yeah, but I'm assuming if you know you need static config you can work that one out | 21:31 |
| aveiga | ok | 21:31 |
| aveiga | so in the case where we have SLAAC and DHCP | 21:32 |
| ijw | DHCP / SLAAC is more of an issue. SLAAC will come up with an address which isn't the one you have put on the port, for instance | 21:32 |
| aveiga | I'm worried about collisions | 21:32 |
| aveiga | so this is why I think the port needs to take a huint from the network | 21:32 |
| ijw | What happens if we just don't let SLAAC addressed traffic through the port firewall? | 21:33 |
| aveiga | you potentially break distruibutions | 21:33 |
| ijw | Obviously a SLAAC chosen address wouldn't work, but we can require that VMs using v6 take the address they've been given and don't just make it up | 21:33 |
| *** sarob has quit IRC | 21:33 | |
| *** alazarev has quit IRC | 21:34 | |
| aveiga | if it's a mixed mode network and you block the SLAAC addr at the port, then some distros that get the SLAAC addr up first will be forever dead in the water | 21:34 |
| aveiga | unless you manually alter routing tables | 21:34 |
| *** sarob_ has quit IRC | 21:34 | |
| aveiga | I think we need to make DHCP and SLAAC mutually exclusive | 21:35 |
| *** mcohen2 has joined #openstack-meeting-alt | 21:35 | |
| ijw | Again, can we exclude mixed mode? | 21:35 |
| ijw | I'm out of my depth here, so I'm honestly asking | 21:35 |
| aveiga | yes | 21:35 |
| aveiga | you can safely make the assumption that EUI-64 SLAAC is the least common denominator | 21:36 |
| *** nati_ueno has quit IRC | 21:36 | |
| *** IlyaE has quit IRC | 21:36 | |
| aveiga | since it existed for years before anything else | 21:36 |
| *** demorris has quit IRC | 21:36 | |
| ijw | Yeah, but the issue is that it's damned nice to be able to force an address on a VM rather than have one given | 21:36 |
| aveiga | and assume that an operator choosing DHCP should know that their guest images must be able to use it | 21:36 |
| aveiga | then you use DHCP | 21:36 |
| aveiga | you can theoretically force an address | 21:37 |
| aveiga | you have control of the MAC | 21:37 |
| ijw | Well, you can predict it | 21:37 |
| aveiga | my turn for devil's advocate | 21:37 |
| aveiga | what if you want to put multiple addresses on the same interface? | 21:37 |
| aveiga | i.e. bind apache to one and ssh to the other? | 21:38 |
| aveiga | DHCP won't do that | 21:38 |
| aveiga | SLAAC wont' | 21:38 |
| aveiga | but if you filter the port on non-assigned addresses | 21:38 |
| aveiga | that breaks | 21:38 |
| ijw | static config, probably, at that point | 21:38 |
| ijw | And there's an extension for that that arosen did, so we're not screwed | 21:38 |
| aveiga | does it support injecting rotues? | 21:38 |
| aveiga | routes* | 21:38 |
| ijw | Don't think so, but you can see that coming, I agree | 21:39 |
| aveiga | because (due to the RA bug in some distros) one of the main points for static is addressing with out RA so that you can do HSRP in v6 | 21:39 |
| ijw | Well, I'm still going to write a BP recommending against SLAAC (also, SLAAC only works on a /64 aiui) | 21:40 |
| aveiga | that way RA juggling isn't necessary for multi-homed switches | 21:40 |
| aveiga | that's correct | 21:40 |
| ijw | and /64 is a big tenant net | 21:40 |
| ijw | But anyway, initially let's assume we're going to want to make that extension either core or more widely implemented. I'll go and find the one in question. | 21:41 |
| aveiga | so what do you intend to do with clients that don't have a working DHCPv6 stack? | 21:41 |
| aveiga | fore static injection? | 21:41 |
| ijw | There's also magic to turn off antispoof entirely for a whole net. It was much more important in nova-net than it is in Neutron (where you can have total control of all your VIFs on the network) | 21:41 |
| ijw | configdrive? | 21:42 |
| ijw | cloud-init happily supports config drives and they work without a functional network to get a network up. | 21:43 |
| aveiga | I'm wary of saying that we support IPv6 if we don't support SLAAC | 21:43 |
| aveiga | since SLAAC is part of the IPv6 RFC | 21:43 |
| sc68cal | +1 | 21:43 |
| ijw | Better say that it's not core, I would say | 21:43 |
| *** sarob has joined #openstack-meeting-alt | 21:43 | |
| sc68cal | and we have a BP registered for how we deploy openstack at Comcast | 21:43 |
| sc68cal | which involves SLAAC | 21:43 |
| ijw | It's not that you can't do it, but I think we should aim for v4 parity in this, which is basically that you get to choose an address from the subnet and have it assigned via a handful of recognised methods | 21:44 |
| ijw | SLAAC on internal networks? | 21:44 |
| aveiga | both | 21:44 |
| ijw | OK, point me at that offline | 21:44 |
| *** drake__ has quit IRC | 21:44 | |
| ijw | We're going around on this, so let's cover something else while we have the time | 21:44 |
| sc68cal | #link https://blueprints.launchpad.net/neutron/+spec/ipv6-provider-nets-slaac Provider networking with slaac | 21:44 |
| ijw | .. that's provider nets, not internal, though | 21:44 |
| *** rnirmal has quit IRC | 21:45 | |
| aveiga | what did you have in mind? | 21:45 |
| *** jecarey has quit IRC | 21:45 | |
| ijw | floating IPs | 21:45 |
| aveiga | ah, the killer | 21:45 |
| *** SergeyLukjanov has joined #openstack-meeting-alt | 21:45 | |
| ijw | Absolutely | 21:45 |
| ijw | Now, no-one is allowed to say the N word without putting a quid in the swear jar | 21:45 |
| aveiga | I have a better proposal | 21:46 |
| aveiga | change the DHCP reservation | 21:46 |
| aveiga | and keep the valid lifetime low | 21:46 |
| ijw | Renumber the machine? | 21:46 |
| aveiga | yup | 21:46 |
| ijw | Hm | 21:46 |
| ijw | How about change the router firewall | 21:46 |
| ijw | So where before you would n.. things, you let incoming connections in | 21:46 |
| ijw | different change, but same place | 21:47 |
| aveiga | actually | 21:47 |
| aveiga | DHCPv6 supports having multiple addresses | 21:47 |
| aveiga | we could inject both in the renew | 21:47 |
| aveiga | well | 21:47 |
| ijw | That's a rather nice idea | 21:47 |
| aveiga | tell it rebind fail | 21:47 |
| aveiga | then start over | 21:47 |
| sc68cal | kind of like it | 21:48 |
| *** sarob has quit IRC | 21:48 | |
| aveiga | effectively use DHCP to inject it without renumbering | 21:48 |
| ijw | However, the thing here is that even with private (fixed) v4 addresses I have external access | 21:48 |
| aveiga | no loss of existing bindings/TCP sessions | 21:48 |
| aveiga | are we doing private v6? I propose we ignore ULA | 21:48 |
| *** sarob has joined #openstack-meeting-alt | 21:48 | |
| ijw | So the question is whether this is about having two addresses for one machine or about the kind of inbound access that machine has, philosophically | 21:49 |
| aveiga | actually, that was selfish | 21:49 |
| aveiga | we should support it | 21:49 |
| aveiga | eh, it's reachability on an address that isn't the machine's primary access | 21:49 |
| sc68cal | I think from the outside it's just about being able to move an IP across boxes | 21:49 |
| aveiga | because you can ssh to the fixed before a flaot is assigned | 21:49 |
| sc68cal | dynamically without mucking around inside the machines | 21:49 |
| aveiga | and you can reserve floats | 21:49 |
| ijw | You see, that's two things - reachability and primary access - why can't it be primary? | 21:49 |
| ijw | sc68cal may have it | 21:50 |
| aveiga | because you'd rebind daemons or kill tcp sessions | 21:50 |
| ijw | Though it's a very slow way of moving the address, you know | 21:50 |
| sc68cal | I think primary access just leaked in because of the design of nova-network | 21:50 |
| sc68cal | to the floating ip concept | 21:50 |
| aveiga | we shouldn't break existing access while adding a float | 21:50 |
| *** jdob has quit IRC | 21:50 | |
| sc68cal | but elastic IPs in amazon was reachability | 21:50 |
| aveiga | yeah, but I can see that as being useful | 21:50 |
| ijw | Only if you change the address, not if you use the same one and it's routeable (which it would want to be if it were to have the equivalent of a fixed address, which if it's on a router has external dialout access) | 21:50 |
| *** sarob has quit IRC | 21:51 | |
| aveiga | I think the real issue is WHICH address | 21:51 |
| ijw | So the minimal solution is there's no second address, by default it can dial out and with special permissions it can dial in. But that removes transferrability | 21:51 |
| aveiga | one reason for reserving floats and putting them on a new VM is for upstream security outside of OpenStack | 21:52 |
| aveiga | yeah, transferrability is a key concept of flaots | 21:52 |
| aveiga | they float between VMs | 21:52 |
| aveiga | I don't think you can support flaoting IPs and ignore that feature | 21:52 |
| aveiga | whether we like it or not, people are using it in that manner already | 21:53 |
| ijw | OK, so it's a secondary address. What pool are we drawing from? | 21:53 |
| aveiga | this sounds like a bigger topic though | 21:53 |
| aveiga | and we're close to time | 21:53 |
| ijw | Yeah - clearly there's no simple answer here | 21:53 |
| aveiga | want to put this on the agenda for next week or take it to the ML (or the neutron channel)? | 21:53 |
| ijw | Both, I think | 21:53 |
| aveiga | maybe some fols in the neutron channel have opinions here? | 21:53 |
| aveiga | ok, I think we're done here | 21:54 |
| aveiga | sc68cal: care to do the honors? | 21:54 |
| ijw | To my mind it's one of the biggest stumbling blocks, possibly second only to ensuring all your addresses are routeable and non-overlapping | 21:54 |
| sc68cal | sure - if nobody has anything else we can end early | 21:55 |
| aveiga | yeah, I think making prov modes mutually exclusive helps there, but I agree | 21:55 |
| aveiga | and on that, I need to head out to get dinner anyway | 21:55 |
| ijw | Well, I think we have more than enough work for a week. | 21:55 |
| *** demorris has joined #openstack-meeting-alt | 21:55 | |
| aveiga | +1 | 21:55 |
| sc68cal | Alright then - see everyone next week | 21:55 |
| ijw | o/ | 21:55 |
| sc68cal | #endmeeting | 21:55 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 21:55 | |
| openstack | Meeting ended Thu Dec 12 21:55:49 2013 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:55 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/neutron_ipv6/2013/neutron_ipv6.2013-12-12-21.02.html | 21:55 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/neutron_ipv6/2013/neutron_ipv6.2013-12-12-21.02.txt | 21:55 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/neutron_ipv6/2013/neutron_ipv6.2013-12-12-21.02.log.html | 21:55 |
| ijw | Dinner. There's a fine plan. | 21:56 |
| *** BrianB_ has quit IRC | 22:02 | |
| *** aignatov has quit IRC | 22:03 | |
| *** jasonb365_ has joined #openstack-meeting-alt | 22:04 | |
| *** ashaikh_ has joined #openstack-meeting-alt | 22:04 | |
| *** dougshelley66 has quit IRC | 22:04 | |
| *** julim_ has joined #openstack-meeting-alt | 22:05 | |
| *** jasonb365 has quit IRC | 22:05 | |
| *** jasonb365_ is now known as jasonb365 | 22:05 | |
| *** tomoko__ has joined #openstack-meeting-alt | 22:05 | |
| *** aveiga has left #openstack-meeting-alt | 22:06 | |
| *** ashaikh has quit IRC | 22:07 | |
| *** ashaikh_ is now known as ashaikh | 22:07 | |
| *** julim has quit IRC | 22:07 | |
| *** markmcclain has quit IRC | 22:07 | |
| *** AlanClark has quit IRC | 22:09 | |
| *** baoli has quit IRC | 22:09 | |
| *** abramley has quit IRC | 22:10 | |
| *** pdmars has quit IRC | 22:11 | |
| *** boris-42 has quit IRC | 22:11 | |
| *** banix has joined #openstack-meeting-alt | 22:13 | |
| *** Dane has quit IRC | 22:15 | |
| *** lblanchard has quit IRC | 22:16 | |
| *** brents has quit IRC | 22:18 | |
| *** ichihara has left #openstack-meeting-alt | 22:18 | |
| *** dprince has quit IRC | 22:22 | |
| *** brents has joined #openstack-meeting-alt | 22:31 | |
| *** denis_makogon has quit IRC | 22:33 | |
| *** noslzzp has quit IRC | 22:33 | |
| *** krtaylor has quit IRC | 22:38 | |
| *** brents has quit IRC | 22:39 | |
| *** brents has joined #openstack-meeting-alt | 22:41 | |
| *** banix has quit IRC | 22:42 | |
| *** brents has quit IRC | 22:43 | |
| *** abramley has joined #openstack-meeting-alt | 22:43 | |
| *** Barker has quit IRC | 22:47 | |
| *** kevinconway has quit IRC | 22:48 | |
| *** eankutse1 has joined #openstack-meeting-alt | 22:49 | |
| *** eankutse1 has quit IRC | 22:49 | |
| *** banix has joined #openstack-meeting-alt | 22:49 | |
| *** brents has joined #openstack-meeting-alt | 22:50 | |
| *** tomoko__ has quit IRC | 22:51 | |
| *** eankutse has quit IRC | 22:52 | |
| *** rudrarug_ has joined #openstack-meeting-alt | 23:00 | |
| *** rudrarug_ has quit IRC | 23:01 | |
| *** rudrarugge has quit IRC | 23:02 | |
| *** jergerber has quit IRC | 23:02 | |
| *** NehaV has quit IRC | 23:04 | |
| *** yogesh has quit IRC | 23:06 | |
| *** jcoufal has quit IRC | 23:12 | |
| *** vkmc has quit IRC | 23:19 | |
| *** sacharya has quit IRC | 23:22 | |
| *** ijw has left #openstack-meeting-alt | 23:25 | |
| *** dougshelley66 has joined #openstack-meeting-alt | 23:26 | |
| *** jasonb365 has quit IRC | 23:26 | |
| *** mcohen2 has quit IRC | 23:30 | |
| *** amytron has quit IRC | 23:30 | |
| *** alazarev has joined #openstack-meeting-alt | 23:35 | |
| *** IlyaE has joined #openstack-meeting-alt | 23:44 | |
| *** sarob has joined #openstack-meeting-alt | 23:44 | |
| *** bdpayne has quit IRC | 23:48 | |
| *** ErikB has quit IRC | 23:51 | |
| *** SergeyLukjanov has quit IRC | 23:57 | |
| *** yamahata_ has joined #openstack-meeting-alt | 23:58 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!