Re: [Openstack] [Blueprint automatic-secure-key-generation] Automatic SECURE_KEY generation
Ah, you're thinking of a setup where there are multiple dashboard VMs behind a load-balancer serving requests. Indeed, there the dashboard instances should either share the SECRET_KEY or the load-balancer has to make sure that all requests of a given session are redirected to the same dashboard instance. I'm concerned that anything which automatically generates a secret key will cause further problems down the line for other users. For example, you've clearly experienced what happens when you use more than one worker and generate a per-process key. Imagine trying to debug that same problem on a multi-system cloud (with a load balancer that usually routes people to the same place, but not always). If you aren't forced to learn about this setting during deployment, you are faced with a nearly impossible problem of "users just sometimes get logged out". I feel like this patch is merely kicking the can down the road just a little past where your particular project needs it to be, without thinking about the bigger picture. I'm sure you're not seriously suggesting that a large-scale production deployment of openstack will be served entirely by a single point of failure dashboard server. But shouldn't local_settings.py still take preference over settings.py? Thus the admin could still set a specific SECRET_KEY in local_settings.py regardless of the default (auto-generated) one. So I only would have to fix the patch by not removing the documentation about SECRET_KEY from local_settings.py, right? I agree with Gabriel. Horizon should ship with no secret key (so it won't start until you set one). At most, it should automatically generate a key on a per-process basis, or possibly as part of run_tests, so that getting started with development is easy. Under no circumstances should it attempt to read the mind of an admin doing a production deployment, because it will invariably do the wrong thing more often than the right. As a security issue, it's important that admins READ THE DOCUMENTATION. Preventing the project from starting until they address the issue is one good way. Unfortunately, this is only relevant for securing production deployments. Nobody cares if a developer instance is setup securely ;-) I beg to differ. Opening trivially exploitable holes in development machines (especially laptops) can be extremely damaging. (you did read the docs about the consequences of disclosing a secret key, right?) If we don't force developers and end-users to read the documentation, particularly around security features, they will get them wrong. "Best Guess" security isn't a business I want to be in. Regards, -Paul ___ 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] Openstack and Google Compute Engine
It's KVM on Redhat with a fairly custom guest kernel, including optimized drivers for their network encapsulation. Auth is handled using their existing OAuth2.0 infrastructure. As Matt said, their offering is fairly different from EC2 (and Openstack), competing more with compute-heavy providers, rather than amazon-like application-host offerings. Their beta is currently only available to customers that they expect will run real jobs. Expect a phone call and a conversation about your application and current compute use before your organization gets an invite. One neat thing about their product is that they provide dedicated spindles on ephemeral disks for instances with more than 2 cores. Their user tooling looks very nice. There are probably features worth borrowing there. -Paul ___ 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] OpenStack "G" naming poll
On 07/03/2012 04:50 PM, Brian Waldon wrote: TL;DR - Screw the rules, let's call the next release 'Grizzly' Do it! ___ 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
+1 for option 1. Bite the bullet now, rather than making it worse later. -Paul ___ 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] No /etc/nova/nova.conf
It looks like some nova and keystone services are not running. So my question is how to check the status and restart all services in devStack? I can't use commands like "restart nova-api" because they are not installed. There should be other ways to start services in devStack. Devstack is for development. If you shut the machine off that's running it, you need to re-run the script. Many devs run devstack in a VM for convenience (pause command, easy to blow away if something gets screwed up, easy to do a clean install). ___ 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] FW: dashboard in oneric
On 02/01/2012 07:27 AM, George Mihaiescu wrote: I hope that any of the Dashboard developers can provide instructions on how to install Dashboard from a milestone-release source code (Essex2 or Essex3) while using MySQL for DB and Apache2 as the web server, AND NOT by using virtual-env + sqlite. I don't know about essex-2, but essex-3 should work reasonably well. If you don't like virtual-env, don't use it and use pip to directly install the appropriate dependencies. You can specify the use of MySQL in the local settings file, and if you prefer Apache2, you can read the general Django setup instructions: https://docs.djangoproject.com/en/1.3/topics/install/#install-apache-and-mod-wsgi ___ 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] Being pedantic about pedanticism: HACKING styleguide
On 03/22/2012 10:47 AM, Doug Hellmann wrote: Why are those sorts of instructions replicated in each project in the first place? Shouldn't they be in the wiki? Because nobody reads wikis. Especially not developers who are in a hurry to make a small fix. At least this way, we can yell at them and say "You saw the HACKING file, and you didn't read it." ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
