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
>>> 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
