...', the final
consensus might actually BE to use separate stackforge project for plugins
anyways, and in that case we will have a head start ;-)
On Thu, Sep 4, 2014 at 10:59 PM, Prasad Vellanki
Thanks for initiating this and also good discussion today on the IRC.
My thoughts are that it is important to make this available to potential
users and customers as soon as possible so that we can get the necessary
feedback. Considering that the neutron cores and community are battling
GBP is about networking policy and hence limited to networking constructs.
It enhances the networking constructs. Since it follows more or less the
plugin model, it is not in one monolithic module but fans out to the policy
module and is done via extension.
On Fri, Aug 8, 2014 at 12:45 PM,
On Fri, Aug 8, 2014 at 2:21 PM, Armando M. arma...@gmail.com wrote:
Adding the GBP extension to Neutron does not change the nature of the
software architecture of Neutron making it more or less monolithic.
I agree with this statement...partially: the way GBP was developed is in
Doesnt the current plugin model in neutron work the way you are saying. We
have a a core set of APIs that there is a reference model for and
individual vendors have substituted plugins that enhance and sometimes
replace networking component. GBP in that respect does not change. There is
It seems like Option 1 would be preferable. User can use this right away.
The code and to a large extent BP has gone through quite a bit of review
already so it seems to me that there actually going lot less than usual. I
dont see a whole of lot Con on this. Though there are still some issues
2014 17:34, Prasad Vellanki
It seems like Option 1 would be preferable. User can use this right
People choosing Option 1 may think that the shortest route may be the
best, that said the drawback I identified is not to be dismissed either
Great to see the discussions on the ML.
Mohammad - Good summary.
I would like to make few points
1) The current GP API is tuned towards person deploying the application as
opposed to the networking person. This is probably a better way as one
starts to think about self service infrastructure
One use case is that tenant would like to put all the servers in a single
broadcast domain (thus single IP/subnet domain). The servers can include
the 3 tier servers (web database and application server). Why would he do
that - Because it is simpler.
Then the tenant would like to put
On Thu, Feb 6, 2014 at 1:19 AM, Clint Byrum cl...@fewbar.com wrote:
Excerpts from Mike Spreitzer's message of 2014-02-05 22:17:50 -0800:
From: Prasad Vellanki prasad.vella...@oneconvergence.com
To: OpenStack Development Mailing List (not for usage questions)
Thanks for putting this together. This will guide us as we develop some
resources in Heat.
As chmouel said it would be great if this can be converted to blog article.
On Wed, Jan 29, 2014 at 11:09 PM, Chmouel Boudjnah chmo...@enovance.comwrote:
That should work. We will look at implementing a resource that spins up a
shortlived VM for bootstrapping a service VM and informing configuration
server for further configuration.
On Wed, Jan 15, 2014 at 7:53 PM, Steven Dake sd...@redhat.com wrote:
to work without password prompting. But I do see that ansible
and salt support username/password option.
If this would not work, I agree that the best option is to make them
On Mon, Jan 13, 2014 at 11:23 PM, Prasad Vellanki
On Thu, Jan 9, 2014 at 6:14 AM, Steven Dake sd...@redhat.com wrote:
Thanks for detailed email. Apologize for the delayed response but we have
been thinking about how does software config fit into configuring network
and service function devices. I agree with you that in general it
One scenario we are trying to see is whether and how Heat software-config
enables deployment of images available from third party as virtual
appliances, providing network, security or acceleration capabilities. The
vendor in some cases might not allow rebuilding and/or may not
On Dec 17, 2013 3:22 PM, Tim Hinrichs thinri...@vmware.com wrote:
- Original Message -
| From: Prasad Vellanki prasad.vella...@oneconvergence.com
| To: OpenStack Development Mailing List (not for usage questions)
| Sent: Monday, December 16, 2013 2
On Tue, Dec 17, 2013 at 7:34 PM, Stephen Wong s3w...@midokura.com wrote:
Thanks for the comments, please see responses inline.
On Mon, Dec 16, 2013 at 2:11 PM, Prasad Vellanki
Please see inline
On Sun, Dec 15, 2013
Mail list logo