Re: [openstack-dev] [keystone] role of Domain in VPC definition
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 su...@subbu.org 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 hna...@contrailsystems.com 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
Re: [openstack-dev] VPC Proposal
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 hna...@contrailsystems.comwrote: Comments Inline Regards -Harshad On Sat, Feb 15, 2014 at 11:39 PM, Allamaraju, Subbu su...@subbu.orgwrote: 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 hna...@contrailsystems.com 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
[openstack-dev] [keystone] role of Domain in VPC definition
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
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 hen...@linux.vnet.ibm.comwrote: 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 paul.belan...@polybeacon.com 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 ravi...@gmail.com 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
Re: [openstack-dev] [keystone] domain admin role query
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 dolph.math...@gmail.comwrote: On Wed, Dec 18, 2013 at 12:48 PM, Ravi Chunduru ravi...@gmail.com 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 hen...@linux.vnet.ibm.comwrote: 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 paul.belan...@polybeacon.com 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 ravi...@gmail.com 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 -- -Dolph ___ 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
Re: [openstack-dev] [keystone] domain admin role query
Thanks Dolph, It worked now. I specified domain id in the scope. -Ravi. On Wed, Dec 18, 2013 at 12:05 PM, Ravi Chunduru ravi...@gmail.com 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 dolph.math...@gmail.comwrote: On Wed, Dec 18, 2013 at 12:48 PM, Ravi Chunduru ravi...@gmail.comwrote: 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 hen...@linux.vnet.ibm.comwrote: 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 paul.belan...@polybeacon.com 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 ravi...@gmail.com 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 -- -Dolph ___ 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?
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
vishvana...@gmail.comwrote:
On Nov 29, 2013, at 9:24 PM, Chris Friesen chris.frie...@windriver.com
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
Well said. This will encourage new developers. On Wed, Nov 6, 2013 at 11:26 AM, Andrew Woodward xar...@gmail.com 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 stanislaw.pitu...@hp.com 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' ?)
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 jden...@redhat.com 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
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 o...@valinux.co.jp 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 enikano...@mirantis.com 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 o...@valinux.co.jp ___ 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
Count me in as well. On Tue, Oct 22, 2013 at 1:20 PM, Kyle Mestery (kmestery) kmest...@cisco.com 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 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 mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Tenant's info from plugin/services
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 gong...@unitedstack.comwrote: 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 i...@embrane.com 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] What should be Neutron behavior with scoped token?
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 ravi...@gmail.com wrote: Does the described behavior qualify as a bug? Thanks, -Ravi. On Thu, Oct 3, 2013 at 5:21 PM, Ravi Chunduru ravi...@gmail.com 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?
Does the described behavior qualify as a bug? Thanks, -Ravi. On Thu, Oct 3, 2013 at 5:21 PM, Ravi Chunduru ravi...@gmail.com 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
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 berra...@redhat.comwrote: 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
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 bob.b...@citrix.com 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 berra...@redhat.comwrote: 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
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_UScmd=displayKCexternalId=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 rbry...@redhat.com wrote: On 09/30/2013 07:57 AM, Sean Dague wrote: On 09/30/2013 07:51 AM, Daniel P. Berrange wrote: snip 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
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 berra...@redhat.com 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
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 b37...@freescale.comwrote: 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 patnala...@gmail.com *发送时间：*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 hao...@unitedstack.com wrote: On Sep 24, 2013, at 6:40 PM, P Balaji-B37839 b37...@freescale.com 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] [Libvirt] Virtio-Serial support for Nova libvirt driver
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 ravi...@gmail.com 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 b37...@freescale.comwrote: 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 patnala...@gmail.com *发送时间：*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 hao...@unitedstack.com wrote: On Sep 24, 2013, at 6:40 PM, P Balaji-B37839 b37...@freescale.com 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] Virtio-Serial support for Nova libvirt driver
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 b37...@freescale.comwrote: 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
+1 On Fri, Sep 20, 2013 at 10:12 AM, Russell Bryant rbry...@redhat.com 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 blueprints - ensure all blueprints have appropriate design documentation and fit within the
Re: [openstack-dev] [Neutron] Security groups with OVS instead of iptables?
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 dev...@anl.gov 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 lo...@nimbisservices.comwrote: (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
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 endpointhttp://docs.openstack.org/trunk/openstack-ops/content/scaling.htmlfor 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] [Neutron] Configuration of Openflow controller reachability information in OVS from Openstack
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:IP Address of one of your Nicira NVP 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 b22...@freescale.com 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
Re: [openstack-dev] Openstack Service requirement
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 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 -- 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
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 mord...@inaugust.com 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 ravi...@gmail.com 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] Fwd: Blueprint information
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 sorla...@nicira.comwrote: 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 obl...@redhat.com 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
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 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
