Open Stack

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.