Re: [openstack-dev] [neutron] Creating recipes for mimicking behavior of nova-networking network managers.
On 12/09/2013 04:05 PM, Brent Eagles wrote: On 12/04/2013 07:56 PM, Tom Fifield wrote: On 05/12/13 01:14, Brent Eagles wrote: Hi, snip I think that's a great idea. What kind of format would you like to see the recepies in? Regards, Tom I think a wiki is the right way to start. It will allow us to include diagrams and access other online content fairly easily. Other suggestions are welcome of course! Cheers, Brent FWIW: I stoked a wiki with some content from network manager descriptions if it makes a reasonable starting point. https://wiki.openstack.org/wiki/NovaNetNeutronRecipes Cheers, Brent ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [neutron] Creating recipes for mimicking behavior of nova-networking network managers.
Hi, As part of the Icehouse nova-networking parity effort, we need to describe how nova-networking managers work and how the behavior is mapped to neutron. The benefits are: 1. It aides migration: deployers who are nova-network savvy can see how functionality maps from one to the other. 2. It aides implementation: if we cannot provide a mapping, there is a breakage in parity and it needs to be addressed somehow. 3. It aides testing (and debugging): by illuminating points where the implementations differ, it makes it easier to design and implement tests that can be expected to function the same for each networking implementation. 4. It aides acceptance: at some point, the proverbial *we* are going to decide whether neutron is ready to replace nova. The existence of working recipes is a pretty strong set of acceptance criteria. Another way to look at it is that the recipes are essentially a high level description of how to go about manually testing parity. 5. It aides support and documentation efforts: nearly any point in the openstack user spectrum (casual experimenter to hard-core developer/implementer) who has anything to do with legacy deployments or parity itself will benefit from having these recipes on hand. NOT to mention the rtfm option when somebody asks I'm using FlatManager in nova-network and want to do the same in neutron, how does that work? (I love being able to write rtfm, don't you?) Sounds great!?! Cool! Do you want to help or know someone who does (or should - third-person volunteering not discouraged!)? We need nova-networking savvy and neutron savvy folks alike, though you need not necessarily be both at the same time. As some of the aforementioned benefits are directly relevant to the Icehouse development cycle AND the holiday season is upon us, it is important to get the ball rolling ASAP. To be specific, working recipes are most valuable if they are available for Icehouse-2 (see reasons 2, 3 and most importantly 4). Please respond if interested, want to volunteer someone or have comments and suggestions. Cheers, Brent ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] Creating recipes for mimicking behavior of nova-networking network managers.
On 05/12/13 01:14, Brent Eagles wrote: Hi, As part of the Icehouse nova-networking parity effort, we need to describe how nova-networking managers work and how the behavior is mapped to neutron. The benefits are: 1. It aides migration: deployers who are nova-network savvy can see how functionality maps from one to the other. 2. It aides implementation: if we cannot provide a mapping, there is a breakage in parity and it needs to be addressed somehow. 3. It aides testing (and debugging): by illuminating points where the implementations differ, it makes it easier to design and implement tests that can be expected to function the same for each networking implementation. 4. It aides acceptance: at some point, the proverbial *we* are going to decide whether neutron is ready to replace nova. The existence of working recipes is a pretty strong set of acceptance criteria. Another way to look at it is that the recipes are essentially a high level description of how to go about manually testing parity. 5. It aides support and documentation efforts: nearly any point in the openstack user spectrum (casual experimenter to hard-core developer/implementer) who has anything to do with legacy deployments or parity itself will benefit from having these recipes on hand. NOT to mention the rtfm option when somebody asks I'm using FlatManager in nova-network and want to do the same in neutron, how does that work? (I love being able to write rtfm, don't you?) Sounds great!?! Cool! Do you want to help or know someone who does (or should - third-person volunteering not discouraged!)? We need nova-networking savvy and neutron savvy folks alike, though you need not necessarily be both at the same time. As some of the aforementioned benefits are directly relevant to the Icehouse development cycle AND the holiday season is upon us, it is important to get the ball rolling ASAP. To be specific, working recipes are most valuable if they are available for Icehouse-2 (see reasons 2, 3 and most importantly 4). Please respond if interested, want to volunteer someone or have comments and suggestions. I think that's a great idea. What kind of format would you like to see the recepies in? Regards, Tom ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
