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 ). 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) > >  Design doc: > https://docs.google.com/document/d/1ksDilJYXV-5AXWON8PLMedDKr9NpS8VbT0jIy_MIEtI/edit >  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> 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> 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] >>> *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 >>> Tel. +1 650 963 9828 >>> Mob. +1 650 996 3284 >>> >>> _________________________________________________________________________________________________________________________ >>> >>> 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> >> >> -- >> Georgy Okrokvertskhov >> Architect, >> OpenStack Platform Products, >> Mirantis >> 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