<div dir="ltr"><div><div>Hi, Zane, <br><br></div>Sorry for the late reply I was on leave for a couple of days.<br><br></div><div>Firstly, Thanks for the clear in detail analysis and suggestions on quotas and resources-management it really means a lot to us :).<br></div><div><br></div><div>Secondly, these are the use-cases which kingbird is mainly developed for.<br></div><div><br></div><div><u>OUR USE-CASES QUOTA-MANAGEMENT:</u><br></div><div><br>1. Admin must have a global view of all quotas to all tenants across all the regions<br></div><div>2. Admin can periodically balance the quotas (we have a formula using which we do this balancing ) across regions<br></div><div>3. Admin can update, Delete quotas for tenants<br></div><div>4. Admin can sync quotas for all tenants so that the quotas will be updated in all regions.<br></div><div><br></div><div><u>USE-CASES FOR RESOURCE-MANAGEMENT:</u><br></div><div>1. Resources which are required to boot up a VM in One region should be accessible in other target-regions<br></div><div> In the process, Kingbird has support for the following<br></div><div> a) Sync/Replicate existing Nova-Keypairs<br></div><div> b) Sync/Replicate existing Glance-Images <br></div><div> c) Sync/Replicate existing Nova-Flavors.(Only admin can sync these.)<br><br></div><div>2. User who has a VM in one region should have the ease or possibility to have a replica of the same vm in target-region(s)<br></div><div> a) It can be a snapshot of the already booted-up VM or with the same qcow2 image.<br></div><div></div><div><br><u>GENERIC USE-CASES</u><br><br></div><div class="gmail_extra">1. <span style="color:rgb(0,0,0)"> Automation scripts for kingbird in<br> -ansible,<br> -salt <br> -puppet.<br>2. Add <span class="gmail-m_4760619863291455827m_1218604755317977593gmail-gr_ gmail-m_4760619863291455827m_1218604755317977593gmail-gr_50 gmail-m_4760619863291455827m_1218604755317977593gmail-gr-alert gmail-m_4760619863291455827m_1218604755317977593gmail-gr_spell gmail-m_4760619863291455827m_1218604755317977593gmail-gr_inline_cards gmail-m_4760619863291455827m_1218604755317977593gmail-gr_run_anim gmail-m_4760619863291455827m_1218604755317977593gmail-ContextualSpelling gmail-m_4760619863291455827m_1218604755317977593gmail-ins-del gmail-m_4760619863291455827m_1218604755317977593gmail-multiReplace" id="gmail-m_4760619863291455827m_1218604755317977593gmail-50">SSL</span> support to kingbird <br>3. Resource management in Kingbird-dashboard.<br>4. Kingbird in a docker<br>5. Add Kingbird into Kolla.<br></span> <br><div class="gmail_quote">On Fri, Feb 9, 2018 at 12:47 AM, Zane Bitter <span dir="ltr"><<a href="mailto:zbitter@redhat.com" target="_blank">zbitter@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 07/02/18 12:24, Goutham Pratapa wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>Yes as you said it can be interpreted as a tool that can<br>
orchestrate multiple-regions. <br>
</blockquote>
<br></span>
Actually from your additional information I'm now getting the impression that you are, in fact, positioning this as a partial competitor to Heat.<span class="gmail-"></span> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>To some extent yes, Till now we have focused on resource-synchronization and quota-balancing for various tenants across multiple-regions. But in the coming cycle we want to enter the orchestration game.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Just to be sure does openstack already has project which can<br>
replicate the resources and orchestrate???<br>
</blockquote>
<br></span>
OpenStack has an orchestration service - Heat - and it allows you to do orchestration across multiple regions by creating a nested Stack in an arbitrary region as a resource in a Heat Stack.[1]<br>
<br>
Heat includes the ability to create Nova keypairs[2] and even, for those users with sufficient privileges, flavors[3] and quotas[4][5][6]. (It used to be able to create Glance images as well, but this was deprecated because it is not feasible using the Glance v2 API.)<br>
<br>
[1] <a href="https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Heat::Stack" rel="noreferrer" target="_blank">https://docs.openstack.org/hea<wbr>t/latest/template_guide/openst<wbr>ack.html#OS::Heat::Stack</a><br>
[2] <a href="https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Nova::KeyPair" rel="noreferrer" target="_blank">https://docs.openstack.org/hea<wbr>t/latest/template_guide/openst<wbr>ack.html#OS::Nova::KeyPair</a><br>
[3] <a href="https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Nova::Flavor" rel="noreferrer" target="_blank">https://docs.openstack.org/hea<wbr>t/latest/template_guide/openst<wbr>ack.html#OS::Nova::Flavor</a><br>
[4] <a href="https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Nova::Quota" rel="noreferrer" target="_blank">https://docs.openstack.org/hea<wbr>t/latest/template_guide/openst<wbr>ack.html#OS::Nova::Quota</a><br>
[5] <a href="https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Cinder::Quota" rel="noreferrer" target="_blank">https://docs.openstack.org/hea<wbr>t/latest/template_guide/openst<wbr>ack.html#OS::Cinder::Quota</a><br>
[6] <a href="https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Neutron::Quota" rel="noreferrer" target="_blank">https://docs.openstack.org/hea<wbr>t/latest/template_guide/openst<wbr>ack.html#OS::Neutron::Quota</a><span class="gmail-"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
why because In coming<br>
cycle our idea is that a user just gives a VM-ID or Vm-name and we<br>
sync all the resources with which the vm is actually created<br>
ofcourse we cant have the same network in target-region so we may<br>
need the network-id or port-id from the target region from user so<br>
that kingbird will boot up the requested vm in the target region(s).<br>
</blockquote>
<br></span>
So it sounds like you are starting from the premise that users will create stuff in an ad-hoc way, then later discover that they need to replicate their ad-hoc deployments to multiple regions, and you're building a tool to do that. Heat, on the other hand, starts from the premise that users will invest a little up-front effort to create a declarative definition of their deployment, which they can then deploy repeatably in multiple (or the same!) regions. Our experience is that people have shown themselves to be quite willing to do this, because repeatable deployments have lots of benefits. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Yes that is true. But, our idea is the same as what you have stated above `
<b>So it sounds like you are starting from the premise that users will
create stuff in an ad-hoc way, then later discover that they need to
replicate their ad-hoc deployments to multiple regions
</b>` to reduce the repeatable deployments.<br><div>
<br>
Looking at the things you want to synchronise:<br>
<br>
* Quotas </div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Synchronize after balancing quotas across regions. (our use-case is if an admin user wants to know the global limit for a tenant across regions then he can view, update and delete from one region using Kingbird.)<br><div>
<br>
Operators can already use Heat templates to manage these if they so desire.<br>
<br>
* Flavors<br>
<br>
Some clouds allow users to create flavors, and those users can use Heat templates to manage them already. <br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br></div><div>
<br>
Operators can *not* use Heat templates to manage flavors in the same way that that can with quotas, because the OS::Nova::Flavor resource was designed with the above use-case in mind instead. (Specifically, it doesn't allow you to set the name.) Support has been requested for it in the past, however, and given the other kinds of admin-only resources we have in Heat (Quotas, Keystone resources) it would be consistent to modify OS::Nova::Flavor to allow this additional use case. <br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>> Yes, it is true but we thought of handling these issues along with our use-cases.<br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<br>
It's possible that operators could benefit from better/other tooling for Flavors and Quotas. In fact, the reason I've pushed back against some of the admin-facing stuff in Heat is that it often seems to me that Heat is an awkward tool for managing global-singleton or tenant-local-singleton administrator resources. It's definitely fine for multiple tools to co-exist, although a separate OpenStack service with an API seems like it could be overkill to me. <br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>> Our idea is the same `manage adminstrator resource` <br></div><div>
<br>
* Keypairs<br>
<br>
This is a non-issue IMHO.<br>
<br>
* Images<br>
<br>
I agree with what I think Jay is suggesting here - not that there should be a single global Glance handling multiple regions (locality is important for images), but definitely some sort of multi-region support in Glance (e.g. a built-in way to automatically replicate an image to other regions) would be a better solution than an external service doing it. Glance is always looking for new contributors :) <br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>> We definetly would love to try that and if possible contribute to glance.<br></div><div>
<br>
Though I really think the problem here is that there aren't good ways to automate image upload in general with the Glance v2 API; the multiregion part is just a for-loop. Allowing Glance to download an image from a URL (or even if it were limited to Swift objects) instead of having to upload one to it would allow us to resurrect OS::Glance::Image in Heat. <br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>> Kingbird does`not` download image from a URL and then uploads it to glance rather it uses the existing image and the replicates it into the other region . <br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>> Kingbird can also Sync Vm snapshot.(Yet to be committed. )<br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>><a href="https://github.com/openstack/kingbird/blob/master/kingbird/drivers/openstack/glance_v2.py#L149">https://github.com/openstack/kingbird/blob/master/kingbird/drivers/openstack/glance_v2.py#L149</a> <br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<br>
* Other user resources<br>
<br>
These are already handled, in a much more general way, by Heat.<br>
<br>
<br>
Honestly, it seems like a lot of wheels are being reinvented here. I think it would be more productive to start with a list of use cases and see whether the gaps can be covered by changes to existing services that they would consider in-scope. <br></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>> Kingbird does have many features like quota-management and resource-management of which one is the Multi-region Orchestration.<br></div><div><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
cheers,<br>
Zane.<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <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>
<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><br>
</div></div></div></blockquote></div><br><br></div><div><div class="gmail_extra">We really thank you for all the suggestions this definitely gives us a way forward. :)<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature"><div dir="ltr">Cheers !!!<div>Goutham Pratapa</div></div></div>
</div></div></div>