Open Stack

Image sharing does seem to be quite a common requirement between multiple
clouds with some degree of trust.

Has anyone found a good way to do this without needing the user to upload
to each cloud (and handle the associated consistency themselves) ?

Tim

On 4/23/15, 6:13 AM, "Mike Smith" <mismith at overstock.com> wrote:

>At Overstock we have a number of separate Openstack deployments in
>different facilities that are completely separated from each other.  No
>shared services between them.   Some of the separation is due to the kind
>of instances they contain (³Dev/Test" vs ³Prod² for example), but it is
>largely due to the location diversity and the desire to not require
>everything to be upgraded at once.
>
>We have automation to build and push out new glance images every month
>(built via Oz) to the multiple glance instances.  Our home-made
>orchestration knows how to provision to the multiple clouds.   We are not
>currently using corporate LDAP for these, but our orchestration tool does
>use AD and that¹s where we do most of our work from anyway.  All of these
>are managed by our Website Systems team and we do basic show-back to
>various teams that use these services using data from nova statistics (no
>Ceilometer yet).
>
>Mike Smith
>Principal Engineer, Website Systems
>Overstock.com
>
>
>
>> On Apr 22, 2015, at 6:26 PM, Marc Heckmann <marc.heckmann at ubisoft.com>
>>wrote:
>>
>> [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 at 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 at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>________________________________
>
>CONFIDENTIALITY NOTICE: This message is intended only for the use and
>review of the individual or entity to which it is addressed and may
>contain information that is privileged and confidential. If the reader of
>this message is not the intended recipient, or the employee or agent
>responsible for delivering the message solely to the intended recipient,
>you are hereby notified that any dissemination, distribution or copying
>of this communication is strictly prohibited. If you have received this
>communication in error, please notify sender immediately by telephone or
>return email. Thank you.
>_______________________________________________
>OpenStack-operators mailing list
>OpenStack-operators at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators