Hi all,
there is related blueprint [1]. Once it will be implemented it could
support this usecase. So policy defined in congress modifies environment
prior deployment. I think this mechanism could be used to enforce
placement to region/AZ.
[1]
https://blueprints.launchpad.net/murano/+spec/policy-based-env-modification
Regards
Filip
On 07/06/2015 08:40 PM, Georgy Okrokvertskhov wrote:
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 <t...@styra.com
<mailto:t...@styra.com>> 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
<gokrokvertsk...@mirantis.com
<mailto:gokrokvertsk...@mirantis.com>> 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,
<ruby.krishnasw...@orange.com
<mailto:ruby.krishnasw...@orange.com>> 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:gokrokvertsk...@mirantis.com
<mailto:gokrokvertsk...@mirantis.com>]
*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:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?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:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
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
