Re: [Openstack] New code name for networks
Not sure if this has been proposed before or even it is at all feasible, but how about changing the last/first letter? Quantum - QuantuS, QuantuN, Cuantum...? There are a plenty of options to go by. On Mon, May 13, 2013 at 5:28 PM, Monty Taylor mord...@inaugust.com wrote: On 05/13/2013 11:03 AM, Doug Hellmann wrote: On Sat, May 11, 2013 at 5:48 PM, Anne Gentle a...@openstack.org mailto:a...@openstack.org wrote: On Sat, May 11, 2013 at 3:12 PM, Monty Taylor mord...@inaugust.com mailto:mord...@inaugust.com wrote: On 05/11/2013 04:07 PM, Asher Newcomer wrote: Or even better, just continue to call it openstack networking. The code names only serve to confuse the uninitiated. They needlessly steepen the learning curve and slow uptake. The problem with OpenStack Networking (or getting rid of codenames) is seen with pre-incubation-incubation-integrated cycle. A project cannot call itself OpenStack Foo until it actually _is_ openstack foo. So any new project by necessity has to start off as something else. But - if we then require them to drop that name and become openstack foo when they become incubated or integrated, then we've got what's become a stable project with a decent amount of contributors renaming itself. Every. Time. The code names aren't just cute. I kind of wish they were, because it would make several things much easier if we could just ditch them and do a pure openstack. code namespace. But the reality is that it gets really really tricky to deal with a bunch of things if they go away. I told Monty and the TC this at the Summit (sorry I couldn't attend the session about code names). I find this trickiness a weak argument in the face of the invented names that are getting to be as bad as U.S. pharmaceuticals. Plus it forces us to put a lookup table in the docs forever. [1] Let's find a process for naming that meets a few reqs: - describes the service - goes through a legal review - enables new eyes to understanding it by reading the English word that the service represents (that can be translated into a meaningful word in other languages) If we have to preface with Stackforge to indicate pre-incubation, that's fine. Use Incubating or some such to indicate incubation. Meaningful words have meaning. +1 Use a namespace package openstack then each project has a unique package under that for their meaningfully named package (compute, networking, etc.). We only have to rename projects if they start out with bad names to begin with. Projects that want to be integrated should be developing on stackforge and using the openstack namespace package. It's just logically infeasible. If we were to make that choice, I'm pretty sure we'd have to stop everything that everyone is doing and just deal the fallout from doing it. In any case - we did have a session on this at the summit, and we did lay out a strategy for moving forward. The etherpad is here https://etherpad.openstack.org/ProjectsReNaming tl;dr - we are going to rename quantum to a new codename, and we are going to do our best as a community to lessen the external usage of our codenames. I acknowledge we still have to indicate what commands, daemon names, and so on are related to a particular service. That issue is also fixable with some resources and effort and pays off in easier adoption and understanding. The unified command line project will resolve the command issue because all commands will be openstack $noun $verb (end users shouldn't have to know which OpenStack component owns a resource in order to operate on it via the command line). Daemon startup scripts could use a similar framework, or just a naming convention (openstack-compute-api, openstack-network-api, etc.). I agree - having the unified command line client will be very helpful to lessening our externally-facing usages of code names. Doug Anne 1. http://docs.openstack.org/grizzly/openstack-compute/install/yum/content/terminology-codenames.html On May 11, 2013 3:59 PM, Davanum Srinivas dava...@gmail.com mailto:dava...@gmail.com mailto:dava...@gmail.com mailto:dava...@gmail.com wrote: Lattice -- dims On Sat, May 11, 2013 at 3:52 PM, Mark Turner m...@amerine.net mailto:m...@amerine.net mailto:m...@amerine.net mailto:m...@amerine.net wrote: Tubes ;-) On Sat, May
Re: [Openstack] Nova different sr
Hi, If I understand your request correctly, say you have two storage backends with different QoS and you want to use both of them in your OpenStack/XCP deployment, what you can do is: 1) create SR1 for XCP1 that maps to storage array at QoS1 1a) configure the compute domU for XCP1 to point to SR1, by specifying sr_matching_filter in your nova.conf accordingly. 2) create SR2 for XCP2 that maps to storage array at QoS2 2a) configure the compute domU for XCP2 to point to SR2, by specifying sr_matching_filter in your nova.conf accordingly. You can find more details here: http://wiki.openstack.org/XenServer/NovaFlags Obviously this can be extended to multiple nodes; then you can use the CLI/scheduler filters to redirect the create request to the right host. That is one way, but there are a few others like or compute extra capabilities (Essex) or general host aggregates (Folsom+) Hope this helps, Armando On Fri, Nov 2, 2012 at 9:34 AM, Egoitz Aurrekoetxea Aurre ego...@ramattack.net wrote: Or unless… If I had to use forcibly the same storage…. for all vm provisioned in a single nova-compute…. is it anyway of saying Openstack to create a vm in a nova-compute or another one… depending on the storage attached to the nova-compute's dom0?? El 02/11/2012, a las 10:25, Egoitz Aurrekoetxea Aurre ego...@ramattack.net escribió: Good morning, Perhaps I have not explained properly…. I have different IBM arrays whose disks are disks of different speeds… and wanted to have the possibility of provisioning vm on different speed storages for example…. Could this be possible??… I'm using XCP (1.5, 1.1 and 1.6 versions so I could test it in all of them)… Anne the link you provided me, although has important information… does not answer my question… Sorry… Best regards, El 01/11/2012, a las 15:35, Anne Gentle a...@openstack.org escribió: Hi Egoitz - This topic would probably help answer your question: http://docs.openstack.org/trunk/openstack-compute/install/yum/content/terminology-storage.html Anne On Wed, Oct 31, 2012 at 4:29 PM, Egoitz Aurrekoetxea Aurre ego...@ramattack.net wrote: Good night, Could anyone know if it's possible to use different nfs servers or different storages for launching instances in Openstack? Anyone knows about this please? Best regards, Egoirz Aurrekoetxea Aurre ego...@ramattack.net Sent from my smartphone El 29/10/2012, a las 16:13, Egoitz Aurrekoetxea Aurre ego...@ramattack.net escribió: Good afternoon, Is it possible for Nova to deploy vm in different storages?? rather than just use the storage which matches sr_matching_filter parameter?? Best regards, ___ 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 ___ 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] Nova different sr
Egoirz, On Fri, Nov 2, 2012 at 6:29 PM, Egoitz Aurrekoetxea Aurre ego...@ramattack.net wrote: Good afternoon Armando, Thanks a lot for you're answer. Yes basically I want to setup a virtual housing service in the way you can create a machine in sas or sata storage for example. If each nova-compute should point to just one sr (storage kind) of xcp it would be one or the other one (in this example... sas or sata)... Ok then. So you mean the right way of doing this with Openstack is to basically have different nova-computes pointing to different sr and sharing the other properties... Have I understand properly?? That's not exactly what I meant, especially in relation to what is _right_ in OpenStack; I was providing input in relation to the use of the flag you mentioned. Actually, if you want to support storage at different levels of QoS, Cinder is another project worth looking at. http://wiki.openstack.org/Cinder A. In the last two paragraph I assume you're just talking about load balancing... Isn't it?? Where did you get that? No I wasn't ;) Very thankful for you're time. Regards, Egoirz Aurrekoetxea Aurre ego...@ramattack.net Sent from my smartphone El 02/11/2012, a las 18:47, Armando Migliaccio amigliac...@internap.com escribió: Hi, If I understand your request correctly, say you have two storage backends with different QoS and you want to use both of them in your OpenStack/XCP deployment, what you can do is: 1) create SR1 for XCP1 that maps to storage array at QoS1 1a) configure the compute domU for XCP1 to point to SR1, by specifying sr_matching_filter in your nova.conf accordingly. 2) create SR2 for XCP2 that maps to storage array at QoS2 2a) configure the compute domU for XCP2 to point to SR2, by specifying sr_matching_filter in your nova.conf accordingly. You can find more details here: http://wiki.openstack.org/XenServer/NovaFlags Obviously this can be extended to multiple nodes; then you can use the CLI/scheduler filters to redirect the create request to the right host. That is one way, but there are a few others like or compute extra capabilities (Essex) or general host aggregates (Folsom+) Hope this helps, Armando On Fri, Nov 2, 2012 at 9:34 AM, Egoitz Aurrekoetxea Aurre ego...@ramattack.net wrote: Or unless… If I had to use forcibly the same storage…. for all vm provisioned in a single nova-compute…. is it anyway of saying Openstack to create a vm in a nova-compute or another one… depending on the storage attached to the nova-compute's dom0?? El 02/11/2012, a las 10:25, Egoitz Aurrekoetxea Aurre ego...@ramattack.net escribió: Good morning, Perhaps I have not explained properly…. I have different IBM arrays whose disks are disks of different speeds… and wanted to have the possibility of provisioning vm on different speed storages for example…. Could this be possible??… I'm using XCP (1.5, 1.1 and 1.6 versions so I could test it in all of them)… Anne the link you provided me, although has important information… does not answer my question… Sorry… Best regards, El 01/11/2012, a las 15:35, Anne Gentle a...@openstack.org escribió: Hi Egoitz - This topic would probably help answer your question: http://docs.openstack.org/trunk/openstack-compute/install/yum/content/terminology-storage.html Anne On Wed, Oct 31, 2012 at 4:29 PM, Egoitz Aurrekoetxea Aurre ego...@ramattack.net wrote: Good night, Could anyone know if it's possible to use different nfs servers or different storages for launching instances in Openstack? Anyone knows about this please? Best regards, Egoirz Aurrekoetxea Aurre ego...@ramattack.net Sent from my smartphone El 29/10/2012, a las 16:13, Egoitz Aurrekoetxea Aurre ego...@ramattack.net escribió: Good afternoon, Is it possible for Nova to deploy vm in different storages?? rather than just use the storage which matches sr_matching_filter parameter?? Best regards, ___ 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
Re: [Openstack] Regular XenAPI Meeting
I'd be interest to join too. Shall we use a wiki page to collate names and affiliations of people interested (there's a Launchpad group set up by the way - https://launchpad.net/~openstack-xenapi), as well as meeting details? Thanks, Armando On Tue, Apr 24, 2012 at 3:32 PM, Alan Kavanagh alan.kavan...@ericsson.com wrote: Hi John +1 would be interested for monthly meeting. Time is ok. Alan From: openstack-bounces+alan.kavanagh=ericsson@lists.launchpad.net [mailto:openstack-bounces+alan.kavanagh=ericsson@lists.launchpad.net] On Behalf Of John Garbutt Sent: April-23-12 1:21 PM To: openstack@lists.launchpad.net Subject: [Openstack] Regular XenAPI Meeting Hi, Are people keen for a XenAPI virt layer meetup on IRC every month? I have added a suggested time to the wiki, as a starting point: Monthly, second Wednesday at 17:00 UTC Does that seem a reasonable time for those that want to attend? It can be more frequent if we find that useful. I don’t want to detract from the other meetings, but it would be good to keep all of us working on the XenAPI layer in regular contact. Cheers, John ___ 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] Install instance failed on xenserver 6.0.2
1.3GB is more than enough. When you get that message, usually space has already dried up, or there is a problem authenticating with xenapi. Check that: xenapi_connection_url xenapi_connection_password are set correctly, and that you can reach dom0 from your devstack instance. Have a look at your localrc, xenrc, and nova.conf, see if you can find anything wrong with them. Hope this help! Armando On Thu, Apr 12, 2012 at 5:03 AM, Yi Sun beyo...@gmail.com wrote: Hi, I used devstack to install openstack on my xenserver 6.0.2. I followed the video found in this link http://wiki.openstack.org/XenServer/DevStack. After installation, I can access dashboard. But I failed to launch an instance. I tried to launch image tty, after launching, the instance status field shows Error and there has no new VM showing up in my xencenter. I did a ps ax on my domU VM, I see following nova processes: stack@ALLINONE:~/nova/bin$ ps ax | grep nova 5246 pts/6 S+ 0:02 python /opt/stack/nova/bin/nova-api 5325 pts/8 S+ 0:03 python /opt/stack/nova/bin/nova-cert 5346 pts/9 S+ 0:03 python /opt/stack/nova/bin/nova-volume 5371 pts/10 S+ 0:03 python /opt/stack/nova/bin/nova-network 5426 pts/11 S+ 0:03 python /opt/stack/nova/bin/nova-scheduler 5457 pts/12 S+ 0:00 python ./utils/nova-novncproxy --config-file /etc/nova/nova.conf --web . 5477 pts/13 S+ 0:00 python ./bin/nova-xvpvncproxy --config-file /etc/nova/nova.conf 5497 pts/14 S+ 0:03 python ./bin/nova-consoleauth 5537 pts/16 S+ 0:00 python /opt/stack/nova/bin/nova-objectstore I'm not seeing nova-compute running. So I tried to start it manually, Then I got errors attached in later section. Can someone help to take a look to see if I have missed anything during the installation? Also, is there a way to see find more debug information when failed to launch a instance? BTW-- I checked Dom0, I have 1.3G free space, is that enough to run nova-compute? Thanks Yi 012-04-12 03:42:33 CRITICAL nova [-] Unable to log in to XenAPI (is the Dom0 disk full?) 2012-04-12 03:42:33 TRACE nova Traceback (most recent call last): 2012-04-12 03:42:33 TRACE nova File ./nova-compute, line 47, in module 2012-04-12 03:42:33 TRACE nova server = service.Service.create(binary='nova-compute') 2012-04-12 03:42:33 TRACE nova File /opt/stack/nova/nova/service.py, line 272, in create 2012-04-12 03:42:33 TRACE nova periodic_fuzzy_delay=periodic_fuzzy_delay) 2012-04-12 03:42:33 TRACE nova File /opt/stack/nova/nova/service.py, line 167, in __init__ 2012-04-12 03:42:33 TRACE nova self.manager = manager_class(host=self.host, *args, **kwargs) 2012-04-12 03:42:33 TRACE nova File /opt/stack/nova/nova/compute/manager.py, line 198, in __init__ 2012-04-12 03:42:33 TRACE nova utils.import_object(compute_driver), 2012-04-12 03:42:33 TRACE nova File /opt/stack/nova/nova/utils.py, line 90, in import_object 2012-04-12 03:42:33 TRACE nova return cls() 2012-04-12 03:42:33 TRACE nova File /opt/stack/nova/nova/virt/connection.py, line 76, in get_connection 2012-04-12 03:42:33 TRACE nova conn = xenapi_conn.get_connection(read_only) 2012-04-12 03:42:33 TRACE nova File /opt/stack/nova/nova/virt/xenapi_conn.py, line 144, in get_connection 2012-04-12 03:42:33 TRACE nova return XenAPIConnection(url, username, password) 2012-04-12 03:42:33 TRACE nova File /opt/stack/nova/nova/virt/xenapi_conn.py, line 152, in __init__ 2012-04-12 03:42:33 TRACE nova self._session = XenAPISession(url, user, pw) 2012-04-12 03:42:33 TRACE nova File /opt/stack/nova/nova/virt/xenapi_conn.py, line 491, in __init__ 2012-04-12 03:42:33 TRACE nova url = self._create_first_session(url, user, pw, exception) 2012-04-12 03:42:33 TRACE nova File /opt/stack/nova/nova/virt/xenapi_conn.py, line 500, in _create_first_session 2012-04-12 03:42:33 TRACE nova session.login_with_password(user, pw) 2012-04-12 03:42:33 TRACE nova File /usr/local/lib/python2.7/dist-packages/XenAPI.py, line 182, in lambda 2012-04-12 03:42:33 TRACE nova return lambda *params: self._login(name, params) 2012-04-12 03:42:33 TRACE nova File /usr/local/lib/python2.7/dist-packages/XenAPI.py, line 148, in _login 2012-04-12 03:42:33 TRACE nova result = _parse_result(getattr(self, 'session.%s' % method)(*params)) 2012-04-12 03:42:33 TRACE nova File /usr/lib/python2.7/xmlrpclib.py, line 1224, in __call__ 2012-04-12 03:42:33 TRACE nova return self.__send(self.__name, args) 2012-04-12 03:42:33 TRACE nova File /usr/lib/python2.7/xmlrpclib.py, line 1575, in __request 2012-04-12 03:42:33 TRACE nova verbose=self.__verbose 2012-04-12 03:42:33 TRACE nova File /usr/lib/python2.7/xmlrpclib.py, line 1264, in request 2012-04-12 03:42:33 TRACE nova return self.single_request(host, handler, request_body, verbose) 2012-04-12 03:42:33 TRACE nova File /usr/lib/python2.7/xmlrpclib.py, line
Re: [Openstack] OpenStack immaturity
Another perspective worth considering is immaturity vs growth. Are there enough progresses being made? When problems are identified, are these solved swiftly and effectively? I think the people involved in the OpenStack community do and have done a great job in this regard, and should be praised rather than bashed. I personally think that talking about immaturity does not address the major question one should ask: assess if the platform fit the bill for whatever goals/requirements one has. So going back to Sébastien Han's question: what are you looking for in OpenStack? My 2c A. On Wed, Apr 4, 2012 at 9:48 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: Maybe it would be more interesting, instead of getting on the defensive to instead start asking what people think is broken or is immature and fix those areas. Push forward, get peoples feelings about it, and take it as constructive input. If people think its immature, ask for why and then fix those points... -Josh On 4/4/12 1:05 PM, Jay Payne lett...@gmail.com wrote: There are many projects rolled up into the thing called OpenStack. Nova is only one of them and is the one that most people are talking about when they say OpenStack. This does a huge disservice to the other projects especially Swift. It's very frustrating to see the other projects all painted with the Nova brush. On Wed, Apr 4, 2012 at 1:25 PM, Ryan Lane rl...@wikimedia.org wrote: According to the statement of this article from Gartner group http://blogs.gartner.com/lydia_leong/2012/04/03/citrix-cloudstack-openstack-and-the-war-for-open-source-clouds/ Openstack is a highly immature platform. But why? What's make Openstack so immature? Any comments on that? Thank you in advance :) I agree that it's an immature platform. That said, it's also a very young platform and isn't that to be expected? There's a number of things that need to be fixed before I'd ever recommend Nova's use in production: 1. There's no upgrade path currently. Upgrading requires fairly substantial downtime. 2. Live migration is broken. Utterly. 3. Every release fixes so many things that it's really important to upgrade every time; however, only one release will likely be supported every Ubuntu LTS release, meaning you're either stuck with a really old (likely broken) version of nova, or you're stuck will a very likely unstable version of Ubuntu. This will be easier over time, when nova is more stable and has less bugs, but it's incredibly painful right now. That said, I feel OpenStack's strengths greatly outweigh its immatureness. I ran a private cloud at my last organization using a VMWare ESXi cluster. It was more mature, upgrades worked appropriately, live migration was solid, etc. I had (and still have) the choice to run VMWare for my current project and am extremely happy with my choice of OpenStack. The flexibility provided by the platform and my ability to contribute to its future make its immaturity a non-concern. Every release gets closer and closer to a stability point I'm comfortable with. This article isn't bad news. In fact, I'd say it shows that competitors see OpenStack as a fairly major threat. We should be celebrating this ;). - Ryan ___ 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] Limit flavors to specific hosts
On Tue, Apr 3, 2012 at 7:10 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: On Apr 3, 2012, at 6:45 AM, Day, Phil wrote: Hi John, Maybe the problem with host aggregates is that it too quickly became something that was linked to hypervisor capability, rather than being the more general mechanism of which one form of aggregate could be linked to hypervisor capabilities ? The host aggregate model is not tied to no hypervisor-dependent detail, it's a group of hosts with metadata linked to it. As far as the the functionality around it, that can evolve to make it work as you expected it to work. If I understand it correctly, you'd not be interested in xenapi (whose implementation is wrapped around the concept of pool), and as far as KVM is concerned, this is still a blank canvas. As for the scheduler, as most things in Nova, you can write a new one (that's host-aggregate aware), or you can extend an existing one to make sure it understands the metadata related to a host belonging to an aggregate. The latter, in particular, was not done in the Essex timeframe for lack of time ;( Should we have a “host aggregates 2.0” session at the Design Summit ? I am all in for a host aggregate 2.0 so to speak, or just the continuation of the work that was started; at first I got the impression that we were going to write new abstraction/functionality from scratch just because the one that already existed did not fit the bill...I am glad I was wrong :) + 1 I think the primary use case is associating metadata with groups of hosts that can be interpreted by the scheduler. Obviously, this same metadata can be used to create pools/etc. in the hypervisor, but we can't forget about the scheduler. Modifying flags on the hosts for capabilities is ugly. 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 ___ 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] error on nova-compute on domU on xen
check you have XenAPI installed on your system. 'sudo easy_install xenapi' should suffice. On Thu, Mar 15, 2012 at 5:00 PM, Eduardo Nunes eduardo.ke...@gmail.com wrote: got this error on log, 2012-03-15 16:52:33,809 ERROR nova.compute.manager [-] Unable to load the virtualization driver: No module named XenAPI my nova-compute version diablo 2011.3 ___ 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
-Original Message- From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack- bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On Behalf Of Jay Pipes Sent: 02 March 2012 15:17 To: openstack@lists.launchpad.net Subject: Re: [Openstack] eventlet weirdness On 03/02/2012 05:34 AM, Day, Phil wrote: In our experience (running clusters of several hundred nodes) the DB performance is not generally the significant factor, so making its calls non- blocking gives only a very small increase in processing capacity and creates other side effects in terms of slowing all eventlets down as they wait for their turn to run. Yes, I believe I said that this was the case at the last design summit -- or rather, I believe I said is there any evidence that the database is a performance or scalability problem at all? That shouldn't really be surprising given that the Nova DB is pretty small and MySQL is a pretty good DB - throw reasonable hardware at the DB server and give it a bit of TLC from a DBA (remove deleted entries from the DB, add indexes where the slow query log tells you to, etc) and it shouldn't be the bottleneck in the system for performance or scalability. ++ We use the python driver and have experimented with allowing the eventlet code to make the db calls non-blocking (its not the default setting), and it works, but didn't give us any significant advantage. Yep, identical results to the work that Mark Washenberger did on the same subject. For example in the API server (before we made it properly multi-threaded) By properly multi-threaded are you instead referring to making the nova-api server multi-*processed* with eventlet greenthread pools in each process? i.e. The way Swift (and now Glance) works? Or are you referring to a different approach entirely? with blocking db calls the server was essentially a serial processing queue - each request was fully processed before the next. With non-blocking db calls we got a lot more apparent concurrencybut only at the expense of making all of the requests equally bad. Yep, not surprising. Consider a request takes 10 seconds, where after 5 seconds there is a call to the DB which takes 1 second, and three are started at the same time: Blocking: 0 - Request 1 starts 10 - Request 1 completes, request 2 starts 20 - Request 2 completes, request 3 starts 30 - Request 3 competes Request 1 completes in 10 seconds Request 2 completes in 20 seconds Request 3 completes in 30 seconds Ave time: 20 sec Non-blocking 0 - Request 1 Starts 5 - Request 1 gets to db call, request 2 starts 10 - Request 2 gets to db call, request 3 starts 15 - Request 3 gets to db call, request 1 resumes 19 - Request 1 completes, request 2 resumes 23 - Request 2 completes, request 3 resumes 27 - Request 3 completes Request 1 completes in 19 seconds (+ 9 seconds) Request 2 completes in 24 seconds (+ 4 seconds) Request 3 completes in 27 seconds (- 3 seconds) Ave time: 20 sec So instead of worrying about making db calls non-blocking we've been working to make certain eventlets non-blocking - i.e. add sleep(0) calls to long running iteration loops - which IMO has a much bigger impact on the performance of the apparent latency of the system. Yep, and I think adding a few sleep(0) calls in various places in the Nova codebase (as was recently added in the _sync_power_states() periodic task) is an easy and simple win with pretty much no ill side-effects. :) I'd be cautious to say that no ill side-effects were introduced. I found a race condition right in the middle of sync_power_states, which I assume was exposed by breaking the task deliberately. Curious... do you have a list of all the places where sleep(0) calls were inserted in the HP Nova code? I can turn that into a bug report and get to work on adding them... All the best, -jay Phil -Original Message- From: openstack-bounces+philip.day=hp@lists.launchpad.net [mailto:openstack-bounces+philip.day=hp@lists.launchpad.net] On Behalf Of Brian Lamar Sent: 01 March 2012 21:31 To: openstack@lists.launchpad.net Subject: 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
Re: [Openstack] eventlet weirdness
I knew you'd say that :P There you go: https://bugs.launchpad.net/nova/+bug/944145 Cheers, Armando -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: 02 March 2012 16:22 To: Armando Migliaccio Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] eventlet weirdness On 03/02/2012 10:52 AM, Armando Migliaccio wrote: I'd be cautious to say that no ill side-effects were introduced. I found a race condition right in the middle of sync_power_states, which I assume was exposed by breaking the task deliberately. Such a party-pooper! ;) Got a link to the bug report for me? Thanks! -jay ___ 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
-Original Message- From: Eric Windisch [mailto:e...@cloudscaling.com] Sent: 02 March 2012 19:04 To: Joshua Harlow Cc: Armando Migliaccio; Jay Pipes; openstack Subject: Re: [Openstack] eventlet weirdness The problem is that unless you sleep(0), eventlet only switches context when you hit a file descriptor. As long as python coroutines are used, we should put sleep(0) where-ever it is expected that there will be a long-running loop where file descriptors are not touched. As noted elsewhere in this thread, MySQL file descriptors don't count, they're not coroutine friendly. The premise is that cpus are pretty fast and get quickly from one call of a file descriptor to another, that the blocking of these descriptors is what a CPU most waits on, and this is an easy and obvious place to switch coroutines via monkey-patching. That said, it shouldn't be necessary to sprinkle sleep(0) calls. They should be strategically placed, as necessary. I agree, but then the whole assumption of adopting eventlet to simplify the programming model is hindered by the fact that one has to think harder to what is doing...Nova could've kept Twisted for that matter. The programming model would have been harder, but at least it would have been cleaner and free from icky patching (that's my own opinion anyway). race-conditions around coroutine switching sounds more like thread-safety issues... Yes. There is a fine balance to be struck here: do you let potential races appear in your system and deal with them on a case-by-case base, or do you introduce mutexes and deal with potential inefficiency and/or deadlocks? I'd rather go with the former here. -- Eric Windisch On Friday, March 2, 2012 at 1:35 PM, Joshua Harlow wrote: Re: [Openstack] eventlet weirdness Does anyone else feel that the following seems really “dirty”, or is it just me. “adding a few sleep(0) calls in various places in the Nova codebase (as was recently added in the _sync_power_states() periodic task) is an easy and simple win with pretty much no ill side-effects. :)” Dirty in that it feels like there is something wrong from a design point of view. Sprinkling “sleep(0)” seems like its a band-aid on a larger problem imho. But that’s just my gut feeling. :-( On 3/2/12 8:26 AM, Armando Migliaccio armando.migliac...@eu.citrix.com wrote: I knew you'd say that :P There you go: https://bugs.launchpad.net/nova/+bug/944145 Cheers, Armando -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: 02 March 2012 16:22 To: Armando Migliaccio Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] eventlet weirdness On 03/02/2012 10:52 AM, Armando Migliaccio wrote: I'd be cautious to say that no ill side-effects were introduced. I found a race condition right in the middle of sync_power_states, which I assume was exposed by breaking the task deliberately. Such a party-pooper! ;) Got a link to the bug report for me? Thanks! -jay ___ 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 (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] Remove Zones code - FFE
-1 for ServerGroup because in the OSAPI terminology Server is a guest instance rather than a physical host. I assume that the relationship between zone and availability zone will still exist (and I remind you that host-aggregates have been coming along to). So you have: ?? -- Availability Zones -- Host Aggregates How about ?? == Deployment [Slice | Area | or Section] I know that Region may not be liked by some people, but that is good too. Armando -Original Message- From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack- bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On Behalf Of Martin Paulo Sent: 14 February 2012 23:34 To: Jay Pipes Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE ServerGroup gets my vote at the moment: it's a term that has an overloaded meaning (as far as I know) Martin On 15 February 2012 06:25, Jay Pipes jaypi...@gmail.com wrote: -1 on shard b/c of database terminology. -1 on cluster because of HPC and database terminology. Zone was originally used because it is general -- referring to merely a collection of hosts or other zones and not having a geographic connotation like Region does. Other possibilities: * Container (not recommended, as it is overloaded with Solaris or Linux container virtualization) * ServerGroup * HostGroup * Group * Collection If Zone isn't used, I suppose I would prefer ServerGroup -jay On 02/13/2012 08:45 PM, Yun Mao wrote: agreed.. -1 on shard, +1 on cluster Yun On Mon, Feb 13, 2012 at 7:59 PM, Martin Paulomartin.pa...@gmail.com wrote: Please not 'shards' Sharding as a concept is so intertwined with databases IMHO that it will serve to confuse even more. Why not 'cluster'? Martin On 13 February 2012 09:50, Chris Behrenscbehr...@codestud.com wrote: Sorry, I'm late. Really getting down to the wire here. :) I've thrown up a version here: https://review.openstack.org/#change,4062 I've not functionally tested it yet, but there's really good test coverage for the zones service itself. I also have added a test_compute_zones which tests that all of the compute tests pass while using the new ComputeZonesAPI class. There's a couple bugs I note in the review and then I think I'm missing pushing some instance updates to the top in libvirt code. And missing an update for instance deletes in the compute manager. Going to hit those up today and finish this off. One other comment: It's been suggested we not call this stuff 'Zones' anymore. It gets confused with availability zones and so forth. Since this is really a way to shard nova, it has been suggested to call this 'Shards'. :) Not sure I dig that name completely, although it makes sense. Thoughts? - Chris On Feb 9, 2012, at 10:29 AM, Leandro Reox wrote: Awesome Chris !!! Lean On Thu, Feb 9, 2012 at 3:26 PM, Alejandro Comisarioalejandro.comisa...@mercadolibre.com wrote: Niceee !! Alejandro. On 02/09/2012 02:02 PM, Chris Behrens wrote: I should be pushing something up by end of day... Even if it's not granted an FFE, I'll have a need to keep my branch updated and working, so I should at least always have a branch pushed up to a github account somewhere until F1 opens up. So, I guess worst case... there'll be a branch somewhere for you to play with. :) - Chris On Feb 8, 2012, at 3:21 PM, Tom Fifield wrote: Just raising another deployment waiting on this new Zone implementation - we currently have 2000 cores sitting idle in another datacentre that we can use better if this is done. How can we help? ;) Regards, Tom On 02/08/2012 07:30 PM, Ziad Sawalha wrote: We were working on providing the necessary functionality in Keystone but stopped when we heard of the alternative solution. We could resume the conversation about what is needed on the Keystone side and implement if needed. Z From: Sandy Walsh sandy.wa...@rackspace.com mailto:sandy.wa...@rackspace.com Date: Thu, 2 Feb 2012 01:49:58 + To: Joshua McKenty jos...@pistoncloud.com mailto:jos...@pistoncloud.com , Vishvananda Ishaya vishvana...@gmail.commailto:vishvana...@gmail.com Cc: openstack@lists.launchpad.net mailto:openstack@lists.launchpad.netopenstack@lists.launchp ad.net mailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Understood, timing is everything. I'll let Chris talk about expected timing for the replacement. From a deployers side, nothing would really change, just some configuration options ... but a replacement should be available. I'm sure we could get it working pretty easily. The Keystone integration was the biggest pita. I can keep this branch fresh with trunk for when we're ready to pull
Re: [Openstack] Remove Zones code - FFE
I am a bit lost...what has size got to do with relationship? -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: 15 February 2012 14:36 To: Gabe Westmaas Cc: Armando Migliaccio; Martin Paulo; openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE On 02/15/2012 09:13 AM, Gabe Westmaas wrote: I think this thing we call zones is fundamentally different from an Availability Zone or a Host Aggregate. An Availability Zone is about redundancy, a Host Aggregate is about capabilities, and a Zone is about infrastructure performance. That is an awesome way of describing the differences. I could easily imagine an Availability Zone larger than a Zone, and vice versa, thus I want to be cautious about talking about the relationships between them. Very true. I would disagree with this, maybe if you could elaborate a bit more... To me an availability zone is a partition of the infrastructure that can fail as a whole. I increase the reliability of my cloud app by deploying across multiple availability zones. To this aim, I would keep an availability zone as small as possible. A zone is for load balancing on a large (geographical) scale. I can scale my cloud app horizontally by deploying it in multiple zones. This way of arranging a cloud app would imply the following options: a) zones contains availability zones b) zones and availability zones are arranged in a grid but to me a) is way easier to understand. And I think host aggregates are way too powerful an idea to keep inside either of those boxes as well. Perhaps, yes. In the new implementation we don't have entire openstack deployments - we have parts of an openstack deployment. Hypervisors, DB, and the queuing service are all that are the new Zones. Words that make the most sense to me are words that talk about that split rather than words that talk about location or aggregation. Eventually, though, even the hypervisor wouldn't be unique in a Zone, right? HostAggregates would take over the role of exposing virtualization capacity and abilities... so really, a Zone is just the partition of DB and MQ that services a segment of HostAggregates? Slice, section, segment, sector, division, partition - something along those lines. Slice is overloaded from Slicehost... Partition is fairly overloaded from filesystem and database terminology... Segment has network connotations... Sector has disk/drive connotations... Perhaps division is the only one left out of the above that seems to fit the bill? :) -jay Gabe -Original Message- From: openstack-bounces+gabe.westmaas=rackspace@lists.launchpad.net [mailto:openstack-bounces+gabe.westmaas=rackspace.com@lists.launchpad. net] On Behalf Of Armando Migliaccio Sent: Wednesday, February 15, 2012 6:36 AM To: Martin Paulo; Jay Pipes Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE -1 for ServerGroup because in the OSAPI terminology Server is a guest instance rather than a physical host. I assume that the relationship between zone and availability zone will still exist (and I remind you that host-aggregates have been coming along to). So you have: ??-- Availability Zones-- Host Aggregates How about ?? == Deployment [Slice | Area | or Section] I know that Region may not be liked by some people, but that is good too. Armando -Original Message- From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.ne openstack-bounces+t [mailto:openstack- bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On bounces+Behalf Of Martin Paulo Sent: 14 February 2012 23:34 To: Jay Pipes Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE ServerGroup gets my vote at the moment: it's a term that has an overloaded meaning (as far as I know) Martin On 15 February 2012 06:25, Jay Pipesjaypi...@gmail.com wrote: -1 on shard b/c of database terminology. -1 on cluster because of HPC and database terminology. Zone was originally used because it is general -- referring to merely a collection of hosts or other zones and not having a geographic connotation like Region does. Other possibilities: * Container (not recommended, as it is overloaded with Solaris or Linux container virtualization) * ServerGroup * HostGroup * Group * Collection If Zone isn't used, I suppose I would prefer ServerGroup -jay On 02/13/2012 08:45 PM, Yun Mao wrote: agreed.. -1 on shard, +1 on cluster Yun On Mon, Feb 13, 2012 at 7:59 PM, Martin Paulomartin.pa...@gmail.com wrote: Please not 'shards' Sharding as a concept is so intertwined with databases IMHO that it will serve to confuse even more. Why not 'cluster'? Martin On 13 February 2012 09:50, Chris Behrenscbehr...@codestud.com wrote: Sorry, I'm
Re: [Openstack] Remove Zones code - FFE
See comments inline. -Original Message- From: Mark Washenberger [mailto:mark.washenber...@rackspace.com] Sent: 15 February 2012 15:51 To: Gabe Westmaas Cc: Armando Migliaccio; Jay Pipes; openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE Gabe Westmaas gabe.westm...@rackspace.com said: I think both these approaches are valid, and speaks to the fact that there isn't really a relationship between the two concepts. Absolutely. An availability zone is about partitioning user instance infrastructure and exposing that partitioning scheme to the api user for reliability purposes. What we're talking about with zones is partitioning the nova *control* infrastructure (nova-api, nova-compute, database, rabbit, etc) in a way that enables scale. And we most likely do not expose these scale-partitioning details to the api user. I think you touched the crucial point here: what is exposed to the user and what not. Reading: http://wiki.openstack.org/MultiClusterZones#Design one would think that zones is a concept exposed to end users. You're saying otherwise; Is it just my misunderstanding or the wiki page is out of sync with the latest developments? If zones are not going to be exposed to the users, what will? Just availability zones? The two concepts seem wholly independent to me, which is one reason why I think we should ditch the term zone. Gabe Westmaas gabe.westm...@rackspace.com said: On 2/15/12 9:48 AM, Armando Migliaccio armando.migliac...@eu.citrix.com wrote: I am a bit lost...what has size got to do with relationship? -Original Message- From: Jay Pipes [mailto:jaypi...@gmail.com] Sent: 15 February 2012 14:36 To: Gabe Westmaas Cc: Armando Migliaccio; Martin Paulo; openstack@lists.launchpad.net Subject: Re: [Openstack] Remove Zones code - FFE On 02/15/2012 09:13 AM, Gabe Westmaas wrote: I think this thing we call zones is fundamentally different from an Availability Zone or a Host Aggregate. An Availability Zone is about redundancy, a Host Aggregate is about capabilities, and a Zone is about infrastructure performance. That is an awesome way of describing the differences. I could easily imagine an Availability Zone larger than a Zone, and vice versa, thus I want to be cautious about talking about the relationships between them. Very true. I would disagree with this, maybe if you could elaborate a bit more... To me an availability zone is a partition of the infrastructure that can fail as a whole. I increase the reliability of my cloud app by deploying across multiple availability zones. To this aim, I would keep an availability zone as small as possible. A zone is for load balancing on a large (geographical) scale. I can scale my cloud app horizontally by deploying it in multiple zones. This way of arranging a cloud app would imply the following options: a) zones contains availability zones b) zones and availability zones are arranged in a grid but to me a) is way easier to understand. I think it all depends on scale. Some very large nova deployments may have an availability zone at the datacenter level, but for infrastructure performance reasons, need to split that up into multiple zones. A datacenter could be considered an availability zone depending on your application - you want to be redundant even if the datacenter goes down. Much smaller deployments may consider a single switch to the bound on an availability zone, and probably don't need to even consider what we call zones until they get to several of those switches. I think both these approaches are valid, and speaks to the fact that there isn't really a relationship between the two concepts. It may mean that we need more options when defining availability zones, but that's for another thread! Gabe And I think host aggregates are way too powerful an idea to keep inside either of those boxes as well. Perhaps, yes. In the new implementation we don't have entire openstack deployments - we have parts of an openstack deployment. Hypervisors, DB, and the queuing service are all that are the new Zones. Words that make the most sense to me are words that talk about that split rather than words that talk about location or aggregation. Eventually, though, even the hypervisor wouldn't be unique in a Zone, right? HostAggregates would take over the role of exposing virtualization capacity and abilities... so really, a Zone is just the partition of DB and MQ that services a segment of HostAggregates? Slice, section, segment, sector, division, partition - something along those lines. Slice is overloaded from Slicehost... Partition is fairly overloaded from filesystem and database terminology... Segment has network connotations... Sector has disk/drive connotations... Perhaps division is the only one
Re: [Openstack] [Nova] Essex dead wood cutting
To the best of my knowledge, the ESXi support is up to date. There may be bugs, but which virt driver is perfect ;)? Sateesh may know more, because he is the main contributor/maintainer from Citrix. However, as Vish pointed out in a previous email, any driver is doomed to rot if: a) no one is deploying OpenStack using the specific driver, thus unveiling potential problems; b) a pool of developers (not necessarily the first committer) keep the code up to date, increase functionality and test coverage (both unit and functional); Clearly both xenapi and libvirt are actively developed and deployed. How about vmwareapi? Anyone? Let's make sure that vmwareapi is not going to be the next one to bite the dust. A. -Original Message- From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack- bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On Behalf Of Thierry Carrez Sent: 02 February 2012 08:53 To: openstack@lists.launchpad.net Subject: Re: [Openstack] [Nova] Essex dead wood cutting Thierry Carrez wrote: Just as Nova enters feature freeze, it sounds like a good moment to consider removing deprecated, known-buggy-and-unmaintained or useless feature code from the Essex tree. Here are my suggestions for removal: - Ajaxterm (unmaintained, security issues, replaced by VNC console) - Hyper-V support (known broken and unmaintained) While we are at it (and since I'm getting used to press coverage), what's the state of the VMWareAPI support ? I knew Hyper-V was not working because bugs were reported against it... but I don't really know how functional vmwareapi actually is. -- 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 ___ 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] [Nova] Essex dead wood cutting
Errata corrige for point b) a pool of developers (not necessarily the first committer) DOES NOT keep the code up to date, AND DOES NOT increase functionality and test coverage (both unit and functional); :) -Original Message- From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack- bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On Behalf Of Armando Migliaccio Sent: 02 February 2012 11:52 To: Thierry Carrez; openstack@lists.launchpad.net Subject: Re: [Openstack] [Nova] Essex dead wood cutting To the best of my knowledge, the ESXi support is up to date. There may be bugs, but which virt driver is perfect ;)? Sateesh may know more, because he is the main contributor/maintainer from Citrix. However, as Vish pointed out in a previous email, any driver is doomed to rot if: a) no one is deploying OpenStack using the specific driver, thus unveiling potential problems; b) a pool of developers (not necessarily the first committer) keep the code up to date, increase functionality and test coverage (both unit and functional); Clearly both xenapi and libvirt are actively developed and deployed. How about vmwareapi? Anyone? Let's make sure that vmwareapi is not going to be the next one to bite the dust. A. -Original Message- From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack- bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On Behalf Of Thierry Carrez Sent: 02 February 2012 08:53 To: openstack@lists.launchpad.net Subject: Re: [Openstack] [Nova] Essex dead wood cutting Thierry Carrez wrote: Just as Nova enters feature freeze, it sounds like a good moment to consider removing deprecated, known-buggy-and-unmaintained or useless feature code from the Essex tree. Here are my suggestions for removal: - Ajaxterm (unmaintained, security issues, replaced by VNC console) - Hyper-V support (known broken and unmaintained) While we are at it (and since I'm getting used to press coverage), what's the state of the VMWareAPI support ? I knew Hyper-V was not working because bugs were reported against it... but I don't really know how functional vmwareapi actually is. -- 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 ___ 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] Host aggregates - FF-Exception request
Hi folks, I am asking for a Feature-Freeze exception for the blueprint https://blueprints.launchpad.net/nova/+spec/host-aggregates. I appreciate that is now late for getting the bulk of this feature into E3, however we are ready to get this feature early in E4. We have got a few reviews in the queue, and we are close to completing them. It was my understanding that E4 was not for big changes (or even API changes), however Host Aggregates is barely touching the core code (actually, it can be argued that is not touching it at all). More importantly, having this stuff in trunk will unblock other features that will help close the gap between KVM and XenAPI. Thanks, Armando ___ 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] Is m1.tiny instance type supported for Xen?
Is this what you're looking for? https://blueprints.launchpad.net/nova/+spec/disk-configuration-parity A. -Original Message- From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack- bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On Behalf Of Alessio Ababilov Sent: 17 January 2012 16:12 To: openstack@lists.launchpad.net Subject: [Openstack] Is m1.tiny instance type supported for Xen? Hi! OpenStack Nova allows to run instances with local_gb = 0 for m1.tiny instance type if libvirt is used. As I see, m1.tiny is not supported when using Xen. Am I right? I think it would be better to unify behavior for different backends. Here are code examples. Generic code allows local_gb == 0 (nova/compute/manager.py): # NOTE(jk0): Since libvirt uses local_gb as a secondary drive, we # need to handle potential situations where local_gb is 0. This is # the default for m1.tiny. if allowed_size_gb == 0: Libvirt backend handles m1.tiny in special way (nova/virt/libvirt/connection.py): if inst_type['name'] == 'm1.tiny' or suffix == '.rescue': size = None Xen backend just checks the size (nova/virt/xenapi/vm_utils.py) @classmethod def _check_vdi_size(cls, context, session, instance, vdi_uuid): size_bytes = cls._get_vdi_chain_size(context, session, vdi_uuid) # FIXME(jk0): this was copied directly from compute.manager.py, let's # refactor this to a common area instance_type_id = instance['instance_type_id'] instance_type = db.instance_type_get(context, instance_type_id) allowed_size_gb = instance_type['local_gb'] allowed_size_bytes = allowed_size_gb * 1024 * 1024 * 1024 LOG.debug(_(image_size_bytes=%(size_bytes)d, allowed_size_bytes= %(allowed_size_bytes)d) % locals()) if size_bytes allowed_size_bytes: LOG.info(_(Image size %(size_bytes)d exceeded instance_type allowed size %(allowed_size_bytes)d) % locals()) raise exception.ImageTooLarge() -- Alessio Ababilov Software Engineer Grid Dynamics ___ 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] Swift on RHEL/CentOS in prod?
What swift version did you run for your experimental campaign? It’s been a long time, but I seem to remember a similar problem; IIRC this was solved after swift 1.4.2 and more precisely with this bug fix: https://bugs.launchpad.net/swift/+bug/794618 HTH A. From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On Behalf Of Rustam Aliyev Sent: 10 January 2012 16:49 To: openstack@lists.launchpad.net Subject: Re: [Openstack] Swift on RHEL/CentOS in prod? Hi Armando, Thanks for sharing your experience. It's interesting to hear that you run 5.5. My problem is Swift performance (only Swift, I wasn't interested in Nova). I couldn't get beyond 6-7 writes/sec with 5 node Swift cluster running on CentOS 5.7 (2.6.18-238.19.1.el5) and with RF=3. After troubleshooting for a couple of weeks, we came to conclusion that CentOS 5.x is not supported. See my explanation here: https://lists.launchpad.net/openstack/msg06303.html Right now decision was made to upgrade to CentOS 6.x, but it will take a while. Did you run any performance tests at all? Would be interesting to see some swift-bench figures if available. Many thanks, Rustam. On 10/01/2012 13:59, Armando Migliaccio wrote: We (Citrix) have used CentOS 5.5 (kernel 2.6.18-194.32.1.el5xen), in small pilot environments. Our choice has fallen on CentOS for reasons that I am not going to bore you with. We are going to switch to Ubuntu not because of performance but primarily because of packaging. What are your concerns? Performance, stability or setup complexities? A. From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.netmailto:openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On Behalf Of Rustam Aliyev Sent: 22 December 2011 11:08 To: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: [Openstack] Swift on RHEL/CentOS in prod? Hi, I was wondering if anyone uses Swift on RHEL/CentOS in production? If yes, which version of RHEL/CentOS you are using? Thanks, Rustam. ___ 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] Host Aggregates ...
Hi Sandy, Thanks for taking the time to read this. My understanding is that a typical Nova deployment would span across multiple zones, that zones may have subzones, and that child zones will have a number of availability zones in them; please do correct me if I am wrong :) That stated, it was assumed that an aggregate will be a grouping of servers within an availability zone (hence the introduction of the extra concept), and would be used to manage hypervisor pools when and if required. This introduces benefits like VM live migration, VM HA and zero-downtime host upgrades. The introduction of hypervisor pools is just the easy way to get these benefits in the short term. Going back to your point, it is possible to match host-aggregates with single-zone that uses capabilities on the implementation level (assumed that it is okay to be unable to represent aggregates as children of availability zones). Nevertheless, I still see zones and aggregates as being different on the conceptual level. What is your view if we went with the approach of implementing an aggregate as a special single-zone that uses capabilities? Would there be a risk of tangling the zone management API a bit? Thanks for feedback! Cheers, Armando -Original Message- From: Sandy Walsh [mailto:sandy.wa...@rackspace.com] Sent: 09 November 2011 21:10 To: Armando Migliaccio Cc: openstack@lists.launchpad.net Subject: Host Aggregates ... Hi Armando, I finally got around to reading https://blueprints.launchpad.net/nova/+spec/host-aggregates. Perhaps you could elaborate a little on how this differs from host capabilities (key-value pairs associated with a service) that the scheduler can use when making decisions? The distributed scheduler doesn't need zones to operate, but will use them if available. Would host-aggregates simply be a single-zone that uses capabilities? Cheers, Sandy ___ 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] Hardware HA
There is a blueprint that touches these aspects: https://blueprints.launchpad.net/nova/+spec/guest-ha This is tailored at use cases where you cannot redesign an existing app. The work is at the early stages, but you are more than welcome to join the effort! Cheers, Armando -Original Message- From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack- bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On Behalf Of Soren Hansen Sent: 10 November 2011 15:51 To: Viacheslav Biriukov Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Hardware HA 2011/11/10 Viacheslav Biriukov v.v.biriu...@gmail.com: Hi all. What are the best practices for HA of the hardware compute-node, and virtual machines. After googling I found matahari, pacemaker-cloud, but nothing about build-in fiches openstack. 1) How do you create such environments? 2) Does it is right way to use pacemaker-cloud with openstack? Is it stable? I'd avoid depending on anything like that altogether. Try to design your application so that it doesn't depend on any one instance being up. It'll work out better in the long run. -- Soren Hansen | http://linux2go.dk/ 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 ___ 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] Dashboard Diablo update
Hi Devin, thanks for this update. Below you mentioned support for managing Nova volumes, floating IPs. Can you tell us a bit more about this? I cannot see a volume section in the dashboard UI, are there specific extensions to pull into the code? Thanks, Armando -Original Message- From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack- bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On Behalf Of Devin Carlen Sent: 01 September 2011 22:18 To: openstack@lists.launchpad.net Subject: [Openstack] Dashboard Diablo update Hey everyone, I wanted to update everyone on where we've made it so far in the Diablo release. First off, along with the Keystone project, the Dashboard project has been promoted to OpenStack core, meaning it is now an officially recognized part of the OpenStack ecosystem. There are a few outstanding things we need to do to fully integrate with existing processes, though we are pretty far along: * Move code reviews from Github to Gerrit * Synch up on packaging efforts * Redouble efforts on documentation * Pick an official codename for the project I'll be sending out a list of codename candidates soon for us to decide on as a community. :) We put a lot of work into Dashboard in the Diablo timeframe. Some of the highlights: * uses OpenStack API instead of EC2 API for underlying calls * full support for Keystone for authentication * support for managing Swift containers and objects * support for managing Quantum networks and ports * support for managing Nova volumes, floating IPs, etc (mostly got feature parity with EC2 API) * a new look and feel * new features for sysadmins * ... and more! There are three phases to a project's life: 1) make it work (austin/bexar) 2) more is better (cactus/diablo) 3) better is more I feel that as a project we've fulfilled our more is better phase, as in having more features is more important than perfecting each piece. During the Essex release, we're going into our better is more phase. We'll be focusing on user experience and interaction design and making this project a world class web application. We'll be talking quite a bit about this at the design summit as well, so we'll look for you all there! Devin ___ 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] Graphical Console for VMs w/o Network Stacks
If you run OpenStack you are NOT forced to use libvirt; you can also use XCP (i.e. Xen Cloud Platform)/XenServer, or ESXi by setting the following flag appropriately: --connection_type Libvirt supports Xen too (which is different from XCP/XenServer). From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On Behalf Of Mike Scherbakov Sent: 18 May 2011 14:12 To: Donal Lafferty Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Graphical Console for VMs w/o Network Stacks If you run OpenStack I guess you are forced to use libvirt. You can only choose what hypervisor will be driven by libvirt. Regarding blueprint, I guess it's https://blueprints.launchpad.net/nova/+spec/web-based-serial-console Skimming through the code, I've seen only stub for Xen... On Wed, May 18, 2011 at 5:02 PM, Donal Lafferty donal.laffe...@citrix.commailto:donal.laffe...@citrix.com wrote: Hmm. Don't think Xen uses libvirt. BTW, do you have a blueprint that I can reference? Don't see on your Launchpad page. DL From: Mike Scherbakov [mailto:mih...@gmail.commailto:mih...@gmail.com] Sent: 18 May 2011 13:54 To: Donal Lafferty Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Graphical Console for VMs w/o Network Stacks It should. We have tested this functionality only with KVM, but if libvirt provides it the same way for other hypervisors, it should be Ok. Regards, Mike Scherbakov www.mirantis.comhttp://www.mirantis.com/ On Wed, May 18, 2011 at 4:49 PM, Donal Lafferty donal.laffe...@citrix.commailto:donal.laffe...@citrix.com wrote: Cool. Does this work with any VMM? E.g. KVM Xen? From: Mike Scherbakov [mailto:mih...@gmail.commailto:mih...@gmail.com] Sent: 18 May 2011 12:08 To: Donal Lafferty Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Graphical Console for VMs w/o Network Stacks Hi, there is a VNC button if you click on instance link in Dashboard. Instructions on how to make it work are below. 1. Get Nova mkdir ~/src bzr branch lp:nova 1. Get noVNC cd ~/src git clone https://github.com/openstack/noVNC.githttp://github.com/openstack/noVNC.git 1. Get and install my branch of dashboard cd ~/src bzr branch lp:openstack-dashboard cd openstack-dashboard/openstack-dashboard python tools/install_venv.py cp local/local_settings.py.example local/local_settings.py 1. Install and run Nova cd ~/src/nova sudo contrib/nova.sh install . sudo contrib/nova.sh run . 1. Run vncproxy Create new screen window with ctrl-a ctrl-c bin/nova-vncproxy --vncproxy_wwwroot ~/src/noVNC 1. Run dashboard Create new screen window with ctrl-a ctrl-c Prepare dashboard's db (once): cd ~/src/openstack-dashboard/openstack-dashboard tools/with_venv.sh dashboard/manage.py syncdb When asked to create superuser, type yes and create user with name admin and any email and password. cd ~/src/openstack-dashboard/openstack-dashboard tools/with_venv.sh dashboard/manage.py runserver 8080 Now you can navigate to http://127.0.0.1:8080http://127.0.0.1:8080/, login with user admin and specified password and have fun. Regards, Mike Scherbakov www.mirantis.comhttp://www.mirantis.com On Wed, May 18, 2011 at 2:52 PM, Donal Lafferty donal.laffe...@citrix.commailto:donal.laffe...@citrix.com wrote: Sorry if this is a repeat question, but I was wondering whether there were any blueprints completed or afoot to provide a graphical console for VMs that don't have their network stacks configured. E.g. https://blueprints.launchpad.net/nova/+spec/web-based-serial-console offers the ability to interact with VMs whose network is dead. I'm looking for something similar, but with a graphical console rather than a text-based version. Any information would be most appreciated, DL ___ Mailing list: https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstackhttps://launchpad.net/%7Eopenstack More help : https://help.launchpad.net/ListHelp Regards, Mike Scherbakov www.mirantis.comhttp://www.mirantis.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
[Openstack] new config file for nova-api
Hi, I have noticed that recently a new way of configuring nova-api has been introduced. It seems that the old gflags style has been replaced in favour of paste.deploy style. I am trying to find information about this transition, and how old config files can be translated to new ones. Do we just past the flags under the [DEFAULT] section? I am also wondering if this is going to be done for other services other than nova-api. This blueprinthttp://wiki.openstack.org/blueprint-paste-deploy does not seem to have a lot of information. Many thanks, Armando ___ 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 config file for nova-api
I think the root of my confusion came from the fact that I was configuring nova-api using --flagfile=nova-api.conf and nova-api.conf contained the list of flags for the node. This is also the reason why I filed a bug to suggest that nova-api.conf is not hardcoded in bin/nova-api From: openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net [mailto:openstack-bounces+armando.migliaccio=eu.citrix@lists.launchpad.net] On Behalf Of Andy Smith Sent: 19 January 2011 19:03 To: Jay Pipes Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] new config file for nova-api On Wed, Jan 19, 2011 at 11:01 AM, Jay Pipes jaypi...@gmail.commailto:jaypi...@gmail.com wrote: If more documentation enables deployers to properly deploy Nova, it's in scope. At least, that's my opinion. In scope for documentation, I meant that flags and paste.deploy don't configure the same types of things. --andy -jay On Wed, Jan 19, 2011 at 2:00 PM, Andy Smith andys...@gmail.commailto:andys...@gmail.com wrote: My understanding is that the paste.deploy config is unrelated to the flags system and is rather separate in scope. On Wed, Jan 19, 2011 at 10:56 AM, Jay Pipes jaypi...@gmail.commailto:jaypi...@gmail.com wrote: On Wed, Jan 19, 2011 at 6:41 AM, Armando Migliaccio armando.migliac...@eu.citrix.commailto:armando.migliac...@eu.citrix.com wrote: I have noticed that recently a new way of configuring nova-api has been introduced. It seems that the old gflags style has been replaced in favour of paste.deploy style. I am trying to find information about this transition, and how old config files can be translated to new ones. Do we just past the flags under the [DEFAULT] section? I am also wondering if this is going to be done for other services other than nova-api. This blueprint does not seem to have a lot of information. Hey Todd and Anne, Think we can add a bit of documentation about this? Armando, can you file a bug so that we can track the documentation needs? Thanks! jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto: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
