[Openstack] [ANN] Tsuru PaaS Free Trial SignUp
Hi, We from globo.com's PaaS team are launching try.tsuru.io as a private beta with the goal of making available an easy way of people get to know and try tsuru. With tsuru, developers and teams don't need to worry with servers or with building a deploy, they can focus on the most important: the application. Tsuru makes possible to write applications in the language of your preference, to use services like SQL and NoSQL databases, memcached, redis (and many others) by simply plugin them into your application. You manage your application using the command line or the web interface and you deploy via git. Everything is taken care by tsuru's infrastructure. You also can change tsuru's orchestration system. We currently work with Amazon, OpenStack (via EC2 api), LXC, and docker (the latter is in development stage). Tsuru is an Open Source project, feel free to look its source[0], build your own PaaS using tsuru[1], contribute[2] or suggest features/report bugs[3]. [0] - https://github.com/globocom/tsuru/ [1] - http://docs.tsuru.io/en/latest/lxc.html [2] - http://docs.tsuru.io/en/latest/#contributions-and-feedback [3] - https://github.com/globocom/tsuru/issues Thank you! -- Flavia ___ 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] paas in openstack and forked cloudfoindry
Hi Frans, You should take a look at tsuru[1], it's build in go and there's a lot to improve, but it's a great and stable paas, built to be flexible! [1] https://github.com/timeredbull/tsuru/ -- Flavia ___ 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] [cinder] Nova-volume vs. Cinder in Folsom
Hi, On Sat, Jul 14, 2012 at 1:51 PM, Andrew Clay Shafer a...@parvuscaptus.comwrote: I disagree with your last point, it is true if we look only into this particular problem, but if you look into the whole ecosystem you'll realize that the code removal of nova-volumes is not the only change from essex to folsom.. if we had deprecated all other changes, this particular one would not be painful at all. I'm not sure what you are disagreeing with or advocating. We should expect code to change between releases, no? Sure! As this thread demonstrated, we collectively have done a poor job of communicating and managing those changes. It is precisely because I expect more changes that I state that option 2 is postponing risks, not lowering them. I'm not saying you are wrong, or that my assumptions are correct, but I don't understand what you disagree with. Ok, I'll try to explain: I don't disagree when you say that we are postponing risks, maybe you're also right about confusing operators, my point is that it's one more non optional change (I'm not separating deployment from usage here). [...] On the question of compatibility, my assumption is this a non-issue for the moment. I believe it wouldn't be an issue if people were not using OpenStack, but we are.. I thought it was clear from the context of the thread and my email that compatibility in this case is in reference to the consumers of the API and not to the differences for managing deployments. Sorry, I read it again and that makes sense. On the question of an upgrade path and the relative ease of deployment, my assumption is this is no worse than any of the other upgrades. It doesn't really mean a good thing, since I don't think that the others upgrades were good, based on what I heard and experienced with sysadmins from my team... I totally agree that it's not a good thing. Do we believe that keeping nova-volumes will make it painless? I don't, as I said before (don't recall where), I think the problem is the whole, a lot of stuff changes without any deprecations, this change is just one more. I don't want to blame anyone by this, even the comunity, I just think we should go smoothly on upgrades. [...] In specific, I think getting more information from operators and users is generally good. Ultimately, if OpenStack cannot be operated and utilized, the mission will fail. I agree! (finally :P) I also think that it's our responsibility (as developers) to ask for input from operators, it's not because they are not complaining that things are going smoothly. We should ask for every one we know who's working with OpenStack and do our best to get feedback. Definitely! There are also different sets of unstated assumptions about what OpenStack is or should be that have to be resolved or we are going to keep running into these type of situations. Those definitely create the situation we are facing, but they aren't unique to Cinder/Volumes, so I will start another thread. Great :) Regards, -- Flavia ___ 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] [cinder] Nova-volume vs. Cinder in Folsom
Hi, On Fri, Jul 13, 2012 at 9:20 PM, Andrew Clay Shafer a...@parvuscaptus.comwrote: [...] In this particular case, I chose option 1 under the following assumptions (which may be wrong): - the api for the end user would not change - the code for the service is essentially the same, it is just being renamed - option 2 doesn't lower risk or burden for anyone, it just postpones them, while increasing complexity, confusion and future burdens for core development and probably operators as well I disagree with your last point, it is true if we look only into this particular problem, but if you look into the whole ecosystem you'll realize that the code removal of nova-volumes is not the only change from essex to folsom.. if we had deprecated all other changes, this particular one would not be painful at all. [...] On the question of compatibility, my assumption is this a non-issue for the moment. I believe it wouldn't be an issue if people were not using OpenStack, but we are.. On the question of an upgrade path and the relative ease of deployment, my assumption is this is no worse than any of the other upgrades. It doesn't really mean a good thing, since I don't think that the others upgrades were good, based on what I heard and experienced with sysadmins from my team... [...] In specific, I think getting more information from operators and users is generally good. Ultimately, if OpenStack cannot be operated and utilized, the mission will fail. I agree! (finally :P) I also think that it's our responsibility (as developers) to ask for input from operators, it's not because they are not complaining that things are going smoothly. We should ask for every one we know who's working with OpenStack and do our best to get feedback. Regards, -- Flavia ___ 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] [cinder] Nova-volume vs. Cinder in Folsom
For me it's +1 to 1, but... Here at Globo.com we're already deploying clouds based on openstack (not in production yet, we have dev and lab), and it's really painful when openstack just forces us to change, I mean, sysadmins are not that happy, so I think it's more polite if we warn them in Folsom, and remove everything next. Maybe this way nobody's going to fear the update. It also make us lose the chain of thought.. you're learning, and suddenly you have to change something for an update, and then you come back to what you we're doing... Anyway... :) Thanks, On Wed, Jul 11, 2012 at 3:09 PM, Renuka Apte renuka.a...@citrix.com wrote: +1 for 1 On 11/07/12 8:26 AM, Vishvananda Ishaya vishvana...@gmail.com wrote: Hello Everyone, Now that the PPB has decided to promote Cinder to core for the Folsom release, we need to decide what happens to the existing Nova Volume code. As far as I can see it there are two basic strategies. I'm going to give an overview of each here: Option 1 -- Remove Nova Volume == Process --- * Remove all nova-volume code from the nova project * Leave the existing nova-volume database upgrades and tables in place for Folsom to allow for migration * Provide a simple script in cinder to copy data from the nova database to the cinder database (The schema for the tables in cinder are equivalent to the current nova tables) * Work with package maintainers to provide a package based upgrade from nova-volume packages to cinder packages * Remove the db tables immediately after Folsom Disadvantages - * Forces deployments to go through the process of migrating to cinder if they want to use volumes in the Folsom release Option 2 -- Deprecate Nova Volume = Process --- * Mark the nova-volume code deprecated but leave it in the project for the folsom release * Provide a migration path at folsom * Backport bugfixes to nova-volume throughout the G-cycle * Provide a second migration path at G * Package maintainers can decide when to migrate to cinder Disadvantages - * Extra maintenance effort * More confusion about storage in openstack * More complicated upgrade paths need to be supported Personally I think Option 1 is a much more manageable strategy because the volume code doesn't get a whole lot of attention. I want to keep things simple and clean with one deployment strategy. My opinion is that if we choose option 2 we will be sacrificing significant feature development in G in order to continue to maintain nova-volume for another release. But we really need to know if this is going to cause major pain to existing deployments out there. If it causes a bad experience for deployers we need to take our medicine and go with option 2. Keep in mind that it shouldn't make any difference to end users whether cinder or nova-volume is being used. The current nova-client can use either one. 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 -- Flavia ___ 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] auto_assign_floating_ip in essex
They've already fixed that in trunk: https://bugs.launchpad.net/nova/+bug/939122 []'s On Tue, May 22, 2012 at 6:21 PM, Boris-Michel Deschenes boris-michel.desche...@ubisoft.com wrote: OK’ I’ve found this here which seems to be related (for those who experience the same problem): ** ** https://bugs.launchpad.net/nova/+bug/967166 ** ** *De :* openstack-bounces+boris-michel.deschenes= ubisoft@lists.launchpad.net [mailto: openstack-bounces+boris-michel.deschenes=ubisoft@lists.launchpad.net] *De la part de* Boris-Michel Deschenes *Envoyé :* 22 mai 2012 17:09 *À :* openstack@lists.launchpad.net *Objet :* [Openstack] auto_assign_floating_ip in essex ** ** Hi everybody, ** ** I’ve noticed that the behavior changed in essex regarding automatic assignation of floating ips : ** ** **· **In Diablo, as soon as the instance was spawned, the floating ip was showing in nova and horizon. **· **In Essex, the instance first spawns and then, later, as much as 60 seconds later the floating IP gets attached. ** ** This is not so bad but sometimes, the floating IP never appears, neither in horizon nor “nova list”. The strange thing is that the IP is there, attached to the interface of the nova-network server and usable, but since it does not appear in nova or horizon, the user will never get to know it. ** ** anyone else noticed this problem? ** ** I had this problem with AND without multi_host. ** ** Boris ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Flavia ___ 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-compute] Startup error
Could you paste your nova.conf? Looks like your instances_path flag is pointing to python's dist packages directory, maybe you've set it with a relative path...? Have you already checked it? []'s On Fri, Apr 27, 2012 at 1:00 PM, Leander Bessa leande...@gmail.com wrote: Hello, I'm clueless as how to solve this problem, any ideas? DEBUG nova.utils [req-007e9c3f-2dcb-4b42-8486-800a51e272e1 None None] backend module 'nova.db.sqlalchemy.api' from '/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.pyc' from (pid=17035) __get_backend /usr/lib/python2.7/dist-packages/nova/utils.py:658 Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 336, in fire_timers timer() File /usr/lib/python2.7/dist-packages/eventlet/hubs/timer.py, line 56, in __call__ cb(*args, **kw) File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 192, in main result = function(*args, **kwargs) File /usr/lib/python2.7/dist-packages/nova/service.py, line 101, in run_server server.start() File /usr/lib/python2.7/dist-packages/nova/service.py, line 174, in start self.manager.update_available_resource(ctxt) File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 2403, in update_available_resource self.driver.update_available_resource(context, self.host) File /usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line 1898, in update_available_resource 'local_gb': self.get_local_gb_total(), File /usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line 1712, in get_local_gb_total stats = libvirt_utils.get_fs_info(FLAGS.instances_path) File /usr/lib/python2.7/dist-packages/nova/virt/libvirt/utils.py, line 277, in get_fs_info hddinfo = os.statvfs(path) OSError: [Errno 2] No such file or directory: '/usr/lib/python2.7/dist-packages/instances' 2012-04-27 16:51:48 CRITICAL nova [-] [Errno 2] No such file or directory: '/usr/lib/python2.7/dist-packages/instances' 2012-04-27 16:51:48 TRACE nova Traceback (most recent call last): 2012-04-27 16:51:48 TRACE nova File /usr/bin/nova-compute, line 49, in module 2012-04-27 16:51:48 TRACE nova service.wait() 2012-04-27 16:51:48 TRACE nova File /usr/lib/python2.7/dist-packages/nova/service.py, line 413, in wait 2012-04-27 16:51:48 TRACE nova _launcher.wait() 2012-04-27 16:51:48 TRACE nova File /usr/lib/python2.7/dist-packages/nova/service.py, line 131, in wait 2012-04-27 16:51:48 TRACE nova service.wait() 2012-04-27 16:51:48 TRACE nova File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 166, in wait 2012-04-27 16:51:48 TRACE nova return self._exit_event.wait() 2012-04-27 16:51:48 TRACE nova File /usr/lib/python2.7/dist-packages/eventlet/event.py, line 116, in wait 2012-04-27 16:51:48 TRACE nova return hubs.get_hub().switch() 2012-04-27 16:51:48 TRACE nova File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 177, in switch 2012-04-27 16:51:48 TRACE nova return self.greenlet.switch() 2012-04-27 16:51:48 TRACE nova File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line 192, in main 2012-04-27 16:51:48 TRACE nova result = function(*args, **kwargs) 2012-04-27 16:51:48 TRACE nova File /usr/lib/python2.7/dist-packages/nova/service.py, line 101, in run_server 2012-04-27 16:51:48 TRACE nova server.start() 2012-04-27 16:51:48 TRACE nova File /usr/lib/python2.7/dist-packages/nova/service.py, line 174, in start 2012-04-27 16:51:48 TRACE nova self.manager.update_available_resource(ctxt) 2012-04-27 16:51:48 TRACE nova File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line 2403, in update_available_resource 2012-04-27 16:51:48 TRACE nova self.driver.update_available_resource(context, self.host) 2012-04-27 16:51:48 TRACE nova File /usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line 1898, in update_available_resource 2012-04-27 16:51:48 TRACE nova 'local_gb': self.get_local_gb_total(), 2012-04-27 16:51:48 TRACE nova File /usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.py, line 1712, in get_local_gb_total 2012-04-27 16:51:48 TRACE nova stats = libvirt_utils.get_fs_info(FLAGS.instances_path) 2012-04-27 16:51:48 TRACE nova File /usr/lib/python2.7/dist-packages/nova/virt/libvirt/utils.py, line 277, in get_fs_info 2012-04-27 16:51:48 TRACE nova hddinfo = os.statvfs(path) 2012-04-27 16:51:48 TRACE nova OSError: [Errno 2] No such file or directory: '/usr/lib/python2.7/dist-packages/instances' 2012-04-27 16:51:48 TRACE nova Exception KeyError: KeyError(140477118368240,) in module 'threading' from '/usr/lib/python2.7/threading.pyc' ignored Regards, Leander ___ Mailing list: https://launchpad.net/~openstack Post to :
Re: [Openstack] Error in scheduler when create a new instance.
Rogerio, I had this problem and solved it by setting the following flag: scheduler_default_filters=AllHostsFilter Hope it helps. []'s On Fri, Apr 27, 2012 at 12:29 PM, Rogerio Goncalves roge...@gmail.comwrote: is enabled and not running my compute node is virtual machine to test and configured with qemu (2 core, 4gb, 10gb free in nova-volumes) my last log message on nova-compute is: 2012-04-27 12:22:25 DEBUG nova.virt.libvirt.connection [-] Connecting to libvirt: qemu:///system from (pid=18588) _get_connection /usr/lib/python2.7/dist-packages/nova/virt/libvirt/connection.*py*:292 libvirt is running 18420 ?Sl 0:00 /usr/sbin/libvirtd -d On Thu, Apr 26, 2012 at 10:43 PM, heut2008 heut2...@gmail.com wrote: be sure nova-compute is running and is enabled by using nova-manage service list,also confirm that the compute node have enough resources(cpu,mem,disk) . 2012/4/27 Rogerio Goncalves roge...@gmail.com: Hello, Im getting this error when launching a new instance. Failed to schedule_run_instance: No valid host was found. Is the appropriate service running? http://paste.openstack.org/show/14020/ SO Ubuntu 12.04 libvirt-bin start/running, process 4153 nova-network start/running, process 4174 nova-compute start/running, process 4187 nova-api start/running, process 4198 nova-objectstore start/running, process 4210 nova-scheduler start/running, process 4222 nova-volume start/running, process 4235 nova-vncproxy start/running, process 4246 rabbitmq is up too Thanks Rogério Gonçalves ___ 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 -- Flávia Missi @flaviamissi http://twitter.com/flaviamissi flaviamissi.com.br https://github.com/flaviamissi ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
