Re: [openstack-dev] [Cyborg]Queens PTL candidacy
Howard, I guess you will need some +1 votes and I certainly support you based on our joint early work on these projects. I regret not having time to participate actively this year. However your contribution has been great for the project and the OpenStack community On Thu, Aug 3, 2017 at 3:55 AM, Zhipeng Huang wrote: > Yes tony I was intended to refer to the official procedure for the > self-nomination period, which would be 5 buiz days. > > Thx for the offer to help with the civs poll :) > > On Thu, Aug 3, 2017 at 3:11 PM, Tony Breeds > wrote: > >> On Thu, Aug 03, 2017 at 11:59:55AM +0800, Zhipeng Huang wrote: >> > Hi Team, >> > >> > Even though Cyborg is not an official project yet, however with an >> ultimate >> > goal of becoming one it is necessary to conduct our project governance >> with >> > compliance of OpenStack community general requirements/culture. >> >> You didn't specify how long the self-nomination period is. I assume >> you're going for 5 business days? >> >> So any self nominations need to be in within a week from now >> >> Yours Tony. >> >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Zhipeng (Howard) Huang > > Standard Engineer > IT Standard & Patent/IT Product Line > Huawei Technologies Co,. Ltd > Email: huangzhip...@huawei.com > Office: Huawei Industrial Base, Longgang, Shenzhen > > (Previous) > Research Assistant > Mobile Ad-Hoc Network Lab, Calit2 > University of California, Irvine > Email: zhipe...@uci.edu > Office: Calit2 Building Room 2402 > > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- 宋慢 Harm Sluiman __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cyborg]Nominate Rushil Chugh and Justin Kilpatrick as new core reviewers
+1 I haven't had time to actively participate these past months but have monitored and agree :) Thanks for your time Harm Sluiman harm.slui...@gmail.com > On May 25, 2017, at 10:24 AM, Zhipeng Huang wrote: > > Hi Team, > > This is an email for nomination of rushil and justin to the core team. They > have been very active in our development and the specs they helped draft have > been merged after several rounds of review. The statistics could be found at > http://stackalytics.com/?project_type=all&module=cyborg&metric=person-day . > > Since we are not an official project and i'm the only core reviewer at the > moment, I think we should have a simple procedure for the first additional > core reviewers to be added. Therefore if there are no outstanding oppositions > by the end of the day of next Wed, I will suppose there is a consensus and > add these guys to the core team to help accelerating our development. > > Please voice your support or concerns if there are any within the next 7 days > :) > > -- > Zhipeng (Howard) Huang > > Standard Engineer > IT Standard & Patent/IT Product Line > Huawei Technologies Co,. Ltd > Email: huangzhip...@huawei.com > Office: Huawei Industrial Base, Longgang, Shenzhen > > (Previous) > Research Assistant > Mobile Ad-Hoc Network Lab, Calit2 > University of California, Irvine > Email: zhipe...@uci.edu > Office: Calit2 Building Room 2402 > > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [acceleration] No team meeting today, resume next Wed
Thanks for the update. Unfortunately I could not attend and can't seem to find a summary or anything about what took place. A pointer would be appreciated please ;-) Thanks for your time Harm Sluiman harm.slui...@gmail.com > On Mar 8, 2017, at 7:22 AM, Zhipeng Huang wrote: > > Hi team, > > As agreed per our PTG/VTG session, we will have the team meeting two weeks > after to give people enough time to prepare the BPs we discussed. > > Therefore there will be no team meeting today, and the next meeting is on > next Wed. > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [acceleration]Team Bi-weekly Meeting 2017.01.18 Agenda
I am afraid I am stuck in an alternate reality meeting this week. my apologies I will work to get the other meeting moved in the future On Tue, Jan 17, 2017 at 10:26 PM, Zhipeng Huang wrote: > Hi Team, > > Please find the agenda at https://wiki.openstack.org/ > wiki/Meetings/CyborgTeamMeeting#Agenda_for_next_meeting > > our IRC channel is #openstack-cyborg > > > -- > Zhipeng (Howard) Huang > > Standard Engineer > IT Standard & Patent/IT Prooduct Line > Huawei Technologies Co,. Ltd > Email: huangzhip...@huawei.com > Office: Huawei Industrial Base, Longgang, Shenzhen > > (Previous) > Research Assistant > Mobile Ad-Hoc Network Lab, Calit2 > University of California, Irvine > Email: zhipe...@uci.edu > Office: Calit2 Building Room 2402 > > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado > -- 宋慢 Harm Sluiman __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [acceleration]Team Bi-weekly Meeting 2017.1.4 Agenda
One question regarding PTG, Since we don't get a specific room allocated, and the intent is for people to not float around meetings... What day(s) are you expecting to have Cyborg specific discussion? It seem hotel booking will be a premium soon On Wed, Jan 4, 2017 at 11:13 AM, Zhipeng Huang wrote: > Hi Team, > > Thanks for a great discussion at today's meeting, please find the minutes > at https://wiki.openstack.org/wiki/Cyborg/MeetingLogs#2017-01-04 > > On Wed, Jan 4, 2017 at 10:40 PM, Miroslav Halas wrote: > >> Howard and team, >> >> >> >> I have usually conflict at this time, but I am trying to keep up with >> meeting logs and etherpads J. Either Scott or I will be at PTG >> representing Lenovo so we would be happy to participate. >> >> >> >> From last meeting I have added TODO to Nasca etherpard to link the design >> document and the code being discussed. I cannot seem to locate the original >> files Mellanox team shared with us. Would somebody who know where these are >> shared be able to insert the links to the etherpad >> https://etherpad.openstack.org/p/cyborg-nasca-design >> >> >> >> Thank you, >> >> >> >> Miro Halas >> >> >> >> *From:* Harm Sluiman [mailto:harm.slui...@gmail.com] >> *Sent:* Wednesday, January 04, 2017 9:22 AM >> *To:* Zhipeng Huang >> *Cc:* OpenStack Development Mailing List (not for usage questions); >> Miroslav Halas; rodolfo.alonso.hernan...@intel.com; Michele Paolino; >> Scott Kelso; Roman Dobosz; Jim Golden; pradeep.jagade...@huawei.com; >> michael.ro...@nokia.com; jian-feng.d...@intel.com; >> martial.mic...@nist.gov; Moshe Levi; Edan David; Francois Ozog; Fei K >> Chen; jack...@huawei.com; li.l...@huawei.com >> *Subject:* Re: [acceleration]Team Bi-weekly Meeting 2017.1.4 Agenda >> >> >> >> Happy New Year everyone. >> >> I won't be able participate in the IRC today due to a conflict, but I >> will try to connect and monitor. >> >> I will also put more comments in the etherpads that are linked >> >> >> >> >> >> On Wed, Jan 4, 2017 at 6:28 AM, Zhipeng Huang >> wrote: >> >> Hi Team, >> >> >> >> Please find the agenda at https://wiki.openstack.org/ >> wiki/Meetings/CyborgTeamMeeting#Agenda_for_next_meeting >> >> >> >> our IRC channel is #openstack-cyborg >> >> >> >> -- >> >> Zhipeng (Howard) Huang >> >> >> >> Standard Engineer >> >> IT Standard & Patent/IT Prooduct Line >> >> Huawei Technologies Co,. Ltd >> >> Email: huangzhip...@huawei.com >> >> Office: Huawei Industrial Base, Longgang, Shenzhen >> >> >> >> (Previous) >> >> Research Assistant >> >> Mobile Ad-Hoc Network Lab, Calit2 >> >> University of California, Irvine >> >> Email: zhipe...@uci.edu >> >> Office: Calit2 Building Room 2402 >> >> >> >> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado >> >> >> >> >> >> -- >> >> 宋慢 >> Harm Sluiman >> >> >> >> > > > -- > Zhipeng (Howard) Huang > > Standard Engineer > IT Standard & Patent/IT Prooduct Line > Huawei Technologies Co,. Ltd > Email: huangzhip...@huawei.com > Office: Huawei Industrial Base, Longgang, Shenzhen > > (Previous) > Research Assistant > Mobile Ad-Hoc Network Lab, Calit2 > University of California, Irvine > Email: zhipe...@uci.edu > Office: Calit2 Building Room 2402 > > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado > -- 宋慢 Harm Sluiman __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [acceleration]Team Bi-weekly Meeting 2017.1.4 Agenda
Happy New Year everyone. I won't be able participate in the IRC today due to a conflict, but I will try to connect and monitor. I will also put more comments in the etherpads that are linked On Wed, Jan 4, 2017 at 6:28 AM, Zhipeng Huang wrote: > Hi Team, > > Please find the agenda at https://wiki.openstack.org/wiki/Meetings/ > CyborgTeamMeeting#Agenda_for_next_meeting > > our IRC channel is #openstack-cyborg > > -- > Zhipeng (Howard) Huang > > Standard Engineer > IT Standard & Patent/IT Prooduct Line > Huawei Technologies Co,. Ltd > Email: huangzhip...@huawei.com > Office: Huawei Industrial Base, Longgang, Shenzhen > > (Previous) > Research Assistant > Mobile Ad-Hoc Network Lab, Calit2 > University of California, Irvine > Email: zhipe...@uci.edu > Office: Calit2 Building Room 2402 > > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado > -- 宋慢 Harm Sluiman __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [acceleration]Team Bi-weekly Meeting 2016.12.21 Agenda
Assuming we have a room/place and objectives, I can attend. On Wed, Dec 21, 2016 at 11:15 AM, Zhipeng Huang wrote: > Hi all, > > Thanks for attending the last team meeting in year 2016 :) Please find the > meeting notes at https://wiki.openstack.org/wiki/Cyborg/MeetingLogs#2016- > 12-21 . > > Our next meeting will be held at Jan 4th, 2017. > > At the meantime, could you indicate whether you would attend Atlanta PTG > by replying to this email ? Many thanks :) > > On Wed, Dec 21, 2016 at 3:14 PM, Zhipeng Huang > wrote: > >> Hi Team, >> >> Please find the agenda at https://wiki.openstack.org/ >> wiki/Meetings/CyborgTeamMeeting#Next_meeting_:_UTC_1500.2C_Dec_21th >> >> Remember that our IRC channel is #openstack-cyborg >> >> -- >> Zhipeng (Howard) Huang >> >> Standard Engineer >> IT Standard & Patent/IT Prooduct Line >> Huawei Technologies Co,. Ltd >> Email: huangzhip...@huawei.com >> Office: Huawei Industrial Base, Longgang, Shenzhen >> >> (Previous) >> Research Assistant >> Mobile Ad-Hoc Network Lab, Calit2 >> University of California, Irvine >> Email: zhipe...@uci.edu >> Office: Calit2 Building Room 2402 >> >> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado >> > > > > -- > Zhipeng (Howard) Huang > > Standard Engineer > IT Standard & Patent/IT Prooduct Line > Huawei Technologies Co,. Ltd > Email: huangzhip...@huawei.com > Office: Huawei Industrial Base, Longgang, Shenzhen > > (Previous) > Research Assistant > Mobile Ad-Hoc Network Lab, Calit2 > University of California, Irvine > Email: zhipe...@uci.edu > Office: Calit2 Building Room 2402 > > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado > -- 宋慢 Harm Sluiman __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [acceleration]Team Biweekly Meeting 2016.11.23 agenda
yup agree We have spent more time thinking through FPGA and GPU but certainly all devices are possible. Miroslav, you may recall in the isn examples I sent a while back I called them “programmable devices” ;-) We may need to think about defining a crips line however between these managed devices versus anything attached by PCI, but maybe not. Up for discussion I think… > On Dec 7, 2016, at 10:11 AM, Zhipeng Huang wrote: > > Hi Miroslav, > > GPU and NVMe devices are definitely in my understanding within the scope of > Cyborg, however we need a road map for each type of accelerator devices :) > > > On Wed, Dec 7, 2016 at 4:04 AM, Miroslav Halas <mailto:mha...@lenovo.com>> wrote: > Hello Harm, > > > > Thank you for sharing. I was wondering if you have given any thoughts how > other type of devices other than FPGAs would fit into this framework. For > example, GPUs or block devices (such as NVMe drives) for exclusive access by > the VMs. Could these type of devices be also managed by cyborg? > > > > Thanks, > > > > Miro Halas > > > > From: Harm Sluiman [mailto:harm.slui...@gmail.com > <mailto:harm.slui...@gmail.com>] > Sent: Saturday, December 03, 2016 4:54 AM > To: Zhipeng Huang > Cc: OpenStack Development Mailing List (not for usage questions); > rodolfo.alonso.hernan...@intel.com > <mailto:rodolfo.alonso.hernan...@intel.com>; Michele Paolino; Scott Kelso; > Roman Dobosz; Jim Golden; Miroslav Halas; pradeep.jagade...@huawei.com > <mailto:pradeep.jagade...@huawei.com>; michael.ro...@nokia.com > <mailto:michael.ro...@nokia.com>; jian-feng.d...@intel.com > <mailto:jian-feng.d...@intel.com>; martial.mic...@nist.gov > <mailto:martial.mic...@nist.gov>; Moshe Levi; Edan David; Francois Ozog; Fei > K Chen; jack...@huawei.com <mailto:jack...@huawei.com>; lil...@huawei.com > <mailto:lil...@huawei.com> > Subject: Re: [acceleration]Team Biweekly Meeting 2016.11.23 agenda > > > > Team I promised to comment on NASCA and provide some thoughts and ppt on > flows for cyborg > > > > Sorry for the delay. > > > > I added a few words to the NASCA etherpad, > > > > I waited for cyborg git to drop ppt but no luck yet so I put it here on > google drive. I hope you can reach it. follow it in show mode for a “rich” > experience ;-) > > I captured some FPGA run time flows as background, and then some sequences of > lifecycle management. I have shared this with a few of you before. > > https://drive.google.com/open?id=0B_Dc7PdTARsxc2cwTlJnelctWHM > <https://drive.google.com/open?id=0B_Dc7PdTARsxc2cwTlJnelctWHM> > I am creating etherpad to discuss > > https://etherpad.openstack.org/p/cyborg-initial-flow-discussion > <https://etherpad.openstack.org/p/cyborg-initial-flow-discussion> > I am also creating an etherpad to discuss the in POC we have talked about for > February to help define the scope of Cyborg > > https://etherpad.openstack.org/p/cyborg-initial-design-poc > <https://etherpad.openstack.org/p/cyborg-initial-design-poc> > > > > > I would also like to intro/welcome a couple more people to the Cyborg topic > > > > Chen, Fei (aka Fei) from IBM research and the SuperVessel project among > other things > > Jack Ng and Li Liu, my colleagues from Huawei that will be participating in > Cyborg and helping get our initial POC underway > > > > > > > > > > > > > > Thanks for your time. > 宋哲 > Harm Sluiman > > > > > > > > On Nov 23, 2016, at 11:49 PM, Zhipeng Huang <mailto:zhipengh...@gmail.com>> wrote: > > > > Hi team, > > > > Thanks for the discussion and please find the minutes here > https://wiki.openstack.org/wiki/Cyborg/MeetingLogs > <https://wiki.openstack.org/wiki/Cyborg/MeetingLogs> > > > On Wed, Nov 23, 2016 at 8:38 PM, Zhipeng Huang <mailto:zhipengh...@gmail.com>> wrote: > > Forward here again in case you have not registered to openstack-dev > mailinglist > > > > -- Forwarded message -- > From: Zhipeng Huang mailto:zhipengh...@gmail.com>> > Date: Wed, Nov 23, 2016 at 8:34 PM > Subject: [acceleration]Team Biweekly Meeting 2016.11.23 agenda > To: "OpenStack Development Mailing List (not for usage questions)" > mailto:openstack-dev@lists.openstack.org>> > > > Hi Team, > > > > Please find the meeting logistics and agendas at > https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting > <https://wiki.openstack
Re: [openstack-dev] [acceleration]Team Biweekly Meeting 2016.11.23 agenda
Team I promised to comment on NASCA and provide some thoughts and ppt on flows for cyborg Sorry for the delay. I added a few words to the NASCA etherpad, I waited for cyborg git to drop ppt but no luck yet so I put it here on google drive. I hope you can reach it. follow it in show mode for a “rich” experience ;-) I captured some FPGA run time flows as background, and then some sequences of lifecycle management. I have shared this with a few of you before. https://drive.google.com/open?id=0B_Dc7PdTARsxc2cwTlJnelctWHM <https://drive.google.com/open?id=0B_Dc7PdTARsxc2cwTlJnelctWHM> I am creating etherpad to discuss https://etherpad.openstack.org/p/cyborg-initial-flow-discussion <https://etherpad.openstack.org/p/cyborg-initial-flow-discussion> I am also creating an etherpad to discuss the in POC we have talked about for February to help define the scope of Cyborg https://etherpad.openstack.org/p/cyborg-initial-design-poc <https://etherpad.openstack.org/p/cyborg-initial-design-poc> I would also like to intro/welcome a couple more people to the Cyborg topic Chen, Fei (aka Fei) from IBM research and the SuperVessel project among other things Jack Ng and Li Liu, my colleagues from Huawei that will be participating in Cyborg and helping get our initial POC underway Thanks for your time. 宋哲 Harm Sluiman > On Nov 23, 2016, at 11:49 PM, Zhipeng Huang wrote: > > Hi team, > > Thanks for the discussion and please find the minutes here > https://wiki.openstack.org/wiki/Cyborg/MeetingLogs > <https://wiki.openstack.org/wiki/Cyborg/MeetingLogs> > > On Wed, Nov 23, 2016 at 8:38 PM, Zhipeng Huang <mailto:zhipengh...@gmail.com>> wrote: > Forward here again in case you have not registered to openstack-dev > mailinglist > > -- Forwarded message -- > From: Zhipeng Huang mailto:zhipengh...@gmail.com>> > Date: Wed, Nov 23, 2016 at 8:34 PM > Subject: [acceleration]Team Biweekly Meeting 2016.11.23 agenda > To: "OpenStack Development Mailing List (not for usage questions)" > mailto:openstack-dev@lists.openstack.org>> > > > Hi Team, > > Please find the meeting logistics and agendas at > https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting > <https://wiki.openstack.org/wiki/Meetings/CyborgTeamMeeting> > > -- > Zhipeng (Howard) Huang > > Standard Engineer > IT Standard & Patent/IT Prooduct Line > Huawei Technologies Co,. Ltd > Email: huangzhip...@huawei.com <mailto:huangzhip...@huawei.com> > Office: Huawei Industrial Base, Longgang, Shenzhen > > (Previous) > Research Assistant > Mobile Ad-Hoc Network Lab, Calit2 > University of California, Irvine > Email: zhipe...@uci.edu <mailto:zhipe...@uci.edu> > Office: Calit2 Building Room 2402 > > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado > > > > -- > Zhipeng (Howard) Huang > > Standard Engineer > IT Standard & Patent/IT Prooduct Line > Huawei Technologies Co,. Ltd > Email: huangzhip...@huawei.com <mailto:huangzhip...@huawei.com> > Office: Huawei Industrial Base, Longgang, Shenzhen > > (Previous) > Research Assistant > Mobile Ad-Hoc Network Lab, Calit2 > University of California, Irvine > Email: zhipe...@uci.edu <mailto:zhipe...@uci.edu> > Office: Calit2 Building Room 2402 > > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado > > > > -- > Zhipeng (Howard) Huang > > Standard Engineer > IT Standard & Patent/IT Prooduct Line > Huawei Technologies Co,. Ltd > Email: huangzhip...@huawei.com <mailto:huangzhip...@huawei.com> > Office: Huawei Industrial Base, Longgang, Shenzhen > > (Previous) > Research Assistant > Mobile Ad-Hoc Network Lab, Calit2 > University of California, Irvine > Email: zhipe...@uci.edu <mailto:zhipe...@uci.edu> > Office: Calit2 Building Room 2402 > > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [acceleration]Team Biweekly Meeting 2016.11.10 minutes
Hi Howard. Can you send out the IRC in advance if you have it for Wednesday meeting? On Thu, Nov 10, 2016 at 10:55 AM, Zhipeng Huang wrote: > Hi Team, > > Thanks for attending today's meeting and again sorry for not be able to > host it on yesterday. > > Since we don't have a meetbot now associated with a fix channel, I > recorded the irc chat in a doc file and you could find it in the attachment. > > Key Takeaways: > 1. Nomad project will be renamed to Cyborg (what a cool name) based upon > our final tally on the etherpad > <https://etherpad.openstack.org/p/nomad-ocata-design-session> > 2. Moshe introduced Nacsa project proposal, and an initial design doc has > been shared among the team. We will make the doc public after a few rounds > of review and discussion > 3. Reminder for the team to take a look at the Scientific Working Group > etherpad <https://etherpad.openstack.org/p/scientific-wg-barcelona-agenda> for > use cases > > Our next meeting will be on Nov 23th, 10:00am on irc > > -- > Zhipeng (Howard) Huang > > Standard Engineer > IT Standard & Patent/IT Prooduct Line > Huawei Technologies Co,. Ltd > Email: huangzhip...@huawei.com > Office: Huawei Industrial Base, Longgang, Shenzhen > > (Previous) > Research Assistant > Mobile Ad-Hoc Network Lab, Calit2 > University of California, Irvine > Email: zhipe...@uci.edu > Office: Calit2 Building Room 2402 > > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado > -- 宋慢 Harm Sluiman __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] FPGA as a dynamic nested resources
> On Jul 28, 2016, at 7:57 AM, Jay Pipes wrote: > > On 07/19/2016 06:51 PM, Ed Leafe wrote: >> On Jul 19, 2016, at 2:58 PM, Chris Friesen >> wrote: Why would a VM program the slot? Wouldn’t it usually be at the host level? >>> >>> Are there no cases where a VM might want to download a proprietary >>> program into an FPGA? >> >> That doesn’t sound right to me, but maybe I’m just not that familiar >> with FPGA specifics. In general, VMs don’t control their hosts. > > Oh, but in NFV-land they most certainly do. :/ > > It's commonplace now to see NFV use cases where VMs are provided passthrough > access to an SR-IOV physical function on the host and the VMs application > code then controls and allocates at will virtual functions from that physical > function. Once that happens, yes, it's true that Nova no longer has any clue > about the resource usage of VFs on that host device -- it's essentially at > that point totally up to the VNF software to properly manage and maintain > access to those VFs and allocate/free resources as needed on the host device. > Agreed as a statement of today. Once the “VM” application has what looks like dedicated FPGA resources to it, it typically does both management and optionally the actual application workload. That typically includes loading the bitstream on the device as well and then executing API calls to the service it then provides. This can all be done now with PCIe/SR-IOV , which is great…. But the generic boards are getting bigger and we often want greater utilization of them and to virtualize and manage them separately from the VM based application code that may utilize them. In other words these “funky” devices are becoming hosts for dynamically loaded services. While a key first step to enable allocating the virtual region of the device to a VM when it is provisioned, we may want to enable separating management from data plane (aka workload) and support dynamic service consumption through more than network connections. VNFs are a use case for sure and a dominant one, but now that we have NICs on these large boards and also want to support service chaining, we have the opportunity to do that without consuming many CPU cycles. When I can push firewall, or ipsec or compression to the “NIC” and not use CPU cycles, why not ;-), and why not share it to other nearby VMs. Then take it past VNFs to other workloads that can exploit FPGA... > Same goes for FPGAs. VNF vendors want access to the physical host device and > want to be able to do with that host device whatever they please. > > As I wrote on Twitter recently, NFV is changing software-defined > infrastructure to instead be hardware-defined software. > > It's a funky new* world we live in, Ed :) > > -jay > > * new == old == new again. > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] FPGA as a dynamic nested resources
On Jul 21, 2016 5:12 AM, "Daniel P. Berrange" wrote: > > On Thu, Jul 21, 2016 at 07:54:48AM +0200, Roman Dobosz wrote: > > On Wed, 20 Jul 2016 10:07:12 +0100 > > "Daniel P. Berrange" wrote: > > > > Hey Daniel, thanks for the feedback. > > > > > > Thoughts? > > > > > > I'd suggest you'll increase your chances of success with nova design > > > approval if you focus on implementing a really simple usage scheme for > > > FPGA as the first step in Nova. > > > > This. Maybe I'm wrong, but for me the minimal use case for FPGA would > > be ability to schedule VM which need certain accelerator from multiple > > potential ones on available FPGA/fixed slot. How insane does it sound? > > > > Providing fixed, prepared earlier by DC administrator accelerator > > resource, doesn't bring much value, beyond what we already have in > > Nova, since PCI/SR-IOV passthrough might be used for accelerators, > > which expose their functionality via VF. > > IIUC, there's plenty of FPGAs which are not SRIOV based, so there's > still scope for Nova enhancement in this area. > > The fact that some FPGAs are SRIOV & some are not though, is is also > why I'm suggesting that any work related to FPGA should be based around > refactoring of the existing PCI device assignment model to form a more > generic "Hardware device assignment" model. If we end up having a > completely distinct data model for FPGAs that is a failure. We need to > have a generalized hardware assignment model that can be used for generic > PCI devices, NICs, FPGAs, TPMs, GPUs, etc regardless of whether they > are backed by SRIOV, or their own non-PCI virtual functions. Personally > I'll reject any spec proposal that ignores existing PCI framework and > introduces a separate model for FPGA. > > > > All the threads I've see go well off into the weeds about trying to > > > solve everybody's niche/edge cases perfectly and as a result get > > > very complicated. > > > > The topic is complicated :) > > Which is why i'm advising to not try to solve the perfect case and instead > focus on getting something simple & good enough for common case. > I think the simple use cases can be covered today for PCIe SR-IOV config easily and some number of VFs are applied to regions of a pre-initialized board. I know of successful deployments that do the initialization with ironic and use nova to allocate the PCIe SR-IOV access using existing extension points. Once allocated the actual function bitstream gets pushed in by the owning VM. The application owners manage concurrency. This level of support could be made mainstream rather than custom extension as a first step and then add support for alternatives to PCIe based connections. That said there are many use cases in play today outside of openstack unfortunately that manage the loading of the bitstream that implements a specific function. The desire is to load those bitstreams and manage a life cycle just like we manage a VM and image today. In effect the static region of the FPGA has the role of a very simple hypervisor. FPGA boards are getting denser and more common, and they are getting their own peripherals like on board NICs, serial ports, storage etc. I don't believe we need to expose complicated physical structure to management, but a device with the ability to be virtualized and dynamically programmed and has connection to the other infrastructure in the environment needs to be managed withe things it connects to. I suggest the following : First standardize how to describe and allocate a real or virtualized FPGA. Specify the meta data and related filter rules. Second, mirror the glance/nova process of image loading on hypervisor for bitstream loading of a reProgramable Region. Third keep the functions of the actual bit stream separate from the above management just like we do with VM or container functional capabilities. When the lifecycle of the PR is tied to a VM, just like ephemeral storage, driving allocation from nova seems to make the most sense. Am I way out of line? > Regards, > Daniel > -- > |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] Please vote -> Removal of Harm Weites from the core reviewer team
Hi guys, As Steven noted, activity from my side has dropped significantly, and with +2 comes a certain responsibility of at the very least keeping track of the codebase. Various reasons keep me from even doing that so this seems the logical outcome. Thanks for your support, it’s been a great ride :) see you in #kolla! > Op 15 jan. 2016, om 20:10 heeft Steven Dake (stdake) het > volgende geschreven: > > I counted 6 votes in favor of removal. We have 10 people on our core team. > A majority has been met and I have removed Harm from the core reviewer team. > > Harm, > > Thanks again for your helpful reviews and remember, your always welcome back > in the future if your availability changes. > > For the record, the core reviewers that voted for removal were: > Steven Dake > Jeff Peeler > Paul Bourke > Michal Jastrzebski > Ryan Hallisey > Michal Rostecki > > Regards, > -steve > > > From: Steven Dake mailto:std...@cisco.com>> > Reply-To: openstack-dev <mailto:openstack-dev@lists.openstack.org>> > Date: Thursday, January 14, 2016 at 5:12 PM > To: openstack-dev <mailto:openstack-dev@lists.openstack.org>> > Subject: [openstack-dev] [kolla] Please vote -> Removal of Harm Weites from > the core reviewer team > > Hi fellow core reviewers, > > Harm joined Kolla early on with great enthusiasm and did a bang-up job for > several months working on Kolla. We voted unanimously to add him to the core > team. Over the last 6 months Harm hasn't really made much contribution to > Kolla. I have spoken to him about it in the past, and he indicated his work > and other activities keep him from being able to execute the full job of a > core reviewer and nothing environmental is changing in the near term that > would improve things. > > I faced a similar work/life balance problem when working on Magnum as a core > reviewer and also serving as PTL for Kolla. My answer there was to step down > from the Magnum core reviewer team [1] because Kolla needed a PTL more then > Magnum needed a core reviewer. I would strongly prefer if folks don't have > the time available to serve as a Kolla core reviewer, to step down as was > done in the above example. Folks that follow this path will always be > welcome back as a core reviewer in the future once they become familiar with > the code base, people, and the project. > > The other alternative to stepping down is for the core reviewer team to vote > to remove an individual from the core review team if that is deemed > necessary. For future reference, if you as a core reviewer have concerns > about a fellow core reviewer's performance, please contact the current PTL > who will discuss the issue with you. > > I propose removing Harm from the core review team. Please vote: > > +1 = remove Harm from the core review team > -1 = don't remove Harm from the core review team > > Note folks that are voted off the core review team are always welcome to > rejoin the core team in the future once they become familiar with the code > base, people, and the project. Harm is a great guy, and I hope in the future > he has more time available to rejoin the Kolla core review team assuming this > vote passes with simple majority. > > It is important to explain why, for some folks that may be new to a core > reviewer role (which many of our core reviewers are), why a core reviewer > should have their +2/-2 voting rights removed when they become inactive or > their activity drops below an acceptable threshold for extended or permanent > periods. This hasn't happened in Harm's case, but it is possible that a core > reviewer could approve a patch that is incorrect because they lack sufficient > context with the code base. Our core reviewers are the most important part > of ensuring quality software. If the individual has lost context with the > code base, their voting may be suspect, and more importantly the other core > reviewers may not trust the individual's votes. Trust is the cornerstone of > a software review process, so we need to maximize trust on a technical level > between our core team members. That is why maintaining context with the code > base is critical and why I am proposing a vote to remove Harm from the core > reviewer team. > > On a final note, folks should always know, joining the core review team is > never "permanent". Folks are free to move on if their interests take them > into other areas or their availability becomes limited. Core Reviewers can > also be removed by majority vote. If there is any core reviewer's > performance you are concerned with, please contact the current
Re: [openstack-dev] [kolla] Proposing Michal Rostecki for Core Reviewer (nihilfer on IRC)
+1 :) Jeff Peeler schreef op 2015-11-13 19:51: On 12/11/15 08:41, Steven Dake (stdake) wrote: Hey folks, Its been awhile since we have had a core reviewer nomination, but I really feel like Michal has the right stuff. If you look at the 30 day stats for kolla[1] , he is #3 in reviews (70 reviews) with 6 commits in a 30 day period. He is beating 2/3rds of our core reviewer team on all stats. I think his reviews, while could use a little more depth, are solid and well considered. That said he participates on the mailing list more then others and has been very active in IRC. He has come up to speed on the code base in quick order and I expect if he keeps pace, the top reviewers in Kolla will be challenged to maintain their spots :) Consider this proposal as a +1 vote from me. As a reminder, our core review process requires 3 core reviewer +1 votes, with no core reviewer –1 (veto) votes within a 1 week period. If your on the fence, best to abstain :) I'll close voting November 20th, or sooner if there I a veto vote or a unanimous vote. Regards -steve http://stackalytics.com/report/contribution/kolla-group/30 +1! ___ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] Integrating kollacli as python-kollaclient
+1 this sort of stuff makes live a lot better :) Swapnil Kulkarni schreef op 2015-10-23 07:08: On Thu, Oct 22, 2015 at 3:50 AM, Steven Dake (stdake) wrote: Hello Folks, Oracle has developed a CLI tool for managing OpenStack Kolla clusters. Several months ago at our midcycle, the topic was brought up an I suggested to go ahead and get started on the work. We clearly didn't spend enough time discussing how it should be integrated into the code base or developed or even what its features should be, and that is my error. What ended up happening is sort of a code dump, which is not ideal, but I can only work so many 20 hour days ;) I didn't believe our community had the bandwidth to deal with integrating a CLI directly into the tree while we were focused on our major objective of implementing Ansible deployment of OpenStack in Docker containers. Possibly the wrong call, but it is what it is and it is my error, not Oracles. I think user experience will of the one of the major milestones for Kolla in Mitaka, e.g. user facing documentation, operator integration etc. a CLI would be helpful in that. The code can be cloned from: git clone git://oss.oracle.com/git/openstack-kollacli.git [1] The code as is is very high quality but will likely need to go through alot of refactoring to ReST-ify it. There are two major authors of the code, Borne Mace and Steve Noyes. I'd like a majority vote from the core team as to whether we should add this repository to our list of governed repositories in the OpenStack Kolla governance repository here: hub.com/openstack/governance/blob/master/reference/projects.yaml#L1509 [2] Consider this email a +1 vote from me. +1 from me A completely separate email thread and decision will be made by the community about core team membership changes to handle maintenance of the code. Assuming this code is voted into Kolla's governance, I plan to propose Borne as a core reviewer, which will be open to core team vote as a separate act with our 3 +1 votes no vetos within 1 week period. We will address that assuming a majority vote of the code merge wins. Steve can follow the normal processes for joining the core team if he wishes (reviewing patches) - clearly his code contributions are there. Borne already does some reviews, and although he isn't a top reviewer, he does have some contribution in this area making it into the top 10 for the Liberty cycle. Kolla CLI Features: * dynamic ansible inventory manipulation via the host, group and service commands * ssh key push via the host setup command * ssh key validation via the host check command * ansible deployment via the deploy command * property viewing and modification with the property list, set and clear commands * cleanup of docker containers on a single, multiple or all hosts via the host destroy command * debug data collection via the dump command * configuration of openstack passwords via the password command * Lines of python = 2700 * Lines of test case code = 1800 * ~ 200 commits ___ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe [3] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [4] Links: -- [1] http://oss.oracle.com/git/openstack-kollacli.git [2] hub.com/openstack/governance/blob/master/reference/projects.yaml#L1509 [3] http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe [4] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] proposing Michal Jastrzebski (inc0) for core reviewer
Looks like he passed 3 already, but here's another +1 :) Steven Dake (stdake) schreef op 2015-09-30 00:20: Hi folks, I am proposing Michal for core reviewer. Consider my proposal as a +1 vote. Michal has done a fantastic job with rsyslog, has done a nice job overall contributing to the project for the last cycle, and has really improved his review quality and participation over the last several months. Our process requires 3 +1 votes, with no veto (-1) votes. If your uncertain, it is best to abstain :) I will leave the voting open for 1 week until Tuesday October 6th or until there is a unanimous decision or a veto. Regards -steve ___ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] Followup to review in gerrit relating to RHOS + RDO types
we add?” sort of sounds like ‘how many do we support?”. The answer to the second question is none – again the Kolla community does not support any deployment of OpenStack. To the question as posed, how many we add, the answer is it is really up to community members willing to implement and maintain the work. In this case, I have personally stepped up to implement RHOS and maintain it going forward. Our policy on adding a new type could be simple or onerous. I prefer simple. If someone is willing to write the code and maintain it so that is stays in good working order, I see no harm in it remaining in tree. I don’t suspect there will be a lot of people interested in adding multiple distributions for a particular operating system. To my knowledge, and I could be incorrect, Red Hat is the only OpenStack company with a paid and community version available of OpenStack simultaneously and the paid version is only available on RHEL. I think the risk of RPM based distributions plus their type count spiraling out of manageability is low. Even if the risk were high, I’d prefer to keep an open mind to facilitate an increase in diversity in our community (which is already fantastically diverse, btw ;) I am open to questions, comments or concerns. Please feel free to voice them. Regards, -steve ___ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe [4] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [5] Both arguments sound valid to me, both have pros and cons. I think it's valuable to look to the experiences of Cinder and Neutron in this area, both of which seem to have the same scenario and have existed much longer than Kolla. From what I know of how these operate, proprietary code is allowed to exist in the mainline so long as certain set of criteria is met. I'd have to look it up but I think it mostly comprises of the relevant parties must "play by the rules", e.g. provide a working CI, help with reviews, attend weekly meetings, etc. If Kolla can look to craft a similar set of criteria for proprietary code down the line, I think it should work well for us. Steve has a good point in that it may be too much overhead to implement a plugin system or similar up front. Instead, we should actively monitor the overhead in terms of reviews and code size that these extra implementations add. Perhaps agree to review it at the end of Mitaka? Given the project is young, I think it can also benefit from the increased usage and exposure from allowing these parties in. I would hope independent contributors would not feel rejected from not being able to use/test with the pieces that need a license. The libre distros will remain #1 for us. So based on the above explanation, I'm +1. -Paul ___ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe [4] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev [5] Given Paul's comments I would agree here as well. I would like to get that 'criteria' required for Kolla to allow this proprietary code into the main repo down as soon as possible though and suggest that we have a bare minimum of being able to gate against it as one of the criteria. As for a plugin system, I also agree with Paul that we should check the overhead of including these other distros and any types needed after we have had time to see if they do introduce any additional overhead. So for the question 'Do we allow code that relies on proprietary packages?' I would vote +1, with the condition that we define the requirements of allowing that code as soon as possible. Links: -- [1] https://review.openstack.org/#/c/222893/ [2] https://wiki.openstack.org/wiki/CinderSupportMatrix [3] https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers [4] http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe [5] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] Proposing Swapnil Kulkarni (coolsvap) for kolla core reviewer team
great! +1 :) Op 14-08-15 om 15:38 schreef Paul Bourke: +1, Swapnil has made a ton of useful contributions and continues to do so :) On 14/08/15 14:29, Steven Dake (stdake) wrote: Hi folks, Swapnil has done a bunch of great technical work, participates heavily in IRC, and has contributed enormously to the implementation of Kolla. I’d like to see more reviews from Swapnil, but he has committed to doing more reviews and already has gone from something like 0 reviews to 90 reviews in about a month. Count this proposal as a +1 from me. His 90 day stats are: http://stackalytics.com/report/contribution/kolla-group/90 The process we go to select new core reviewers is that we require a minimum of 3 +1 votes within a 1 week voting window. A vote of –1 is a veto. It is fine to abstain as well without any response to this email. If the vote is unanimous or there is a veto vote prior to the end of the voting window, I’ll close voting then. The voting is open until Friday August 21st. Thanks! -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla][magnum] Removal of Daneyon Hansen from the Core Reviewer team for Kolla
Agreed, everyone should do what they love - so I wish you the best of luck with the Magnum crew Daneyon! Op 22-07-15 om 22:47 schreef Steven Dake (stdake): Fellow Kolla developers, Daneyon has been instrumental in getting Kolla rolling and keeping our project alive. He even found me a new job that would pay my mortgage and Panamera payment so I could continue performing as PTL for Kolla and get Magnum off the ground. But Daneyon has conferred with me that he has a personal objective of getting highly involved in the Magnum project and leading the container networking initiative coming out of Magnum. For a sample of his new personal mission: https://review.openstack.org/#/c/204686/ I’m a bit sad to lose Daneyon to Magnum, but life is short and not sweet enough. I personally feel people should do what makes them satisfied and happy professionally. Daneyon will still be present at the Kolla midcycle and contribute to our talk (if selected by the community) in Tokyo. I expect Daneyon will make a big impact in Magnum, just as he has with Kolla. In the future if Daneyon decides he wishes to re-engage with the Kolla project, we will welcome him with open arms because Daneyon rocks and does super high quality work. NB Typically we would vote on removal of a core reviewer, unless they wish to be removed to focus on on other projects. Since that is the case here, there is no vote necessary. Please wish Daneyon well in his adventures in Magnum territory and prey he comes back when he finishes the job on Magnum networking :) Regards -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core
no-brainer: +1 Op 14-07-15 om 13:19 schreef Ryan Hallisey: +1 I echo all the prior comments. -Ryan - Original Message - From: "Steven Dake (stdake)" To: "OpenStack Development Mailing List (not for usage questions)" Sent: Monday, July 13, 2015 10:40:11 PM Subject: [openstack-dev] [kolla] Proposal for Paul Bourke for Kolla Core Hey folks, I am proposing Paul Bourke for the Kolla core team. He did a fantastic job getting Kolla into shape to support multiple distros and from source/from binary installation. His statistics are fantastic including both code and reviews. His reviews are not only voluminous, but consistently good. Paul is helping on many fronts and I would feel make a fantastic addition to our core reviewer team. Consider my proposal to count as one +1 vote. Any Kolla core is free to vote +1, abstain, or vote –1. A –1 vote is a veto for the candidate, so if you are on the fence, best to abstain :) We require 3 core reviewer votes to approve a candidate. I will leave the voting open until July 20th UTC. If the vote is unanimous prior to that time or a veto vote is received, I’ll close voting and make appropriate adjustments to the gerrit groups. Regards -steve __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] Proposal for changing 1600UTC meeting to 1700 UTC
I'm ok with moving to 16:30 UTC instead of staying at 16:00. I actually prefer it in my evening schedule :) Moving to 16:30 would already be a great improvement to the current schedule and should at least allow me to not miss everything. - harmw Op 12-06-15 om 15:44 schreef Steven Dake (stdake): Even though 7am is not ideal for the west coast, I¹d be willing to go back that far. That would put the meeting at the morning school rush for the west coast folks though (although we are in summer break in the US and we could renegotiate a time in 3 months when school starts up again if its a problem) - so creating different set of problems for different set of people :) This would be a 1400 UTC meeting. While I wake up prior to 7am, (usually around 5:30) I am not going to put people through the torture of a 6am meeting in any timezone if I can help it so 1400 is the earliest we can go :) Regards -steve On 6/12/15, 4:37 AM, "Paul Bourke" wrote: I'm fairly easy on this but, if the issue is that the meeting is running into people's evening schedules (in EMEA), would it not make sense to push it back an hour or two into office hours, rather than forward? On 10/06/15 18:20, Ryan Hallisey wrote: After some upstream discussion, moving the meeting from 1600 to 1700 UTC does not seem very popular. It was brought up that changing the time to 16:30 UTC could accommodate more people. For the people that attend the 1600 UTC meeting time slot can you post further feedback to address this? Thanks, Ryan - Original Message - From: "Jeff Peeler" To: "OpenStack Development Mailing List (not for usage questions)" Sent: Tuesday, June 9, 2015 2:19:00 PM Subject: Re: [openstack-dev] [kolla] Proposal for changing 1600UTC meeting to 1700 UTC On Mon, Jun 08, 2015 at 05:15:54PM +, Steven Dake (stdake) wrote: Folks, Several people have messaged me from EMEA timezones that 1600UTC fits right into the middle of their family life (ferrying kids from school and what-not) and 1700UTC while not perfect, would be a better fit time-wise. For all people that intend to attend the 1600 UTC, could I get your feedback on this thread if a change of the 1600UTC timeslot to 1700UTC would be acceptable? If it wouldn¹t be acceptable, please chime in as well. Both 1600 and 1700 UTC are fine for me. Jeff _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _ _ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla] Proposal for new core-reviewer Harm Waites
Thanks guys, both for all the nice words and the acceptance!
harmw
Op 16-06-15 om 16:32 schreef Steven Dake (stdake):
Its unanimous! Welcome to the core reviewer team Harm!
Regards
-steve
From: Steven Dake mailto:std...@cisco.com>>
Reply-To: "OpenStack Development Mailing List (not for usage
questions)" <mailto:openstack-dev@lists.openstack.org>>
Date: Sunday, June 14, 2015 at 10:48 AM
To: "OpenStack Development Mailing List (not for usage questions)"
<mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [kolla] Proposal for new core-reviewer Harm
Waites
Hey folks,
I am proposing Harm Waites for the Kolla core team. He did a
fantastic job implementing Designate in a container[1] which I’m
sure was incredibly difficult and never gave up even though there
were 13 separate patch reviews :) Beyond Harm’s code
contributions, he is responsible for 32% of the “independent”
reviews[1] where independents compose 20% of our total reviewer
output. I think we should judge core reviewers on more then
output, and I knew Harm was core reviewer material with his
fantastic review of the cinder container where he picked out 26
specific things that could be broken that other core reviewers may
have missed ;) [3]. His other reviews are also as thorough as
this particular review was. Harm is active in IRC and in our
meetings for which his TZ fits. Finally Harm has agreed to
contribute to the ansible-multi implementation that we will finish
in the liberty-2 cycle.
Consider my proposal to count as one +1 vote.
Any Kolla core is free to vote +1, abstain, or vote –1. A –1 vote
is a veto for the candidate, so if you are on the fence, best to
abstain :) Since our core team has grown a bit, I’d like 3 core
reviewer +1 votes this time around (vs Sam’s 2 core reviewer
votes). I will leave the voting open until June 21 UTC. If
the vote is unanimous prior to that time or a veto vote is
received, I’ll close voting and make appropriate adjustments to
the gerrit groups.
Regards
-steve
[1] https://review.openstack.org/#/c/182799/
[2]
http://stackalytics.com/?project_type=all&module=kolla&company=%2aindependent
[3] https://review.openstack.org/#/c/170965/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Status of Neutron IPv6 dual stack
Hi, We're running Juno since a few weeks now, is it now possible to go dual stack with l3-routers or are there some pieces missing and should I wait for Kilo? -Harm On 08/19/2014 07:08 PM, Dane Leblanc (leblancd) wrote: > > Hi Harm: > > > > Unfortunately I haven’t had time to complete the changes yet. Even > if/when these changes are completed, it’s unlikely that this blueprint > will get approved for Juno, but I’ll see what I can do. > > > > Thanks, > > Dane > > > > > > *From:*Harm Weites [mailto:h...@weites.com] > *Sent:* Tuesday, August 19, 2014 12:53 PM > *To:* openstack-dev@lists.openstack.org > *Subject:* Re: [openstack-dev] Status of Neutron IPv6 dual stack > > > > Thiago, > > My old setup was dual-stacked, simply using a flat linuxbridge. It's > just that I now realy would like to separate multiple tenants using L3 > routers, which should be easy (dual stacked) to achieve once Dane's > work is completed. > > Did you find the time to commit those required changes for that yet Dane? > > Regards, > Harm > > op 16-08-14 23:33, Martinx - ジェームズ schreef: > > Guys, > > > > Just for the record, I'm using IceHouse in a Dual-Stacked > environment (with security groups working) but, Instance's IPv6 > address are static (no upstream SLAAC, arrived in Juno-2, I think) > and the topology is `VLAN Provider Networks`, no Neutron L3 > Router. Where each VLAN have v4/v6 addrs, same upstream router > (also dual-stacked - still no radvd enabled). > > > > Looking forward to start testing L3 + IPv6 in K... > > > > Best, > > Thiago > > > > On 16 August 2014 16:21, Harm Weites <mailto:h...@weites.com>> wrote: > > Hi Dane, > > Thanks, that looks promising. Once support for multiple v6 > addresses on > gateway ports is added I'll be happy to give this a go. Should it work > just fine with an otherwise Icehouse based deployment? > > Regards, > Harm > > op 16-08-14 20:31, Dane Leblanc (leblancd) schreef: > > > Hi Harm: > > > > Can you take a look at the following, which should address this: > > > https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes > > > > There are some diffs out for review for this blueprint: > >https://review.openstack.org/#/c/113339/ > > but the change to support 1 V4 + multiple V6 addresses on a > gateway port hasn't been added yet. I should be adding this soon. > > > > There was a request for a Juno feature freeze exception for this > blueprint, but there's been no response, so this may not get > approved until K release. > > > > -Dane > > > > -Original Message- > > From: Harm Weites [mailto:h...@weites.com <mailto:h...@weites.com>] > > Sent: Saturday, August 16, 2014 2:22 PM > > To: openstack-dev@lists.openstack.org > <mailto:openstack-dev@lists.openstack.org> > > Subject: [openstack-dev] Status of Neutron IPv6 dual stack > > > > Hi, > > > > Given the work on [1] has been abandoned, I'm wondering what the > current status of going dual stack is. Of course, given Neutron > got something like that on it's roadmap. > > > > The initial BP [2] aimed for Havana and Icehouse, and I'm > unaware of something similar to achieve a dual stack network. What > are the options, if any? To my knowledge it all comes down to > supporting multiple exterior interfaces (networks) on a l3-agent, > which is currently limited to just 1: either IP4 or IP6. > > > > [1] https://review.openstack.org/#/c/77471/ > > [2] > > > > https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port > > > > Regards, > > Harm > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _
Re: [openstack-dev] ipv6 and ipv4 dual stack for floating IP
I'm seeing the same error when trying to setup a whole new network
through Horizon with external gateway and an ipv4 and ipv6 subnet. Eg,
without floating ip.
l3_agent.py is trying this: prefixlen =
netaddr.IPNetwork(port['subnet']['cidr']).prefixlen
Looking inside port[] lists the following items:
2014-10-30 10:26:05.834 21765 ERROR neutron.agent.l3_agent [-] Ignoring
multiple IPs on router port b4d94d2a-0ba2-43f0-be5f-bb53e89abe32
2014-10-30 10:26:05.836 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[status] = DOWN
2014-10-30 10:26:05.837 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:host_id] = myhostname
2014-10-30 10:26:05.839 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[name] =
2014-10-30 10:26:05.840 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[allowed_address_pairs] = []
2014-10-30 10:26:05.841 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[admin_state_up] = True
2014-10-30 10:26:05.843 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[network_id] = 00539791-0b2f-4628-9599-622fa00993b5
2014-10-30 10:26:05.844 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[tenant_id] =
2014-10-30 10:26:05.846 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[extra_dhcp_opts] = []
2014-10-30 10:26:05.847 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:vif_details] = {}
2014-10-30 10:26:05.848 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:vif_type] = binding_failed
2014-10-30 10:26:05.849 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[device_owner] = network:router_gateway
2014-10-30 10:26:05.851 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[mac_address] = fa:16:3e:53:89:8d
2014-10-30 10:26:05.853 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:profile] = {}
2014-10-30 10:26:05.854 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[binding:vnic_type] = normal
2014-10-30 10:26:05.856 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[fixed_ips] = [{u'subnet_id':
u'faaf9c91-19ce-4c14-8f86-c81949cdbac5', u'ip_address':
u'192.168.64.30'}, {u'subnet_id':
u'381d0c54-1a4e-4a27-9858-a81202e81487', u'ip_address':
u'2001:470::64::'}]
2014-10-30 10:26:05.857 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[id] = b4d94d2a-0ba2-43f0-be5f-bb53e89abe32
2014-10-30 10:26:05.858 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[security_groups] = []
2014-10-30 10:26:05.860 21765 INFO neutron.agent.l3_agent [-] CHECK:
port[device_id] = d3bbec5a-2075-4229-ba88-698f27cd0943
_set_subnet_info() is set to log an ERROR when it encounters multiple
addresses and then happily continues doing something:
prefixlen = netaddr.IPNetwork(port['subnet']['cidr']).prefixlen
port['ip_cidr'] = "%s/%s" % (ips[0]['ip_address'], prefixlen)
Operations with just 1 (ipv6) ip go without any issues, the adress is
added to a namespace and pongs just fine. Adding 2 subnets to this
external net and creating a gateway to it on the l3 router causes a problem.
Do we need to wait for K before we can fully go dual-stack?
- Harm
op 29-10-14 15:29, Jerry Xinyu Zhao schreef:
> Hi
> I want to use both ipv4 and ipv6 for floating ip at the same time.
> However, I have the following issue when setting router gateway or
> associate floating ip to an instance.
> Is it supported in the first place? What should I do to make it work?
> Thanks!
>
> neutron router-list
> +--++---+-+---+
> | id | name |
> external_gateway_info
>
>
> |
> distributed | ha|
> +--++---+-+---+
> | b243c786-4648-4d69-b749-ee5fad02069b | default-router |
> {"network_id": "02eca54a-420d-4d52-b045-1207e17994e5", "enable_snat"
Re: [openstack-dev] Status of Neutron IPv6 dual stack
Hi Dane, Just wondering if you've made some progression on the matter :) Regards, Harm op 19-08-14 19:08, Dane Leblanc (leblancd) schreef: > > Hi Harm: > > > > Unfortunately I haven't had time to complete the changes yet. Even > if/when these changes are completed, it's unlikely that this blueprint > will get approved for Juno, but I'll see what I can do. > > > > Thanks, > > Dane > > > > > > *From:*Harm Weites [mailto:h...@weites.com] > *Sent:* Tuesday, August 19, 2014 12:53 PM > *To:* openstack-dev@lists.openstack.org > *Subject:* Re: [openstack-dev] Status of Neutron IPv6 dual stack > > > > Thiago, > > My old setup was dual-stacked, simply using a flat linuxbridge. It's > just that I now realy would like to separate multiple tenants using L3 > routers, which should be easy (dual stacked) to achieve once Dane's > work is completed. > > Did you find the time to commit those required changes for that yet Dane? > > Regards, > Harm > > op 16-08-14 23:33, Martinx - ? schreef: > > Guys, > > > > Just for the record, I'm using IceHouse in a Dual-Stacked > environment (with security groups working) but, Instance's IPv6 > address are static (no upstream SLAAC, arrived in Juno-2, I think) > and the topology is `VLAN Provider Networks`, no Neutron L3 > Router. Where each VLAN have v4/v6 addrs, same upstream router > (also dual-stacked - still no radvd enabled). > > > > Looking forward to start testing L3 + IPv6 in K... > > > > Best, > > Thiago > > > > On 16 August 2014 16:21, Harm Weites <mailto:h...@weites.com>> wrote: > > Hi Dane, > > Thanks, that looks promising. Once support for multiple v6 > addresses on > gateway ports is added I'll be happy to give this a go. Should it work > just fine with an otherwise Icehouse based deployment? > > Regards, > Harm > > op 16-08-14 20:31, Dane Leblanc (leblancd) schreef: > > > Hi Harm: > > > > Can you take a look at the following, which should address this: > > > https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes > > > > There are some diffs out for review for this blueprint: > >https://review.openstack.org/#/c/113339/ > > but the change to support 1 V4 + multiple V6 addresses on a > gateway port hasn't been added yet. I should be adding this soon. > > > > There was a request for a Juno feature freeze exception for this > blueprint, but there's been no response, so this may not get > approved until K release. > > > > -Dane > > > > -Original Message- > > From: Harm Weites [mailto:h...@weites.com <mailto:h...@weites.com>] > > Sent: Saturday, August 16, 2014 2:22 PM > > To: openstack-dev@lists.openstack.org > <mailto:openstack-dev@lists.openstack.org> > > Subject: [openstack-dev] Status of Neutron IPv6 dual stack > > > > Hi, > > > > Given the work on [1] has been abandoned, I'm wondering what the > current status of going dual stack is. Of course, given Neutron > got something like that on it's roadmap. > > > > The initial BP [2] aimed for Havana and Icehouse, and I'm > unaware of something similar to achieve a dual stack network. What > are the options, if any? To my knowledge it all comes down to > supporting multiple exterior interfaces (networks) on a l3-agent, > which is currently limited to just 1: either IP4 or IP6. > > > > [1] https://review.openstack.org/#/c/77471/ > > [2] > > > > https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port > > > > Regards, > > Harm > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > ___ > OpenStack-dev
Re: [openstack-dev] Status of Neutron IPv6 dual stack
Thiago, My old setup was dual-stacked, simply using a flat linuxbridge. It's just that I now realy would like to separate multiple tenants using L3 routers, which should be easy (dual stacked) to achieve once Dane's work is completed. Did you find the time to commit those required changes for that yet Dane? Regards, Harm op 16-08-14 23:33, Martinx - ? schreef: > Guys, > > Just for the record, I'm using IceHouse in a Dual-Stacked environment > (with security groups working) but, Instance's IPv6 address are static > (no upstream SLAAC, arrived in Juno-2, I think) and the topology is > `VLAN Provider Networks`, no Neutron L3 Router. Where each VLAN have > v4/v6 addrs, same upstream router (also dual-stacked - still no radvd > enabled). > > Looking forward to start testing L3 + IPv6 in K... > > Best, > Thiago > > > On 16 August 2014 16:21, Harm Weites <mailto:h...@weites.com>> wrote: > > Hi Dane, > > Thanks, that looks promising. Once support for multiple v6 > addresses on > gateway ports is added I'll be happy to give this a go. Should it work > just fine with an otherwise Icehouse based deployment? > > Regards, > Harm > > op 16-08-14 20:31, Dane Leblanc (leblancd) schreef: > > Hi Harm: > > > > Can you take a look at the following, which should address this: > > > https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes > > > > There are some diffs out for review for this blueprint: > >https://review.openstack.org/#/c/113339/ > > but the change to support 1 V4 + multiple V6 addresses on a > gateway port hasn't been added yet. I should be adding this soon. > > > > There was a request for a Juno feature freeze exception for this > blueprint, but there's been no response, so this may not get > approved until K release. > > > > -Dane > > > > -Original Message- > > From: Harm Weites [mailto:h...@weites.com <mailto:h...@weites.com>] > > Sent: Saturday, August 16, 2014 2:22 PM > > To: openstack-dev@lists.openstack.org > <mailto:openstack-dev@lists.openstack.org> > > Subject: [openstack-dev] Status of Neutron IPv6 dual stack > > > > Hi, > > > > Given the work on [1] has been abandoned, I'm wondering what the > current status of going dual stack is. Of course, given Neutron > got something like that on it's roadmap. > > > > The initial BP [2] aimed for Havana and Icehouse, and I'm > unaware of something similar to achieve a dual stack network. What > are the options, if any? To my knowledge it all comes down to > supporting multiple exterior interfaces (networks) on a l3-agent, > which is currently limited to just 1: either IP4 or IP6. > > > > [1] https://review.openstack.org/#/c/77471/ > > [2] > > > > https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port > > > > Regards, > > Harm > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > <mailto:OpenStack-dev@lists.openstack.org> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Status of Neutron IPv6 dual stack
Hi Dane, Thanks, that looks promising. Once support for multiple v6 addresses on gateway ports is added I'll be happy to give this a go. Should it work just fine with an otherwise Icehouse based deployment? Regards, Harm op 16-08-14 20:31, Dane Leblanc (leblancd) schreef: > Hi Harm: > > Can you take a look at the following, which should address this: > https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes > > There are some diffs out for review for this blueprint: >https://review.openstack.org/#/c/113339/ > but the change to support 1 V4 + multiple V6 addresses on a gateway port > hasn't been added yet. I should be adding this soon. > > There was a request for a Juno feature freeze exception for this blueprint, > but there's been no response, so this may not get approved until K release. > > -Dane > > -Original Message- > From: Harm Weites [mailto:h...@weites.com] > Sent: Saturday, August 16, 2014 2:22 PM > To: openstack-dev@lists.openstack.org > Subject: [openstack-dev] Status of Neutron IPv6 dual stack > > Hi, > > Given the work on [1] has been abandoned, I'm wondering what the current > status of going dual stack is. Of course, given Neutron got something like > that on it's roadmap. > > The initial BP [2] aimed for Havana and Icehouse, and I'm unaware of > something similar to achieve a dual stack network. What are the options, if > any? To my knowledge it all comes down to supporting multiple exterior > interfaces (networks) on a l3-agent, which is currently limited to just 1: > either IP4 or IP6. > > [1] https://review.openstack.org/#/c/77471/ > [2] > https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port > > Regards, > Harm > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Status of Neutron IPv6 dual stack
Hi, Given the work on [1] has been abandoned, I'm wondering what the current status of going dual stack is. Of course, given Neutron got something like that on it's roadmap. The initial BP [2] aimed for Havana and Icehouse, and I'm unaware of something similar to achieve a dual stack network. What are the options, if any? To my knowledge it all comes down to supporting multiple exterior interfaces (networks) on a l3-agent, which is currently limited to just 1: either IP4 or IP6. [1] https://review.openstack.org/#/c/77471/ [2] https://blueprints.launchpad.net/neutron/+spec/allow-multiple-subnets-on-gateway-port Regards, Harm ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
