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