Hi Tim,
Thank you for the comprehensive information.
From Murano standpoint each OpenStack region is a separate
Heat endpoint. So once Murano has a decision about placement
it will just use proper Heat endpoint to initiate stack
creation process.
Murano does not expect that Congress will do actual
placement. Murano has a way to do this by itself as it just
pushes stack template to the Heat.
As I see in your reply there is a clear way to define such
policies which is really great. It sounds like there is
nothing we need to change in the Congress itself which is
also great.
I think we have explicit Congress call in Murano, at least it
was discussed in Paris. I will check if we have someone in
Murano team who can draft a spec for this feature and use
case in Murano. Sounds like we have enough information for that.
Once again, thank you for the information.
Regards,
Gosha
On Mon, Jul 6, 2015 at 9:13 AM, Tim Hinrichs <[email protected]
<mailto:[email protected]>> wrote:
Sorry--hit the Send button by accident.
Hi Gosha,
This definitely sounds like an interesting use case
for Congress. Keep in mind that Congress doesn't
itself do placement (though we did some
experimentation with that [1][2]). Some thoughts.
1. Let's suppose Murano/Congress/etc. allow us to
figure out which app should be deployed in which
region. Is there a separate Nova for each region that
can do the actual scheduling? If not, how would
Murano force the app to be deployed in the proper region?
2. Let's assume Murano can force the app to the
proper region. One option for using Congress to
compute the proper region would be to write policy
statements that enumerate the permitted regions for a
given application, and then ask Congress for one of
those regions. For your suggested policies above, we
could write the following datalog statements
"Solaris is required then select Region_Solaris. "
permitted_region(app, "region_solaris") :-
murano:app_requires(app, "solaris")
A. If Solaris is required then select region_solaris
permitted_region(app, "region_solaris") :-
murano:app_requires(app, "solaris")
B. If Solaris is required then select less loaded regions
from [Region_Solaris1, Region_Solaris2]
This one requires additional expressiveness in the
language than we currently have (because it asks to
minimize over several options). But it would be
something like...
best_region(app, min(y)) :-
permitted_region(app, x),
ceilometer:region_load(x, y)
[1] Design doc:
https://docs.google.com/document/d/1ksDilJYXV-5AXWON8PLMedDKr9NpS8VbT0jIy_MIEtI/edit
[2] Slides:
https://drive.google.com/a/styra.com/file/d/0ByDz-eYOtswScUFUc1ZrVVhmQlk/view
Tim
On Thu, Jul 2, 2015 at 7:36 AM Georgy Okrokvertskhov
<[email protected]
<mailto:[email protected]>> wrote:
Hi,
All applications are monolithic so they don't
need to be split over multiple regions. It is
necessary to have an ability to select a region
based on requirements and for now I don't care
how they are placed inside the region.
I am not sure how region's capabilities will be
stored and actually this is a reason why I am
asking if Congress will solve this. I can imagine
a policy which says if Solaris is required then
select Region_Solaris. Or more complex If Solaris
is required then select less loaded regions from
[Region_Solaris1, Region_Solaris2]
In this use case Murano will deploy complex
environment which consist of multiple atomic
applications with different requirements, so
deployment will be across clouds but for whole
environment. Imagine IBM MQ on AIX and PowerPC +
Oracle DB on Solaris + Microsoft IIS on Windows
2012 & HyperV + WebSphere on RHEL & KVM.
Thanks
Gosha
On Wed, Jul 1, 2015 at 10:17 PM,
<[email protected]
<mailto:[email protected]>> wrote:
Hi
Did you mean placement at “two levels”. First
to select the region and then within each
region, Nova scheduler will place on hosts.
But where will the capabilities of each
region (based on which placement decision
will be made) be stored? Will each region be
queried to obtain this information?
Will a single application need to be placed
(split across) different regions?
Ruby
*De :*Georgy Okrokvertskhov
[mailto:[email protected]
<mailto:[email protected]>]
*Envoyé :* mercredi 1 juillet 2015 21:26
*À :* OpenStack Development Mailing List
*Objet :* [openstack-dev] [Murano][Congress]
Application placement use case
Hi,
I would like to share with the community one
of the real use case which we saw while
working with one of the Murano customer and
ask an advice. This customer has multiple
OpenStack regions which are serving for
different hypervisors. The reason for that is
Oracle OpenStack which is used to work with
Solaris on top of SPARC architecture. There
are other hypervisors KVM and VMWare which
are used.
There are multiple applications which should
be placed to different regions based on their
requirements (OS, Hypervisor, networking
restrictions). As there is no single cloud,
Nova scheduler can’t be used (at least in my
understanding) so we need to have some
placement policies to put applications
properly. And obviously we don’t want to ask
end user about the placement.
Right now in Murano we can do this by:
1.Hardcoding placement inside application.
This approach will work and does not require
any significant change in Murano. But there
are obvious limitations like if we have two
options for placement which one should be
hardcoded.
2.Create special placement scheduler
application\class in Murano which will use
some logic to place applications properly.
This is better approach as nothing is hard
coded in applications except their
requirements. Applications will just have a
workflow to ask placement scheduler for a
decision and then will just use this decision.
3.Use some external tool or OpenStack
component for placement decision. This is a
very generic use case which we saw multiple
times. Tools like CIRBA are often used for
this. Murano will need an interface to ask
these tools. I think about this solution as
an extension of 2.
I am aware that Murano is working on
integration with Congress and I am looking
for an opportunity here to address real use
case of Murano usage in real customer
environment. It will be great to know if
OpenStack can offer something here without
involving 3rd party tools. I suspect that
this is a good use case for Congress, but I
would like to see how it might be implemented.
Thanks
Gosha
--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com
<http://www.mirantis.com/>
Tel. +1 650 963 9828
<tel:%2B1%20650%20963%209828>
Mob. +1 650 996 3284
<tel:%2B1%20650%20996%203284>
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des
informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans
autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces
jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete
altere, deforme ou falsifie. Merci.
This message and its attachments may contain
confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without
authorisation.
If you have received this email in error, please notify
the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for
messages that have been modified, changed or falsified.
Thank you.
__________________________________________________________________________
OpenStack Development Mailing List (not for
usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com <http://www.mirantis.com/>
Tel. +1 650 963 9828 <tel:%2B1%20650%20963%209828>
Mob. +1 650 996 3284 <tel:%2B1%20650%20996%203284>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage
questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Georgy Okrokvertskhov
Architect,
OpenStack Platform Products,
Mirantis
http://www.mirantis.com <http://www.mirantis.com/>
Tel. +1 650 963 9828
Mob. +1 650 996 3284
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:[email protected]?subject:unsubscribe
<mailto:[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
