Re: [openstack-dev] [all][Kingbird][Heat][Glance]Multi-Region Orchestrator

[Goutham Pratapa]

Hi Colleen,

Thanks for writing to us.

Sure, we will definitely try to help as much as we can :).



On Mon, Feb 12, 2018 at 8:44 PM, Colleen Murphy  wrote:

> On Mon, Feb 12, 2018 at 7:44 AM, Goutham Pratapa
>  wrote:
> 
> >
> > 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.
>
> Global quota management is something we're seeking to solve in
> keystone[1][2][3][4], which would enable admins to do 1, 3, and 4 via
> keystone (though admittedly this is a few cycles out). We expect to
> dive into this at the PTG if you'd like to help shape this work.
>
> [1] http://specs.openstack.org/openstack/keystone-specs/
> specs/keystone/ongoing/unified-limits.html
> [2] http://specs.openstack.org/openstack/keystone-specs/
> specs/keystone/queens/limits-api.html
> [3] https://review.openstack.org/#/c/441203/
> [4] https://review.openstack.org/#/c/540803/
>
> Colleen
>
> __
> 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
>



-- 
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

Re: [openstack-dev] [all][Kingbird][Heat][Glance]Multi-Region Orchestrator

[Colleen Murphy]

On Mon, Feb 12, 2018 at 7:44 AM, Goutham Pratapa
 wrote:

>
> 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.

Global quota management is something we're seeking to solve in
keystone[1][2][3][4], which would enable admins to do 1, 3, and 4 via
keystone (though admittedly this is a few cycles out). We expect to
dive into this at the PTG if you'd like to help shape this work.

[1] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/unified-limits.html
[2] 
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/limits-api.html
[3] https://review.openstack.org/#/c/441203/
[4] https://review.openstack.org/#/c/540803/

Colleen

__
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

Re: [openstack-dev] [all][Kingbird][Heat][Glance]Multi-Region Orchestrator

[Goutham Pratapa]

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  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 

Re: [openstack-dev] [all][Kingbird][Heat][Glance]Multi-Region Orchestrator

[Zane Bitter]

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.



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/openstack.html#OS::Heat::Stack
[2] 
https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Nova::KeyPair
[3] 
https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Nova::Flavor
[4] 
https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Nova::Quota
[5] 
https://docs.openstack.org/heat/latest/template_guide/openstack.html#OS::Cinder::Quota
[6] 
https://docs.openstack.org/heat/latest/template_guide/openstack.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.


Looking at the things you want to synchronise:

* Quotas

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.


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.


* 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 :)


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.


* 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.


cheers,
Zane.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: