<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 6, 2018 at 6:03 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Goutham, comments inline...<br>
<br>
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:<br>
<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2018-January/126842.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pip<wbr>ermail/openstack-dev/2018-Janu<wbr>ary/126842.html</a><br>
<br>
You can't tell who is saying what in the mailing list post...<br>
<br>
Much better to use non-HTML email and demarcate responses with the traditional > marker. :)<br>
<br>
OK, comments inline below.<span class=""><br>
<br>
On 01/31/2018 01:17 PM, Goutham Pratapa wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Jay,<br>
<br>
Thanks for the questions.. :)<br>
<br>
What precisely do you mean by "resources" above ??<br>
<br>
Resources as-in resources required to boot-up a vm (Keypair, Image, Flavors )<br>
</blockquote>
<br></span>
Gotcha. Thanks for the answer.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
Yes as you said syncing as-in replicating only.<br>
</blockquote>
<br></span>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and yes we cannot sync vm's across regions but our idea is to sync/replicate all the parameters required to boot a vm<br>
</blockquote>
<br></span>
OK, sounds good.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(viz. *image, keypair, flavor*) which are originally there in the source region to the target regions in a single-go.<br>
</blockquote>
<br>
Gotcha.<br>
<br>
Some questions on scope that piqued my interest while reading your response...<br>
<br>
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)?<br>
<br>
Further, does Kingbird intend to get into the multi-cloud (as in AWS, OpenStack, Azure, etc) orchestration game? <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> >
For now Kingbird is designed for openstack deployments that are all
owned by the same deployer and yes we would like to get into multi-cloud
orchestration dont know how ?? But the idea is there. (If you can
please guide us then may be we can acheive this :) ) </blockquote></blockquote><div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> We have to see how far we can adhere between different multiple-openstack deployments</blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
I'm curious what you mean by "resource management". Could you elaborate a bit on this?<br>
<br></span>
Resource management as-in managing the resources i.e say a user has a glance image(*qcow2 or ami format*) or<br>
say flavor(*works only if admin*) with some properties or keypair present in one source regionand he wants the same image or<span class=""><br>
same flavor with same properties or the same keypair in another set of regions user may have to recreate them in all target regions.<br>
<br>
But with the help of kingbird you can do all the operations in a single go.<br>
<br>
--> 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 )<br>
--> 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<br>
</span></blockquote>
<br>
OK, I understand your use case here, thanks.<br>
<br>
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.</blockquote><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Frankly we never tried this. we will have to try this.<br><div>
<br>
That way, there'd be no need for replicating anything.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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...<br>
<br>
Anyway, mostly just rambling/ranting... just food for thought.</div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Yes :) thanks for your suggestions and ideas.. this is good way forward for our team.<br>
<br>
Best,<br>
-jay<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks<br>
Goutham.<div><div class="h5"><br>
<br>
On Wed, Jan 31, 2018 at 9:25 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a> <mailto:<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>>> wrote:<br>
<br>
On 01/31/2018 01:49 AM, Goutham Pratapa wrote:<br>
<br>
*Kingbird (The Multi Region orchestrator):*<br>
<br>
We are proud to announce kingbird is not only a centralized<br>
quota and resource-manager but also a Multi-region Orchestrator.<br>
<br>
*Use-cases covered:<br>
<br>
*- Admin can synchronize and periodically balance quotas across<br>
regions and can have a global view of quotas of all the tenants<br>
across regions.<br>
- A user can sync a resource or a group of resources from one<br>
region to other in a single go<br>
<br>
<br>
What precisely do you mean by "resources" above?<br>
<br>
Also, by "syncing", do you mean "replicating"? The reason I ask is<br>
because in the case of, say, VM "resources", you can't "sync" a VM<br>
across regions. You can replicate its bootable image, but you can't<br>
"sync" a VM's state across multiple OpenStack deployments.<br>
<br>
A user can sync multiple key-pairs, images, and flavors from<br>
one region to other, ( Flavor can be synced only by admin)<br>
<br>
- A user must have complete tempest test-coverage for all the<br>
scenarios/services rendered by kingbird.<br>
<br>
- Horizon plugin so that user can access/view global limits.<br>
<br>
* Our Road-map:*<br>
<br>
-- Automation scripts for kingbird in<br>
-ansible,<br>
-salt<br>
-puppet.<br>
-- Add SSL support to kingbird<br>
-- Resource management in Kingbird-dashboard.<br>
<br>
<br>
I'm curious what you mean by "resource management". Could you<br>
elaborate a bit on this?<br>
<br>
Thanks,<br>
-jay<br>
<br>
-- Kingbird in a docker<br>
-- Add Kingbird into Kolla.<br>
<br>
We are looking out for*_contributors and ideas_* which can<br>
enhance Kingbird and make kingbird a one-stop solution for all<br>
multi-region problems<br>
<br>
<br>
<br>
*_Stable Branches :_<br>
*<br>
*<br>
Kingbird-server:<br>
<a href="https://github.com/openstack/kingbird/tree/stable/queens" rel="noreferrer" target="_blank">https://github.com/openstack/k<wbr>ingbird/tree/stable/queens</a><br>
<<a href="https://github.com/openstack/kingbird/tree/stable/queens" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>kingbird/tree/stable/queens</a>><br>
<<a href="https://github.com/openstack/kingbird/tree/stable/queens" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>kingbird/tree/stable/queens</a><br>
<<a href="https://github.com/openstack/kingbird/tree/stable/queens" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>kingbird/tree/stable/queens</a>>><br>
*<br>
*Python-Kingbird-client (0.2.1):<br>
<a href="https://github.com/openstack/python-kingbirdclient/tree/0.2.1" rel="noreferrer" target="_blank">https://github.com/openstack/p<wbr>ython-kingbirdclient/tree/0.2.<wbr>1</a><br>
<<a href="https://github.com/openstack/python-kingbirdclient/tree/0.2.1" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>python-kingbirdclient/tree/0.2<wbr>.1</a>><br>
<<a href="https://github.com/openstack/python-kingbirdclient/tree/0.2.1" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>python-kingbirdclient/tree/0.2<wbr>.1</a><br>
<<a href="https://github.com/openstack/python-kingbirdclient/tree/0.2.1" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>python-kingbirdclient/tree/0.2<wbr>.1</a>>><br>
*<br>
<br>
I would like to Thank all the people who have helped us in<br>
achieving this milestone and guided us all throughout this<br>
Journey :)<br>
<br>
Thanks<br>
Goutham Pratapa<br>
PTL<br>
OpenStack-Kingbird.<br>
<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe:<br>
<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br></div></div>
<<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@<wbr>lists.openstack.org?subject:un<wbr>subscribe</a>><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cg<wbr>i-bin/mailman/listinfo/opensta<wbr>ck-dev</a>><span class=""><br>
<br>
<br>
<br>
<br>
-- <br>
Cheers !!!<br>
Goutham Pratapa<br>
</span></blockquote>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Cheers !!!<div>Goutham Pratapa</div></div></div>
</div></div>