Filip, Are you sure that this bp is still alive? Looks like the spec was freezed a month ago and development wasn't started.
Nikolay Starodubtsev Software Engineer Mirantis Inc. Skype: dark_harlequine1 2015-07-07 17:47 GMT+03:00 vemana Kanaka Durgarao <vkdrtechsa...@gmail.com>: > vemana.kanakadurga...@gmail.com > > On Tue, 7 Jul 2015 10:24 Filip Blaha <filip.bl...@hp.com> wrote: > >> 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> 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> 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 <%2B1%20650%20963%209828> >>>>>> Mob. +1 650 996 3284 <%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://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 <%2B1%20650%20963%209828> >>>>> Mob. +1 650 996 3284 <%2B1%20650%20996%203284> >>>>> >>>>> __________________________________________________________________________ >>>>> 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 >>> >>> >> >> >> -- >> 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:unsubscribehttp://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 >> > > __________________________________________________________________________ > 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
