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: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
