Hi, Zane, Sorry for the late reply I was on leave for a couple of days.
Firstly, Thanks for the clear in detail analysis and suggestions on quotas and resources-management it really means a lot to us :). Secondly, these are the use-cases which kingbird is mainly developed for. *OUR USE-CASES QUOTA-MANAGEMENT:* 1. Admin must have a global view of all quotas to all tenants across all the regions 2. Admin can periodically balance the quotas (we have a formula using which we do this balancing ) across regions 3. Admin can update, Delete quotas for tenants 4. Admin can sync quotas for all tenants so that the quotas will be updated in all regions. *USE-CASES FOR RESOURCE-MANAGEMENT:* 1. Resources which are required to boot up a VM in One region should be accessible in other target-regions In the process, Kingbird has support for the following a) Sync/Replicate existing Nova-Keypairs b) Sync/Replicate existing Glance-Images c) Sync/Replicate existing Nova-Flavors.(Only admin can sync these.) 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) a) It can be a snapshot of the already booted-up VM or with the same qcow2 image. *GENERIC USE-CASES* 1. Automation scripts for kingbird in -ansible, -salt -puppet. 2. Add SSL support to kingbird 3. Resource management in Kingbird-dashboard. 4. Kingbird in a docker 5. Add Kingbird into Kolla. On Fri, Feb 9, 2018 at 12:47 AM, Zane Bitter <zbit...@redhat.com> wrote: > On 07/02/18 12:24, Goutham Pratapa wrote: > >> >Yes as you said it can be interpreted as a tool that can >> orchestrate multiple-regions. >> > > Actually from your additional information I'm now getting the impression > that you are, in fact, positioning this as a partial competitor to Heat. >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. > > Just to be sure does openstack already has project which can >> replicate the resources and orchestrate??? >> > > 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] > > 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.) > > [1] https://docs.openstack.org/heat/latest/template_guide/openst > ack.html#OS::Heat::Stack > [2] https://docs.openstack.org/heat/latest/template_guide/openst > ack.html#OS::Nova::KeyPair > [3] https://docs.openstack.org/heat/latest/template_guide/openst > ack.html#OS::Nova::Flavor > [4] https://docs.openstack.org/heat/latest/template_guide/openst > ack.html#OS::Nova::Quota > [5] https://docs.openstack.org/heat/latest/template_guide/openst > ack.html#OS::Cinder::Quota > [6] https://docs.openstack.org/heat/latest/template_guide/openst > ack.html#OS::Neutron::Quota > > why because In coming >> cycle our idea is that a user just gives a VM-ID or Vm-name and we >> sync all the resources with which the vm is actually created >> ofcourse we cant have the same network in target-region so we may >> need the network-id or port-id from the target region from user so >> that kingbird will boot up the requested vm in the target region(s). >> > > 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. > Yes that is true. But, our idea is the same as what you have stated above > ` *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 *` to reduce the > repeatable deployments. > > Looking at the things you want to synchronise: > > * Quotas > > 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.) > > Operators can already use Heat templates to manage these if they so desire. > > * Flavors > > Some clouds allow users to create flavors, and those users can use Heat > templates to manage them already. > > > > 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. > > Yes, it is true but we thought of handling these issues along with our > use-cases. > > 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. > > Our idea is the same `manage adminstrator resource` > > * Keypairs > > This is a non-issue IMHO. > > * Images > > 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 :) > > We definetly would love to try that and if possible contribute to glance. > > 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. > > 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 . > > Kingbird can also Sync Vm snapshot.(Yet to be committed. ) > > > https://github.com/openstack/kingbird/blob/master/kingbird/drivers/openstack/glance_v2.py#L149 > > * Other user resources > > These are already handled, in a much more general way, by Heat. > > > 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. > > Kingbird does have many features like quota-management and > resource-management of which one is the Multi-region Orchestration. > > > cheers, > Zane. > > __________________________________________________________________________ > 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 > We really thank you for all the suggestions this definitely gives us a way forward. :) -- 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