[openstack-dev] [NFV] What is NFV - Wiki page updated with proposal
Hello, Just a quick note to mention that I just updated the subteam wiki page with a proposed definition of what NFV means. Comments and updates are of course welcome. https://wiki.openstack.org/wiki/Teams/NFV#What_is_NFV.3F Cheers, -- Nicolas Barcet a.k.a. nijaba, nick ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [NFV][QA] Mission statement prosal
As no more remarks have came in in the past 5 days, I propose that we use the following statement. The only change since the last email is s/instances/workloads/ in the first sentence. --- Mission statement for the OpenStack NFV Sub-team: The sub-team aims to define the use cases and identify and prioritise the requirements which are needed to run Network Function Virtualization (NFV) workloads on top of OpenStack. This work includes identifying functional gaps, creating blueprints, submitting and reviewing patches to the relevant OpenStack projects and tracking their completion in support of NFV. The requirements expressed by this group should be made so that each of them have a test case which can be verified using an OpenSource implementation. This is to ensure that tests can be done without any special hardware or proprietary software, which is key for continuous integration tests in the OpenStack gate. If special setups are required which cannot be reproduced on the standard OpenStack gate, the use cases proponent will have to provide a 3rd party CI setup, accessible by OpenStack infra, which will be used to validate developments against. --- Any last thoughts? Nick On Wed, May 21, 2014 at 5:38 PM, Nicolas Barcet wrote: > > Thanks a lot for the comments so far. Please see bellow an updated version trying to integrate the remarks. I have created an Etherpad for this [1] so that we can jointly update it. > > --- > Mission statement for the OpenStack NFV Sub-team: > > The sub-team aims to define the use cases and identify and prioritise the requirements which are needed to run Network Function Virtualization (NFV) instances on top of OpenStack. This work includes identifying functional gaps, creating blueprints, submitting and reviewing patches to the relevant OpenStack projects and tracking their completion in support of NFV > > The requirements expressed by this group should be made so that each of them have a test case which can be verified using an OpenSource implementation. This is to ensure that tests can be done without any special hardware or proprietary software, which is key for continuous integration tests in the OpenStack gate. If special setups are required which cannot be reproduced on the standard OpenStack gate, the use cases proponent will have to provide a 3rd party CI setup, accessible by OpenStack infra, which will be used to validate developments against. > > -- > > [1] https://etherpad.openstack.org/p/nvf-subteam-mission-statement > > Further thoughts or updates are welcome here or there. > > Nick > > > On Tue, May 20, 2014 at 7:43 AM, Jiang, Yunhong wrote: >> >> Hi, Nick, >> >> For “have a test case which can be verified using a an OpenSource implementation ….. ensure that tests can be done without any special hardware or proprietary software”, I totally agree the requirement for without proprietary software, however, I’m not sure about your exact meaing of “special hardware”. >> >> >> >> I had a quick chat with Daniel in the summit on this also. Several NFV tasks, like large page, guest NUMA, SR-IOV, require hardware support. Those features are widely supported in volume servers already for a long time, but can’t be achieved, or can’t be achieved well, in VM yet, thus can’t be verified in current gate. IMHO, even VM can support/emulate such feature, it’s not so good to use VM to verify them. >> >> >> >> How about have a standard 3rd party CI test for hardware based feature testing and make it an extensible framework? I think there are requirement at least from both ironic and NFV? >> >> >> >> Our team have 3rd party CI test for PCI pass-through and OAT trusted computing, which can’t be achieved through CI now. These tests are based on real hardware environment instead of VM. We didn’t publish result yet because of some IT logistic support. >> >> >> >> Thanks >> >> --jyh >> >> >> >> From: Nicolas Barcet [mailto:nico...@barcet.com] >> Sent: Monday, May 19, 2014 10:19 AM >> To: openstack-dev >> >> >> Subject: [openstack-dev] [NFV] Mission statement prosal >> >> >> >> Hello, >> >> >> As promised during the second BoF session (thanks a lot to Chris Wright for leading this), here is a first try at defining the purpose of our special interest group. >> >> --- >> Mission statement for the OpenStack NFV Special Interest Group: >> >> The SIG aims to define and prioritize the use cases which are required to run Network Function Virtualization (NFV) instances on top of OpenStack. The requirements are to be passed on to various projects within OpenStack to promote their implementation. >> >> >> The requirements expressed by this group should b
Re: [openstack-dev] [NFV][QA] Mission statement prosal
Thanks a lot for the comments so far. Please see bellow an updated version trying to integrate the remarks. I have created an Etherpad for this [1] so that we can jointly update it. --- Mission statement for the OpenStack NFV Sub-team: The sub-team aims to define the use cases and identify and prioritise the requirements which are needed to run Network Function Virtualization (NFV) instances on top of OpenStack. This work includes identifying functional gaps, creating blueprints, submitting and reviewing patches to the relevant OpenStack projects and tracking their completion in support of NFV The requirements expressed by this group should be made so that each of them have a test case which can be verified using an OpenSource implementation. This is to ensure that tests can be done without any special hardware or proprietary software, which is key for continuous integration tests in the OpenStack gate. If special setups are required which cannot be reproduced on the standard OpenStack gate, the use cases proponent will have to provide a 3rd party CI setup, accessible by OpenStack infra, which will be used to validate developments against. -- [1] https://etherpad.openstack.org/p/nvf-subteam-mission-statement Further thoughts or updates are welcome here or there. Nick On Tue, May 20, 2014 at 7:43 AM, Jiang, Yunhong wrote: > Hi, Nick, > > For “have a test case which can be verified using a an OpenSource > implementation ….. ensure that tests can be done without any special > hardware or proprietary software”, I totally agree the requirement for > without proprietary software, however, I’m not sure about your exact > meaing of “special hardware”. > > > > I had a quick chat with Daniel in the summit on this also. Several NFV > tasks, like large page, guest NUMA, SR-IOV, require hardware support. Those > features are widely supported in volume servers already for a long time, > but can’t be achieved, or can’t be achieved well, in VM yet, thus can’t be > verified in current gate. IMHO, even VM can support/emulate such feature, > it’s not so good to use VM to verify them. > > > > How about have a standard 3rd party CI test for hardware based feature > testing and make it an extensible framework? I think there are requirement > at least from both ironic and NFV? > > > > Our team have 3rd party CI test for PCI pass-through and OAT trusted > computing, which can’t be achieved through CI now. These tests are based > on real hardware environment instead of VM. We didn’t publish result yet > because of some IT logistic support. > > > > Thanks > > --jyh > > > > *From:* Nicolas Barcet [mailto:nico...@barcet.com] > *Sent:* Monday, May 19, 2014 10:19 AM > *To:* openstack-dev > > *Subject:* [openstack-dev] [NFV] Mission statement prosal > > > > Hello, > > As promised during the second BoF session (thanks a lot to Chris Wright > for leading this), here is a first try at defining the purpose of our > special interest group. > > --- > Mission statement for the OpenStack NFV Special Interest Group: > > The SIG aims to define and prioritize the use cases which are required to > run Network Function Virtualization (NFV) instances on top of OpenStack. > The requirements are to be passed on to various projects within OpenStack > to promote their implementation. > > > The requirements expressed by this group should be made so that each of > them have a test case which can be verified using a an OpenSource > implementation. This is to ensure that tests can be done without any > special hardware or proprietary software, which is key for continuous > integration tests in the OpenStack gate. > > --- > > > > Comments, suggestions and fixes are obviously welcome! > > > > Best, > > Nick > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Nicolas Barcet a.k.a. nijaba, nick ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [NFV] Mission statement prosal
Hello, As promised during the second BoF session (thanks a lot to Chris Wright for leading this), here is a first try at defining the purpose of our special interest group. --- Mission statement for the OpenStack NFV Special Interest Group: The SIG aims to define and prioritize the use cases which are required to run Network Function Virtualization (NFV) instances on top of OpenStack. The requirements are to be passed on to various projects within OpenStack to promote their implementation. The requirements expressed by this group should be made so that each of them have a test case which can be verified using a an OpenSource implementation. This is to ensure that tests can be done without any special hardware or proprietary software, which is key for continuous integration tests in the OpenStack gate. --- Comments, suggestions and fixes are obviously welcome! Best, Nick ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] Nomination of Sandy Walsh to core team
+1 in support of Sandy. He is a proven contributor and reviewer and he brings a great business vision and experience to the team. Cheers, Nick On Wed, Dec 11, 2013 at 8:18 PM, Gordon Chung wrote: > > To that end, I would like to nominate Sandy Walsh from Rackspace to > > ceilometer-core. Sandy is one of the original authors of StackTach, and > > spearheaded the original stacktach-ceilometer integration. He has been > > instrumental in many of my codes reviews, and has contributed much of the > > existing event storage and querying code. > > +1 in support of Sandy. the Event work he's led in Ceilometer has been an > important feature and i think he has some valuable ideas. > > cheers, > gordon chung > openstack, ibm software standards > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Nicolas Barcet a.k.a. nijaba, nick ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ceilometer] [Rally] Does Ceilometer affect instance creation?
On Tue, Dec 10, 2013 at 3:59 PM, Julien Danjou wrote: > > Please Julien correct me if I'm wrong. And maybe Ceilometer has > > recommendations for production deployment and I just missed it? > > There's no recommendation per-say, except what we added on the > documentation so far. For reference, it can be found here: http://docs.openstack.org/developer/ceilometer/install/dbreco.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Unified Guest Agent proposal
On Sat, Dec 7, 2013 at 9:08 AM, Clint Byrum wrote: > So what is needed is domain specific command execution and segregation > of capabilities. > To further this, I know that a lot of security minded people consider this types of agent sorts of backdoors. Having one generic "backdoor" that can do everything is something that could be less acceptable as you would not have the choice to pinpoint what you'd like to allow it to do, or then the constraints in terms of fine grained access control becomes huge. I did not realize this until I too spoke with Scott about this. Cloud-init, or any such generic tool, should only enable deployment domain specific tool, based on the specific needs of given use case, not become an agent (backdoor) itself. This said, I imagine we could get some benefits out of a generic framework/library that could be used create such agents in a manner where base authentication and access control is done properly. This would allow to simplify security analysis and impacts of agents developped using that framework, but the framework itself should never become a generic binary that is deploy everywhere by default and allow way too much in itself. Binary instances of agents written using the framework would be what could be eventually deployed via cloud-init on a case by case basis. Wdyt? Nick -- Nicolas Barcet a.k.a. nijaba, nick ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Proposal to recognize indirect contributions to our code base
Dear TC members, Our companies are actively encouraging our respective customers to have the patches they mission us to make be contributed back upstream. In order to encourage this behavior from them and others, it would be nice that if could gain some visibility as "sponsors" of the patches in the same way we get visibility as "authors" of the patches today. The goal here is not to provide yet another way to count affiliations of direct contributors, nor is it a way to introduce sales pitches in contrib. The only acceptable and appropriate use of the proposal we are making is to signal when a patch made by a contributor for another comany than the one he is currently employed by. For example if I work for a company A and write a patch as part of an engagement with company B, I would signal that Company B is the sponsor of my patch this way, not Company A. Company B would under current circumstances not get any credit for their indirect contribution to our code base, while I think it is our intent to encourage them to contribute, even indirectly. To enable this, we are proposing that the commit text of a patch may include a sponsored-by: line which could be used by various tools to report on these commits. Sponsored-by should not be used to report on the name of the company the contributor is already affiliated to. We would appreciate to see your comments on the subject and eventually get your approval for it's use. Boris Rensky, Tristan Goode, Nick Barcet ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Ceilometer] Nomination for Mehdi Abaakouk
+1 On Wed, Jul 31, 2013 at 8:55 PM, Lu, Lianhao http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>> wrote: >* +1*>**>* -Lianhao*>**>* Angus Salkeld wrote on 2013-07-31:*>* > On 31/07/13 >10:56 +0200, Julien Danjou wrote:*>* >> Hi,*>* >>*>* >> I'd like to propose to >add Mehdi Abaakouk (sileht) to ceilometer-core.*>* >> He has been a valuable >contributor for the last months, doing a lot of*>* >> work in the alarming >blueprints, and useful code reviews.*>* >*>* > +1*>* >*>* >>*>* >> --*>* >> >Julien Danjou*>* >> -- Free Software hacker - freelance consultant*>* >> -- >http://julien.danjou.info*>**> ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
