Open Stack

Adam,

fuel does support multiple PXE networks via the nodegroup/multiple clusters
feature, however in the geo-diverse case this would receive limited use as
it's mostly useful for a spine and leaf network topology. As you noted, in
the geo-diverse case you would typically deploy an env for the keystone /
glance cluster and then separate env's (most like with different fuel
nodes) you would deploy the individual regions.

On Wed, Oct 7, 2015 at 3:28 AM Adam Heczko <aheczko at mirantis.com> wrote:

> Hi, although I'm not participating in this story since very beginning, let
> me add my 2 cents.
> For scalability purposes Nova considers rather use of 'cells' rather than
> 'regions' construct.
> Regions as name suggests deals with geographically dispersed data centre
> locations.
> In regards to Fuel architecture, since Fuel supports only one PXE network,
> it is IMO unable to deploy multi region clouds.
> Fuel uses 'environments' construct, but again it doesn't fit to 'region'
> nor 'cell', since Fuel's 'environment' deploys just another cluster (with
> own set of controllers, computes etc.) over the shared PXE network.
> It is probably quite affordable to add 'cells' capability to Fuel, maybe
> through Fuel-plugins mechanism, which could decouple nova-scheduler and
> related roles from 'main' controller role.
> For true multi-region capability, it would be required to operate
> multi-cobbler Fuel instances / multiple PXE networks with appropriate
> 'region' names provided.
> A initial approach to it would be probably to deploy multiple Fuel
> instances (one Fuel per region) and then bound them altogether through
> RESTful API / operate at scale through API, at least when it comes to
> Keystone and Galera cluster configuration.
> There are several approaches to multi region, maybe good one would be
> plugin allowing to select remote data centre Galera cluster as a partner
> for replication.
> I'm not sure at this moment how HA would be operated this way, since
> Keystone utilizes memcached for various operations. Would multi-region
> memcached memory states also be synchronized?
> So multi-region DC could rise up a lot related to it problems.
>
> Regards,
>
> A.
>
>
>
> On Wed, Oct 7, 2015 at 11:49 AM, Roman Sokolkov <rsokolkov at mirantis.com>
> wrote:
>
>> Sheena, thanks. I agree with Chris full Multi-DC it's different scale
>> task.
>>
>> For now Services just need +1 tiny step from Fuel/Product in favor
>> supporting current Multi-DC deployments architectures. (i.e. shared
>> Keystone)
>>
>> Andrew, Ruslan, Mike,
>>
>> i've created tiny blueprint
>> https://blueprints.launchpad.net/fuel/+spec/expose-region-name-to-ui
>>
>> We just need to expose already existing functionality to UI.
>>
>> Can someone pickup this blueprint? And/Or reassign to appropriate team.
>>
>> Thanks
>>
>> On Fri, Oct 2, 2015 at 7:41 PM, Sheena Gregson <sgregson at mirantis.com>
>> wrote:
>>
>>> Forwarding since Chris isn’t subscribed.
>>>
>>>
>>>
>>> *From:* Chris Clason [mailto:cclason at mirantis.com]
>>> *Sent:* Friday, October 02, 2015 6:30 PM
>>> *To:* Sheena Gregson <sgregson at mirantis.com>; OpenStack Development
>>> Mailing List (not for usage questions) <
>>> openstack-dev at lists.openstack.org>
>>> *Subject:* Re: [openstack-dev] [Fuel] 8.0 Region name support / Multi-DC
>>>
>>>
>>>
>>> We are doing some technology evaluations with the intent of publishing
>>> reference architectures at various scale points (500, 1500, 2000 etc). Part
>>> of this work will be to determine how to best partition the nodes in to
>>> regions based on scale limits of OpenStack components and workload
>>> characteristics. The work we are doing increased in scope significantly, so
>>> the first RA will be coming at the end of Q1 or early Q2.
>>>
>>>
>>>
>>> We do plan on using some components of Fuel for our testing but the main
>>> purpose is path finding. The work we do will eventually make it into Fuel,
>>> but we are going to run in front of it a bit.
>>>
>>>
>>>
>>> On Fri, Oct 2, 2015 at 9:19 AM Sheena Gregson <sgregson at mirantis.com>
>>> wrote:
>>>
>>> Plans for multi-DC: my understanding is that we are working on
>>> developing a whitepaper in Q4 that will provide a possible OpenStack
>>> multi-DC configuration, but I do not know whether or not we intend to
>>> include Fuel in the scope of this work (my guess would be no).  Chris – I
>>> copied you in case you wanted to comment here.
>>>
>>>
>>>
>>> Regarding specifying region names in UI, is it possible to specify
>>> region names in API?  And (apologies for my ignorance on this one) what is
>>> the relative equivalence to environments in Fuel (e.g. 1 environment : many
>>> regions, 1 environment == 1 region)?
>>>
>>>
>>>
>>> *From:* Roman Sokolkov [mailto:rsokolkov at mirantis.com]
>>> *Sent:* Friday, October 02, 2015 5:26 PM
>>> *To:* OpenStack Development Mailing List (not for usage questions) <
>>> openstack-dev at lists.openstack.org>
>>> *Subject:* [openstack-dev] [Fuel] 8.0 Region name support / Multi-DC
>>>
>>>
>>>
>>> Folks,
>>>
>>>
>>>
>>> i've dug around 8.0 roadmap and didn't find anythind regarding Multi-DC
>>> support.
>>>
>>>
>>>
>>> My ask is about tiny(but useful) feature: give user ability to *specify
>>> Region name in UI.*
>>>
>>>
>>>
>>> Region name is already in every puppet module, so we just need to add
>>> this to UI.
>>>
>>>
>>>
>>> Do we have smth already?
>>>
>>>
>>>
>>> More general question: What are our plans in regards Multi-DC?
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> --
>>>
>>> Roman Sokolkov,
>>>
>>> Deployment Engineer,
>>>
>>> Mirantis, Inc.
>>> Skype rsokolkov,
>>> rsokolkov at mirantis.com
>>>
>>> --
>>>
>>> Chris Clason
>>>
>>> Director of Architecture
>>>
>>> cclason at mirantis.com
>>>
>>> Mobile: +1.408.409.0295
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>>
>> --
>> Roman Sokolkov,
>> Deployment Engineer,
>> Mirantis, Inc.
>> Skype rsokolkov,
>> rsokolkov at mirantis.com
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Adam Heczko
> Security Engineer @ Mirantis Inc.
>
-- 
--
Andrew Woodward
Mirantis
Fuel Community Ambassador
Ceph Community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151008/62b273c1/attachment.html>