[openstack-dev] [Murano][Congress] Application placement use case

Filip Blaha filip.blaha at hp.com
Tue Jul 7 14:16:06 UTC 2015


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 <tim at styra.com 
> <mailto:tim at 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
>         <gokrokvertskhov at mirantis.com
>         <mailto:gokrokvertskhov at 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.krishnaswamy at orange.com
>             <mailto:ruby.krishnaswamy at 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:gokrokvertskhov at mirantis.com
>                 <mailto:gokrokvertskhov at 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-request at lists.openstack.org?subject:unsubscribe
>                 <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>             <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
>     <http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150707/7d9cb52a/attachment-0001.html>


More information about the OpenStack-dev mailing list