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" <mism...@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.heckm...@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@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 > > >________________________________ > >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@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
