[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