[top posting on this one] Hi,
When you write "Openstack instances", I'm assuming that you're referring to Openstack deployments right? We have different deployments based on geographic regions for performance concerns but certainly not by department. Each Openstack project is tied to a department/project budget code and re-billed accordingly based on Ceilometer data. No need to have separate deployments for that. Central IT owns all the Cloud infra. In the separate deployments the only thing that we aim to have shared is Swift and Keystone (it's not the case for us right now). Glance images need to be identical between deployments but that's easily achievable through automation both for the operator and the end user. We make sure that the users understand that these are separate regions/Clouds akin to AWS regions. -m On Wed, 2015-04-22 at 13:50 +0000, Fox, Kevin M wrote: > This is a case for a cross project cloud (institutional?). It costs > more to run two little clouds then one bigger one. Both in terms of > man power, and in cases like these. under utilized resources. > > #3 is interesting though. If there is to be an openstack app catalog, > it would be inportant to be able to pull the needed images from > outside the cloud easily. > > Thanks, > Kevin > > > ______________________________________________________________________ > From: Adam Young > Sent: Wednesday, April 22, 2015 6:32:17 AM > To: openstack-operators@lists.openstack.org > Subject: [Openstack-operators] Sharing resources across OpenStack > instances > > > Its been my understanding that many people are deploying small > OpenStack > instances as a way to share the Hardware owned by their particular > team, > group, or department. The Keystone instance represents ownership, > and > the identity of the users comes from a corporate LDAP server. > > Is there much demand for the following scenarios? > > 1. A project team crosses organizational boundaries and has to work > with VMs in two separate OpenStack instances. They need to set up a > network that requires talking to two neutron instances. > > 2. One group manages a powerful storage array. Several OpenStack > instances need to be able to mount volumes from this array. > Sometimes, > those volumes have to be transferred from VMs running in one instance > to > another. > > 3. A group is producing nightly builds. Part of this is an image > building system that posts to glance. Ideally, multiple OpenStack > instances would be able to pull their images from the same glance. > > 4. Hadoop ( or some other orchestrated task) requires more resources > than are in any single OpenStack instance, and needs to allocate > resources across two or more instances for a single job. > > > I suspect that these kinds of architectures are becoming more > common. > Can some of the operators validate these assumptions? Are there > other, > more common cases where Operations need to span multiple clouds which > would require integration of one Nova server with multiple Cinder, > Glance, or Neutron servers managed in other OpenStack instances? > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators