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 <jaypi...@gmail.com
<mailto:jaypi...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
