Open Stack

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.