from:"\"Ravi Chunduru\""

Re: [openstack-dev] [Neutron] VPC Proposal

2014-02-18 Thread Ravi Chunduru

Hi JC,
  I suggest we have a VPC meetup to get those who are interested on the
same page and present the resulted draft proposal in the summit design
discussions.

Thanks,
-Ravi.


On Tue, Feb 18, 2014 at 10:12 AM, Martin, JC  wrote:

> We have started a discussion on the proper model to implement a Virtual
> Private Cloud (VPC) feature in openstack.
>
> I feel that there was not a lot of discussion on this topic in the past,
> and this may be because of the ML tags used.
> I am pointing out this discussion to this group with the Neutron tag as I
> think that networking is a big aspect of VPC.
>
> Please, jump in the discussion and share your comments.
>
> See
> http://lists.openstack.org/pipermail/openstack-dev/2014-February/026892.html
>
> and
>
>
> http://lists.openstack.org/pipermail/openstack-dev/2014-February/027171.html
>
> JC
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] VPC Proposal

2014-02-16 Thread Ravi Chunduru

IMO, VPC means to have managed set of resources not just limited to
networks but also projects.
I feel its not about incrementally starting with AWS compatibility, But
doing it right with AWS compatibility into consideration.

Thanks,
-Ravi.


On Sun, Feb 16, 2014 at 8:47 AM, Harshad Nakil
wrote:

> Comments Inline
>
> Regards
> -Harshad
>
>
> On Sat, Feb 15, 2014 at 11:39 PM, Allamaraju, Subbu wrote:
>
>> Harshad,
>>
>> Curious to know if there is a broad interest in an AWS compatible API in
>> the community?
>
>
> We started looking at this as some our customers/partners were interested
> in get AWS API compatibility. We have this blueprint and code review
> pending for long time now. We will know based on this thread wether the
> community is interested. But I assumed that community was interested as the
> blueprint was approved and code review has no -1(s) for long time now.
>
>
>> To clarify, a clear incremental path from an AWS compatible API to an
>> OpenStack model is not clear.
>>
>
> In my mind AWS compatible API does not need new openstack model. As more
> discussion happen on JC's proposal and implementation becomes clear we will
> know how incremental is the path. But at high level there two major
> differences
> 1. New first class object will be introduced which effect all components
> 2. more than one project can be supported within VPC.
> But it does not change AWS API(s). So even in JC(s) model if you want AWS
> API then we will have to keep VPC to project mapping 1:1, since the API
> will not take both VPC ID and project ID.
>
>



> As more users want to migrate from AWS or IaaS providers who want compete
> with AWS should be interested in this compatibility.
>
> There also seems to be terminology issue here Whats is definition of "VPC"
> if we assume what AWS implements is "VPC"
> then what JC is proposing "VOS" or "VDC" (virtual openstack or virtual DC)
> as all or most of current openstack features are available to user in  this
> new Abstraction. I actually like this new abstraction.
>
>
>> Subbu
>>
>> On Feb 15, 2014, at 10:04 PM, Harshad Nakil 
>> wrote:
>>
>> >
>> > I agree with problem as defined by you and will require more
>> fundamental changes.
>> > Meanwhile many users will benefit from AWS VPC api compatibility.
>>
>>
>> ___
>> 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
>
>


-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] role of Domain in VPC definition

2014-02-16 Thread Ravi Chunduru

I agree with JC that we need to pause and discuss VPC model with in
openstack before considering AWS compatibility. As Subbu said, We need this
discussion in Juno summit and get consensus.

Thanks,
-Ravi.


On Sun, Feb 16, 2014 at 10:31 AM, Allamaraju, Subbu  wrote:

> Harshad,
>
> This is great. At least there is consensus on what it is and what it is
> not. I would leave it to others to discuss merits of a an AWS compat VPC
> API for Icehouse.
>
> Perhaps this is a good topic to discuss at the Juno design summit.
>
> Subbu
>
> On Feb 16, 2014, at 10:15 AM, Harshad Nakil 
> wrote:
>
> > As said I am not disagreeing with you or Ravi or JC. I also agree that
> > Openstack VPC implementation will benefit from these proposals.
> > What I am saying is it is not required AWS VPC API compatibility at
> > this point.  Which is what our blueprint is all about. We are not
> > defining THE "VPC".
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] role of Domain in VPC definition

2013-12-19 Thread Ravi Chunduru

Hi,
  We had some internal discussions on role of Domain and VPCs. I would like
to expand and understand community thinking of Keystone domain and VPCs.

Is VPC equivalent to Keystone Domain?

If so, as a public cloud provider - I create a Keystone domain and give it
to an organization which wants a virtual private cloud.

Now the question is if that organization wants to have  departments wise
allocation of resources it is becoming difficult to visualize with existing
v3 keystone constructs.

Currently, it looks like each department of an organization cannot have
their own resource management with in the organization VPC ( LDAP based
user management, network management or dedicating computes etc.,) For us,
Openstack Project does not match the requirements of a department of an
organization.

I hope you guessed what we wanted - Domain must have VPCs and VPC to have
projects.

I would like to know how community see the VPC model in Openstack.

Thanks,
-Ravi.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] domain admin role query

2013-12-18 Thread Ravi Chunduru

Thanks Dolph,
 It worked now. I specified domain id in the scope.

-Ravi.


On Wed, Dec 18, 2013 at 12:05 PM, Ravi Chunduru  wrote:

> Hi Dolph,
>   I dont have project yet to use in the scope. The intention is to get a
> token using domain admin credentials and create project using it.
>
> Thanks,
> -Ravi.
>
>
> On Wed, Dec 18, 2013 at 11:39 AM, Dolph Mathews 
> wrote:
>
>>
>> On Wed, Dec 18, 2013 at 12:48 PM, Ravi Chunduru wrote:
>>
>>> Thanks all for the information.
>>> I have now v3 policies in place, the issue is that as a domain admin I
>>> could not create a project in the domain. I get 403 unauthorized status.
>>>
>>> I see that when as a  'domain admin' request a token, the response did
>>> not have any roles.  In the token request, I couldnt specify the project -
>>> as we are about to create the project in next step.
>>>
>>
>> Specify a domain as the "scope" to obtain domain-level authorization in
>> the resulting token.
>>
>> See the third example under Scope:
>>
>>
>> https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#scope-scope
>>
>>
>>>
>>> Here is the complete request/response of all the steps done.
>>> https://gist.github.com/kumarcv/8015275
>>>
>>> I am assuming its a bug. Please let me know your opinions.
>>>
>>> Thanks,
>>> -Ravi.
>>>
>>>
>>>
>>>
>>> On Thu, Dec 12, 2013 at 3:00 PM, Henry Nash 
>>> wrote:
>>>
>>>> Hi
>>>>
>>>> So the idea wasn't the you create a domain with the id of
>>>> 'domain_admin_id', rather that you create the domain that you plan to use
>>>> for your admin domain, and then paste its (auto-generated) domain_id into
>>>> the policy file.
>>>>
>>>> Henry
>>>> On 12 Dec 2013, at 03:11, Paul Belanger 
>>>> wrote:
>>>>
>>>> > On 13-12-11 11:18 AM, Lyle, David wrote:
>>>> >> +1 on moving the domain admin role rules to the default policy.json
>>>> >>
>>>> >> -David Lyle
>>>> >>
>>>> >> From: Dolph Mathews [mailto:dolph.math...@gmail.com]
>>>> >> Sent: Wednesday, December 11, 2013 9:04 AM
>>>> >> To: OpenStack Development Mailing List (not for usage questions)
>>>> >> Subject: Re: [openstack-dev] [keystone] domain admin role query
>>>> >>
>>>> >>
>>>> >> On Tue, Dec 10, 2013 at 10:49 PM, Jamie Lennox <
>>>> jamielen...@redhat.com> wrote:
>>>> >> Using the default policies it will simply check for the admin role
>>>> and not care about the domain that admin is limited to. This is partially a
>>>> left over from the V2 api when there wasn't domains to worry > about.
>>>> >>
>>>> >> A better example of policies are in the file
>>>> etc/policy.v3cloudsample.json. In there you will see the rule for
>>>> create_project is:
>>>> >>
>>>> >>   "identity:create_project": "rule:admin_required and
>>>> domain_id:%(project.domain_id)s",
>>>> >>
>>>> >> as opposed to (in policy.json):
>>>> >>
>>>> >>   "identity:create_project": "rule:admin_required",
>>>> >>
>>>> >> This is what you are looking for to scope the admin role to a domain.
>>>> >>
>>>> >> We need to start moving the rules from policy.v3cloudsample.json to
>>>> the default policy.json =)
>>>> >>
>>>> >>
>>>> >> Jamie
>>>> >>
>>>> >> - Original Message -
>>>> >>> From: "Ravi Chunduru" 
>>>> >>> To: "OpenStack Development Mailing List" <
>>>> openstack-dev@lists.openstack.org>
>>>> >>> Sent: Wednesday, 11 December, 2013 11:23:15 AM
>>>> >>> Subject: [openstack-dev] [keystone] domain admin role query
>>>> >>>
>>>> >>> Hi,
>>>> >>> I am trying out Keystone V3 APIs and domains.
>>>> >>> I created an domain, created a project in that domain, created an
&g

Re: [openstack-dev] [keystone] domain admin role query

2013-12-18 Thread Ravi Chunduru

Hi Dolph,
  I dont have project yet to use in the scope. The intention is to get a
token using domain admin credentials and create project using it.

Thanks,
-Ravi.


On Wed, Dec 18, 2013 at 11:39 AM, Dolph Mathews wrote:

>
> On Wed, Dec 18, 2013 at 12:48 PM, Ravi Chunduru  wrote:
>
>> Thanks all for the information.
>> I have now v3 policies in place, the issue is that as a domain admin I
>> could not create a project in the domain. I get 403 unauthorized status.
>>
>> I see that when as a  'domain admin' request a token, the response did
>> not have any roles.  In the token request, I couldnt specify the project -
>> as we are about to create the project in next step.
>>
>
> Specify a domain as the "scope" to obtain domain-level authorization in
> the resulting token.
>
> See the third example under Scope:
>
>
> https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#scope-scope
>
>
>>
>> Here is the complete request/response of all the steps done.
>> https://gist.github.com/kumarcv/8015275
>>
>> I am assuming its a bug. Please let me know your opinions.
>>
>> Thanks,
>> -Ravi.
>>
>>
>>
>>
>> On Thu, Dec 12, 2013 at 3:00 PM, Henry Nash wrote:
>>
>>> Hi
>>>
>>> So the idea wasn't the you create a domain with the id of
>>> 'domain_admin_id', rather that you create the domain that you plan to use
>>> for your admin domain, and then paste its (auto-generated) domain_id into
>>> the policy file.
>>>
>>> Henry
>>> On 12 Dec 2013, at 03:11, Paul Belanger 
>>> wrote:
>>>
>>> > On 13-12-11 11:18 AM, Lyle, David wrote:
>>> >> +1 on moving the domain admin role rules to the default policy.json
>>> >>
>>> >> -David Lyle
>>> >>
>>> >> From: Dolph Mathews [mailto:dolph.math...@gmail.com]
>>> >> Sent: Wednesday, December 11, 2013 9:04 AM
>>> >> To: OpenStack Development Mailing List (not for usage questions)
>>> >> Subject: Re: [openstack-dev] [keystone] domain admin role query
>>> >>
>>> >>
>>> >> On Tue, Dec 10, 2013 at 10:49 PM, Jamie Lennox <
>>> jamielen...@redhat.com> wrote:
>>> >> Using the default policies it will simply check for the admin role
>>> and not care about the domain that admin is limited to. This is partially a
>>> left over from the V2 api when there wasn't domains to worry > about.
>>> >>
>>> >> A better example of policies are in the file
>>> etc/policy.v3cloudsample.json. In there you will see the rule for
>>> create_project is:
>>> >>
>>> >>   "identity:create_project": "rule:admin_required and
>>> domain_id:%(project.domain_id)s",
>>> >>
>>> >> as opposed to (in policy.json):
>>> >>
>>> >>   "identity:create_project": "rule:admin_required",
>>> >>
>>> >> This is what you are looking for to scope the admin role to a domain.
>>> >>
>>> >> We need to start moving the rules from policy.v3cloudsample.json to
>>> the default policy.json =)
>>> >>
>>> >>
>>> >> Jamie
>>> >>
>>> >> - Original Message -
>>> >>> From: "Ravi Chunduru" 
>>> >>> To: "OpenStack Development Mailing List" <
>>> openstack-dev@lists.openstack.org>
>>> >>> Sent: Wednesday, 11 December, 2013 11:23:15 AM
>>> >>> Subject: [openstack-dev] [keystone] domain admin role query
>>> >>>
>>> >>> Hi,
>>> >>> I am trying out Keystone V3 APIs and domains.
>>> >>> I created an domain, created a project in that domain, created an
>>> user in
>>> >>> that domain and project.
>>> >>> Next, gave an admin role for that user in that domain.
>>> >>>
>>> >>> I am assuming that user is now admin to that domain.
>>> >>> Now, I got a scoped token with that user, domain and project. With
>>> that
>>> >>> token, I tried to create a new project in that domain. It worked.
>>> >>>
>>> >>> But, using the same token, I could also create a new project in a
>>> 'default'
>&

Re: [openstack-dev] [keystone] domain admin role query

2013-12-18 Thread Ravi Chunduru

Thanks all for the information.
I have now v3 policies in place, the issue is that as a domain admin I
could not create a project in the domain. I get 403 unauthorized status.

I see that when as a  'domain admin' request a token, the response did not
have any roles.  In the token request, I couldnt specify the project - as
we are about to create the project in next step.

Here is the complete request/response of all the steps done.
https://gist.github.com/kumarcv/8015275

I am assuming its a bug. Please let me know your opinions.

Thanks,
-Ravi.




On Thu, Dec 12, 2013 at 3:00 PM, Henry Nash wrote:

> Hi
>
> So the idea wasn't the you create a domain with the id of
> 'domain_admin_id', rather that you create the domain that you plan to use
> for your admin domain, and then paste its (auto-generated) domain_id into
> the policy file.
>
> Henry
> On 12 Dec 2013, at 03:11, Paul Belanger 
> wrote:
>
> > On 13-12-11 11:18 AM, Lyle, David wrote:
> >> +1 on moving the domain admin role rules to the default policy.json
> >>
> >> -David Lyle
> >>
> >> From: Dolph Mathews [mailto:dolph.math...@gmail.com]
> >> Sent: Wednesday, December 11, 2013 9:04 AM
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> Subject: Re: [openstack-dev] [keystone] domain admin role query
> >>
> >>
> >> On Tue, Dec 10, 2013 at 10:49 PM, Jamie Lennox 
> wrote:
> >> Using the default policies it will simply check for the admin role and
> not care about the domain that admin is limited to. This is partially a
> left over from the V2 api when there wasn't domains to worry > about.
> >>
> >> A better example of policies are in the file
> etc/policy.v3cloudsample.json. In there you will see the rule for
> create_project is:
> >>
> >>   "identity:create_project": "rule:admin_required and
> domain_id:%(project.domain_id)s",
> >>
> >> as opposed to (in policy.json):
> >>
> >>   "identity:create_project": "rule:admin_required",
> >>
> >> This is what you are looking for to scope the admin role to a domain.
> >>
> >> We need to start moving the rules from policy.v3cloudsample.json to the
> default policy.json =)
> >>
> >>
> >> Jamie
> >>
> >> - Original Message -
> >>> From: "Ravi Chunduru" 
> >>> To: "OpenStack Development Mailing List" <
> openstack-dev@lists.openstack.org>
> >>> Sent: Wednesday, 11 December, 2013 11:23:15 AM
> >>> Subject: [openstack-dev] [keystone] domain admin role query
> >>>
> >>> Hi,
> >>> I am trying out Keystone V3 APIs and domains.
> >>> I created an domain, created a project in that domain, created an user
> in
> >>> that domain and project.
> >>> Next, gave an admin role for that user in that domain.
> >>>
> >>> I am assuming that user is now admin to that domain.
> >>> Now, I got a scoped token with that user, domain and project. With that
> >>> token, I tried to create a new project in that domain. It worked.
> >>>
> >>> But, using the same token, I could also create a new project in a
> 'default'
> >>> domain too. I expected it should throw authentication error. Is it a
> bug?
> >>>
> >>> Thanks,
> >>> --
> >>> Ravi
> >>>
> >
> > One of the issues I had this week while using the
> policy.v3cloudsample.json was I had no easy way of creating a domain with
> the id of 'admin_domain_id'.  I basically had to modify the SQL directly to
> do it.
> >
> > Any chance we can create a 2nd domain using 'admin_domain_id' via
> keystone-manage sync_db?
> >
> > --
> > Paul Belanger | PolyBeacon, Inc.
> > Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
> > Github: https://github.com/pabelanger | Twitter:
> https://twitter.com/pabelanger
> >
> > ___
> > 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
>
>


-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [keystone] domain admin role query

2013-12-10 Thread Ravi Chunduru

Hi,
  I am trying out Keystone V3 APIs and domains.
I created an domain, created a project in that domain, created an user in
that domain and project.
Next, gave an admin role for that user in that domain.

I am assuming that user is now admin to that domain.
Now, I got a scoped token with that user, domain and project. With that
token, I tried to create a new project in that domain. It worked.

But, using the same token, I could also create a new project in a 'default'
domain too. I expected it should throw authentication error. Is it a bug?

Thanks,
-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] problems with rabbitmq on HA controller failure...anyone seen this?

2013-12-02 Thread Ravi Chunduru

We do had the same problem in our deployment.  Here is the brief
description of what we saw and how we fixed it.
http://l4tol7.blogspot.com/2013/12/openstack-rabbitmq-issues.html


On Mon, Dec 2, 2013 at 10:37 AM, Vishvananda Ishaya
wrote:

>
> On Nov 29, 2013, at 9:24 PM, Chris Friesen 
> wrote:
>
> > On 11/29/2013 06:37 PM, David Koo wrote:
> >> On Nov 29, 02:22:17 PM (Friday), Chris Friesen wrote:
> >>> We're currently running Grizzly (going to Havana soon) and we're
> >>> running into an issue where if the active controller is ungracefully
> >>> killed then nova-compute on the compute node doesn't properly
> >>> connect to the new rabbitmq server on the newly-active controller
> >>> node.
> >
> >>> Interestingly, killing and restarting nova-compute on the compute
> >>> node seems to work, which implies that the retry code is doing
> >>> something less effective than the initial startup.
> >>>
> >>> Has anyone doing HA controller setups run into something similar?
> >
> > As a followup, it looks like if I wait for 9 minutes or so I see a
> message in the compute logs:
> >
> > 2013-11-30 00:02:14.756 1246 ERROR nova.openstack.common.rpc.common [-]
> Failed to consume message from queue: Socket closed
> >
> > It then reconnects to the AMQP server and everything is fine after that.
>  However, any instances that I tried to boot during those 9 minutes stay
> stuck in the "BUILD" status.
> >
> >
> >>
> >> So the rabbitmq server and the controller are on the same node?
> >
> > Yes, they are.
> >
> > > My
> >> guess is that it's related to this bug 856764 (RabbitMQ connections
> >> lack heartbeat or TCP keepalives). The gist of it is that since there
> >> are no heartbeats between the MQ and nova-compute, if the MQ goes down
> >> ungracefully then nova-compute has no way of knowing. If the MQ goes
> >> down gracefully then the MQ clients are notified and so the problem
> >> doesn't arise.
> >
> > Sounds about right.
> >
> >> We got bitten by the same bug a while ago when our controller node
> >> got hard reset without any warning!. It came down to this bug (which,
> >> unfortunately, doesn't have a fix yet). We worked around this bug by
> >> implementing our own crude fix - we wrote a simple app to periodically
> >> check if the MQ was alive (write a short message into the MQ, then
> >> read it out again). When this fails n-times in a row we restart
> >> nova-compute. Very ugly, but it worked!
> >
> > Sounds reasonable.
> >
> > I did notice a kombu heartbeat change that was submitted and then backed
> out again because it was buggy. I guess we're still waiting on the real fix?
>
> Hi Chris,
>
> This general problem comes up a lot, and one fix is to use keepalives.
> Note that more is needed if you are using multi-master rabbitmq, but for
> failover I have had great success with the following (also posted to the
> bug):
>
> When a connection to a socket is cut off completely, the receiving side
> doesn't know that the connection has dropped, so you can end up with a
> half-open connection. The general solution for this in linux is to turn on
> TCP_KEEPALIVES. Kombu will enable keepalives if the version number is high
> enough (>1.0 iirc), but rabbit needs to be specially configured to send
> keepalives on the connections that it creates.
>
> So solving the HA issue generally involves a rabbit config with a section
> like the following:
>
> [
>  {rabbit, [{tcp_listen_options, [binary,
> {packet, raw},
> {reuseaddr, true},
> {backlog, 128},
> {nodelay, true},
> {exit_on_close, false},
> {keepalive, true}]}
>   ]}
> ].
>
> Then you should also shorten the keepalive sysctl settings or it will
> still take ~2 hrs to terminate the connections:
>
> echo "5" > /proc/sys/net/ipv4/tcp_keepalive_time
> echo "5" > /proc/sys/net/ipv4/tcp_keepalive_probes
> echo "1" > /proc/sys/net/ipv4/tcp_keepalive_intvl
>
> Obviously this should be done in a sysctl config file instead of at the
> command line. Note that if you only want to shorten the rabbit keepalives
> but keep everything else as a default, you can use an LD_PRELOAD library to
> do so. For example you could use:
>
> https://github.com/meebey/force_bind/blob/master/README
>
> Vish
>
> >
> > Chris
> >
> >
> > ___
> > 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
>
>


-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Bad review patterns

2013-11-06 Thread Ravi Chunduru

Well said. This will encourage new developers.


On Wed, Nov 6, 2013 at 11:26 AM, Andrew Woodward  wrote:

> Great thread and very insightful. Yes; please make this more
> accessible to other reviewers. Adding this to the wiki is a great
> start.
>
> Andrew
> Mirantis
>
> On Wed, Nov 6, 2013 at 11:05 AM, Pitucha, Stanislaw Izaak
>  wrote:
> > How about putting it on a wiki and linking it from the top bar of gerrit
> itself? (call it "review guidelines" for example)
> > That way, even people who didn't look for it explicitly could find it.
> >
> > Regards,
> > Stanisław Pitucha
> > Cloud Services
> > Hewlett Packard
> >
> > -Original Message-
> > From: Sergey Skripnick [mailto:sskripn...@mirantis.com]
> > Sent: Wednesday, November 06, 2013 6:50 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > Subject: Re: [openstack-dev] Bad review patterns
> >
> >
> > This definitely should be somewhere in wiki or blog and in the bookmarks.
> >
> > ___
> > 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
>
>
>
> --
> If google has done it, Google did it right!
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Re : welcoming new committers (was Re: When is it okay for submitters to say 'I don't want to add tests' ?)

2013-11-04 Thread Ravi Chunduru

Good points from John.

The only concern for first time reviewers is that their comments gets
overseen by the committer. If the review comment is good, I feel
core-reviewer must put some weight on it and thus encourage genuine
suggestions.


On Mon, Nov 4, 2013 at 9:33 AM, John Dennis  wrote:

> On 10/31/2013 10:36 PM, Jeremy Stanley wrote:
> > As has been said many times already, OpenStack does not lack
> > developers... it lacks reviewers.
>
> In regards to reviews in general and in particular for welcoming new
> committers I think we need to be careful about reviewers NAK'ing a
> submission for what is essentially bikeshedding [1]. Reviewers should
> focus on code correctness and adherence to required guidelines and not
> NAK a submission because the submission offends their personal coding
> preferences [2].
>
> If a reviewer thinks the code would be better with changes which do not
> affect correctness and are more in the vein of "style" modifications
> they should make helpful suggestions but give the review a 0 instead of
> actually NAK'ing the submission. NAK'ed reviews based on style issues
> force the submitter to adhere to someone else's unsubstantiated opinion
> and slows down the entire contribution process while submissions are
> reworked multiple times without any significant technical change. It's
> also demoralizing for submitters to have their contributions NAK'ed for
> reasons that are issues of opinion only, the submitter has to literally
> submit [3].
>
> [1] http://en.wiktionary.org/wiki/bikeshedding
>
> [2] Despite the best attempts of computer science researchers over the
> years software development remains more of a craft than a science with
> unambiguous rules yielding exactly one solution. Often there are many
> valid approaches to solve a particular coding problem, the selection of
> one approach often boils down to the personal preferences of the
> craftsperson. This does not diminish the value of coding guidelines
> gleaned from years of analyzing software issues, what it does mean is
> those guidelines still leave plenty of room for different approaches and
> no one is the arbiter of the "one and only correct way".
>
> [3] to give over or yield to the power or authority of another.
>
> --
> John
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][LBaaS] Object status and admin_state_up

2013-10-29 Thread Ravi Chunduru

Generally loadbalancer will have the following options

enable - configurationally enable
disable - configurationally disable

up - status alive
down - status down

If we have the above it will be meaningful to get actual status of the
object.

Thanks,
-Ravi.




On Tue, Oct 29, 2013 at 4:33 PM, Itsuro ODA  wrote:

> Hi,
>
> I think "INACTIVE" is right for resources with admin_statu_up False.
>
> BTW, there are following requirements:
> * Change to ACTIVE from PENDING_CREATE/UPDATE when the serives
>   is available actually. (ie. after lbaas_agent done the job.)
> * Reflect a member is alive or not to the 'status' attribute of
>   member resource. (ie. if a member is not alive, the status is
>   "DOWN".)
>
> Note that we are planning to implement above requiremants to LVS
> driver.
>
> Thanks,
> Itsuro Oda
>
> On Tue, 29 Oct 2013 13:19:16 +0400
> Eugene Nikanorov  wrote:
>
> > Hi folks,
> >
> > Currently there are two attributes of vips/pools/members that represent a
> > status: 'status' and 'admin_state_up'.
> >
> > The first one is used to represent deployment status and can be
> > PENDING_CREATE, ACTIVE, PENDING_DELETE, ERROR.
> > We also have admin_state_up which could be True or False.
> >
> > I'd like to know your opinion on how to change 'status' attribute based
> on
> > admin_state_up changes.
> > For instance. If admin_state_up is updated to be False, how do you think
> > 'status' should change?
> >
> > Also, speaking of reference implementation (HAProxy), changing vip or
> pool
> > admin_state_up to False effectively destroys the balancer (undeploys it),
> > while the objects remain in ACTIVE state.
> > There are two options to fix this discrepancy:
> > 1) Change status of vip/pool to PENDING_CREATE if admin_state_up changes
> to
> > False
> > 2) Don't destroy the loadbalancer and use HAProxy capability to disable
> > frontend and backend while leave vip/pool in ACTIVE state
> >
> > Please share your opinion.
> >
> > Thanks,
> > Eugene.
>
> --
> Itsuro ODA 
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Distributed Virtual Router Discussion

2013-10-22 Thread Ravi Chunduru

Count me in as well.


On Tue, Oct 22, 2013 at 1:20 PM, Kyle Mestery (kmestery)  wrote:

> Count me in on this discussion as well. May make sense to have a lightning
> talk at the summit, or an unconference slot.
>
> On Oct 22, 2013, at 1:50 PM, "Vasudevan, Swaminathan (PNB Roseville)" <
> swaminathan.vasude...@hp.com> wrote:
>
> > Hi Folks,
> > Thanks for your interests in the DVR feature.
> > We should get together to start discussing the details in the DVR.
> > Please let me know who else is interested, probably the time slot and we
> can start nailing down the details.
> >  https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
> > https://wiki.openstack.org/wiki/Distributed_Router_for_OVS
> > Thanks
> > Swami
> >
> > From: Robin Wang [mailto:cloudbe...@gmail.com]
> > Sent: Tuesday, October 22, 2013 11:45 AM
> > To: Artem Dmytrenko; yong sheng gong (gong...@unitedstack.com);
> OpenStack Development Mailing List; Vasudevan, Swaminathan (PNB Roseville)
> > Subject: Re: Re: [openstack-dev] [Neutron] Distributed Virtual Router
> Discussion
> >
> > Hi Artem,
> >
> > Very happy to see more stackers working on this feature. : )
> >
> > "Note that the images in your document are badly corrupted - maybe my
> questions could already be answered by your diagrams. "
> > I met the same issue at first. Downloading the doc and open it locally
> may help. It works for me.
> >
> > Also, a wiki page for DVR/VDR feature is created, including some
> interesting performance test output. Thanks.
> > https://wiki.openstack.org/wiki/Distributed_Router_for_OVS
> >
> > Best,
> > Robin Wang
> >
> > From: Artem Dmytrenko
> > Date: 2013-10-22 02:51
> > To: yong sheng gong \(gong...@unitedstack.com\); cloudbe...@gmail.com;
> OpenStack Development Mailing List
> > Subject: Re: [openstack-dev] Distributed Virtual Router Discussion
> > Hi Swaminathan.
> >
> > I work for a virtual networking startup called Midokura and I'm very
> interested in joining the discussion. We currently have distributed router
> implementation using existing Neutron API. Could you clarify why
> distributed vs centrally located routing implementation need to be
> distinguished? Another question is that are you proposing distributed
> routing implementation for tenant routers or for the router connecting the
> virtual cloud to the external network? The reason that I'm asking this
> question is because our company would also like to propose a router
> implementation that would eliminate a single point uplink failures. We have
> submitted a couple blueprints on that topic (
> https://blueprints.launchpad.net/neutron/+spec/provider-router-support,
> https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing) and
> would appreciate an opportunity to collaborate on making it a reality.
> >
> > Note that the images in your document are badly corrupted - maybe my
> questions could already be answered by your diagrams. Could you update your
> document with legible diagrams?
> >
> > Looking forward to further discussing this topic with you!
> >
> > Sincerely,
> > Artem Dmytrenko
> >
> > 
> > On Mon, 10/21/13, Vasudevan, Swaminathan (PNB Roseville) <
> swaminathan.vasude...@hp.com> wrote:
> >
> >  Subject: [openstack-dev] Distributed Virtual Router Discussion
> >  To: "yong sheng gong (gong...@unitedstack.com)" <
> gong...@unitedstack.com>, "cloudbe...@gmail.com" ,
> "OpenStack Development Mailing List (openstack-dev@lists.openstack.org)" <
> openstack-dev@lists.openstack.org>
> >  Date: Monday, October 21, 2013, 12:18 PM
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >  Hi Folks,
> >  I am currently working on a
> >  blueprint for Distributed Virtual Router.
> >  If anyone interested in
> >  being part of the discussion please let me know.
> >  I have put together a first
> >  draft of my blueprint and have posted it on Launchpad for
> >  review.
> >  https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
> >
> >
> >
> >  Thanks.
> >
> >  Swaminathan Vasudevan
> >  Systems Software Engineer
> >  (TC)
> >
> >
> >  HP Networking
> >  Hewlett-Packard
> >  8000 Foothills Blvd
> >  M/S 5541
> >  Roseville, CA - 95747
> >  tel: 916.785.0937
> >  fax: 916.785.1815
> >  email: swaminathan.vasude...@hp.com
> >
> >
> >
> >
> >
> >
> >
> >  -Inline Attachment Follows-
> >
> >  ___
> >  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
>



-- 
Ravi
___
OpenStack-dev ma

Re: [openstack-dev] [Neutron] Tenant's info from plugin/services

2013-10-16 Thread Ravi Chunduru

As Yongsheng said, use keystone tenant-list. We overload keystone tenant
with lot more tenant specific information as metadata and use it in other
openstack services.


On Wed, Oct 16, 2013 at 4:11 PM, Yongsheng Gong wrote:

> I think this should be done in keystone. maybe you need a CLI command:
> keystone tenant-get
>
>
> On Thu, Oct 17, 2013 at 6:55 AM, Ivar Lazzaro  wrote:
>
>>  Hello Everyone,
>>
>> ** **
>>
>> I was wondering if there’s a “standard” way within Neutron to retrieve
>> tenants’ specific information (e.g. “name”) from a plugin/service.
>>
>> The call “context” already provides the tenant’s UUID, but that may be
>> useful to have some extra info in certain cases.
>>
>> ** **
>>
>> Thanks,
>>
>> Ivar.
>>
>> ___
>> 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
>
>


-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] How to get VXLAN Endpoint IP without agent

2013-10-16 Thread Ravi Chunduru

I guess the intention is to make VXLAN work with out quantum agent. It
means you are using an external openflow controller to manage OVS switches.

In such a case, there is a need to specifically get the compute node IP
from the VM data interface network( and not the management or openstack
network interface IP)

I think of two solutions
1) There must be a onboarding process for each compute node that can
indicate your controller of the compute's local_ip
2) Make sure OVS uses VM data interface network to connect to the
controller.

I don't prefer 2, as OVS mgmt traffic should not be on VM data network.

For solution#1, its a pain to load compute local IP onto openflow
controller but it can be automated using puppet etc.,

(I have verified nova database for compute - but it stores management
network interface IP but not from data network- Makes sense as endpoints
are on management network)

Alternately, we can propose a blueprint to include an option in nova.conf
on compute for local_ip as there is a need for consumption using VXLAN
based overlay networks.

Hope it helps.

Thanks,
-Ravi.

On Tue, Oct 15, 2013 at 3:45 AM, B Veera-B37207 wrote:

>  Hi,
>
> ** **
>
> Vxlan endpoint ip is configured in ‘*
> /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini*’ as ‘*local_ip*’*
> ***
>
> While starting openvswitch agent the above local ip is populated in
> neutron database.
>
> ** **
>
> Is there any way to get local_ip of compute node without any agent running?
> 
>
> ** **
>
> Thanks in advance.
>
> ** **
>
> Regards,
>
> Veera.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>

-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] What should be Neutron behavior with scoped token?

2013-10-07 Thread Ravi Chunduru

I raised a bug with my findings
https://bugs.launchpad.net/neutron/+bug/1236704


On Fri, Oct 4, 2013 at 10:16 AM, Ravi Chunduru  wrote:

> Does the described behavior qualify as a bug?
>
> Thanks,
> -Ravi.
>
>
> On Thu, Oct 3, 2013 at 5:21 PM, Ravi Chunduru  wrote:
>
>> Hi,
>>   In my tests, I observed that when an admin of a tenant runs 'nova list'
>> to list down all the servers of the tenant - nova-api makes a call to
>> quantum to get_ports with filter set to device owner. This operation is
>> taking about 1m 30s in our setup(almost having 100 VMs i.e > 100 ports)
>>
>> While a user of a tenant runs the same command, the response is immediate.
>>
>> Going into details - the only difference between those two operations is
>> the 'role'.
>>
>> Looking into the code, I have the following questions
>> 1) Scoped Admin token returned all entries of a resource. Any reason not
>> filtered per tenant?
>> Comparing with Nova - it always honored tenant from the scoped token and
>> returns values specific to tenant.
>>
>> 2) In the above described test, the DB access should not take much time
>> with or with out tenant-id in filter. Why change in response time for
>> tenant admin or a member user?
>>
>> Thanks,
>> -Ravi.
>>
>>
>>
>>
>>
>
>
> --
> Ravi
>



-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] What should be Neutron behavior with scoped token?

2013-10-04 Thread Ravi Chunduru

Does the described behavior qualify as a bug?

Thanks,
-Ravi.


On Thu, Oct 3, 2013 at 5:21 PM, Ravi Chunduru  wrote:

> Hi,
>   In my tests, I observed that when an admin of a tenant runs 'nova list'
> to list down all the servers of the tenant - nova-api makes a call to
> quantum to get_ports with filter set to device owner. This operation is
> taking about 1m 30s in our setup(almost having 100 VMs i.e > 100 ports)
>
> While a user of a tenant runs the same command, the response is immediate.
>
> Going into details - the only difference between those two operations is
> the 'role'.
>
> Looking into the code, I have the following questions
> 1) Scoped Admin token returned all entries of a resource. Any reason not
> filtered per tenant?
> Comparing with Nova - it always honored tenant from the scoped token and
> returns values specific to tenant.
>
> 2) In the above described test, the DB access should not take much time
> with or with out tenant-id in filter. Why change in response time for
> tenant admin or a member user?
>
> Thanks,
> -Ravi.
>
>
>
>
>


-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] What should be Neutron behavior with scoped token?

2013-10-03 Thread Ravi Chunduru

Hi,
  In my tests, I observed that when an admin of a tenant runs 'nova list'
to list down all the servers of the tenant - nova-api makes a call to
quantum to get_ports with filter set to device owner. This operation is
taking about 1m 30s in our setup(almost having 100 VMs i.e > 100 ports)

While a user of a tenant runs the same command, the response is immediate.

Going into details - the only difference between those two operations is
the 'role'.

Looking into the code, I have the following questions
1) Scoped Admin token returned all entries of a resource. Any reason not
filtered per tenant?
Comparing with Nova - it always honored tenant from the scoped token and
returns values specific to tenant.

2) In the above described test, the DB access should not take much time
with or with out tenant-id in filter. Why change in response time for
tenant admin or a member user?

Thanks,
-Ravi.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver

2013-10-02 Thread Ravi Chunduru

Hi Bob,
 Are we talking about naming convention, if so - I am open to suggestions.
 We are defining  metadata for Image - Based on it, virt drivers can
consume it appropriately.

Thanks,
-Ravi.


On Wed, Oct 2, 2013 at 3:17 PM, Bob Ball  wrote:

>  The blueprint currently seems libvirt specific to me?  Is there a common
> - perhaps abstracted - interface that we can provide through Nova / image
> meta-data which will be implemented by each driver in their own way?
>
> Otherwise I can see a bigger mess of metadata values where libvirt uses
> enable_unix_channels, Xen uses enable_cross_domain_channel - each with
> their corresponding and custom ways of configuring the behaviour.
>
>
>
> Bob
>
>
>  ------
> *From:* Ravi Chunduru [ravi...@gmail.com]
> *Sent:* 02 October 2013 19:07
> *To:* Daniel P. Berrange; OpenStack Development Mailing List
>
> *Subject:* Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for
> Nova libvirt driver
>
>   Hi Daniel,
>   I will modify the blueprint as per your suggestions. Actually, we can
> use state_path in nova.conf if set or the default location.
>
>  Thanks,
> -Ravi.
>
>
> On Tue, Oct 1, 2013 at 1:57 AM, Daniel P. Berrange wrote:
>
>> On Mon, Sep 30, 2013 at 02:25:30PM -0700, Ravi Chunduru wrote:
>> > Alessandro,
>> >  I agree with you. I created a Blueprint. Let us collaborate and achieve
>> > this on all types of hypervisors.
>> >
>> > All,
>> >
>> > Here is the link for the BP as discussed.
>> >
>> https://blueprints.launchpad.net/nova/+spec/appliance-communication-channel
>>
>>  That needs to be expanded to describe more about the intended usage
>> of the setup, and consider any security issues. IMHO we really do
>> not want this exposed to end users - particularly not whuen you are
>> proposing the ability to set arbitrary file paths for the UNIX
>> sockets against images. That woudl be a security flaw as proposed
>> in that doc.
>>
>>
>> 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-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
>  --
> Ravi
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver

2013-10-02 Thread Ravi Chunduru

Hi Daniel,
  I will modify the blueprint as per your suggestions. Actually, we can use
state_path in nova.conf if set or the default location.

Thanks,
-Ravi.


On Tue, Oct 1, 2013 at 1:57 AM, Daniel P. Berrange wrote:

> On Mon, Sep 30, 2013 at 02:25:30PM -0700, Ravi Chunduru wrote:
> > Alessandro,
> >  I agree with you. I created a Blueprint. Let us collaborate and achieve
> > this on all types of hypervisors.
> >
> > All,
> >
> > Here is the link for the BP as discussed.
> >
> https://blueprints.launchpad.net/nova/+spec/appliance-communication-channel
>
> That needs to be expanded to describe more about the intended usage
> of the setup, and consider any security issues. IMHO we really do
> not want this exposed to end users - particularly not whuen you are
> proposing the ability to set arbitrary file paths for the UNIX
> sockets against images. That woudl be a security flaw as proposed
> in that doc.
>
>
> 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-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver

2013-09-30 Thread Ravi Chunduru

Alessandro,
 I agree with you. I created a Blueprint. Let us collaborate and achieve
this on all types of hypervisors.

All,

Here is the link for the BP as discussed.
https://blueprints.launchpad.net/nova/+spec/appliance-communication-channel

Thanks,
-Ravi.


On Mon, Sep 30, 2013 at 12:56 PM, Alessandro Pilotti <
apilo...@cloudbasesolutions.com> wrote:

>  Hi all,
>
>  A host / guest communication channel can be useful in a lot of
> scenarios. What about thinking on a common interface to be implemented on
> other hypervisors as well and not only on KVM?
> We're planning to start working on something similar for Hyper-V and there
> were some chats about ideas related to XenServer as well (John?).
>
>  Each hypervisor provides different ways of achieving this goal, but IMO
> it'd be fairly easy to define a common adapter interface.
>
>
>  Alessandro
>
>
>  On Sep 30, 2013, at 20:21 , Daniel P. Berrange 
> wrote:
>
> On Mon, Sep 30, 2013 at 09:46:02AM -0700, Ravi Chunduru wrote:
>
> Let me present an use case.
> Today Nova enables to launch guests of different types.  For real
> deployments we would need appliances from various vendors to run as
> instances.  Appliances can be Loadbalancer, Firewall, IPsec, Routers  or
> UTM etc.,
>
> These appliances can be tied up with Neutron Services and would need
> configuration from various services like FWaaS, LBaaS, VPNaaS etc.,
> One way to configure these appliances from Neutron Agents is by opening up
> the so needed virtio unix channel socket and reach the configuration daemon
> in the appliance.
> Other approach is by having a separate network for management activities
> and having agent to communicate to a daemon in netns to reach out to
> appliance.
>
>
> Thanks, this is the kind of usage information I was asking for, wrt
> host integration. This shows the use case for virtio-serial is as a
> mechanism for integration between infrastructure pieces controlled by
> the cloud admin, not as something that is targetted towards end users
> of the cloud.
>
> I think we need to have a detailed blueprint for this, describing the
> use case(s) to be addressed and proposing some possible design(s).
>
>
> 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-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
>
>


-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver

2013-09-30 Thread Ravi Chunduru

Let me present an use case.
Today Nova enables to launch guests of different types.  For real
deployments we would need appliances from various vendors to run as
instances.  Appliances can be Loadbalancer, Firewall, IPsec, Routers  or
UTM etc.,

These appliances can be tied up with Neutron Services and would need
configuration from various services like FWaaS, LBaaS, VPNaaS etc.,
One way to configure these appliances from Neutron Agents is by opening up
the so needed virtio unix channel socket and reach the configuration daemon
in the appliance.
Other approach is by having a separate network for management activities
and having agent to communicate to a daemon in netns to reach out to
appliance.

For us, it means additional daemon in the second approach. In case of first
approach it is similar to Vmware way of configuring appliance.

Check this for reference
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1010806

Please look from Network appliance perspective to enable this featue. I
welcome if you can suggest us if spicevm or generic qemu guest agent can
help. If so, how the adaptability with vendors can be solved.

Let me know if you need more information.

Thanks,
-Ravi.

On Mon, Sep 30, 2013 at 8:05 AM, Russell Bryant  wrote:

> On 09/30/2013 07:57 AM, Sean Dague wrote:
> > On 09/30/2013 07:51 AM, Daniel P. Berrange wrote:
> > 
> >> I'm not convinced that we should be in the business of adding features
> to
> >> Nova for integration with arbitrary, closed source host components which
> >> we have no information about.
> >
> > +1
>
> +2
>
> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver

2013-09-25 Thread Ravi Chunduru

I got this working after I made guest to behave as serial device and host
side program as unix socket based client.
Now all set to collaborate the BP  with the use case.

Thanks,
-Ravi.


On Wed, Sep 25, 2013 at 8:09 AM, Ravi Chunduru  wrote:

> I am working on this generic virtio-serial interface for appliances. To
> start with I experimented on existing Wangpan's added feature on
> hw_qemu_guest agent. I am preparing to propose a blueprint to modify it for
> generic use and open to collaborate.
>
> I could bring up VM with generic source path(say /tmp/appliance_port) and
> target name(appliance_port). But I see qemu listening on the unix socket in
> host as soon as I start the VM. If we want to have our server program on
> host listening, that should not happen. How do I overcome that?
>
> Thanks,
> -Ravi.
>
>
>
> On Wed, Sep 25, 2013 at 3:01 AM, P Balaji-B37839 wrote:
>
>> 
>>
>> Hi Wangpan,
>>
>> Thanks for Information and suggestions.
>>
>> We want to have generic virtio-serial interface for Libvirt  and
>> applications can use this irrespective of Qemu Guest Agent in VM.
>>
>> As suggested, Daniel can throw some light on this and help us.
>>
>> Regards,
>>
>> Balaji.P
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> *From:* Wangpan [mailto:hzwang...@corp.netease.com]
>> *Sent:* Wednesday, September 25, 2013 3:24 PM
>> *To:* OpenStack Development Mailing List
>> *Subject:* Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support
>> for Nova libvirt driver
>>
>> ** **
>>
>> Hi all,
>>
>>  
>>
>> I'm the owner of this bp
>> https://blueprints.launchpad.net/nova/+spec/qemu-guest-agent-support
>>
>> and Daniel Berrange gave me lots of help about implementing this bp, and
>> the original idea of mine is the same as yours.
>>
>> So I think the opinion of Daniel will be very useful.
>>
>>  
>>
>> 2013-09-25
>>  --
>>
>> Wangpan
>>   --
>>
>> *发件人：*balaji patnala 
>>
>> *发送时间：*2013-09-25 22:36
>>
>> *主**题：*Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for
>> Nova libvirt driver
>>
>> *收件人：*"OpenStack Development Mailing List"<
>> openstack-dev@lists.openstack.org>
>>
>> *抄送：*
>>
>>  
>>
>> Hi Haomai, 
>>
>> ** **
>>
>> Thanks for your interest on this.
>>
>> ** **
>>
>> The code check-ins done against the below bp are more specific to Qemu
>> Guest Agent.
>>
>> ** **
>>
>>  https://blueprints.launchpad.net/nova/+spec/qemu-guest-agent-support
>>
>> ** **
>>
>> ** **
>>
>> Our requirement is to enable Virtio-Serial Interface to the applications
>> running in VM.
>>
>> ** **
>>
>> Do you have the same requirement?
>>
>> ** **
>>
>> We will share the draft BP on this.
>>
>> ** **
>>
>> ** **
>>
>> Any comments on this approach will be helpful.
>>
>> ** **
>>
>> Regards,
>>
>> Balaji.P
>>
>> ** **
>>
>> On Tue, Sep 24, 2013 at 8:10 PM, Haomai Wang 
>> wrote:
>>
>>
>> On Sep 24, 2013, at 6:40 PM, P Balaji-B37839 
>> wrote:
>>
>> > Hi,
>> >
>> > Virtio-Serial interface support for Nova - Libvirt is not available
>> now. Some VMs who wants to access the Host may need like running
>> qemu-guest-agent or any proprietary software want to use this mode of
>> communication with Host.
>> >
>> > Qemu-GA uses virtio-serial communication.
>> >
>> > We want to propose a blue-print on this for IceHouse Release.
>> >
>> > Anybody interested on this.
>>
>> Great! We have common interest and I hope we can promote it for IceHouse.
>>
>> BTW, do you have a initial plan or description about it.
>>
>> And I think this bp may invoke.
>> https://blueprints.launchpad.net/nova/+spec/qemu-guest-agent-support
>>
>>
>> >
>> > Regards,
>> > Balaji.P
>> >
>> >
>> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> Best regards,
>> Haomai Wang, UnitedStack Inc.
>>
>>
>>
>> ___
>> 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
>>
>>
>
>
> --
> Ravi
>



-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for Nova libvirt driver

2013-09-25 Thread Ravi Chunduru

I am working on this generic virtio-serial interface for appliances. To
start with I experimented on existing Wangpan's added feature on
hw_qemu_guest agent. I am preparing to propose a blueprint to modify it for
generic use and open to collaborate.

I could bring up VM with generic source path(say /tmp/appliance_port) and
target name(appliance_port). But I see qemu listening on the unix socket in
host as soon as I start the VM. If we want to have our server program on
host listening, that should not happen. How do I overcome that?

Thanks,
-Ravi.



On Wed, Sep 25, 2013 at 3:01 AM, P Balaji-B37839 wrote:

> 
>
> Hi Wangpan,
>
> Thanks for Information and suggestions.
>
> We want to have generic virtio-serial interface for Libvirt  and
> applications can use this irrespective of Qemu Guest Agent in VM.
>
> As suggested, Daniel can throw some light on this and help us.
>
> Regards,
>
> Balaji.P
>
> ** **
>
> ** **
>
> ** **
>
> *From:* Wangpan [mailto:hzwang...@corp.netease.com]
> *Sent:* Wednesday, September 25, 2013 3:24 PM
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for
> Nova libvirt driver
>
> ** **
>
> Hi all,
>
>  
>
> I'm the owner of this bp
> https://blueprints.launchpad.net/nova/+spec/qemu-guest-agent-support
>
> and Daniel Berrange gave me lots of help about implementing this bp, and
> the original idea of mine is the same as yours.
>
> So I think the opinion of Daniel will be very useful.
>
>  
>
> 2013-09-25
>  --
>
> Wangpan
>   --
>
> *发件人：*balaji patnala 
>
> *发送时间：*2013-09-25 22:36
>
> *主**题：*Re: [openstack-dev] [Nova] [Libvirt] Virtio-Serial support for
> Nova libvirt driver
>
> *收件人：*"OpenStack Development Mailing List"<
> openstack-dev@lists.openstack.org>
>
> *抄送：*
>
>  
>
> Hi Haomai, 
>
> ** **
>
> Thanks for your interest on this.
>
> ** **
>
> The code check-ins done against the below bp are more specific to Qemu
> Guest Agent.
>
> ** **
>
>  https://blueprints.launchpad.net/nova/+spec/qemu-guest-agent-support
>
> ** **
>
> ** **
>
> Our requirement is to enable Virtio-Serial Interface to the applications
> running in VM.
>
> ** **
>
> Do you have the same requirement?
>
> ** **
>
> We will share the draft BP on this.
>
> ** **
>
> ** **
>
> Any comments on this approach will be helpful.
>
> ** **
>
> Regards,
>
> Balaji.P
>
> ** **
>
> On Tue, Sep 24, 2013 at 8:10 PM, Haomai Wang 
> wrote:
>
>
> On Sep 24, 2013, at 6:40 PM, P Balaji-B37839  wrote:
>
> > Hi,
> >
> > Virtio-Serial interface support for Nova - Libvirt is not available now.
> Some VMs who wants to access the Host may need like running
> qemu-guest-agent or any proprietary software want to use this mode of
> communication with Host.
> >
> > Qemu-GA uses virtio-serial communication.
> >
> > We want to propose a blue-print on this for IceHouse Release.
> >
> > Anybody interested on this.
>
> Great! We have common interest and I hope we can promote it for IceHouse.
>
> BTW, do you have a initial plan or description about it.
>
> And I think this bp may invoke.
> https://blueprints.launchpad.net/nova/+spec/qemu-guest-agent-support
>
>
> >
> > Regards,
> > Balaji.P
> >
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> Best regards,
> Haomai Wang, UnitedStack Inc.
>
>
>
> ___
> 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
>
>


-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Virtio-Serial support for Nova libvirt driver

2013-09-24 Thread Ravi Chunduru

There is implementation for qemu guest agent checked into the code.
https://blueprints.launchpad.net/nova/+spec/qemu-guest-agent-support


On Tue, Sep 24, 2013 at 3:40 AM, P Balaji-B37839 wrote:

> Hi,
>
> Virtio-Serial interface support for Nova - Libvirt is not available now.
> Some VMs who wants to access the Host may need like running
> qemu-guest-agent or any proprietary software want to use this mode of
> communication with Host.
>
> Qemu-GA uses virtio-serial communication.
>
> We want to propose a blue-print on this for IceHouse Release.
>
> Anybody interested on this.
>
> Regards,
> Balaji.P
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Candidacy for Compute (Nova) PTL

2013-09-20 Thread Ravi Chunduru

+1


On Fri, Sep 20, 2013 at 10:12 AM, Russell Bryant  wrote:

> Greetings,
>
> I would like to run for the OpenStack Compute (Nova) PTL position.
>
> I am the current Nova PTL.  I have been working on OpenStack since late
> 2011 and have been primarily been focused on Nova since then.  I would
> love to continue in this position to help drive the Nova project
> forward.
>
> Quite a bit of work goes into the PTL position beyond specific technical
> work:
>
> https://wiki.openstack.org/wiki/PTLguide
>
> Most of what I will focus on in this message are the things that I have
> done and would like to do that go beyond technical topics.
>
>
> * Havana
>
> The Havana release is the first release where I served as the Nova PTL.
> I feel that Havana has been a successful development cycle for us so
> far.  You can find record of our progress toward the Havana release on
> each of the milestone pages:
>
> https://launchpad.net/nova/+milestone/havana-1
> https://launchpad.net/nova/+milestone/havana-2
> https://launchpad.net/nova/+milestone/havana-3
> https://launchpad.net/nova/+milestone/havana-rc1
>
> As the PTL, I led the creation of the design summit schedule for the
> Nova track, as well as the majority of the blueprint handling for the
> release roadmap.
>
> For Icehouse, I expect this process to be largely the same, but I would
> like to involve more people in prioritizing design summit sessions, as
> well as reviewing blueprints.
>
>
> * Code Review Process
>
> The PTL of Nova is certainly not the only technical leader in
> the project.  There is a team of technical leaders, the nova-core team,
> responsible for processing the high volume of code review requests we
> receive.  A key responsibility of the Nova PTL is to ensure that the
> nova-core team has the right people on it at the right time.
>
> To that end, I have started doing some things in the last release cycle
> to help with managing the core team.  The first is starting to document
> core team expectations:
>
> https://wiki.openstack.org/wiki/Nova/CoreTeam
>
> The second is gathering metrics around the core activity of the team:
> code reviews:
>
> http://russellbryant.net/openstack-stats/nova-reviewers-30.txt
> http://russellbryant.net/openstack-stats/nova-reviewers-90.txt
> http://russellbryant.net/openstack-stats/nova-reviewers-180.txt
>
> The Nova project has seen an ongoing increase in contributions.  As a
> result, there have been some complaints about review times.  It has been
> a priority of mine to get a handle on this from a project management
> perspective.  The first step here was to start collecting metrics on
> review times, which you can find here:
>
> http://russellbryant.net/openstack-stats/nova-openreviews.html
>
> Using these metrics, I can also compare how the Nova project's review
> team is doing compared to other OpenStack projects.
>
> http://russellbryant.net/openstack-stats/all-openreviews.html
>
> Now that we have this information, we have been able to set goals and
> make changes based on real data.
>
> You can find the code for generating all of these stats here:
>
> http://git.openstack.org/cgit/openstack-infra/reviewstats
>
> As for the future, I think there are some obvious improvements that
> could be made.  The biggest is that I think there is room to add more
> people to the review team when the opportunity presents itself.  I would
> also like to have another discussion about the future of compute
> drivers, and whether maintainers of some drivers would rather have their
> own repository.  I expect to have a design summit session on this topic:
>
> http://summit.openstack.org/cfp/details/4
>
>
> * Sub-project Leadership
>
> One thing that is very apparent to me is that given the Nova project's
> size, I think there are too many things for one person to carry.  There
> are multiple great people in the Nova community that step up regularly
> to make things happen.  I think we should start looking at creating some
> official sub-project leadership roles.  Here are some ideas with some
> potential responsibilities:
>
>  - python-novaclient lead
>- have a vision for python-novaclient
>- review all novaclient patches
>- ensure that novaclient blueprints get reviewed and bugs are triaged
>- build and lead a group of people interested in novaclient
>
>  - nova bug triage lead
>- ensure bugs are triaged
>- ensure the highest priority bugs are discussed, either on the
>  mailing list or in the weekly nova meeting
>- generate metrics on nova bugs
>- set goals for nova bug processing, and track our progress against
>  the goals using the generated metrics
>- build and lead a group of people interested in helping nova by
>  doing bug triage
>
>  - nova-drivers team
>- (This actually already exists, but I think we could formalize
>  responsibilities and make more use of it)
>- responsible for reviewing nova bluepri

Re: [openstack-dev] [Neutron] Security groups with OVS instead of iptables?

2013-09-03 Thread Ravi Chunduru

It is possible to enforce security groups on OVS provided you have Openflow
Controller instead of neutron agent managing the OVS switches.


On Tue, Sep 3, 2013 at 10:29 AM, Scott Devoid  wrote:

> +1 for an answer to this.
>
> The reference documentation suggests running Neutron OVS with a total of 6
> software switches between the VM and public NAT addresses. [1]
> What are the performances differences folks see with this configuration
> vs. the 2 software switch configuration for linux bridge?
>
> [1]
> http://docs.openstack.org/grizzly/openstack-network/admin/content/under_the_hood_openvswitch.html#d6e1178
>
>
> On Tue, Sep 3, 2013 at 8:34 AM, Lorin Hochstein 
> wrote:
>
>> (Also asked at
>> https://ask.openstack.org/en/question/4718/security-groups-with-ovs-instead-of-iptables/
>> )
>>
>> The only security group implementations in neutron seem to be
>> iptables-based. Is it technically possible to implement security groups
>> using openvswitch flow rules, instead of iptables rules?
>>
>> It seems like this would cut down on the complexity associated with the
>> current OVSHybridIptablesFirewallDriver implementation, where we need to
>> create an extra linux bridge and veth pair to work around the
>> iptables-openvswitch issues. (This also breaks if the user happens to
>> install the openvswitch brcompat module).
>>
>> Lorin
>> --
>> Lorin Hochstein
>> Lead Architect - Cloud Services
>> Nimbis Services, Inc.
>> www.nimbisservices.com
>>
>> ___
>> 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
>
>


-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Cells - Neutron Service

2013-08-29 Thread Ravi Chunduru

Its an interesting discussion you brought up today. I agree there is no
clear definition of neutron service in that table. The cell goes by its
definition of ability to create instance anywhere. Then there needs to be
inter-vm communication for a given network.

I feel Neutron must be shared service in Cells. Such depth is missing in
Neutron today.

Any thoughts?

Thanks,
-Ravi.


On Thu, Aug 29, 2013 at 8:00 AM, Addepalli Srini-B22160 <
b22...@freescale.com> wrote:

>  Hi,
>
> ** **
>
> While developing some  neutron extensions, one question came up on Cells.
> Appreciate any comments.
>
> ** **
>
> According to this table in operations guide,  a cell shares nova-api and
> keystone, but does not talk about other services.
>
> ** **
>
> I understand from few that Neutron service need to be shared across cells
> if virtual networks are to be extended to multiple cells.   Otherwise,
> neutron service can be dedicated to each cell.
>
> ** **
>
> I guess anybody developing  neutron related extensions need to take care
> both scenarios.
>
> ** **
>
> Is that understanding correct?  
>
> ** **
>
> Also which deployments are more common – Shared Neutron or dedicated
> neutrons?
>
> ** **
>
> Thanks
> Srini
>
> ** **
>
> ** **
>
> *Cell**s*
>
> *Regions*
>
> *Availability Zones*
>
> *Host Aggregates*
>
> *Use when you need* 
>
> A single API 
> endpointfor
>  compute, or you require a second level of scheduling.
> 
>
> Discrete regions with separate API endpoints and no coordination between
> regions.
>
> Logical separation within your nova deployment for physical isolation or
> redundancy.
>
> To schedule a group of hosts with common features.
>
> *Example* 
>
> A cloud with multiple sites where you can schedule VMs "anywhere" or on a
> particular site.
>
> A cloud with multiple sites, where you schedule VMs to a particular site
> and you want a shared infrastructure.
>
> A single site cloud with equipment fed by separate power supplies.
>
> Scheduling to hosts with trusted hardware support.
>
> *Overhead* 
>
> **· **A new service, nova-cells
>
> **· **Each cell has a full nova installation except nova-api
>
> **· **A different API endpoint for every region. 
>
> **· **Each region has a full nova installation.
>
> **· **Configuration changes to nova.conf
>
> **· **Configuration changes to nova.conf
>
> *Shared services* 
>
> Keystone
>
> nova-api 
>
> Keystone
>
> Keystone
>
> All nova services
>
> Keystone
>
> All nova services
>
> ** **
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Blueprint] Network Aware scheduler

2013-08-07 Thread Ravi Chunduru

Thanks, I will go through these BPs and see if my use case fits.

-Ravi.

On Wed, Aug 7, 2013 at 2:31 PM, Day, Phil  wrote:

>  Hi Ravi,
>
> ** **
>
> I don’t know about that BP – but current the group scheduler BP will be
> including network affinity as one of its policies at some point:
>
> ** **
>
> https://blueprints.launchpad.net/nova/+spec/instance-group-api-extension**
> **
>
> ** **
>
> and there is also another active BP to make network bandwidth a consumable
> resource by the scheduler 
>
> ** **
>
> https://blueprints.launchpad.net/nova/+spec/network-bandwidth-entitlement*
> ***
>
> ** **
>
> Both have code posted for review.****
>
> ** **
>
> Cheers,
>
> Phil
>
> ** **
>
> ** **
>
> *From:* Ravi Chunduru [mailto:ravi...@gmail.com]
> *Sent:* 07 August 2013 19:00
> *To:* OpenStack Development Mailing List
> *Subject:* [openstack-dev] [Nova][Blueprint] Network Aware scheduler
>
> ** **
>
> Hi,
>
>   Please let us know if any one working on this blueprint 
>
> https://blueprints.launchpad.net/nova/+spec/network-aware-scheduler
>
> ** **
>
> Thanks,
>
> -Ravi.
> 
>
> ** **
>
> ** **
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Nova][Blueprint] Network Aware scheduler

2013-08-07 Thread Ravi Chunduru

Hi,
  Please let us know if any one working on this blueprint
https://blueprints.launchpad.net/nova/+spec/network-aware-scheduler

Thanks,
-Ravi.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Configuration of Openflow controller reachability information in OVS from Openstack

2013-08-07 Thread Ravi Chunduru

Right, Nicira controller needs manual OVS certificate addition.
>From my earlier mail
*"Nicira approach today  is to add ovs certificates onto ovs controller
manually."*

Hence, I like Srini's proposal. I suggest to write extensions to your
custom plugin. Once accepted it can be part of the core.

Thanks,
-Ravi.


On Wed, Aug 7, 2013 at 8:15 AM, Somanchi Trinath-B39208 <
b39...@freescale.com> wrote:

>  Hi Ravi-
>
> ** **
>
> We want achieve the same from Quantum Client through Quantum OVS Agent. **
> **
>
> ** **
>
> Is there any such implementation available for the same with openstack.***
> *
>
> ** **
>
> I think, the below manual mentions the manual configuration using ovs cli.
> 
>
> ** **
>
> ** **
>
> ** **
>
> Thanking you.
>
> ** **
>
> --
>
> Trinath Somanchi - B39208
>
> trinath.soman...@freescale.com | extn: 4048
>
> ** **
>
> *From:* Ravi Chunduru [mailto:ravi...@gmail.com]
> *Sent:* Wednesday, August 07, 2013 8:04 PM
>
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] [Neutron] Configuration of Openflow
> controller reachability information in OVS from Openstack
>
>  ** **
>
> Hi Trinath,
>
> ** **
>
> I could get this information from Grizzly installation guide 
> <https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/blob/Nicira_SingleNode/OpenStack_Grizzly_Install_Guide.rst>
> 
>
> ** **
>
> **· **Register this Hypervisor Transport Node (Open vSwitch) with
> Nicira NVP:
>
> **·  **
>
> **·  **
>
> **· **# Set the open vswitch manager address
>
> **· **ovs-vsctl set-manager ssl: controllers>
>
> **·  **
>
> **· **# Get the client pki cert
>
> **· **cat /etc/openvswitch/ovsclient-cert.pem
>
> **·  **
>
> **· **# Copy the contents of the output including the BEGIN and END 
> CERTIFICATE lines and be prepared to paste this into NVP manager
>
> **· **# In NVP Manager add a new Hypervisor, follow the prompts and 
> paste the client certificate when prompted
>
>  # Please review the NVP User Guide for details on adding Hypervisor 
> transport nodes to NVP for more information on this step
>
>  ** **
>
> Thanks,
>
> -Ravi.
>
> ** **
>
> On Wed, Aug 7, 2013 at 2:58 AM, Somanchi Trinath-B39208 <
> b39...@freescale.com> wrote:
>
> Hi Ravi-
>
>  
>
> With respect to NICIRA NVP Plugin in Quantum, All the processing is done
> with respect to Nicira NVP. 
>
>  ****
>
> Also, the Controller cluster arguments are provided from ini file. 
>
>  
>
> Can you point me to where the OVS certificates are handled in Nicira code
> base for quantum.
>
>  
>
>  
>
> --
>
> Trinath Somanchi - B39208
>
> trinath.soman...@freescale.com | extn: 4048
>
>  
>
> *From:* Ravi Chunduru [mailto:ravi...@gmail.com]
> *Sent:* Wednesday, August 07, 2013 11:32 AM
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] [Neutron] Configuration of Openflow
> controller reachability information in OVS from Openstack
>
>  
>
> look into nicira neutrón plugin.
> I like the idea of ovs controller config driven through neutrón api.
> Nicira approach today  is to add ovs certificates onto ovs controller
> manually.
>
> On Aug 6, 2013 9:09 PM, "Addepalli Srini-B22160" 
> wrote:
> >
> > Hi,
> >
> > Using OVS Quantum Plugin and agent,  it is possible to configure OVS with
> >
> > Openflow logical switches.
> > Tables
> > Ports to the logical switches (VLAN, VXLAN, GRE etc..)
> >
> > OVS Agent in each compute node uses local ovs-vsctl command to configure
> above.
> >
> > But, there is no simple way for Openstack quantum to configure OVS in
> compute nodes with  OF controller IP address,  TCP Port,  SSL Certificates
> etc..
> > Also, there is no mechanism today to get hold of DPID of the OVS logical
> switches by Openstack controller.
> >
> > Do  you think that it is good to enhance  Openstack OVS Quantum Plugin
> and agent to pass above information?
> >
> > At very high level, we are thinking to introduce following:
> >
> >
> > Configuration of OF Controller reachability information
> > Quantum extension API though  which is used to set following:
> > Set of Openflow controllers  - For each OF controller
> > IP address,   Port
> > SSL  Enabled

Re: [openstack-dev] [Neutron] Configuration of Openflow controller reachability information in OVS from Openstack

2013-08-07 Thread Ravi Chunduru

Hi Trinath,

I could get this information from Grizzly installation guide
<https://github.com/mseknibilel/OpenStack-Grizzly-Install-Guide/blob/Nicira_SingleNode/OpenStack_Grizzly_Install_Guide.rst>


   -

   Register this Hypervisor Transport Node (Open vSwitch) with Nicira NVP:

   # Set the open vswitch manager address
   ovs-vsctl set-manager ssl:

   # Get the client pki cert
   cat /etc/openvswitch/ovsclient-cert.pem
   # Copy the contents of the output including the BEGIN and END
CERTIFICATE lines and be prepared to paste this into NVP manager
   # In NVP Manager add a new Hypervisor, follow the prompts and paste
the client certificate when prompted
   # Please review the NVP User Guide for details on adding Hypervisor
transport nodes to NVP for more information on this step



Thanks,
-Ravi.

On Wed, Aug 7, 2013 at 2:58 AM, Somanchi Trinath-B39208 <
b39...@freescale.com> wrote:

>  Hi Ravi-
>
> ** **
>
> With respect to NICIRA NVP Plugin in Quantum, All the processing is done
> with respect to Nicira NVP. 
>
> ** **
>
> Also, the Controller cluster arguments are provided from ini file. 
>
> ** **
>
> Can you point me to where the OVS certificates are handled in Nicira code
> base for quantum.
>
> ** **
>
> ** **
>
> --
>
> Trinath Somanchi - B39208****
>
> trinath.soman...@freescale.com | extn: 4048
>
> ** **
>
> *From:* Ravi Chunduru [mailto:ravi...@gmail.com]
> *Sent:* Wednesday, August 07, 2013 11:32 AM
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] [Neutron] Configuration of Openflow
> controller reachability information in OVS from Openstack
>
> ** **
>
> look into nicira neutrón plugin.
> I like the idea of ovs controller config driven through neutrón api.
> Nicira approach today  is to add ovs certificates onto ovs controller
> manually.
>
> On Aug 6, 2013 9:09 PM, "Addepalli Srini-B22160" 
> wrote:
> >
> > Hi,
> >
> > Using OVS Quantum Plugin and agent,  it is possible to configure OVS with
> >
> > Openflow logical switches.
> > Tables
> > Ports to the logical switches (VLAN, VXLAN, GRE etc..)
> >
> > OVS Agent in each compute node uses local ovs-vsctl command to configure
> above.
> >
> > But, there is no simple way for Openstack quantum to configure OVS in
> compute nodes with  OF controller IP address,  TCP Port,  SSL Certificates
> etc..
> > Also, there is no mechanism today to get hold of DPID of the OVS logical
> switches by Openstack controller.
> >
> > Do  you think that it is good to enhance  Openstack OVS Quantum Plugin
> and agent to pass above information?
> >
> > At very high level, we are thinking to introduce following:
> >
> >
> > Configuration of OF Controller reachability information
> > Quantum extension API though  which is used to set following:
> > Set of Openflow controllers  - For each OF controller
> > IP address,   Port
> > SSL  Enabled Yes/No.
> > If SSL enabled
> > CA certificate chain to validate OF controller identification by the OVS.
> > Zone/Cell for which this OF controller is applicable for.
> > Changes to QuantumClient to configure above.
> > OVS Quantum Plugin to store above information in the database.
> > OVS Quantum Agent to Plugin communication to get hold of OF controller
> information.
> > OVS Quantum Agent to add the information in OVS using ovs-vsctl.
> > Generation of logical switch certificates
> >   OVS Quantum agent requests the plugin to generate local certificate
> and private key for each one of the logical switches
> > Agent to send DPID
> > Plugin to generate certificate & private key pair and sending them as
> response.
> > Plugin configuration file to have CA certificate to use to sign the
> logical switch certificates.
> >
> >
> > Does that make sense?  Is this work going on somewhere else?
> >
> > Thanks
> > Srini
> >
> >
> >
> >
> > ___
> > 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
>
>


-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Configuration of Openflow controller reachability information in OVS from Openstack

2013-08-06 Thread Ravi Chunduru

look into nicira neutrón plugin.
I like the idea of ovs controller config driven through neutrón api. Nicira
approach today  is to add ovs certificates onto ovs controller manually.

On Aug 6, 2013 9:09 PM, "Addepalli Srini-B22160" 
wrote:
>
> Hi,
>
> Using OVS Quantum Plugin and agent,  it is possible to configure OVS with
>
> Openflow logical switches.
> Tables
> Ports to the logical switches (VLAN, VXLAN, GRE etc..)
>
> OVS Agent in each compute node uses local ovs-vsctl command to configure
above.
>
> But, there is no simple way for Openstack quantum to configure OVS in
compute nodes with  OF controller IP address,  TCP Port,  SSL Certificates
etc..
> Also, there is no mechanism today to get hold of DPID of the OVS logical
switches by Openstack controller.
>
> Do  you think that it is good to enhance  Openstack OVS Quantum Plugin
and agent to pass above information?
>
> At very high level, we are thinking to introduce following:
>
>
> Configuration of OF Controller reachability information
> Quantum extension API though  which is used to set following:
> Set of Openflow controllers  - For each OF controller
> IP address,   Port
> SSL  Enabled Yes/No.
> If SSL enabled
> CA certificate chain to validate OF controller identification by the OVS.
> Zone/Cell for which this OF controller is applicable for.
> Changes to QuantumClient to configure above.
> OVS Quantum Plugin to store above information in the database.
> OVS Quantum Agent to Plugin communication to get hold of OF controller
information.
> OVS Quantum Agent to add the information in OVS using ovs-vsctl.
> Generation of logical switch certificates
>   OVS Quantum agent requests the plugin to generate local certificate and
private key for each one of the logical switches
> Agent to send DPID
> Plugin to generate certificate & private key pair and sending them as
response.
> Plugin configuration file to have CA certificate to use to sign the
logical switch certificates.
>
>
> Does that make sense?  Is this work going on somewhere else?
>
> Thanks
> Srini
>
>
>
>
> ___
> 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] Openstack Service requirement

2013-08-01 Thread Ravi Chunduru

Monty,
 I had a quick look on ceilometer, it looks one place to get all
notifications.
I will deploy and try it out.

Thanks,
-Ravi.

On Wed, Jul 31, 2013 at 10:34 PM, Monty Taylor  wrote:

> Also, if you're wanting to buld services on top of OpenStack that want
> to respond to events - you probably want to look in to ceilometer, which
> has an interface to export such events to you.
>
> On 08/01/2013 01:02 AM, Addepalli Srini-B22160 wrote:
> > RPC  will send the notifications to the queues that have joined the
> > exchanges.
> >
> >
> >
> > Any notifications that were published before your service registers are
> > not seen by your service.
> >
> >
> >
> > Your service needs to get hold of the data using Nova and Neutron API.
> >
> >
> >
> > In summary,  when your service comes up,  in addition to registering for
> > notifications,  it is needed to get the existing data using
> > Nova/Neutrion API.
> >
> >
> >
> > Thanks
> >
> > SRini
> >
> >
> >
> > *From:*Ravi Chunduru [mailto:ravi...@gmail.com]
> > *Sent:* Wednesday, July 31, 2013 10:57 AM
> > *To:* OpenStack Development Mailing List
> > *Subject:* Re: [openstack-dev] Openstack Service requirement
> >
> >
> >
> > Hi,
> >
> >  Could any one respond on this? This helps us in designing services
> > written on top of openstack.
> >
> >
> >
> > Thanks,
> >
> > -Ravi.
> >
> > On Tue, Jul 30, 2013 at 7:38 PM, Ravi Chunduru  > <mailto:ravi...@gmail.com>> wrote:
> >
> > Hi,
> >
> >  I was designing a Openstack service that listens on notifications
> > generated from Nova, Neutron etc., for our custom needs to monitor and
> > act up on events.
> >
> > I have an interesting observation from openstack perspective and I would
> > like to know community thinking about it.
> >
> >
> >
> > By the time an openstack service starts, it would have missed some
> > notifications.  How do we deal with it?
> >
> >
> >
> > For example, Designate(DNSaaS) starts and by that time some VMs got
> > created, it would loose to update the DNS servers for those VMs.
> >
> > Should any openstack service such as Designate  call openstack APIs and
> > get existing configuration?
> >
> >
> >
> > Thanks,
> >
> > --
> > Ravi
> >
> >
> >
> >
> >
> > --
> > Ravi
> >
> >
> >
> > ___
> > 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
>



-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Openstack Service requirement

2013-08-01 Thread Ravi Chunduru

Thanks. This will be expected behavior then.

-Ravi.

On Wed, Jul 31, 2013 at 10:02 PM, Addepalli Srini-B22160 <
b22...@freescale.com> wrote:

>  RPC  will send the notifications to the queues that have joined the
> exchanges.
>
> ** **
>
> Any notifications that were published before your service registers are
> not seen by your service.
>
> ** **
>
> Your service needs to get hold of the data using Nova and Neutron API.
>
> ** **
>
> In summary,  when your service comes up,  in addition to registering for
> notifications,  it is needed to get the existing data using Nova/Neutrion
> API.  
>
> ** **
>
> Thanks
>
> SRini
>
> ** **
>
> *From:* Ravi Chunduru [mailto:ravi...@gmail.com]
> *Sent:* Wednesday, July 31, 2013 10:57 AM
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] Openstack Service requirement
>
> ** **
>
> Hi,
>
>  Could any one respond on this? This helps us in designing services
> written on top of openstack.
>
> ** **
>
> Thanks,
>
> -Ravi.
>
> On Tue, Jul 30, 2013 at 7:38 PM, Ravi Chunduru  wrote:*
> ***
>
> Hi,
>
>  I was designing a Openstack service that listens on notifications
> generated from Nova, Neutron etc., for our custom needs to monitor and act
> up on events.
>
> I have an interesting observation from openstack perspective and I would
> like to know community thinking about it.
>
> ** **
>
> By the time an openstack service starts, it would have missed some
> notifications.  How do we deal with it?
>
> ** **
>
> For example, Designate(DNSaaS) starts and by that time some VMs got
> created, it would loose to update the DNS servers for those VMs.
>
> Should any openstack service such as Designate  call openstack APIs and
> get existing configuration?
>
> ** **
>
> Thanks,
>
> --
> Ravi
>
>
>
> 
>
> ** **
>
> --
> Ravi
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: Blueprint information

2013-07-31 Thread Ravi Chunduru

Hi Salvatore,
 Thanks for the reply.
Currently in our deployments, we do have an Orchestrated implementation
using neutron API calls in nova to assign Floating IP to the VM port. As
you rightly said, there are numerous API calls to Neutron involved. Hence
wanted to move to Neutron.

One use case which is making us think is the ability to provide this
floating IP assignment per tenant's choice. Currently the blueprint
suggests global option. Any suggestion on overriding this option per tenant
basis?

One way is to leave this choice to the deployment. If a tenant does not
want Floating IP assigned to his instances must not associate the subnet to
the router which has external network attached. This way no need to change
in API specs. Will that be good enough?

Appreciate your suggestions.

Thanks,
-Ravi.


On Wed, Jul 31, 2013 at 11:18 AM, Salvatore Orlando wrote:

> Providing this capability in Neutron won't be hard.
> As discussed previously in this thread this operation can be achieved
> using a sequence of Neutron API calls.
> The sequence would be pretty much the following:
> 1) verify network is associated with router, and router has external
> gateway configured
> 2) create port
> 3) allocate floating IP
> 4) associate floating IP with port
>
> You can surely implement it directly in Neutron - and there's no strong
> opposition fromme.
> From an architectural perspective, Neutron exposes an API for 'atomic'
> operations. Composite, or orchestrated, operations, are better delegated to
> an appropriate service, which, in this case, if the
> nova.network.neutronv2.api module.
>
> The argument for building this capability directly in neutron would be to
> reduce the amount of API calls needed to achieve this goal.
> If you want to proceed with implementing it directly in neutron, don't
> mind my opinion. I am just a grumpy guy who loves to moan about pretty much
> everything.
>
> Salvatore
>
>
>
> On 31 July 2013 19:41, Ravi Chunduru  wrote:
>
>> The blueprint proposed to assign auto floating IP during port creation.
>> Since auto floating IP is supported in nova-network, +1 to implement the
>> same in Neutron.
>>
>> Salvatore,
>>   Can you share with us the concerns in implementing in Neutron?
>>
>> Thanks,
>> -Ravi.
>>
>>
>>
>>
>>
>>
>> On Wed, Jul 31, 2013 at 12:57 AM, Salvatore Orlando 
>> wrote:
>>
>>> Hi Ofer,
>>>
>>> Basically this operation consists in ensuring that an instance, when
>>> it's booted, is also associated with a floating IP address, and therefore
>>> publicly accessible.
>>> I discussed this topic a couple months ago with another developer, but I
>>> am now unable to find the chat in the openstack-dev IRC logs.
>>>
>>> The bottom line is that even if this is registered as a neutron
>>> blueprint, we are not really sure Neutron is the right place to perform
>>> orchestration operation.
>>> And this operation falls into this category - since it involves,
>>> creating a port, ensuring the network for that port is associated with a
>>> router, allocating a floating IP, and associating it with the port.
>>>
>>> Currently all the orchestration operations are performed in the module
>>> which configures instances networking, which is part of nova. This module
>>> (nova.network.quantumv2.api) uses the quantum API.
>>> I reckon this blueprint should be implemented there performing the
>>> operations listed above.
>>>
>>> Salvatore
>>>
>>>
>>> On 28 July 2013 16:16, Ofer Blaut  wrote:
>>>
>>>> Hi
>>>>
>>>> Hi, I am interested in helping out with QE efforts on upstream
>>>> OpenStack, specifically around Neutron.
>>>>
>>>> I'm trying to understand the following blueprint,can you please point
>>>> me to more detailed design
>>>>
>>>>
>>>> https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip
>>>>
>>>>
>>>> Thanks
>>>>
>>>> Ofer Blaut
>>>>
>>>>
>>>> ___
>>>> 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
>>>
>>>
>>
>>
>> --
>> Ravi
>>
>> ___
>> 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
>
>


-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Openstack Service requirement

2013-07-31 Thread Ravi Chunduru

Hi,
 Could any one respond on this? This helps us in designing services written
on top of openstack.

Thanks,
-Ravi.

On Tue, Jul 30, 2013 at 7:38 PM, Ravi Chunduru  wrote:

> Hi,
>  I was designing a Openstack service that listens on notifications
> generated from Nova, Neutron etc., for our custom needs to monitor and act
> up on events.
> I have an interesting observation from openstack perspective and I would
> like to know community thinking about it.
>
> By the time an openstack service starts, it would have missed some
> notifications.  How do we deal with it?
>
> For example, Designate(DNSaaS) starts and by that time some VMs got
> created, it would loose to update the DNS servers for those VMs.
> Should any openstack service such as Designate  call openstack APIs and
> get existing configuration?
>
> Thanks,
> --
> Ravi
>



-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Fwd: Blueprint information

2013-07-31 Thread Ravi Chunduru

The blueprint proposed to assign auto floating IP during port creation.
Since auto floating IP is supported in nova-network, +1 to implement the
same in Neutron.

Salvatore,
  Can you share with us the concerns in implementing in Neutron?

Thanks,
-Ravi.






On Wed, Jul 31, 2013 at 12:57 AM, Salvatore Orlando wrote:

> Hi Ofer,
>
> Basically this operation consists in ensuring that an instance, when it's
> booted, is also associated with a floating IP address, and therefore
> publicly accessible.
> I discussed this topic a couple months ago with another developer, but I
> am now unable to find the chat in the openstack-dev IRC logs.
>
> The bottom line is that even if this is registered as a neutron blueprint,
> we are not really sure Neutron is the right place to perform orchestration
> operation.
> And this operation falls into this category - since it involves, creating
> a port, ensuring the network for that port is associated with a router,
> allocating a floating IP, and associating it with the port.
>
> Currently all the orchestration operations are performed in the module
> which configures instances networking, which is part of nova. This module
> (nova.network.quantumv2.api) uses the quantum API.
> I reckon this blueprint should be implemented there performing the
> operations listed above.
>
> Salvatore
>
>
> On 28 July 2013 16:16, Ofer Blaut  wrote:
>
>> Hi
>>
>> Hi, I am interested in helping out with QE efforts on upstream
>> OpenStack, specifically around Neutron.
>>
>> I'm trying to understand the following blueprint,can you please point me
>> to more detailed design
>>
>> https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip
>>
>>
>> Thanks
>>
>> Ofer Blaut
>>
>>
>> ___
>> 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
>
>


-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Openstack Service requirement

2013-07-30 Thread Ravi Chunduru

Hi,
 I was designing a Openstack service that listens on notifications
generated from Nova, Neutron etc., for our custom needs to monitor and act
up on events.
I have an interesting observation from openstack perspective and I would
like to know community thinking about it.

By the time an openstack service starts, it would have missed some
notifications.  How do we deal with it?

For example, Designate(DNSaaS) starts and by that time some VMs got
created, it would loose to update the DNS servers for those VMs.
Should any openstack service such as Designate  call openstack APIs and get
existing configuration?

Thanks,
-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][LBaaS] Appliance support

2013-07-10 Thread Ravi Chunduru

Hi,
 I would like to know if we have any plans/proposal to move forward from
haproxy in network namespace to support haproxy in a virtual appliance.
And any vendor contribution in drivers for their appliances.

Thanks,
-Ravi.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] FW: [Keystone][Folsom] Token re-use

2013-06-20 Thread Ravi Chunduru

I liked the idea of not storing the tokens and keystone will verify the
validity by signature. Expiry time can still be set for the generated token
however we want.

On Thu, Jun 20, 2013 at 1:50 PM, Ali, Haneef  wrote:

>  **1)  **I’m really not sure how that will solve the original issue
> (Token table size increase).  Of course we can have a job to remove the
> expired token. 
>
> **2)  **We really have to think how the other services are using
> keystone.  Keystone “createToken” volume is going to increase. Fixing one
> issue going to create another one.
>
> **1.   ** If I  understood correctly  swift is using memcache to
> increase the  validateToken performance.  What will happen to it?
> Obviously load  to  “validateToken” will also increase.
>
> **2.   **In few cases I have seen VM creation taking more than 5
> min.  ( download image from glance and create vm).   Short lived token ( 5
> min) will be a real fun  in this case.
>
> ** **
>
> Thanks
>
> Haneef
>
> ** **
>
> ** **
>
> *From:* Ravi Chunduru [mailto:ravi...@gmail.com]
> *Sent:* Thursday, June 20, 2013 11:49 AM
>
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] FW: [Keystone][Folsom] Token re-use
>
>  ** **
>
> +1 
>
> On Thu, Jun 20, 2013 at 11:37 AM, Dolph Mathews 
> wrote:
>
> ** **
>
> On Wed, Jun 19, 2013 at 2:20 PM, Adam Young  wrote:
>
> I really want to go the other way on this:  I want token to be very short
> lived, ideally something like 1 minute, but probably 5 minutes to account
> for clock skew.  I want to get rid of token revocation list checking.  I'd
> like to get away from revocation altogether:  tokens are not stored in the
> backend.  If they are ephemeral, we can just check that the token has a
> valid signature and that the time has not expired.
>
> ** **
>
> +10
>
>  
>
>
>
>
>
>
>
> On 06/19/2013 12:59 PM, Ravi Chunduru wrote:
>
> Thats still an open item in this thread. 
>
> ** **
>
> Let me summarize once again
>
> ** **
>
> 1) Use case for keystone not to re-issue same token for same credentials**
> **
>
> 2) Ratelimit cons and service unavailability 
>
> 3) Further information on python keyring if not going by keystone re-issue
> of the tokens.
>
> On Wed, Jun 19, 2013 at 9:16 AM, Yee, Guang  wrote:
>
> Just out of curiosity, is there really a use case where user need to
> request multiple tokens of the same scope, where the only difference are
> the expiration dates?
>
>  
>
>  
>
> Guang
>
>  
>
>  
>
> *From:* Dolph Mathews [mailto:dolph.math...@gmail.com]
> *Sent:* Wednesday, June 19, 2013 7:27 AM
>
>
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] FW: [Keystone][Folsom] Token re-use
>
>  
>
>  
>
> On Wed, Jun 19, 2013 at 1:42 AM, Ali, Haneef  wrote:***
> *
>
> 1)  Token Caching is not always going to help. It depends on the
> application.E.g  A user  writes a cron  job to check the health of
> swift by listing a  predefined container every 1 minute.This will
> obviously create a token every minute.  
>
>  
>
> 2)  Also  I like to understand how rate limiting is done for v3
> tokens.   Rate limiting involves source ip + request pattern.  In V3 there
> are so many ways to get the token and the rate limiting becomes too complex
> 
>
>  
>
> Rate limit the number of requests to POST /v2.0/tokens and POST
> /v3/auth/tokens
>
>  Just for unscoped token,  all the following are equivalent requests.
>  In case of scoped tokens we have even more combinations.   Rouge clients
> can easily mess with rate limiting by mixing request patterns. Also rate
> limiting across regions may not be possible.
>
> a.UserId/Password
>
> b.   UserName/Password/domainId
>
> c.   UserName/Password/DomainName
>
>  
>
> Thanks
>
> Haneef
>
>  
>
> *From:* Ravi Chunduru [mailto:ravi...@gmail.com]
> *Sent:* Tuesday, June 18, 2013 11:02 PM
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] FW: [Keystone][Folsom] Token re-use
>
>  
>
> I agree we need a way to overcome these rogue clients but by rate limiting
> genuine requests will get effected. Then one would need retries and some
> times critical operations gets failed. It beats the whole logic of being
> available.
>
>  
>
>  
>
> About the keyrings, How do we tackle if a service is using JS

Re: [openstack-dev] FW: [Keystone][Folsom] Token re-use

2013-06-20 Thread Ravi Chunduru

+1

On Thu, Jun 20, 2013 at 11:37 AM, Dolph Mathews wrote:

>
> On Wed, Jun 19, 2013 at 2:20 PM, Adam Young  wrote:
>
>>  I really want to go the other way on this:  I want token to be very
>> short lived, ideally something like 1 minute, but probably 5 minutes to
>> account for clock skew.  I want to get rid of token revocation list
>> checking.  I'd like to get away from revocation altogether:  tokens are not
>> stored in the backend.  If they are ephemeral, we can just check that the
>> token has a valid signature and that the time has not expired.
>>
>
> +10
>
>
>>
>>
>>
>>
>>
>>
>> On 06/19/2013 12:59 PM, Ravi Chunduru wrote:
>>
>> Thats still an open item in this thread.
>>
>>  Let me summarize once again
>>
>>  1) Use case for keystone not to re-issue same token for same credentials
>> 2) Ratelimit cons and service unavailability
>> 3) Further information on python keyring if not going by keystone
>> re-issue of the tokens.
>>
>> On Wed, Jun 19, 2013 at 9:16 AM, Yee, Guang  wrote:
>>
>>>  Just out of curiosity, is there really a use case where user need to
>>> request multiple tokens of the same scope, where the only difference are
>>> the expiration dates?
>>>
>>>
>>>
>>>
>>>
>>> Guang
>>>
>>>
>>>
>>>
>>>
>>> *From:* Dolph Mathews [mailto:dolph.math...@gmail.com]
>>> *Sent:* Wednesday, June 19, 2013 7:27 AM
>>>
>>> *To:* OpenStack Development Mailing List
>>> *Subject:* Re: [openstack-dev] FW: [Keystone][Folsom] Token re-use
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jun 19, 2013 at 1:42 AM, Ali, Haneef  wrote:
>>>
>>> 1)  Token Caching is not always going to help. It depends on the
>>> application.E.g  A user  writes a cron  job to check the health of
>>> swift by listing a  predefined container every 1 minute.This will
>>> obviously create a token every minute.
>>>
>>>
>>>
>>> 2)  Also  I like to understand how rate limiting is done for v3
>>> tokens.   Rate limiting involves source ip + request pattern.  In V3 there
>>> are so many ways to get the token and the rate limiting becomes too complex
>>>
>>>
>>>
>>> Rate limit the number of requests to POST /v2.0/tokens and POST
>>> /v3/auth/tokens
>>>
>>>  Just for unscoped token,  all the following are equivalent requests.
>>>  In case of scoped tokens we have even more combinations.   Rouge clients
>>> can easily mess with rate limiting by mixing request patterns. Also rate
>>> limiting across regions may not be possible.
>>>
>>> a.UserId/Password
>>>
>>> b.   UserName/Password/domainId
>>>
>>> c.   UserName/Password/DomainName
>>>
>>>
>>>
>>> Thanks
>>>
>>> Haneef
>>>
>>>
>>>
>>> *From:* Ravi Chunduru [mailto:ravi...@gmail.com]
>>> *Sent:* Tuesday, June 18, 2013 11:02 PM
>>> *To:* OpenStack Development Mailing List
>>> *Subject:* Re: [openstack-dev] FW: [Keystone][Folsom] Token re-use
>>>
>>>
>>>
>>> I agree we need a way to overcome these rogue clients but by rate
>>> limiting genuine requests will get effected. Then one would need retries
>>> and some times critical operations gets failed. It beats the whole logic of
>>> being available.
>>>
>>>
>>>
>>>
>>>
>>> About the keyrings, How do we tackle if a service is using JSON API
>>> calls and not python clients?
>>>
>>>
>>>
>>> Thanks,
>>>
>>> -Ravi.
>>>
>>> On Tue, Jun 18, 2013 at 6:37 PM, Adam Young  wrote:
>>>
>>> On 06/18/2013 09:13 PM, Kant, Arun wrote:
>>>
>>>  The issue with having un-managed number of tokens for same credential
>>> is that it can be easily exploited. Getting a token is one of initial step
>>> (gateway) to get access to services. A rogue client can keep creating
>>> unlimited number of tokens and possibly create denial of service attack on
>>> services. If there are somewhat limited number of tokens, then cloud
>>> provider can possibly use tokenId based rate-limiting approach.
>>>
>>>  Better here to rate limit, then.
>>>
>>>
>>>
>>>
>>>
>>>
>>

Re: [openstack-dev] FW: [Keystone][Folsom] Token re-use

2013-06-19 Thread Ravi Chunduru

Thats still an open item in this thread.

Let me summarize once again

1) Use case for keystone not to re-issue same token for same credentials
2) Ratelimit cons and service unavailability
3) Further information on python keyring if not going by keystone re-issue
of the tokens.

On Wed, Jun 19, 2013 at 9:16 AM, Yee, Guang  wrote:

> Just out of curiosity, is there really a use case where user need to
> request multiple tokens of the same scope, where the only difference are
> the expiration dates?
>
> ** **
>
> ** **
>
> Guang
>
> ** **
>
> ** **
>
> *From:* Dolph Mathews [mailto:dolph.math...@gmail.com]
> *Sent:* Wednesday, June 19, 2013 7:27 AM
>
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] FW: [Keystone][Folsom] Token re-use
>
> ** **
>
> ** **
>
> On Wed, Jun 19, 2013 at 1:42 AM, Ali, Haneef  wrote:***
> *
>
> 1)  Token Caching is not always going to help. It depends on the
> application.E.g  A user  writes a cron  job to check the health of
> swift by listing a  predefined container every 1 minute.This will
> obviously create a token every minute.  
>
>  
>
> 2)  Also  I like to understand how rate limiting is done for v3
> tokens.   Rate limiting involves source ip + request pattern.  In V3 there
> are so many ways to get the token and the rate limiting becomes too complex
> 
>
>  
>
> Rate limit the number of requests to POST /v2.0/tokens and POST
> /v3/auth/tokens
>
> Just for unscoped token,  all the following are equivalent requests.   In
> case of scoped tokens we have even more combinations.   Rouge clients can
> easily mess with rate limiting by mixing request patterns. Also rate
> limiting across regions may not be possible.
>
> a.UserId/Password
>
> b.   UserName/Password/domainId
>
> c.   UserName/Password/DomainName
>
>  
>
> Thanks
>
> Haneef
>
>  
>
> *From:* Ravi Chunduru [mailto:ravi...@gmail.com]
> *Sent:* Tuesday, June 18, 2013 11:02 PM
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] FW: [Keystone][Folsom] Token re-use
>
>  
>
> I agree we need a way to overcome these rogue clients but by rate limiting
> genuine requests will get effected. Then one would need retries and some
> times critical operations gets failed. It beats the whole logic of being
> available.
>
>  
>
>  
>
> About the keyrings, How do we tackle if a service is using JSON API calls
> and not python clients?
>
>  
>
> Thanks,
>
> -Ravi.
>
> On Tue, Jun 18, 2013 at 6:37 PM, Adam Young  wrote:
>
> On 06/18/2013 09:13 PM, Kant, Arun wrote:
>
> The issue with having un-managed number of tokens for same credential is
> that it can be easily exploited. Getting a token is one of initial step
> (gateway) to get access to services. A rogue client can keep creating
> unlimited number of tokens and possibly create denial of service attack on
> services. If there are somewhat limited number of tokens, then cloud
> provider can possibly use tokenId based rate-limiting approach.
>
> Better here to rate limit, then.
>
>
>
>
> 
>
>  
>
> Extending the expiry to some fixed interval might be okay as that can be
> considered as continuing user session similar to what is seen when a user
> keeps browsing an application while logged in.  
>
> Tokens are resources created by Keystone.  No reason to ask to create
> something new if it is not needed.
>
> The caching needs to be done client side.  We have ongoing work using
> python-keyring to support that.
>
> 
>
>  
>
> -Arun****
>
>  
>
>  
>
> *From: *Adam Young 
> *Reply-To: *OpenStack Development Mailing List <
> openstack-dev@lists.openstack.org>
> *Date: *Friday, June 14, 2013 3:33 PM
> *To: *"openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [Keystone][Folsom] Token re-use
>
>  
>
> On 06/13/2013 07:58 PM, Ravi Chunduru wrote:
>
> Hi, 
>
>   We are having Folsom setup and we find that our token table increases a
> lot. I understand client can re-use the token but why doesnt keystone reuse
> the token if client asks it with same credentials.. 
>
> I would like to know if there is any reason for not doing so.
>
>  
>
> Thanks in advance,
>
> --
> Ravi
>
> ** **
>
> ___
>

Re: [openstack-dev] FW: [Keystone][Folsom] Token re-use

2013-06-18 Thread Ravi Chunduru

I agree we need a way to overcome these rogue clients but by rate limiting
genuine requests will get effected. Then one would need retries and some
times critical operations gets failed. It beats the whole logic of being
available.


About the keyrings, How do we tackle if a service is using JSON API calls
and not python clients?

Thanks,
-Ravi.

On Tue, Jun 18, 2013 at 6:37 PM, Adam Young  wrote:

>  On 06/18/2013 09:13 PM, Kant, Arun wrote:
>
>  The issue with having un-managed number of tokens for same credential is
> that it can be easily exploited. Getting a token is one of initial step
> (gateway) to get access to services. A rogue client can keep creating
> unlimited number of tokens and possibly create denial of service attack on
> services. If there are somewhat limited number of tokens, then cloud
> provider can possibly use tokenId based rate-limiting approach.
>
> Better here to rate limit, then.
>
>
>
>  
>
> ** **
>
> Extending the expiry to some fixed interval might be okay as that can be
> considered as continuing user session similar to what is seen when a user
> keeps browsing an application while logged in.
>
> Tokens are resources created by Keystone.  No reason to ask to create
> something new if it is not needed.
>
> The caching needs to be done client side.  We have ongoing work using
> python-keyring to support that.
>
>  
>
> ** **
>
> -Arun
>
> ** **
>
> ** **
>
> *From: *Adam Young 
> *Reply-To: *OpenStack Development Mailing List <
> openstack-dev@lists.openstack.org>
> *Date: *Friday, June 14, 2013 3:33 PM
> *To: *"openstack-dev@lists.openstack.org" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [Keystone][Folsom] Token re-use
>
> ** **
>
> On 06/13/2013 07:58 PM, Ravi Chunduru wrote:
>
> Hi, 
>
>   We are having Folsom setup and we find that our token table increases a
> lot. I understand client can re-use the token but why doesnt keystone reuse
> the token if client asks it with same credentials.. 
>
> I would like to know if there is any reason for not doing so.
>
> ** **
>
> Thanks in advance,
>
> --
> Ravi
>
>
>
>
> 
>
> ___
>
> OpenStack-dev mailing list
>
> OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>  You can cache the token on the client side and reuse. Tokens have a an
> expiry, so if you request a new token, you extend the expiry.  
>
>
> ___
> OpenStack-dev mailing 
> listOpenStack-dev@lists.openstack.orghttp://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
>
>


-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Expired tokens in Keystone

2013-06-18 Thread Ravi Chunduru

The important point I want to make is availability of service, if there are
too many client requests to keystone, it ends up creating too many tokens.
Under such circumstances, when user runs keystone command like user role
add which  makes keystone to revoke tokens for given user id and tenant id
making it unresponsive for several minutes depending on number of tokens.

1) Keystone becomes unavailable for a while
2) DB lookup is not possible directly by user_id in revoke tokens.

Atleast #2 should be fixed for DB query to succeed fast enough.

PS: We are using Folsom

Thanks,
-Ravi.


On Fri, Jun 14, 2013 at 1:43 PM, Dolph Mathews wrote:

> The token creation API (e.g. POST /v2.0/tokens and POST /v3/auth/tokens)
> is not intended to be idempotent. To rephrase RFC 2616 a bit:
>
>   The important distinction here is that the user requested side-effects,
> and can therefore be held accountable for them.
>
> Changing this behavior represents a change to the API, not just it's
> implementation. I don't see how you could make such a change in a backwards
> compatible manner (if a client intends to create multiple tokens, you would
> be breaking them) without introducing a whole new call (e.g. PUT
> /v3/auth/tokens ?).
>
> In the mean time, the burden remains on the client to cache and recycle
> their own tokens.
>
>
> -Dolph
>
>
> On Fri, Jun 14, 2013 at 3:24 PM, Ravi Chunduru  wrote:
>
>> On the problem you described, I like the idea of configuration parameter
>> for what point we need to issue vs re-use.
>>
>> Thanks,
>> -Ravi.
>>
>>
>> On Fri, Jun 14, 2013 at 8:03 AM, Yee, Guang  wrote:
>>
>>> I think there was a case in which user started a VM snapshot in Nova
>>> with a to-be-expired token and by the time the snapshot reached Glance the
>>> token had already expired. 
>>>
>>> ** **
>>>
>>> But I like the idea of token reuse. Probably need a configurable
>>> parameter to determine at what point we need to issue a new token versus
>>> reusing an existing one. Maybe a good topic for the next Summit?
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> Guang
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> *From:* Ravi Chunduru [mailto:ravi...@gmail.com]
>>> *Sent:* Friday, June 14, 2013 7:32 AM
>>> *To:* OpenStack Development Mailing List
>>> *Subject:* Re: [openstack-dev] Expired tokens in Keystone
>>>
>>> ** **
>>>
>>> I asked this question in different thread but no response.
>>>
>>> ** **
>>>
>>> Why does keystone not re-use the token the one it has already issued for
>>> the same credentials. Any reason for not doing that?
>>>
>>> ** **
>>>
>>> Thanks,
>>>
>>> -Ravi.
>>>
>>> On Wed, Jun 12, 2013 at 11:04 AM, Jay Pipes  wrote:*
>>> ***
>>>
>>> On 06/12/2013 12:54 PM, Craig E. Ward wrote:
>>>
>>> I am working with a Folsom installation of OpenStack. The Keystone
>>> database (mysql) gets very large. The token table has millions of rows
>>> of expired tokens. Is there a reason not to delete these from the table?
>>> 
>>>
>>> ** **
>>>
>>> Not unless you need them for some security auditing purpose... and if
>>> you don't, I recommend switching to the memcache token driver. It's faster
>>> and doesn't have the drawback of filling up your identity database will
>>> millions of token records.
>>>
>>> best,
>>> -jay
>>>
>>>
>>>
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> 
>>>
>>> ** **
>>>
>>> --
>>> Ravi
>>>
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Ravi
>>
>> ___
>> 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
>
>


-- 
Ravi
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

45 matches

Mail list logo