Re: [Openstack] Memory leaks from greenthreads
Has there been any thinking around only using eventlet/greenlet for webserver endpoints and using something like multiprocessing for everything else? I was already beginning to think that this would be a good blueprint/discussion topic for the design summit ;-) We've seen a number of issues with the eventlet approach in the computer network manager where a long running activity (such as updating all security groups, creating and uploading a snapshot) will block any other activities. Whilst it's possible to work round the first of these types of issues by planting sleep(0) statements in the loop, snapshot upload is still a problem. Of course making everything thread safe isn't going to be trivial, although there is lock code in place for things like iptables I suspect that there are a whole bunch of other timing / concurrency issues that we'll find once we move to a full threaded model. Phil From: openstack-bounces+philip.day=hp@lists.launchpad.net [mailto:openstack-bounces+philip.day=hp@lists.launchpad.net] On Behalf Of Joshua Harlow Sent: 29 February 2012 21:26 To: Vishvananda Ishaya; openstack Subject: Re: [Openstack] Memory leaks from greenthreads Cool. Just a thought I was having, that others might want to chime in on. Has there been any thinking around only using eventlet/greenlet for webserver endpoints and using something like multiprocessing for everything else? I know its a fundamental change, but it would force people to think about how to break up there code into something that would work with a message passing architecture (this is already happening with nova + rabbitmq). Nova is a good example, but my thought was to go even further and have anything that needs to run for a long time (ie a equivalent of a nova manager) that is shared inside a application also be a separate process with a queue for message passing. Then maybe eventlet/greenlet isn't needed at all? This would force good interfaces, and we wouldn't have to worry about missing a monkey patch. Maybe the python people plan for multiprocess to replace eventlet/greenlet in the end anyway??? Thoughts? On 2/29/12 12:48 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: Hello Everyone, We have had a memory leak due to an interaction with eventlet for a while that Johannes has just made a fix for. bug: https://bugs.launchpad.net/nova/+bug/903199 fix: https://bitbucket.org/which_linden/eventlet/pull-request/10/monkey-patch-threadingcurrent_thread-as Unfortuantely, I don' t think we have a decent workaround for nova while that patch is upstreamed. I wanted to make sure that all of the distros are aware of it in case they want to carry an eventlet patch to prevent the slow memory leak. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Debianizing Documentation
Hi Alexey, It's my understanding that patches are only accepted via Gerrit - http://review.openstack.org/ Gerrit is responsible for managing, among other things, code review and the CLA that is required before signing. https://rackspace.echosign.com/public/hostedForm?formid=3G7VVC397N783J -- CLA that needs signing.. http://wiki.openstack.org/Contributors -- Once you get a confirmation back - Add the number and your launchapd ID here https://launchpad.net/~openstack-cla/+join -- After your ID is listed on the page above, Join this group.. http://wiki.openstack.org/GerritWorkflow -- Finally, submit patches.. I know there is a wiki page somewhere with these links etc - But I couldn't find it faster than the individual links ;) Thanks, Kiall On Thu, Mar 1, 2012 at 4:37 AM, Alexey Eromenko al4...@gmail.com wrote: OK, first version of Debianized nova-docs, for review: [PATCH] Docs: Debianizing The Manuals, v01 https://bugs.launchpad.net/openstack-manuals/+bug/943792 Where are the sources of the Starter Guide ? myuser@nova-server1 :~/openstack-manuals/doc/src/docbkx/openstack-compute-admin$ ls .. api-quick-startopenstack-identity-service-starter common openstack-image-service-admin docbkx-example openstack-install openstack-api-programming openstack-network-connectivity-admin openstack-api-site openstack-object-storage-admin openstack-compute-admin === PATCH: +++ computeinstall.xml 2012-02-29 23:25:44.0 -0500 @@ -127,6 +127,46 @@ clicking the links next to the manual title./para /section /section + +section xml:id=installing-openstack-compute-on-debian +titleInstalling OpenStack Compute on Debian/title +paraStarting with Debian 7.0 Wheezy, the OpenStack packages are +provided as part of the distribution./para +para + For the management node install the following packages: (via apt-get install) +literallayout class=monospaced +nova-api +nova-scheduler +glance +keystone +mysql-server +rabbitmq +memcached +openstack-dashboard +/literallayout +/para +para + For the compute node(s) install the following packages: +literallayout class=monospaced +nova-compute +nova-network +nova-api +/literallayout +/para + note +para + Because this manual takes active advantage of the sudo command, + it would be easier for you to add to it your Debian system, by doing: + literallayout class=monospaced +# usermod -a -G sudo myuser + /literallayout + then re-login. + Otherwise you will have to replace every sudo call by executing from + root account. + /para +/note +/section + section xml:id=installing-openstack-compute-on-rhel6 titleInstalling OpenStack Compute on Red Hat Enterprise Linux 6 /title paraThis section documents a multi-node installation using RHEL 6. RPM repos for the Bexar -- -Alexey Eromenko Technologov ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Running for Nova PTL
2012/2/28 Vishvananda Ishaya vishvana...@gmail.com: There is always progress to be made, but while we are toiling away working on testing, technical debt, and code smell, we have to keep our users in mind. This part of your e-mail really sticks out, along with this one: I disagree with this point. There was a huge amount of effort from a lot of parties on getting things cleaned up during essex. Most of the features that were worked on were getting things aligned and consistent behind our api. We have to make sure that Nova is usable as well as stable. It is tempting to think of things from the developer/code perspective, but we have to put on our user/operator hats as well. I'm trying hard to work out what you're implying here.. Are you suggesting that my suggested policy of not adding features, but focusing almost exclusively on stability isn't for the best of our users? Who do you think (I think) I'm favouring when I propose something like that? -- Soren Hansen | http://linux2go.dk/ Senior Software Engineer | http://www.cisco.com/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Debianizing Documentation
Yes, patches are accepted only through Gerrit. I've written up a First time contributors section here: http://wiki.openstack.org/Documentation/HowTo#First-time_Contributors The Starter Guide is housed in Launchpad at: https://launchpad.net/openstackbook It is reviewed and merged through Launchpad merge requests by the CSS OSS Team. It is also licensed differently from the other manuals and it ships with Ubuntu server so it only documents Ubuntu. Please edit http://docs.openstack.org/diablo/openstack-compute/install/content/ by adding Debian sections rather than editing the Starter Guide. Definitely want to expand the Install Guide to include Debian. Thanks, Anne On Thu, Mar 1, 2012 at 4:53 AM, Kiall Mac Innes ki...@managedit.ie wrote: Hi Alexey, It's my understanding that patches are only accepted via Gerrit - http://review.openstack.org/ Gerrit is responsible for managing, among other things, code review and the CLA that is required before signing. https://rackspace.echosign.com/public/hostedForm?formid=3G7VVC397N783J -- CLA that needs signing.. http://wiki.openstack.org/Contributors -- Once you get a confirmation back - Add the number and your launchapd ID here https://launchpad.net/~openstack-cla/+join -- After your ID is listed on the page above, Join this group.. http://wiki.openstack.org/GerritWorkflow -- Finally, submit patches.. I know there is a wiki page somewhere with these links etc - But I couldn't find it faster than the individual links ;) Thanks, Kiall On Thu, Mar 1, 2012 at 4:37 AM, Alexey Eromenko al4...@gmail.com wrote: OK, first version of Debianized nova-docs, for review: [PATCH] Docs: Debianizing The Manuals, v01 https://bugs.launchpad.net/openstack-manuals/+bug/943792 Where are the sources of the Starter Guide ? myuser@nova-server1:~/openstack-manuals/doc/src/docbkx/openstack-compute-admin$ ls .. api-quick-start openstack-identity-service-starter common openstack-image-service-admin docbkx-example openstack-install openstack-api-programming openstack-network-connectivity-admin openstack-api-site openstack-object-storage-admin openstack-compute-admin === PATCH: +++ computeinstall.xml 2012-02-29 23:25:44.0 -0500 @@ -127,6 +127,46 @@ clicking the links next to the manual title./para /section /section + + section xml:id=installing-openstack-compute-on-debian + titleInstalling OpenStack Compute on Debian/title + paraStarting with Debian 7.0 Wheezy, the OpenStack packages are + provided as part of the distribution./para + para + For the management node install the following packages: (via apt-get install) + literallayout class=monospaced +nova-api +nova-scheduler +glance +keystone +mysql-server +rabbitmq +memcached +openstack-dashboard + /literallayout + /para + para + For the compute node(s) install the following packages: + literallayout class=monospaced +nova-compute +nova-network +nova-api + /literallayout + /para + note + para + Because this manual takes active advantage of the sudo command, + it would be easier for you to add to it your Debian system, by doing: + literallayout class=monospaced +# usermod -a -G sudo myuser + /literallayout + then re-login. + Otherwise you will have to replace every sudo call by executing from + root account. + /para + /note + /section + section xml:id=installing-openstack-compute-on-rhel6 titleInstalling OpenStack Compute on Red Hat Enterprise Linux 6 /title paraThis section documents a multi-node installation using RHEL 6. RPM repos for the Bexar -- -Alexey Eromenko Technologov ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Netstack] Can't associate floating IP
Hi Doude,
I was dealing with another issue caused by this NULL 'host', and Dan told
me that has been fixed:
https://github.com/openstack/nova/commit/43f2492175d11a3f8ea4198e65b2a6a6b38cbbb6
I haven't verified, though. Good luck.
Best,
Tomoe
On Thu, Mar 1, 2012 at 10:11 PM, Doude doudou...@gmail.com wrote:
Hi,
I tested it with Quantum and I confirm the field 'host' in the 'network'
table stays empty.
Someone filled a bug for that ?
Doude.
On Tue, Feb 28, 2012 at 8:06 AM, Vishvananda Ishaya vishvana...@gmail.com
wrote:
...
At least that is the case for nova-network without quantum. I don't know
if using Quantum leads to a different result.
Vish
On Feb 27, 2012, at 9:49 PM, Yapeng Wu wrote:
Hello, Brad,
I read your reply to Darragph's email:
Another thing to check .. when I run devstack by default my network
doesn't get associated with a host [host is NULL in the database].
Make sure the host for that network is set to the hostname of the
compute node.
I found that when I use nova-manage network create CLI command, the
host is NULL in the database as well.
Is this a bug? Where would this host field get updated?
Thanks,
Yapeng
On Feb 27, 2012, at 04:02 PM, Yapeng Wu yapen...@me.com wrote:
Hello, Darragh,
I...
2) For the second problem: command line issue, I found that it was due to
the code in nova/network/manager.py, line 435 to 452:
if network['multi_host']:
instance = self.db.instance_get(context, fixed_ip['instance_id'])
host = instance['host']
else:
host = network['host']
interface = floating_ip['interface']
if host == self.host:
# i'm the correct host
self._associate_floating_ip(context, floating_address,
fixed_address, interface)
else:
# send to correct host
rpc.cast(context,
self.db.queue_get_for(context, FLAGS.network_topic,
host),
{'method': '_associate_floating_ip',
'args': {'floating_address': floating_address,
'fixed_address': fixed_address,
'interface': interface}})
The host should be self.host in this case, but not. So it calls
rpc.cast. I thought host is read from the database by the 'instance_id'? I
am not sure. If I hacked the code by calling self._associate_floating_ip
directly, associate floating ip works.
Maybe someone familiar with nova-network code could help us on this.
Yapeng
On Feb 27, 2012, at 12:18 PM, Dan Wendlandt d...@nicira.com wrote:
Hi Darragh,
Thanks for the detailed write-up. Would be great if you could take this
content and create a bug on launchpad. We'll look into this.
On a related note. The check in stack.sh to avoid creating a floating IP
pool if quantum is enabled is no longer valid, now that Quantum Manager
does (or at least intends to :P ) support floating IPs. But rather than
remove it, it may be good to just change to the check to avoid creating
floating IPs if melange is enabled, as Quantum Manager's current floating
IP support requires using the traditional Nova IPAM, not Melange.
Dan
On Mon, Feb 27, 2012 at 6:38 AM, Darragh OReilly
darragh.orei...@yahoo.com wrote:
When I try to associate a floating IP from the dash I get:
Error: Error associating Floating IP: Associate floating ip failed (HTTP
500)
From the command line I don't get any errors or exceptions on any of
the screens after nova add-floating-ip, but the association does not
happen. Are these steps right?
thanks Darragh
u1@u1110srv:~/devstack$ cat localrc
LOGFILE=stacklog
MYSQL_PASSWORD=nova
RABBIT_PASSWORD=nova
SERVICE_TOKEN=nova
ADMIN_PASSWORD=nova
SWIFT_HASH=nova
ENABLED_SERVICES=g-api,g-reg,key,n-api,n-cpu,n-net,n-sch,n-vnc,horizon,mysql,rabbit,openstackx,n-vol,q-svc,q-agt,swift,quantum
Q_PLUGIN=openvswitch
After running stack.sh have:
u1@u1110srv:~/devstack$ nova-manage network list
id IPv4 IPv6 start address
DNS1 DNS2 VlanID project
uuid
2012-02-27 13:38:04 DEBUG nova.utils
[req-7b6febc7-c8cd-49e5-ac48-5707c70d8bb5 None None] backend module
'nova.db.sqlalchemy.api' from '/opt/stack/nova/nova/db/sqlalchemy/api.pyc'
from (pid=4776) __get_backend /opt/stack/nova/nova/utils.py:603
110.0.0.0/24 None 10.0.0.2
8.8.4.4None None None
20cda3a7-f4a8-4b3c-b399-4dd624cb7a40
u1@u1110srv:~/devstack$ TENANT=
u1@u1110srv:~/devstack$ USERNAME=
u1@u1110srv:~/devstack$ . openrc
u1@u1110srv:~/devstack$
u1@u1110srv:~/devstack$ nova boot --flavor 6 --image
21b0573e-8dd6-4b42-9c01-4c8684b0b080 guest1
u1@u1110srv:~/devstack$ nova show guest1
+---+--+
|
[Openstack] Who is eligible for vote ?
Hi, I'd like to ask: Who is eligible for vote ? I have submitted half-a-dozen patches to openstack-manuals (on launchpad), and I wanted to ask if I'm eligible ? -- -Alexey Eromenko Technologov ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Who is eligible for vote ?
Alexey, This depends on which election you're talking about (the PPB elections or the individual project PTL elections). The attached email from Stefano a couple of weeks ago should answer your questions. In a nutshell, if you are a member of the OpenStack group on Launchpad you're eligible to vote in the PPB elections. If you've submitted code to a project and had it accepted, you're eligible to vote for the PTL of the project. But in either case if you didn't register to vote before the elections started you won't be able to vote in the spring elections regardless of your eligibility. At Your Service, Mark T. Voelker Systems Development Unit Cisco Systems On 03/01/2012 09:30 AM, Alexey Eromenko wrote: Hi, I'd like to ask: Who is eligible for vote ? I have submitted half-a-dozen patches to openstack-manuals (on launchpad), and I wanted to ask if I'm eligible ? ---BeginMessage--- The time is once again upon us for our OpenStack Governance Elections. The OpenStack community is called to elect the Project Technical Leads and two seats of the Project Policy Board. The election committee is made of Stefano Maffulli, Lloyd Dewolf and Dave Nielsen. * February 16 – 26 11:59 PST: Nominations open. * February 28 – March 3 11:59 PST: Online voting open. * March 3 11:59 PST: Voting closed. Final results will be posted immediately upon election close. What seats are up for election * NOVA Project Team Lead (1 Position) * SWIFT Project Team Lead (1 Position) * GLANCE Project Team Lead (1 Position) * HORIZON Project Team Lead (1 Position) * KEYSTONE Project Team Lead (1 Position) * Project Policy Board (2 Open Positions) How to nominate yourself or others as Project Technical Lead Only OpenStack community members who have code in the respective OpenStack subproject are eligible to be elected as that subproject’s Project Team Lead. Please nominate someone from the developer community or yourself at http://etherpad.openstack.org/Spring2012-Nominees under the Nominees heading. Please provide the name and email address of the nominee. The election committee will then confirm with the nominee that they are willing to run for the position.The list of Approved Candidates will be announced with a new blog post on openstack.org/blog when online voting opens (Feb 28). How to nominate yourself or others as member of the Project Policy Board Any registered member of the OpenStack Launchpad group is eligible to run or be nominated for a position on the Project Policy Board. If you want to vote and/or run for a seat you need to register on Launchpad and add yourself to the public OpenStack group on https://launchpad.net/~openstack. Please nominate someone from the community or yourself at http://etherpad.openstack.org/Spring2012-Nominees under the Nominees heading. Please give the name and email address of the nominee. The election committee will then confirm with the nominee that they are willing to run for the position. The list of Approved Candidates will be announced with a new blog post on openstack.org/blog right before the election starts.How to register to vote for PTL Only OpenStack community members who have code in the respective OpenStack subproject are eligible to vote for that subproject’s Project Team Lead. The authoritative list of eligible voters and nominees is the Authors file in each repository. For example, the list of Nova authors is https://github.com/openstack/nova/blob/master/Authors. Make sure your name and correct email address is there or you won’t be able to vote. How to register to vote for Project Policy Board Any registered member of the OpenStack Launchpad group is eligible to vote for the Project Policy Board. If you want to vote you need to register to Launchpad and add yourself to the public OpenStack group on https://launchpad.net/~openstack before registering as a voter using the form at http://ppbelectionsregistration.openstack.org/. Company affiliation is only collected as an interesting statistic; it has no effect on the outcome of the election. Voting process Like previous OpenStack Governance Elections, we will use the Condorcet Internet Voting Service from Cornell University, http://www.cs.cornell.edu/andru/civs.html. This tool uses the Condorcet method of voting which invokes ranking the nominees instead of just selecting one choice. More information on this methodology is at http://www.cs.cornell.edu/w8/~andru/civs/rp.html. All registered voters will receive an email with a unique link allowing them to privately vote. Please note that the voting system is run using private polls with restricted access to ensure voter authenticity; however all results will be made public once the election ends. Voter anonymity is guaranteed. The result’s ranking will be evaluated using Schulze (also known as Beatpath or CSSD) completion rule. Thanks for participating in this essential process. Please remind your
[Openstack] Essex OpenStack Global Hack-In
LLoyd and others, The blog post announcement for this event [1] mentions working on resolving high priority bugs -- I'm assuming that the following list is what identifies them? (I have filtered on essex-4 and rc1) http://goo.gl/Qe17g That includes In Progress ones. This one excludes those, so should offer a list of unclaimed high-priority bugs? http://goo.gl/hMHzb I included essex-4 since I'm not sure if unfinished, unclaimed essex-4 bugs have been moved over to rc1 yet... Is there any other page, document, etc., that tracks what folks should be specifically focusing on today? Thanks so much! d [1] http://www.openstack.org/blog/2012/02/essex-openstack-global-hack-in/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Who is eligible for vote ?
Sure -"How to register to vote for Project Policy BoardAny registered member of the OpenStack Launchpad group is eligible to vote for the Project Policy Board. If you want to vote you need to register to Launchpad and add yourself to the public OpenStack group onhttps://launchpad.net/~openstackbefore registering as a voter using the form athttp://ppbelectionsregistration.openstack.org/. Company affiliation is only collected as an interesting statistic; it has no effect on the outcome of the election.Voting processLike previous OpenStack Governance Elections, we will use the Condorcet Internet Voting Service from Cornell University,http://www.cs.cornell.edu/andru/civs.html. This tool uses the Condorcet method of voting which invokes ranking the nominees instead of just selecting one choice. More information on this methodology is athttp://www.cs.cornell.edu/w8/~andru/civs/rp.html.":) Nuage Co - Razique Mahrouarazique.mahr...@gmail.com Le 1 mars 2012 à 15:33, Alexey Eromenko a écrit :On Thu, Mar 1, 2012 at 4:32 PM, Razique Mahrouarazique.mahr...@gmail.com wrote:Hi :)You mean, to vote, or to be elected ?vote.---Alexey Eromenko "Technologov"___Mailing list: https://launchpad.net/~openstackPost to : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore help : https://help.launchpad.net/ListHelp___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Who is eligible for vote ?
Alexey Eromenko wrote: I'd like to ask: Who is eligible for vote ? I have submitted half-a-dozen patches to openstack-manuals (on launchpad), and I wanted to ask if I'm eligible ? The process was explained by the election officials there: http://www.openstack.org/blog/2012/02/openstack-governance-elections-spring-2012/ To vote for Nova/Glance/Swift/Keystone/Horizon PTL you had to be one of those projects' authors, and to vote on PPB you had to register on a specific website. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Who is eligible for vote ?
Hi Alexey - To be eligible to vote you must follow the OpenStack election guidelines. [1] Your timing and the method you named are not enough to qualify you for this voting season. These are the guidelines for voting for members of the Project Policy Board, or PPB. Any registered member of the OpenStack Launchpad group is eligible to vote for the Project Policy Board. If you want to vote you need to register to Launchpad and add yourself to the public OpenStack group on https://launchpad.net/~openstack before registering as a voter using the form at http://ppbelectionsregistration.openstack.org/. To vote for Project Technical Leads, PTLs, you must be listed in the Authors file for the particular project. The openstack-manuals project does not have a PTL. Hope this helps, Anne [1] http://www.mail-archive.com/openstack@lists.launchpad.net/msg07483.html On Thu, Mar 1, 2012 at 8:33 AM, Alexey Eromenko al4...@gmail.com wrote: On Thu, Mar 1, 2012 at 4:32 PM, Razique Mahroua razique.mahr...@gmail.com wrote: Hi :) You mean, to vote, or to be elected ? vote. -- -Alexey Eromenko Technologov ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Essex-4 milestone proposed candidates
This is a great milestone and I was wondering about upgrade. At the last design summit there was a discussion about how hard/easy it would be to upgrade to Essex. What is the final answer? Are their (going to be) instructions on how to upgrade an operating diablo cluster to essex? And is the answer different if the diablo cluster is not using keystone? -David On 2/29/2012 6:15 AM, Thierry Carrez wrote: Hi everyone, Milestone-proposed branches were just created for Keystone, Glance, Nova and Horizon in preparation for the essex-4 milestone delivery on Thursday. Please test proposed deliveries to ensure no critical regression found its way in. Milestone-critical fixes will be backported to the milestone-proposed branch until final delivery of the milestone, and will be tracked using the essex-4 milestone targeting. Links: for PROJ in ['keystone', 'nova', 'glance', 'horizon']: Milestone-critical bugs: https://launchpad.net/PROJ/+milestone/essex-4 Branch at: https://github.com/openstack/PROJ/tree/milestone-proposed Proposed tarballs at: http://PROJ.openstack.org/tarballs/ (Look for the most recent PROJ-2012.1~e4*.tar.gz build) You can also test the glance, nova and python-novaclient candidates on Ubuntu by enabling the new common ppa:~openstack-ppa/milestone-proposed The current plan is to deliver Essex-4 Thursday morning, US time. The development focus now switched completely from feature development to preparation of final release candidates. Release-blocking bugs will be listed on https://launchpad.net/PROJ/+milestone/essex-rc1. Once we get a valid release candidate, Folsom development will be open. Cheers, ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] A brief update on the invites to the Design Summit
On Fri, 2012-02-24 at 09:45 -0800, Stefano Maffulli wrote: On March 1st access to the summit will be open to anybody interested on a first come first served basis. I'm confident we'll be able to accommodate the demand. As promised: anyone can now register for the OpenStack Spring 2012 'Folsom' conference for $500 *and* sign up to participate to the Design Summit as an option. If you are not interested in the conference, you can register for the Design Summit only for free. http://www.openstack.org/conference/san-francisco-2012/register/ If you already registered to the conference before today, you can amend your registration. If you have received an invite code REGISTER IMMEDIATELY because starting now we cannot guarantee you a place at the summit. See you in San Francisco Stef PS If you can't make it to San Francisco, worry not. We're still working on setting up live streaming from all the rooms at the Design Summit. Stay tuned for more. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Essex-4 milestone proposed candidates
For keystone, we are writing migration docs from Diablo - both with and without keystone configurations. We've implemented export and import mechanisms to bring in data to the new keystone instance, so it's mostly a matter of just explaining how to use it. -joe On Mar 1, 2012, at 7:34 AM, David Kranz wrote: This is a great milestone and I was wondering about upgrade. At the last design summit there was a discussion about how hard/easy it would be to upgrade to Essex. What is the final answer? Are their (going to be) instructions on how to upgrade an operating diablo cluster to essex? And is the answer different if the diablo cluster is not using keystone? -David On 2/29/2012 6:15 AM, Thierry Carrez wrote: Hi everyone, Milestone-proposed branches were just created for Keystone, Glance, Nova and Horizon in preparation for the essex-4 milestone delivery on Thursday. Please test proposed deliveries to ensure no critical regression found its way in. Milestone-critical fixes will be backported to the milestone-proposed branch until final delivery of the milestone, and will be tracked using the essex-4 milestone targeting. Links: for PROJ in ['keystone', 'nova', 'glance', 'horizon']: Milestone-critical bugs: https://launchpad.net/PROJ/+milestone/essex-4 Branch at: https://github.com/openstack/PROJ/tree/milestone-proposed Proposed tarballs at: http://PROJ.openstack.org/tarballs/ (Look for the most recent PROJ-2012.1~e4*.tar.gz build) You can also test the glance, nova and python-novaclient candidates on Ubuntu by enabling the new common ppa:~openstack-ppa/milestone-proposed The current plan is to deliver Essex-4 Thursday morning, US time. The development focus now switched completely from feature development to preparation of final release candidates. Release-blocking bugs will be listed on https://launchpad.net/PROJ/+milestone/essex-rc1. Once we get a valid release candidate, Folsom development will be open. Cheers, ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] A brief update on the invites to the Design Summit
Has anyone else had trouble registering for the Design Summit for Free? We have not been able to 'register for the Design Summit only for free.' Any one been able to without paying the $500 for the conference? -BillF On 3/1/12 8:39 AM, Stefano Maffulli wrote: On Fri, 2012-02-24 at 09:45 -0800, Stefano Maffulli wrote: On March 1st access to the summit will be open to anybody interested on a first come first served basis. I'm confident we'll be able to accommodate the demand. As promised: anyone can now register for the OpenStack Spring 2012 'Folsom' conference for $500 *and* sign up to participate to the Design Summit as an option. If you are not interested in the conference, you can register for the Design Summit only for free. http://www.openstack.org/conference/san-francisco-2012/register/ If you already registered to the conference before today, you can amend your registration. If you have received an invite code REGISTER IMMEDIATELY because starting now we cannot guarantee you a place at the summit. See you in San Francisco Stef PS If you can't make it to San Francisco, worry not. We're still working on setting up live streaming from all the rooms at the Design Summit. Stay tuned for more. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Fail to reboot VM with Nova + Quantum/OVS
When I try reboot a VM, the nova-compute fails and the daemon stop. It fails on unpluging VIF interface of the rebooted VM. I use Nova with Quantum and OVS. 2012-03-01 18:12:31 DEBUG nova.rpc.common [-] Making asynchronous call on network ... from (pid=21485) multicall /usr/local/src/nova/nova/rpc/amqp.py:318 2012-03-01 18:12:31 DEBUG nova.rpc.common [-] MSG_ID is b77f0f284af045f396b90fddd16f724e from (pid=21485) multicall /usr/local/src/nova/nova/rpc/amqp.py:321 2012-03-01 18:12:33 DEBUG nova.utils [-] Running cmd (subprocess): sudo nova-rootwrap ovs-vsctl del-port br-int tap9f5ef54c-38 from (pid=21485) execute /usr/local/src/nova/nova/utils.py:208 2012-03-01 18:12:33 DEBUG nova.utils [-] Running cmd (subprocess): sudo nova-rootwrap ip link delete tap9f5ef54c-38 from (pid=21485) execute /usr/local/src/nova/nova/utils.py:208 2012-03-01 18:12:34 DEBUG nova.utils [-] Running cmd (subprocess): sudo nova-rootwrap ovs-vsctl del-port br-int tap285c8465-dd from (pid=21485) execute /usr/local/src/nova/nova/utils.py:208 2012-03-01 18:12:34 DEBUG nova.utils [-] Running cmd (subprocess): sudo nova-rootwrap ip link delete tap285c8465-dd from (pid=21485) execute /usr/local/src/nova/nova/utils.py:208 2012-03-01 18:12:34 DEBUG nova.utils [-] Attempting to grab semaphore iptables for method apply... from (pid=21485) inner /usr/local/src/nova/nova/utils.py:824 2012-03-01 18:12:34 DEBUG nova.utils [-] Got semaphore iptables for method apply... from (pid=21485) inner /usr/local/src/nova/nova/utils.py:828 2012-03-01 18:12:34 DEBUG nova.utils [-] Attempting to grab file lock iptables for method apply... from (pid=21485) inner /usr/local/src/nova/nova/utils.py:832 2012-03-01 18:12:34 DEBUG nova.utils [-] Got file lock iptables for method apply... from (pid=21485) inner /usr/local/src/nova/nova/utils.py:839 2012-03-01 18:12:34 DEBUG nova.utils [-] Running cmd (subprocess): sudo nova-rootwrap iptables-save -t filter from (pid=21485) execute /usr/local/src/nova/nova/utils.py:208 2012-03-01 18:12:35 INFO nova.virt.libvirt.connection [-] [instance: 9300df8d-1a47-40ce-b90e-28f1a84f064d] Instance destroyed successfully. 2012-03-01 18:12:35 DEBUG nova.utils [-] Running cmd (subprocess): sudo nova-rootwrap iptables-restore from (pid=21485) execute /usr/local/src/nova/nova/utils.py:208 2012-03-01 18:12:35 DEBUG nova.utils [-] Running cmd (subprocess): sudo nova-rootwrap iptables-save -t nat from (pid=21485) execute /usr/local/src/nova/nova/utils.py:208 2012-03-01 18:12:35 DEBUG nova.utils [-] Running cmd (subprocess): sudo nova-rootwrap iptables-restore from (pid=21485) execute /usr/local/src/nova/nova/utils.py:208 2012-03-01 18:12:35 DEBUG nova.network.linux_net [-] IPTablesManager.apply completed with success from (pid=21485) apply /usr/local/src/nova/nova/network/linux_net.py:336 2012-03-01 18:12:37 DEBUG nova.utils [-] Running cmd (subprocess): sudo nova-rootwrap ovs-vsctl del-port br-int tap9f5ef54c-38 from (pid=21485) execute /usr/local/src/nova/nova/utils.py:208 2012-03-01 18:12:37 DEBUG nova.utils [-] Result was 1 from (pid=21485) execute /usr/local/src/nova/nova/utils.py:224 2012-03-01 18:12:37 WARNING nova.virt.libvirt.vif [-] Failed while unplugging vif of instance 'instance-0002' Do you have this problem ? Regards, Doude. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New OpenStack Meetup Group: Atlanta
Stef, et al, I never announced the OpenStack Colorado group on the list. We're already listed in the Global Hack In (and were underway today :^) I'll subscribe to the Int'l User Groups. -dave http://meetup.com/OpenStack-Colorado/ On Wed, 2012-02-29 at 10:51 -0800, Stefano Maffulli wrote: On Tue, 2012-02-28 at 19:29 -0500, Duncan McGreggor wrote: DreamHost is starting up a new office on the East Coast of the US in Atlanta... and one of the first things we did was create an Atlanta OpenStack meetup group: http://www.meetup.com/openstack-atlanta/ Congratulations for both news :) make sure that the coordinator of that group (you) joins the OpenStack International User Groups Community” team on https://launchpad.net/~openstack-community (and subscribes to the mailing list) and ... I already see that Atlanta is listed on http://wiki.openstack.org/OpenStackUsersGroup#Atlanta Perfect. Happy hacking, stef ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] New OpenStack Meetup Group: Atlanta
Woo! /me high-fives the Colorado team! d On Thu, Mar 1, 2012 at 12:23 PM, David Medberry david.medbe...@canonical.com wrote: Stef, et al, I never announced the OpenStack Colorado group on the list. We're already listed in the Global Hack In (and were underway today :^) I'll subscribe to the Int'l User Groups. -dave http://meetup.com/OpenStack-Colorado/ On Wed, 2012-02-29 at 10:51 -0800, Stefano Maffulli wrote: On Tue, 2012-02-28 at 19:29 -0500, Duncan McGreggor wrote: DreamHost is starting up a new office on the East Coast of the US in Atlanta... and one of the first things we did was create an Atlanta OpenStack meetup group: http://www.meetup.com/openstack-atlanta/ Congratulations for both news :) make sure that the coordinator of that group (you) joins the OpenStack International User Groups Community” team on https://launchpad.net/~openstack-community (and subscribes to the mailing list) and ... I already see that Atlanta is listed on http://wiki.openstack.org/OpenStackUsersGroup#Atlanta Perfect. Happy hacking, stef ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Fail to reboot VM with Nova + Quantum/OVS
Hi Doude, At a glance, it seems that unplug() being called twice, with the second call failing because the first call successfully unplugged the vif already. The unplug() action on the bridge does nothing, so there's no harm in calling it twice, which may explain why this is only seen with OVS. A quick workaround would be to remove the raise line at the end of the unplug() method for LibvirtOpenVswitchDriver, in which case you will see the log message still, but it should not disrupt the reboot (this is probably better behavior as well, regardless of the true cause of the bug). We'll look into this. I created this bug to track discussion on the fix: https://bugs.launchpad.net/nova/+bug/944168 Dan On Thu, Mar 1, 2012 at 9:18 AM, Doude doudou...@gmail.com wrote: When I try reboot a VM, the nova-compute fails and the daemon stop. It fails on unpluging VIF interface of the rebooted VM. I use Nova with Quantum and OVS. 2012-03-01 18:12:31 DEBUG nova.rpc.common [-] Making asynchronous call on network ... from (pid=21485) multicall /usr/local/src/nova/nova/rpc/amqp.py:318 2012-03-01 18:12:31 DEBUG nova.rpc.common [-] MSG_ID is b77f0f284af045f396b90fddd16f724e from (pid=21485) multicall /usr/local/src/nova/nova/rpc/amqp.py:321 2012-03-01 18:12:33 DEBUG nova.utils [-] Running cmd (subprocess): sudo nova-rootwrap ovs-vsctl del-port br-int tap9f5ef54c-38 from (pid=21485) execute /usr/local/src/nova/nova/utils.py:208 2012-03-01 18:12:33 DEBUG nova.utils [-] Running cmd (subprocess): sudo nova-rootwrap ip link delete tap9f5ef54c-38 from (pid=21485) execute /usr/local/src/nova/nova/utils.py:208 2012-03-01 18:12:34 DEBUG nova.utils [-] Running cmd (subprocess): sudo nova-rootwrap ovs-vsctl del-port br-int tap285c8465-dd from (pid=21485) execute /usr/local/src/nova/nova/utils.py:208 2012-03-01 18:12:34 DEBUG nova.utils [-] Running cmd (subprocess): sudo nova-rootwrap ip link delete tap285c8465-dd from (pid=21485) execute /usr/local/src/nova/nova/utils.py:208 2012-03-01 18:12:34 DEBUG nova.utils [-] Attempting to grab semaphore iptables for method apply... from (pid=21485) inner /usr/local/src/nova/nova/utils.py:824 2012-03-01 18:12:34 DEBUG nova.utils [-] Got semaphore iptables for method apply... from (pid=21485) inner /usr/local/src/nova/nova/utils.py:828 2012-03-01 18:12:34 DEBUG nova.utils [-] Attempting to grab file lock iptables for method apply... from (pid=21485) inner /usr/local/src/nova/nova/utils.py:832 2012-03-01 18:12:34 DEBUG nova.utils [-] Got file lock iptables for method apply... from (pid=21485) inner /usr/local/src/nova/nova/utils.py:839 2012-03-01 18:12:34 DEBUG nova.utils [-] Running cmd (subprocess): sudo nova-rootwrap iptables-save -t filter from (pid=21485) execute /usr/local/src/nova/nova/utils.py:208 2012-03-01 18:12:35 INFO nova.virt.libvirt.connection [-] [instance: 9300df8d-1a47-40ce-b90e-28f1a84f064d] Instance destroyed successfully. 2012-03-01 18:12:35 DEBUG nova.utils [-] Running cmd (subprocess): sudo nova-rootwrap iptables-restore from (pid=21485) execute /usr/local/src/nova/nova/utils.py:208 2012-03-01 18:12:35 DEBUG nova.utils [-] Running cmd (subprocess): sudo nova-rootwrap iptables-save -t nat from (pid=21485) execute /usr/local/src/nova/nova/utils.py:208 2012-03-01 18:12:35 DEBUG nova.utils [-] Running cmd (subprocess): sudo nova-rootwrap iptables-restore from (pid=21485) execute /usr/local/src/nova/nova/utils.py:208 2012-03-01 18:12:35 DEBUG nova.network.linux_net [-] IPTablesManager.apply completed with success from (pid=21485) apply /usr/local/src/nova/nova/network/linux_net.py:336 2012-03-01 18:12:37 DEBUG nova.utils [-] Running cmd (subprocess): sudo nova-rootwrap ovs-vsctl del-port br-int tap9f5ef54c-38 from (pid=21485) execute /usr/local/src/nova/nova/utils.py:208 2012-03-01 18:12:37 DEBUG nova.utils [-] Result was 1 from (pid=21485) execute /usr/local/src/nova/nova/utils.py:224 2012-03-01 18:12:37 WARNING nova.virt.libvirt.vif [-] Failed while unplugging vif of instance 'instance-0002' Do you have this problem ? Regards, Doude. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] A brief update on the invites to the Design Summit
yeah likewise. On Thu, Mar 1, 2012 at 11:14 AM, William L. Franklin w...@cloudscaling.comwrote: Has anyone else had trouble registering for the Design Summit for Free? We have not been able to 'register for the Design Summit only for free.' Any one been able to without paying the $500 for the conference? -BillF On 3/1/12 8:39 AM, Stefano Maffulli wrote: On Fri, 2012-02-24 at 09:45 -0800, Stefano Maffulli wrote: On March 1st access to the summit will be open to anybody interested on a first come first served basis. I'm confident we'll be able to accommodate the demand. As promised: anyone can now register for the OpenStack Spring 2012 'Folsom' conference for $500 *and* sign up to participate to the Design Summit as an option. If you are not interested in the conference, you can register for the Design Summit only for free. http://www.openstack.org/**conference/san-francisco-2012/**register/http://www.openstack.org/conference/san-francisco-2012/register/ If you already registered to the conference before today, you can amend your registration. If you have received an invite code REGISTER IMMEDIATELY because starting now we cannot guarantee you a place at the summit. See you in San Francisco Stef PS If you can't make it to San Francisco, worry not. We're still working on setting up live streaming from all the rooms at the Design Summit. Stay tuned for more. __**_ Mailing list: https://launchpad.net/~**openstackhttps://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~**openstackhttps://launchpad.net/~openstack More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp __**_ Mailing list: https://launchpad.net/~**openstackhttps://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~**openstackhttps://launchpad.net/~openstack More help : https://help.launchpad.net/**ListHelphttps://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Essex OpenStack Global Hack-In
I don't know if there is a specific list yet. I just noticed a few new bugs reported by rajalakshmi ganesan that probably could be looked into. https://bugs.launchpad.net/~rajalakshmi-ganesan/+bugs (specifically the nova ones) On Mar 1, 2012, at 6:51 AM, Duncan McGreggor wrote: LLoyd and others, The blog post announcement for this event [1] mentions working on resolving high priority bugs -- I'm assuming that the following list is what identifies them? (I have filtered on essex-4 and rc1) http://goo.gl/Qe17g That includes In Progress ones. This one excludes those, so should offer a list of unclaimed high-priority bugs? http://goo.gl/hMHzb I included essex-4 since I'm not sure if unfinished, unclaimed essex-4 bugs have been moved over to rc1 yet... Is there any other page, document, etc., that tracks what folks should be specifically focusing on today? Thanks so much! d [1] http://www.openstack.org/blog/2012/02/essex-openstack-global-hack-in/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Running for Nova PTL
On Mar 1, 2012, at 5:21 AM, Soren Hansen wrote: 2012/2/28 Vishvananda Ishaya vishvana...@gmail.com: There is always progress to be made, but while we are toiling away working on testing, technical debt, and code smell, we have to keep our users in mind. This part of your e-mail really sticks out, along with this one: I disagree with this point. There was a huge amount of effort from a lot of parties on getting things cleaned up during essex. Most of the features that were worked on were getting things aligned and consistent behind our api. We have to make sure that Nova is usable as well as stable. It is tempting to think of things from the developer/code perspective, but we have to put on our user/operator hats as well. I'm trying hard to work out what you're implying here.. Are you suggesting that my suggested policy of not adding features, but focusing almost exclusively on stability isn't for the best of our users? Who do you think (I think) I'm favouring when I propose something like that? It is great for some of our users. I'm sure stability is high on everyone's list, but i think a number of the people building businesses around openstack would be upset that insert_feature_here won't be available for two releases. When I deal with customers during our deploys, they aren't complaining about stability, they are asking when feature x will be available. My notes in the email were just a reminder that we need to keep everyone in mind. Packagers, deployers, developers and end-users all have different priorities. We have a huge community and we need to have a measured approach. We just finished a month long soft feature freeze and are starting a month long hard freeze, so I'm not convinced that an even more extreme freeze is the right strategy. I think the idea of maturing features in focused branches and bugfixing in trunk is very interesting however, and has the potential to allow the stability we want without sacrificing feature development. My only concern with this model is how we deal with smallish features that aren't clearly associated with a particular focused branch. Do we have a separate 'small-features' branch where things can mature? Vish -- Soren Hansen | http://linux2go.dk/ Senior Software Engineer | http://www.cisco.com/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Keystone should to Apache HTTPD.
I wrote up why I think that, at least for Keystone, we should move the front end over to Apache HTTPD. http://adam.younglogic.com/2012/03/keystone-should-move-to-apache-httpd/ I've reposted it below. Keystone and the other Openstack components run in an a href=http://www.eventlet.net;Eventlet/a based HTTP server. Eventlet and a href=http://http://pypi.python.org/pypi/greenlet; Greenlet/a (the project Eventlet is built on) are designed to be highly performant in networked environments due to their non-blocking nature. Everything is handled in a single thread, and scheduling is performed in user space. The one caveat is that not only must the code you write never block, the code you call must not block, either. If you are going to make a call into a third party library that performs I/O, you need to wrap that library in a thread pool. For Keystone, every call is going to be going through to a Database layer, either SQL or LDAP. Which is in turn going to call into the native driver for that Database, or the LDAP libraries. Either way, it is a native call, and it has to be wrapped in a thread pool. Keystone is an authentication hub. As such, it is literally the Keystone of the security architecture around Openstack. In order to do anything on any of the other services in Openstack, a use needs a token from Keystone. But in order to authenticate against Keystone, the user needs to provide a clear-text password. This approach may be sufficient to start development, but it is not going to be acceptable when a company needs to prove compliance with a title=Sarbanes Oxley Act of 2002 href=http://www.soxlaw.com/; target=_blankSarbanes-Oxley/a. Or a title=Health Information Privacy href=http://www.hhs.gov/ocr/privacy/hipaa/understanding/index.html; target=_blankHIPPAA/a. For these cases, we want stronger encryption and better authentication management. The Eventlet based web server does not currently support forms of authentication other than Basic-Auth. Ideally, organizations would be able to employ their Kerberos or Public Key Infrastructure (PKI) assets to support their Openstack based authentication. IPv6 is coming. The last block of IPv4 addresses has been allocated. For Cloud based deployments, people are going to need large numbers of routable IP Addresses. However, Eventlet does not currently support IPv6. Work is happening upstream, but it has not yet been commited, and will not be available for the Essex release of Openstack. There is a simple solution. Keystone is a WSGI application, and has minimal dependencies on Eventlet. Deploying Keystone in an Apache HTTPD server with mod_wsgi running in prefork mode provides the same operating environment as Eventlet does. As the de facto standard open source web server, it has received a higher degree of scrutiny than most other software products. HTTPD support for GSSAPI/Kerberos authentication, Client and Server based certificates, and IPv6. It is well supported in all the major Linux distributions. What would the drawbacks be? Probably the first thing people would look to from Eventlet is performance. I don't have the hard numbers to compare Eventlet to Apache HTTPD, but I do know that Apache is used in enough high volume sites that I would not be overly concerned. The traffic in an Openstack deployment to a Keystone server is going to be about two orders of magnitude less than any other traffic, and is highly unlikely to be the bottleneck. Second is the fact that we would be pulling in dependencies to Apache HTTPD, and that configuring it would be different and more difficult than Eventlet. However, this is a fairly well trodden path. The benefits of putting all HTTP traffic behind ports 80 and 443 overwhelm the drawbacks of configuration. Since Keystone has just gone through a major reworking, I realize that people might be reluctant to support a move like this. However, the effect on other components should be minimal or none. Apache HTTPD can be set up using the same ports that Keystone already uses, and thus replace an existing Keystone install with no changes to the configuration or code to the other services. The changes should be limited to Keystone alone. The problem that Eventlet solves does not map to Keystone. The amount of work it would take to add the features Keystone really requires to Eventlet is significant, is difficult, and is likely to be far buggier than using well established and audited libraries. The simpler path forward is for Keystone to move over to Apache HTTPD. It is also the path for greater stability, security, and growth. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Memory leaks from greenthreads
I wrote up why I think that, at least for Keystone, we should move the front end over to Apache HTTPD. http://adam.younglogic.com/2012/03/keystone-should-move-to-apache-httpd/ I've reposted it below. Keystone and the other Openstack components run in an a href=http://www.eventlet.net;Eventlet/a based HTTP server. Eventlet and a href=http://http://pypi.python.org/pypi/greenlet; Greenlet/a (the project Eventlet is built on) are designed to be highly performant in networked environments due to their non-blocking nature. Everything is handled in a single thread, and scheduling is performed in user space. The one caveat is that not only must the code you write never block, the code you call must not block, either. If you are going to make a call into a third party library that performs I/O, you need to wrap that library in a thread pool. For Keystone, every call is going to be going through to a Database layer, either SQL or LDAP. Which is in turn going to call into the native driver for that Database, or the LDAP libraries. Either way, it is a native call, and it has to be wrapped in a thread pool. Keystone is an authentication hub. As such, it is literally the Keystone of the security architecture around Openstack. In order to do anything on any of the other services in Openstack, a use needs a token from Keystone. But in order to authenticate against Keystone, the user needs to provide a clear-text password. This approach may be sufficient to start development, but it is not going to be acceptable when a company needs to prove compliance with a title=Sarbanes Oxley Act of 2002 href=http://www.soxlaw.com/; target=_blankSarbanes-Oxley/a. Or a title=Health Information Privacy href=http://www.hhs.gov/ocr/privacy/hipaa/understanding/index.html; target=_blankHIPPAA/a. For these cases, we want stronger encryption and better authentication management. The Eventlet based web server does not currently support forms of authentication other than Basic-Auth. Ideally, organizations would be able to employ their Kerberos or Public Key Infrastructure (PKI) assets to support their Openstack based authentication. IPv6 is coming. The last block of IPv4 addresses has been allocated. For Cloud based deployments, people are going to need large numbers of routable IP Addresses. However, Eventlet does not currently support IPv6. Work is happening upstream, but it has not yet been commited, and will not be available for the Essex release of Openstack. There is a simple solution. Keystone is a WSGI application, and has minimal dependencies on Eventlet. Deploying Keystone in an Apache HTTPD server with mod_wsgi running in prefork mode provides the same operating environment as Eventlet does. As the de facto standard open source web server, it has received a higher degree of scrutiny than most other software products. HTTPD support for GSSAPI/Kerberos authentication, Client and Server based certificates, and IPv6. It is well supported in all the major Linux distributions. What would the drawbacks be? Probably the first thing people would look to from Eventlet is performance. I don't have the hard numbers to compare Eventlet to Apache HTTPD, but I do know that Apache is used in enough high volume sites that I would not be overly concerned. The traffic in an Openstack deployment to a Keystone server is going to be about two orders of magnitude less than any other traffic, and is highly unlikely to be the bottleneck. Second is the fact that we would be pulling in dependencies to Apache HTTPD, and that configuring it would be different and more difficult than Eventlet. However, this is a fairly well trodden path. The benefits of putting all HTTP traffic behind ports 80 and 443 overwhelm the drawbacks of configuration. Since Keystone has just gone through a major reworking, I realize that people might be reluctant to support a move like this. However, the effect on other components should be minimal or none. Apache HTTPD can be set up using the same ports that Keystone already uses, and thus replace an existing Keystone install with no changes to the configuration or code to the other services. The changes should be limited to Keystone alone. The problem that Eventlet solves does not map to Keystone. The amount of work it would take to add the features Keystone really requires to Eventlet is significant, is difficult, and is likely to be far buggier than using well established and audited libraries. The simpler path forward is for Keystone to move over to Apache HTTPD. It is also the path for greater stability, security, and growth. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone should to Apache HTTPD.
I like the recommendation. Particularly with regards to using PKI authentication. On Thu, Mar 1, 2012 at 2:05 PM, Adam Young ayo...@redhat.com wrote: I wrote up why I think that, at least for Keystone, we should move the front end over to Apache HTTPD. http://adam.younglogic.com/2012/03/keystone-should-move-to-apache-httpd/ I've reposted it below. Keystone and the other Openstack components run in an a href=http://www.eventlet.net;Eventlet/a based HTTP server. Eventlet and a href=http://http://pypi.python.org/pypi/greenlet; Greenlet/a (the project Eventlet is built on) are designed to be highly performant in networked environments due to their non-blocking nature. Everything is handled in a single thread, and scheduling is performed in user space. The one caveat is that not only must the code you write never block, the code you call must not block, either. If you are going to make a call into a third party library that performs I/O, you need to wrap that library in a thread pool. For Keystone, every call is going to be going through to a Database layer, either SQL or LDAP. Which is in turn going to call into the native driver for that Database, or the LDAP libraries. Either way, it is a native call, and it has to be wrapped in a thread pool. Keystone is an authentication hub. As such, it is literally the Keystone of the security architecture around Openstack. In order to do anything on any of the other services in Openstack, a use needs a token from Keystone. But in order to authenticate against Keystone, the user needs to provide a clear-text password. This approach may be sufficient to start development, but it is not going to be acceptable when a company needs to prove compliance with a title=Sarbanes Oxley Act of 2002 href=http://www.soxlaw.com/; target=_blankSarbanes-Oxley/a. Or a title=Health Information Privacy href=http://www.hhs.gov/ocr/privacy/hipaa/understanding/index.html; target=_blankHIPPAA/a. For these cases, we want stronger encryption and better authentication management. The Eventlet based web server does not currently support forms of authentication other than Basic-Auth. Ideally, organizations would be able to employ their Kerberos or Public Key Infrastructure (PKI) assets to support their Openstack based authentication. IPv6 is coming. The last block of IPv4 addresses has been allocated. For Cloud based deployments, people are going to need large numbers of routable IP Addresses. However, Eventlet does not currently support IPv6. Work is happening upstream, but it has not yet been commited, and will not be available for the Essex release of Openstack. There is a simple solution. Keystone is a WSGI application, and has minimal dependencies on Eventlet. Deploying Keystone in an Apache HTTPD server with mod_wsgi running in prefork mode provides the same operating environment as Eventlet does. As the de facto standard open source web server, it has received a higher degree of scrutiny than most other software products. HTTPD support for GSSAPI/Kerberos authentication, Client and Server based certificates, and IPv6. It is well supported in all the major Linux distributions. What would the drawbacks be? Probably the first thing people would look to from Eventlet is performance. I don't have the hard numbers to compare Eventlet to Apache HTTPD, but I do know that Apache is used in enough high volume sites that I would not be overly concerned. The traffic in an Openstack deployment to a Keystone server is going to be about two orders of magnitude less than any other traffic, and is highly unlikely to be the bottleneck. Second is the fact that we would be pulling in dependencies to Apache HTTPD, and that configuring it would be different and more difficult than Eventlet. However, this is a fairly well trodden path. The benefits of putting all HTTP traffic behind ports 80 and 443 overwhelm the drawbacks of configuration. Since Keystone has just gone through a major reworking, I realize that people might be reluctant to support a move like this. However, the effect on other components should be minimal or none. Apache HTTPD can be set up using the same ports that Keystone already uses, and thus replace an existing Keystone install with no changes to the configuration or code to the other services. The changes should be limited to Keystone alone. The problem that Eventlet solves does not map to Keystone. The amount of work it would take to add the features Keystone really requires to Eventlet is significant, is difficult, and is likely to be far buggier than using well established and audited libraries. The simpler path forward is for Keystone to move over to Apache HTTPD. It is also the path for greater stability, security, and growth. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe :
Re: [Openstack] Keystone should to Apache HTTPD.
This seems like it could also be done for every other WSGI endpoint right? It seems like it should be possible for all WS endpoints to be hosted in apache (or other server) without problems happening. This might be connected to extracting/abstractig out eventlet (since a pre-forked apache doesn't really care about that model) so that it is not always needed. On 3/1/12 11:05 AM, Adam Young ayo...@redhat.com wrote: I wrote up why I think that, at least for Keystone, we should move the front end over to Apache HTTPD. http://adam.younglogic.com/2012/03/keystone-should-move-to-apache-httpd/ I've reposted it below. Keystone and the other Openstack components run in an a href=http://www.eventlet.net;Eventlet/a based HTTP server. Eventlet and a href=http://http://pypi.python.org/pypi/greenlet; Greenlet/a (the project Eventlet is built on) are designed to be highly performant in networked environments due to their non-blocking nature. Everything is handled in a single thread, and scheduling is performed in user space. The one caveat is that not only must the code you write never block, the code you call must not block, either. If you are going to make a call into a third party library that performs I/O, you need to wrap that library in a thread pool. For Keystone, every call is going to be going through to a Database layer, either SQL or LDAP. Which is in turn going to call into the native driver for that Database, or the LDAP libraries. Either way, it is a native call, and it has to be wrapped in a thread pool. Keystone is an authentication hub. As such, it is literally the Keystone of the security architecture around Openstack. In order to do anything on any of the other services in Openstack, a use needs a token from Keystone. But in order to authenticate against Keystone, the user needs to provide a clear-text password. This approach may be sufficient to start development, but it is not going to be acceptable when a company needs to prove compliance with a title=Sarbanes Oxley Act of 2002 href=http://www.soxlaw.com/; target=_blankSarbanes-Oxley/a. Or a title=Health Information Privacy href=http://www.hhs.gov/ocr/privacy/hipaa/understanding/index.html; target=_blankHIPPAA/a. For these cases, we want stronger encryption and better authentication management. The Eventlet based web server does not currently support forms of authentication other than Basic-Auth. Ideally, organizations would be able to employ their Kerberos or Public Key Infrastructure (PKI) assets to support their Openstack based authentication. IPv6 is coming. The last block of IPv4 addresses has been allocated. For Cloud based deployments, people are going to need large numbers of routable IP Addresses. However, Eventlet does not currently support IPv6. Work is happening upstream, but it has not yet been commited, and will not be available for the Essex release of Openstack. There is a simple solution. Keystone is a WSGI application, and has minimal dependencies on Eventlet. Deploying Keystone in an Apache HTTPD server with mod_wsgi running in prefork mode provides the same operating environment as Eventlet does. As the de facto standard open source web server, it has received a higher degree of scrutiny than most other software products. HTTPD support for GSSAPI/Kerberos authentication, Client and Server based certificates, and IPv6. It is well supported in all the major Linux distributions. What would the drawbacks be? Probably the first thing people would look to from Eventlet is performance. I don't have the hard numbers to compare Eventlet to Apache HTTPD, but I do know that Apache is used in enough high volume sites that I would not be overly concerned. The traffic in an Openstack deployment to a Keystone server is going to be about two orders of magnitude less than any other traffic, and is highly unlikely to be the bottleneck. Second is the fact that we would be pulling in dependencies to Apache HTTPD, and that configuring it would be different and more difficult than Eventlet. However, this is a fairly well trodden path. The benefits of putting all HTTP traffic behind ports 80 and 443 overwhelm the drawbacks of configuration. Since Keystone has just gone through a major reworking, I realize that people might be reluctant to support a move like this. However, the effect on other components should be minimal or none. Apache HTTPD can be set up using the same ports that Keystone already uses, and thus replace an existing Keystone install with no changes to the configuration or code to the other services. The changes should be limited to Keystone alone. The problem that Eventlet solves does not map to Keystone. The amount of work it would take to add the features Keystone really requires to Eventlet is significant, is difficult, and is likely to be far buggier than using well established and audited libraries. The simpler path forward is for Keystone to move over to Apache HTTPD. It is also the path for greater
Re: [Openstack] eventlet weirdness
There are plenty eventlet discussion recently but I'll stick my question to this thread, although it's pretty much a separate question. :) How is MySQL access handled in eventlet? Presumably it's external C library so it's not going to be monkey patched. Does that make every db access call a blocking call? Thanks, Yun On Wed, Feb 29, 2012 at 9:18 PM, Johannes Erdfelt johan...@erdfelt.com wrote: On Wed, Feb 29, 2012, Yun Mao yun...@gmail.com wrote: Thanks for the explanation. Let me see if I understand this. 1. Eventlet will never have this problem if there is only 1 OS thread -- let's call it main thread. In fact, that's exactly what Python calls it :) 2. In Nova, there is only 1 OS thread unless you use xenapi and/or the virt/firewall driver. 3. The python logging module uses locks. Because of the monkey patch, those locks are actually eventlet or green locks and may trigger a green thread context switch. Based on 1-3, does it make sense to say that in the other OS threads (i.e. not main thread), if logging (plus other pure python library code involving locking) is never used, and we do not run a eventlet hub at all, we should never see this problem? That should be correct. I'd have to double check all of the monkey patching that eventlet does to make sure there aren't other cases where you may inadvertently use eventlet primitives across real threads. JE ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Memory leaks from greenthreads
On 03/01/2012 02:48 PM, Vishvananda Ishaya wrote: On Mar 1, 2012, at 9:39 AM, Adam Young wrote: What would the drawbacks be? Probably the first thing people would look to from Eventlet is performance. I don't have the hard numbers to compare Eventlet to Apache HTTPD, but I do know that Apache is used in enough high volume sites that I would not be overly concerned. The traffic in an Openstack deployment to a Keystone server is going to be about two orders of magnitude less than any other traffic, and is highly unlikely to be the bottleneck. How did you arrive at this number? Every user has to hit keystone before making a request to any other service (unless they already have a token) and each service needs to authenticate that token. Any request that hits multiple services will hit keystone multiple times. Without caching, keystone is by far the busiest service in an openstack install. Caching should fix some of this, but I don't know that I would expect it to be two orders of magnitude less. Vish Simply that I would expect the various servers to cache the results of validating a token, and thus each user-token should very quickly be populated on each service in the system. If the amount of traffic doesn't call for caching the token, then I expect it would be low enough that the issue is moot. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Keystone should to Apache HTTPD.
On Thu, 2012-03-01 at 14:05 -0500, Adam Young wrote: The traffic in an Openstack deployment to a Keystone server is going to be about two orders of magnitude less than any other traffic, and is highly unlikely to be the bottleneck. Not quite. I wrote this up, back in November: http://etherpad.openstack.org/keystone-scalability Since then, of course, Keystone has gone through some major cleanups that have improved its efficiency, but, as Vish pointed out in the other thread, every service still has to hit Keystone to verify a given token, which makes Keystone have the highest number of hits for any given operation…which in turn makes it *the* most likely bottleneck. -- Kevin L. Mitchell kevin.mitch...@rackspace.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] quantum and openvswitch issue
Hi Jay, The steps you have taken so far seem correct. Have you spun up any VMs yet? The current output from the OVS agent implies you may not have. Quantum networks are logical entities, so you won't see the result of creating a network until you actually spin up a VM that uses that network. When a VM is spun up, there should be an interface created on br-int for each vNIC, and those interfaces will be placed on the right network by setting vlan config on the local port. If you're still seeing problems, create a quantum bug and attach this info plus the output of: sudo ovs-vsctl list Port You can also run the agent with the -v flag for more information. Dan On Wed, Feb 29, 2012 at 9:48 AM, jay_s_b jay_...@yahoo.com wrote: Hello, I have installed one controller node that has nova-compute/nova-network/nova-api/nova-volume. I have installed quantum on another server. I am using openvswitch plugin On the controller node, I have installed openvswitch. I created the bridge/port/interface using the following commands sudo ovs-vsctl add-br br-int sudo ovs-vsctl set bridge br-int datapath_type=netdev sudo ovs-vsctl add-port br-int eth1 I ran the ovs_agent on the controller. It says, INFO:root:Connecting to database ovs_quantum on 192.168.198.55 But, when I tried to do sudo nova-manage --verbose network create --label=public --fixed_range_v4= 10.0.0.0/24 I see network being created in the mysql ovs_quantum database. But, i do not see real network getting created. I do not see any messages in the agent log. neither do i see any messages in the quantum-server log. Is there a client to check the communication from ovs_agent on controller to quantum-server? Thanks, -Jay -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] eventlet weirdness
On Mar 1, 2012, at 12:27 PM, Adam Young wrote: On 03/01/2012 02:45 PM, Yun Mao wrote: There are plenty eventlet discussion recently but I'll stick my question to this thread, although it's pretty much a separate question. :) How is MySQL access handled in eventlet? Presumably it's external C library so it's not going to be monkey patched. Does that make every db access call a blocking call? Thanks, Nope, it goes through a thread pool. Actually, it doesn't use a thread pool right now... so it does block, unless something has changed recently that I'm not aware of. We were using the eventpool dbpool code, but we had to remove it at diablo release time due to issues. Correct me if this is wrong. I'm not sure it's ever been completely revisited, but this is definitely a huge issue for scaling. It's been on my list for a while to take a look at. - Chris ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] eventlet weirdness
On Mar 1, 2012, at 12:36 PM, Vishvananda Ishaya wrote: Yes it does. We actually tried to use a pool at diablo release and it was very broken. There was discussion about moving over to a pure-python mysql library, but it hasn't been tried yet. I know some people have tried this... and the performance is... not great. - Chris ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] eventlet weirdness
How is MySQL access handled in eventlet? Presumably it's external C library so it's not going to be monkey patched. Does that make every db access call a blocking call? Thanks, Nope, it goes through a thread pool. I feel like this might be an over-simplification. If the question is: How is MySQL access handled in nova? The answer would be that we use SQLAlchemy which can load any number of SQL-drivers. These drivers can be either pure Python or C-based drivers. In the case of pure Python drivers, monkey patching can occur and db calls are non-blocking. In the case of drivers which contain C code (or perhaps other blocking calls), db calls will most likely be blocking. If the question is How is MySQL access handled in eventlet? the answer would be to use the eventlet.db_pool module to allow db access using thread pools. B -Original Message- From: Adam Young ayo...@redhat.com Sent: Thursday, March 1, 2012 3:27pm To: openstack@lists.launchpad.net Subject: Re: [Openstack] eventlet weirdness On 03/01/2012 02:45 PM, Yun Mao wrote: There are plenty eventlet discussion recently but I'll stick my question to this thread, although it's pretty much a separate question. :) How is MySQL access handled in eventlet? Presumably it's external C library so it's not going to be monkey patched. Does that make every db access call a blocking call? Thanks, Nope, it goes through a thread pool. Yun On Wed, Feb 29, 2012 at 9:18 PM, Johannes Erdfeltjohan...@erdfelt.com wrote: On Wed, Feb 29, 2012, Yun Maoyun...@gmail.com wrote: Thanks for the explanation. Let me see if I understand this. 1. Eventlet will never have this problem if there is only 1 OS thread -- let's call it main thread. In fact, that's exactly what Python calls it :) 2. In Nova, there is only 1 OS thread unless you use xenapi and/or the virt/firewall driver. 3. The python logging module uses locks. Because of the monkey patch, those locks are actually eventlet or green locks and may trigger a green thread context switch. Based on 1-3, does it make sense to say that in the other OS threads (i.e. not main thread), if logging (plus other pure python library code involving locking) is never used, and we do not run a eventlet hub at all, we should never see this problem? That should be correct. I'd have to double check all of the monkey patching that eventlet does to make sure there aren't other cases where you may inadvertently use eventlet primitives across real threads. JE ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] eventlet weirdness
Just because MySQL is a C library doesn't necessarily mean it can't be made to work with coroutines. ZeroMQ is supported through eventlet.green.zmq and there exists geventmysql (although it appears to me as more a proof-of-concept). Moving to a pure-python mysql library might be the path of least resistance as long as we're committed to eventlet. -- Eric Windisch On Thursday, March 1, 2012 at 3:36 PM, Vishvananda Ishaya wrote: Yes it does. We actually tried to use a pool at diablo release and it was very broken. There was discussion about moving over to a pure-python mysql library, but it hasn't been tried yet. Vish On Mar 1, 2012, at 11:45 AM, Yun Mao wrote: There are plenty eventlet discussion recently but I'll stick my question to this thread, although it's pretty much a separate question. :) How is MySQL access handled in eventlet? Presumably it's external C library so it's not going to be monkey patched. Does that make every db access call a blocking call? Thanks, Yun On Wed, Feb 29, 2012 at 9:18 PM, Johannes Erdfelt johan...@erdfelt.com (mailto:johan...@erdfelt.com) wrote: On Wed, Feb 29, 2012, Yun Mao yun...@gmail.com (mailto:yun...@gmail.com) wrote: Thanks for the explanation. Let me see if I understand this. 1. Eventlet will never have this problem if there is only 1 OS thread -- let's call it main thread. In fact, that's exactly what Python calls it :) 2. In Nova, there is only 1 OS thread unless you use xenapi and/or the virt/firewall driver. 3. The python logging module uses locks. Because of the monkey patch, those locks are actually eventlet or green locks and may trigger a green thread context switch. Based on 1-3, does it make sense to say that in the other OS threads (i.e. not main thread), if logging (plus other pure python library code involving locking) is never used, and we do not run a eventlet hub at all, we should never see this problem? That should be correct. I'd have to double check all of the monkey patching that eventlet does to make sure there aren't other cases where you may inadvertently use eventlet primitives across real threads. JE ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net (mailto:openstack@lists.launchpad.net) Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net (mailto:openstack@lists.launchpad.net) Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net (mailto:openstack@lists.launchpad.net) Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] eventlet weirdness
Someone might have already said this (sure wish the listserv sent me mail faster), but we tried out PyMysql and it was exceptionally slow, even under almost no load. I have a branch in my github that I was using to test out unblocking the database access. For my cases I found that it was unblocked but that it didn't really help performance as much as I had hoped. branch: https://github.com/markwash/nova/tree/optional-db-api-thread-no-pool just the relevant commit: https://github.com/markwash/nova/commit/99e38d3df579670808711eb8acd1f96806d8b6f0 Vishvananda Ishaya vishvana...@gmail.com said: Yes it does. We actually tried to use a pool at diablo release and it was very broken. There was discussion about moving over to a pure-python mysql library, but it hasn't been tried yet. Vish On Mar 1, 2012, at 11:45 AM, Yun Mao wrote: There are plenty eventlet discussion recently but I'll stick my question to this thread, although it's pretty much a separate question. :) How is MySQL access handled in eventlet? Presumably it's external C library so it's not going to be monkey patched. Does that make every db access call a blocking call? Thanks, Yun On Wed, Feb 29, 2012 at 9:18 PM, Johannes Erdfelt johan...@erdfelt.com wrote: On Wed, Feb 29, 2012, Yun Mao yun...@gmail.com wrote: Thanks for the explanation. Let me see if I understand this. 1. Eventlet will never have this problem if there is only 1 OS thread -- let's call it main thread. In fact, that's exactly what Python calls it :) 2. In Nova, there is only 1 OS thread unless you use xenapi and/or the virt/firewall driver. 3. The python logging module uses locks. Because of the monkey patch, those locks are actually eventlet or green locks and may trigger a green thread context switch. Based on 1-3, does it make sense to say that in the other OS threads (i.e. not main thread), if logging (plus other pure python library code involving locking) is never used, and we do not run a eventlet hub at all, we should never see this problem? That should be correct. I'd have to double check all of the monkey patching that eventlet does to make sure there aren't other cases where you may inadvertently use eventlet primitives across real threads. JE ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Netstack] Can't associate floating IP
On Thu, Mar 1, 2012 at 12:51 PM, Yapeng Wu yapen...@me.com wrote:
In the multi-host quantum OVS plugin case, I am not clear how and when
this 'host' in the 'network' table should be updated.
From the code update, I doubt this would work in multi-host case.
It is documented that Quantum does not support multi-host for Essex:
http://docs.openstack.org/incubation/openstack-network/admin/content/Limits-dle455.html
Its something we'll tackle in Folsom.
Dan
Currently I always use manually update of mysql command as Brad showed in
the email.
Yapeng
On Mar 01, 2012, at 09:18 AM, Tomoe Sugihara to...@midokura.com wrote:
Hi Doude,
I was dealing with another issue caused by this NULL 'host', and Dan told
me that has been fixed:
https://github.com/openstack/nova/commit/43f2492175d11a3f8ea4198e65b2a6a6b38cbbb6
I haven't verified, though. Good luck.
Best,
Tomoe
On Thu, Mar 1, 2012 at 10:11 PM, Doude doudou...@gmail.com wrote:
Hi,
I tested it with Quantum and I confirm the field 'host' in the 'network'
table stays empty.
Someone filled a bug for that ?
Doude.
On Tue, Feb 28, 2012 at 8:06 AM, Vishvananda Ishaya
vishvana...@gmail.com wrote:
...
At least that is the case for nova-network without quantum. I don't
know if using Quantum leads to a different result.
Vish
On Feb 27, 2012, at 9:49 PM, Yapeng Wu wrote:
Hello, Brad,
I read your reply to Darragph's email:
Another thing to check .. when I run devstack by default my network
doesn't get associated with a host [host is NULL in the database].
Make sure the host for that network is set to the hostname of the
compute node.
I found that when I use nova-manage network create CLI command, the
host is NULL in the database as well.
Is this a bug? Where would this host field get updated?
Thanks,
Yapeng
On Feb 27, 2012, at 04:02 PM, Yapeng Wu yapen...@me.com wrote:
Hello, Darragh,
I...
2) For the second problem: command line issue, I found that it was due
to the code in nova/network/manager.py, line 435 to 452:
if network['multi_host']:
instance = self.db.instance_get(context,
fixed_ip['instance_id'])
host = instance['host']
else:
host = network['host']
interface = floating_ip['interface']
if host == self.host:
# i'm the correct host
self._associate_floating_ip(context, floating_address,
fixed_address, interface)
else:
# send to correct host
rpc.cast(context,
self.db.queue_get_for(context, FLAGS.network_topic,
host),
{'method': '_associate_floating_ip',
'args': {'floating_address': floating_address,
'fixed_address': fixed_address,
'interface': interface}})
The host should be self.host in this case, but not. So it calls
rpc.cast. I thought host is read from the database by the 'instance_id'? I
am not sure. If I hacked the code by calling self._associate_floating_ip
directly, associate floating ip works.
Maybe someone familiar with nova-network code could help us on this.
Yapeng
On Feb 27, 2012, at 12:18 PM, Dan Wendlandt d...@nicira.com wrote:
Hi Darragh,
Thanks for the detailed write-up. Would be great if you could take this
content and create a bug on launchpad. We'll look into this.
On a related note. The check in stack.sh to avoid creating a floating
IP pool if quantum is enabled is no longer valid, now that Quantum Manager
does (or at least intends to :P ) support floating IPs. But rather than
remove it, it may be good to just change to the check to avoid creating
floating IPs if melange is enabled, as Quantum Manager's current floating
IP support requires using the traditional Nova IPAM, not Melange.
Dan
On Mon, Feb 27, 2012 at 6:38 AM, Darragh OReilly
darragh.orei...@yahoo.com wrote:
When I try to associate a floating IP from the dash I get:
Error: Error associating Floating IP: Associate floating ip failed
(HTTP 500)
From the command line I don't get any errors or exceptions on any of
the screens after nova add-floating-ip, but the association does not
happen. Are these steps right?
thanks Darragh
u1@u1110srv:~/devstack$ cat localrc
LOGFILE=stacklog
MYSQL_PASSWORD=nova
RABBIT_PASSWORD=nova
SERVICE_TOKEN=nova
ADMIN_PASSWORD=nova
SWIFT_HASH=nova
ENABLED_SERVICES=g-api,g-reg,key,n-api,n-cpu,n-net,n-sch,n-vnc,horizon,mysql,rabbit,openstackx,n-vol,q-svc,q-agt,swift,quantum
Q_PLUGIN=openvswitch
After running stack.sh have:
u1@u1110srv:~/devstack$ nova-manage network list
id IPv4 IPv6 start address
DNS1 DNS2 VlanID project
uuid
2012-02-27 13:38:04 DEBUG nova.utils
[req-7b6febc7-c8cd-49e5-ac48-5707c70d8bb5 None None] backend module
Re: [Openstack] Keystone should to Apache HTTPD.
On 03/01/2012 03:52 PM, Kevin L. Mitchell wrote: On Thu, 2012-03-01 at 14:05 -0500, Adam Young wrote: The traffic in an Openstack deployment to a Keystone server is going to be about two orders of magnitude less than any other traffic, and is highly unlikely to be the bottleneck. Not quite. I wrote this up, back in November: http://etherpad.openstack.org/keystone-scalability Since then, of course, Keystone has gone through some major cleanups that have improved its efficiency, but, as Vish pointed out in the other thread, every service still has to hit Keystone to verify a given token, which makes Keystone have the highest number of hits for any given operation…which in turn makes it *the* most likely bottleneck. Good write up. My SWAG estimate was based on an efficient protocol. I am still learning Keystone, so I can't say as far as how it is deployed in practice. HMAC can be supported with a Public/Private key pair fairly easily. If the HMAC is signed with a private key, the other service can confirm them with a public key. It should really not require a round trip to verify a token. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Memory leaks from greenthreads
On 03/01/2012 02:48 PM, Vishvananda Ishaya wrote: On Mar 1, 2012, at 9:39 AM, Adam Young wrote: What would the drawbacks be? Probably the first thing people would look to from Eventlet is performance. I don't have the hard numbers to compare Eventlet to Apache HTTPD, but I do know that Apache is used in enough high volume sites that I would not be overly concerned. The traffic in an Openstack deployment to a Keystone server is going to be about two orders of magnitude less than any other traffic, and is highly unlikely to be the bottleneck. How did you arrive at this number? Every user has to hit keystone before making a request to any other service (unless they already have a token) and each service needs to authenticate that token. Any request that hits multiple services will hit keystone multiple times. Without caching, keystone is by far the busiest service in an openstack install. Caching should fix some of this, but I don't know that I would expect it to be two orders of magnitude less. Vish Seeing as the SQL Alchemy code is blocking on each request, I suspect that performance is now soundly *not* a reason to want to stick with eventlet. My statement that Eventlet is performant is based on the assumption that the benefits of using Greenthreads are realized. It looks like that is not the case. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Essex-4 milestone available for Quantum
Hi all, The Essex-4 milestone for Quantum and updated documentation is available at: https://launchpad.net/quantum/essex/essex-4 Lots of great improvements in this release, including three new plugins (Linux Bridge, Nicira NVP, and Ryu Controller) as well as significant updates to the OVS plugin. We also added 1.1 API support to the quantum client, and squashed a good number of bugs. Great work! Equally important, Essex-4 saw a good number of new people making significant contributions to the project in terms of features, code reviews, and testing, which is crucial for the success of the project. Let's keep it up. Now its time to really test both code docs to make sure they are solid for the main Essex release. If there is an issue that you consider critical for Essex, let me know and we'll get it slotted for RC1: https://launchpad.net/quantum/+milestone/essex-rc1 (no date set, we will release it when we've fixed all issues identified as critical). If you're looking for the doc changes since the last release, you see see the review here: https://review.openstack.org/#change,4774 . Please give feedback via the review. Congrats to the whole team! Dan -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Memory leaks from greenthreads
Sad, especially since so much is using the database :-( On 3/1/12 2:43 PM, Adam Young ayo...@redhat.com wrote: On 03/01/2012 02:48 PM, Vishvananda Ishaya wrote: On Mar 1, 2012, at 9:39 AM, Adam Young wrote: What would the drawbacks be? Probably the first thing people would look to from Eventlet is performance. I don't have the hard numbers to compare Eventlet to Apache HTTPD, but I do know that Apache is used in enough high volume sites that I would not be overly concerned. The traffic in an Openstack deployment to a Keystone server is going to be about two orders of magnitude less than any other traffic, and is highly unlikely to be the bottleneck. How did you arrive at this number? Every user has to hit keystone before making a request to any other service (unless they already have a token) and each service needs to authenticate that token. Any request that hits multiple services will hit keystone multiple times. Without caching, keystone is by far the busiest service in an openstack install. Caching should fix some of this, but I don't know that I would expect it to be two orders of magnitude less. Vish Seeing as the SQL Alchemy code is blocking on each request, I suspect that performance is now soundly *not* a reason to want to stick with eventlet. My statement that Eventlet is performant is based on the assumption that the benefits of using Greenthreads are realized. It looks like that is not the case. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Memory leaks from greenthreads
I agree. It would be awesome if someone could actually make it work. We had a totally broken version using the eventlet db pool 6 months ago. Vish On Mar 1, 2012, at 4:20 PM, Joshua Harlow wrote: Sad, especially since so much is using the database :-( On 3/1/12 2:43 PM, Adam Young ayo...@redhat.com wrote: On 03/01/2012 02:48 PM, Vishvananda Ishaya wrote: On Mar 1, 2012, at 9:39 AM, Adam Young wrote: What would the drawbacks be? Probably the first thing people would look to from Eventlet is performance. I don't have the hard numbers to compare Eventlet to Apache HTTPD, but I do know that Apache is used in enough high volume sites that I would not be overly concerned. The traffic in an Openstack deployment to a Keystone server is going to be about two orders of magnitude less than any other traffic, and is highly unlikely to be the bottleneck. How did you arrive at this number? Every user has to hit keystone before making a request to any other service (unless they already have a token) and each service needs to authenticate that token. Any request that hits multiple services will hit keystone multiple times. Without caching, keystone is by far the busiest service in an openstack install. Caching should fix some of this, but I don't know that I would expect it to be two orders of magnitude less. Vish Seeing as the SQL Alchemy code is blocking on each request, I suspect that performance is now soundly *not* a reason to want to stick with eventlet. My statement that Eventlet is performant is based on the assumption that the benefits of using Greenthreads are realized. It looks like that is not the case. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Test Dependencies
Is there any interest in adding unittest2 to the test dependencies for openstack projects? I have found its enhanced assertions and 'with self.assertRaises' very useful in writing tests. I see there have been past bugs that mentioned unittest2, and am wondering if the reasons for not adopting it still stand. Separately, is the use of mox open to discussion? mock was recently added as a dependency to quantum to perform library patching, which isn't supported by mox as far as I know. The ability to do non-replay mocking is another useful feature of mock. I'm not suggesting that mox be replaced, but am wondering if mock could be an additional dependency and used when the functionality provided by mox falls short. Thanks, Maru ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] eventlet weirdness
As long as we allocate a thread in the eventlet thread pool for the number of mysql connections we want to actually maintain in our connection pool, we shouldn't have problems getting the results we want even with the blocking mysql c drivers. Devin On Thursday, March 1, 2012 at 5:23 PM, Kapil Thangavelu wrote: The standard python postgresql driver (psycopg2) does have an async mode. There are non db api compliant async mysql drivers for gevent. Excerpts from Vishvananda Ishaya's message of 2012-03-01 15:36:43 -0500: Yes it does. We actually tried to use a pool at diablo release and it was very broken. There was discussion about moving over to a pure-python mysql library, but it hasn't been tried yet. Vish On Mar 1, 2012, at 11:45 AM, Yun Mao wrote: There are plenty eventlet discussion recently but I'll stick my question to this thread, although it's pretty much a separate question. :) How is MySQL access handled in eventlet? Presumably it's external C library so it's not going to be monkey patched. Does that make every db access call a blocking call? Thanks, Yun On Wed, Feb 29, 2012 at 9:18 PM, Johannes Erdfelt johan...@erdfelt.com (mailto:johan...@erdfelt.com) wrote: On Wed, Feb 29, 2012, Yun Mao yun...@gmail.com (mailto:yun...@gmail.com) wrote: Thanks for the explanation. Let me see if I understand this. 1. Eventlet will never have this problem if there is only 1 OS thread -- let's call it main thread. In fact, that's exactly what Python calls it :) 2. In Nova, there is only 1 OS thread unless you use xenapi and/or the virt/firewall driver. 3. The python logging module uses locks. Because of the monkey patch, those locks are actually eventlet or green locks and may trigger a green thread context switch. Based on 1-3, does it make sense to say that in the other OS threads (i.e. not main thread), if logging (plus other pure python library code involving locking) is never used, and we do not run a eventlet hub at all, we should never see this problem? That should be correct. I'd have to double check all of the monkey patching that eventlet does to make sure there aren't other cases where you may inadvertently use eventlet primitives across real threads. JE ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net (mailto:openstack@lists.launchpad.net) Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net (mailto:openstack@lists.launchpad.net) Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net (mailto:openstack@lists.launchpad.net) Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Netstack] Essex-4 milestone available for Quantum
Hi Now the Dashboard whether can manage the Quantum? And whether the Devstack script can let dashbaord and Quantum working? On Fri, Mar 2, 2012 at 7:49 AM, Dan Wendlandt d...@nicira.com wrote: Hi all, The Essex-4 milestone for Quantum and updated documentation is available at: https://launchpad.net/quantum/essex/essex-4 Lots of great improvements in this release, including three new plugins (Linux Bridge, Nicira NVP, and Ryu Controller) as well as significant updates to the OVS plugin. We also added 1.1 API support to the quantum client, and squashed a good number of bugs. Great work! Equally important, Essex-4 saw a good number of new people making significant contributions to the project in terms of features, code reviews, and testing, which is crucial for the success of the project. Let's keep it up. Now its time to really test both code docs to make sure they are solid for the main Essex release. If there is an issue that you consider critical for Essex, let me know and we'll get it slotted for RC1: https://launchpad.net/quantum/+milestone/essex-rc1 (no date set, we will release it when we've fixed all issues identified as critical). If you're looking for the doc changes since the last release, you see see the review here: https://review.openstack.org/#change,4774 . Please give feedback via the review. Congrats to the whole team! Dan -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ -- Mailing list: https://launchpad.net/~netstack Post to : netst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp -- 陈沙克 手机：13661187180 msn：shake.c...@hotmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Netstack] Essex-4 milestone available for Quantum
On Thu, Mar 1, 2012 at 5:39 PM, Shake Chen shake.c...@gmail.com wrote: Hi Now the Dashboard whether can manage the Quantum? And whether the Devstack script can let dashbaord and Quantum working? Hi Shake, Unfortunately, the Horizon + Quantum integration is still in bad shape. Devin (Horizon PTL) and I have been talking about how to improve it, but it will be for Folsom, as our attempts to find someone will to do the work during Essex didn't pan out. If anyone on the list is interested in working on this, please let me know. Michael Fork has started doing some work on this, but there's more than enough work to spread around :) Dan On Fri, Mar 2, 2012 at 7:49 AM, Dan Wendlandt d...@nicira.com wrote: Hi all, The Essex-4 milestone for Quantum and updated documentation is available at: https://launchpad.net/quantum/essex/essex-4 Lots of great improvements in this release, including three new plugins (Linux Bridge, Nicira NVP, and Ryu Controller) as well as significant updates to the OVS plugin. We also added 1.1 API support to the quantum client, and squashed a good number of bugs. Great work! Equally important, Essex-4 saw a good number of new people making significant contributions to the project in terms of features, code reviews, and testing, which is crucial for the success of the project. Let's keep it up. Now its time to really test both code docs to make sure they are solid for the main Essex release. If there is an issue that you consider critical for Essex, let me know and we'll get it slotted for RC1: https://launchpad.net/quantum/+milestone/essex-rc1 (no date set, we will release it when we've fixed all issues identified as critical). If you're looking for the doc changes since the last release, you see see the review here: https://review.openstack.org/#change,4774 . Please give feedback via the review. Congrats to the whole team! Dan -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ -- Mailing list: https://launchpad.net/~netstack Post to : netst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp -- 陈沙克 手机：13661187180 msn：shake.c...@hotmail.com -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Netstack] Essex-4 milestone available for Quantum
Did you mean network creation using the dash. Quantum manager works with nova Sent from my iPhone On Mar 1, 2012, at 5:45 PM, Shake Chen shake.c...@gmail.com wrote: Hi Now the Dashboard whether can manage the Quantum? And whether the Devstack script can let dashbaord and Quantum working? On Fri, Mar 2, 2012 at 7:49 AM, Dan Wendlandt d...@nicira.com wrote: Hi all, The Essex-4 milestone for Quantum and updated documentation is available at: https://launchpad.net/quantum/essex/essex-4 Lots of great improvements in this release, including three new plugins (Linux Bridge, Nicira NVP, and Ryu Controller) as well as significant updates to the OVS plugin. We also added 1.1 API support to the quantum client, and squashed a good number of bugs. Great work! Equally important, Essex-4 saw a good number of new people making significant contributions to the project in terms of features, code reviews, and testing, which is crucial for the success of the project. Let's keep it up. Now its time to really test both code docs to make sure they are solid for the main Essex release. If there is an issue that you consider critical for Essex, let me know and we'll get it slotted for RC1: https://launchpad.net/quantum/+milestone/essex-rc1 (no date set, we will release it when we've fixed all issues identified as critical). If you're looking for the doc changes since the last release, you see see the review here: https://review.openstack.org/#change,4774 . Please give feedback via the review. Congrats to the whole team! Dan -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ -- Mailing list: https://launchpad.net/~netstack Post to : netst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp -- 陈沙克 手机：13661187180 msn：shake.c...@hotmail.com -- Mailing list: https://launchpad.net/~netstack Post to : netst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Netstack] Essex-4 milestone available for Quantum
On Fri, Mar 2, 2012 at 9:48 AM, Debo Dutta (dedutta) dedu...@cisco.comwrote: Did you mean network creation using the dash. Quantum manager works with nova yes, I hope the quantum can manage in Dashboard. Sent from my iPhone On Mar 1, 2012, at 5:45 PM, Shake Chen shake.c...@gmail.com wrote: Hi Now the Dashboard whether can manage the Quantum? And whether the Devstack script can let dashbaord and Quantum working? On Fri, Mar 2, 2012 at 7:49 AM, Dan Wendlandt d...@nicira.com wrote: Hi all, The Essex-4 milestone for Quantum and updated documentation is available at: https://launchpad.net/quantum/essex/essex-4 Lots of great improvements in this release, including three new plugins (Linux Bridge, Nicira NVP, and Ryu Controller) as well as significant updates to the OVS plugin. We also added 1.1 API support to the quantum client, and squashed a good number of bugs. Great work! Equally important, Essex-4 saw a good number of new people making significant contributions to the project in terms of features, code reviews, and testing, which is crucial for the success of the project. Let's keep it up. Now its time to really test both code docs to make sure they are solid for the main Essex release. If there is an issue that you consider critical for Essex, let me know and we'll get it slotted for RC1: https://launchpad.net/quantum/+milestone/essex-rc1 (no date set, we will release it when we've fixed all issues identified as critical). If you're looking for the doc changes since the last release, you see see the review here: https://review.openstack.org/#change,4774 . Please give feedback via the review. Congrats to the whole team! Dan -- ~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~ -- Mailing list: https://launchpad.net/~netstack Post to : netst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp -- 陈沙克 手机：13661187180 msn：shake.c...@hotmail.com -- Mailing list: https://launchpad.net/~netstack Post to : netst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp -- 陈沙克 手机：13661187180 msn：shake.c...@hotmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Essex-4 milestone available for Keystone, Glance, Nova and Horizon
Hi In ubuntu 12.04, pool seem not update . the package still is old, like keystone: http://archive.ubuntu.com/ubuntu/pool/universe/k/keystone/ # apt-cache policy keystone keystone: Installed: (none) Candidate: 2012.1~e4~20120203.1574-0ubuntu2 Version table: 2012.1~e4~20120203.1574-0ubuntu2 0 500 http://cn.archive.ubuntu.com/ubuntu/ precise/universe amd64 Packages On Fri, Mar 2, 2012 at 3:27 AM, Thierry Carrez thie...@openstack.orgwrote: Hi everyone, The last milestone of the Essex cycle is now available for Keystone, Glance, Nova and Horizon. It provides a feature-complete beta of the upcoming 2012.1 release, scheduled for final release on April 5. You can see the full list of new features and fixed bugs, as well as tarball downloads, at: https://launchpad.net/keystone/essex/essex-4 https://launchpad.net/glance/essex/essex-4 https://launchpad.net/nova/essex/essex-4 https://launchpad.net/horizon/essex/essex-4 The work now shifts on testing and preparing our final release candidates. You should target release-critical bugs for each project to their essex-rc1 milestone. we have one month left to make OpenStack 2012.1 rock ! Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- 陈沙克 手机：13661187180 msn：shake.c...@hotmail.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Test Dependencies
Apologies to Maru for the double-email. Left out the list by mistake. When you say non-replay mocking, are you talking about ensuring that a particular function is not called, or replacing a function/whatever with a lambda that doesn't care if it gets called or how often it gets called but still shims out say..a network request or whatever. The first is completely supported by mox and the second is just shimming in a lambda with some extra bookkeeping (which python 2.7/unittest2 makes significantly easier with the addCleanup function). Mark On Thu, Mar 1, 2012 at 5:12 PM, Maru Newby mne...@internap.com wrote: Is there any interest in adding unittest2 to the test dependencies for openstack projects? I have found its enhanced assertions and 'with self.assertRaises' very useful in writing tests. I see there have been past bugs that mentioned unittest2, and am wondering if the reasons for not adopting it still stand. Separately, is the use of mox open to discussion? mock was recently added as a dependency to quantum to perform library patching, which isn't supported by mox as far as I know. The ability to do non-replay mocking is another useful feature of mock. I'm not suggesting that mox be replaced, but am wondering if mock could be an additional dependency and used when the functionality provided by mox falls short. Thanks, Maru ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Test Dependencies
Mark: I think Maru is talking about the distinction between record/replay mocking and action/assertion mocking. In record/replay mocking (e.g., mox) you define the expected behavior *before* executing the code under test (i.e., I expect A, B, and C to happen, now go execute the code under test), and in action/assertion mocking (e.g. mock), you check assertions *after* executing the code under test (i.e., Go execute the code under test. Now check: did A, B, C, happen)? Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com On Mar 1, 2012, at 10:03 PM, Mark Gius wrote: Apologies to Maru for the double-email. Left out the list by mistake. When you say non-replay mocking, are you talking about ensuring that a particular function is not called, or replacing a function/whatever with a lambda that doesn't care if it gets called or how often it gets called but still shims out say..a network request or whatever. The first is completely supported by mox and the second is just shimming in a lambda with some extra bookkeeping (which python 2.7/unittest2 makes significantly easier with the addCleanup function). Mark On Thu, Mar 1, 2012 at 5:12 PM, Maru Newby mne...@internap.com wrote: Is there any interest in adding unittest2 to the test dependencies for openstack projects? I have found its enhanced assertions and 'with self.assertRaises' very useful in writing tests. I see there have been past bugs that mentioned unittest2, and am wondering if the reasons for not adopting it still stand. Separately, is the use of mox open to discussion? mock was recently added as a dependency to quantum to perform library patching, which isn't supported by mox as far as I know. The ability to do non-replay mocking is another useful feature of mock. I'm not suggesting that mox be replaced, but am wondering if mock could be an additional dependency and used when the functionality provided by mox falls short. Thanks, Maru ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
