Open Stack

Goutham, comments inline...

Also, FYI, using HTML email with different color fonts to indicate 
different people talking is not particularly mailing list-friendly. For 
reasons why, just check out your last post:

http://lists.openstack.org/pipermail/openstack-dev/2018-January/126842.html

You can't tell who is saying what in the mailing list post...

Much better to use non-HTML email and demarcate responses with the 
traditional > marker. :)

OK, comments inline below.

On 01/31/2018 01:17 PM, Goutham Pratapa wrote:
> Hi Jay,
> 
> Thanks for the questions.. :)
> 
> What precisely do you mean by "resources" above ??
> 
> Resources as-in resources required to boot-up a vm (Keypair, Image, 
> Flavors )

Gotcha. Thanks for the answer.

> Also, by "syncing", do you mean "replicating"? The reason I ask is 
> because in the case of, say, VM "resources", you can't "sync" a VM 
> across regions. You can replicate its bootable image, but you can't 
> "sync" a VM's state across multiple OpenStack deployments.
> 
> Yes as you said syncing as-in replicating only.

Gotcha. You could, of course, actually use synchronous (or semi-sync) 
replication for various databases, including Glance and Keystone's 
identity/assignment information, but yes, async replication is just as good.

> and yes we cannot sync vm's across regions but our idea is to 
> sync/replicate all the parameters required to boot a vm

OK, sounds good.

> (viz. *image, keypair, flavor*) which are originally there in the source 
> region to the target regions in a single-go.

Gotcha.

Some questions on scope that piqued my interest while reading your 
response...

Is Kingbird predominantly designed to be the multi-region orchestrator 
for OpenStack deployments that are all owned/operated by the same 
deployer? Or does Kingbird have intentions of providing glue services 
between multiple fully-independent OpenStack deployments (possibly 
operated by different deployers)?

Further, does Kingbird intend to get into the multi-cloud (as in AWS, 
OpenStack, Azure, etc) orchestration game?

> I'm curious what you mean by "resource management". Could you elaborate 
> a bit on this?
> 
> Resource management as-in managing the resources i.e say a user has a 
> glance image(*qcow2 or ami format*) or
> say flavor(*works only if admin*) with some properties or keypair 
> present in one source regionand he wants the same image or
> same flavor with same properties or the same keypair in another set of 
> regions user may have to recreate them in all target regions.
> 
> But with the help of kingbird you can do all the operations in a single go.
> 
> --> If user wants to sync a resource of type keypair he can replicate 
> the keypair into multiple target regions in single go (similarly glance 
> images and flavors )
> --> If user wants different type of resource( keypair,image and flavor) 
> in a single go then user can  give a yaml file as input and kingbird 
> replicates all resources in all target regions

OK, I understand your use case here, thanks.

It does seem to me, however, that if the intention is *not* to get into 
the multi-cloud orchestration game, that a simpler solution to this 
multi-region OpenStack deployment use case would be to simply have a 
global Glance and Keystone infrastructure that can seamlessly scale to 
multiple regions.

That way, there'd be no need for replicating anything.

I suppose what I'm recommending it that instead of the concept of a 
region (or availability zone in Nova for that matter) being a 
mostly-configuration option thing, that the OpenStack contributor 
community actually work to make regions (the concept that Keystone 
labels a region; which is just a grouping of service endpoints) the one 
and only concept of a user-facing "partition" throughout OpenStack.

That way we would have OpenStack services like Glance, Nova, Cinder, 
Neutron, etc just *natively* understand which region they are in and 
how/if they can communicate with other regions.

Sometimes it seems we (as a community) go through lots of hoops working 
around fundamental architectural problems in OpenStack instead of just 
fixing those problems to begin with. See: Nova cellsv1 (and some of 
cellsv2), Keystone federation, the lack of a real availability zone 
concept anywhere, Nova shelve/unshelve (partly developed because VMs and 
IPs were too closely coupled at the time), the list goes on and on...

Anyway, mostly just rambling/ranting... just food for thought.

Best,
-jay

> Thanks
> Goutham.
> 
> On Wed, Jan 31, 2018 at 9:25 PM, Jay Pipes <jaypipes at gmail.com 
> <mailto:jaypipes at gmail.com>> wrote:
> 
>     On 01/31/2018 01:49 AM, Goutham Pratapa wrote:
> 
>         *Kingbird (The Multi Region orchestrator):*
> 
>         We are proud to announce kingbird is not only a centralized
>         quota and resource-manager but also a  Multi-region Orchestrator.
> 
>         *Use-cases covered:
> 
>         *- Admin can synchronize and periodically balance quotas across
>         regions and can have a global view of quotas of all the tenants
>         across regions.
>         - A user can sync a resource or a group of resources from one
>         region to other in a single go
> 
> 
>     What precisely do you mean by "resources" above?
> 
>     Also, by "syncing", do you mean "replicating"? The reason I ask is
>     because in the case of, say, VM "resources", you can't "sync" a VM
>     across regions. You can replicate its bootable image, but you can't
>     "sync" a VM's state across multiple OpenStack deployments.
> 
>            A user can sync multiple key-pairs, images, and flavors from
>         one region to other, ( Flavor can be synced only by admin)
> 
>         - A user must have complete tempest test-coverage for all the
>         scenarios/services rendered by kingbird.
> 
>         - Horizon plugin so that user can access/view global limits.
> 
>         * Our Road-map:*
> 
>         -- Automation scripts for kingbird in
>               -ansible,
>               -salt
>               -puppet.
>         -- Add SSL support to kingbird
>         -- Resource management in Kingbird-dashboard.
> 
> 
>     I'm curious what you mean by "resource management". Could you
>     elaborate a bit on this?
> 
>     Thanks,
>     -jay
> 
>         -- Kingbird in a docker
>         -- Add Kingbird into Kolla.
> 
>         We are looking out for*_contributors and ideas_* which can
>         enhance Kingbird and make kingbird a one-stop solution for all
>         multi-region problems
> 
> 
> 
>         *_Stable Branches :_
>         *
>         *
>         Kingbird-server:
>         https://github.com/openstack/kingbird/tree/stable/queens
>         <https://github.com/openstack/kingbird/tree/stable/queens>
>         <https://github.com/openstack/kingbird/tree/stable/queens
>         <https://github.com/openstack/kingbird/tree/stable/queens>>
>         *
>         *Python-Kingbird-client (0.2.1):
>         https://github.com/openstack/python-kingbirdclient/tree/0.2.1
>         <https://github.com/openstack/python-kingbirdclient/tree/0.2.1>
>         <https://github.com/openstack/python-kingbirdclient/tree/0.2.1
>         <https://github.com/openstack/python-kingbirdclient/tree/0.2.1>>
>         *
> 
>         I would like to Thank all the people who have helped us in
>         achieving this milestone and guided us all throughout this
>         Journey :)
> 
>         Thanks
>         Goutham Pratapa
>         PTL
>         OpenStack-Kingbird.
> 
> 
> 
>         __________________________________________________________________________
>         OpenStack Development Mailing List (not for usage questions)
>         Unsubscribe:
>         OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>         <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> 
> 
> -- 
> Cheers !!!
> Goutham Pratapa