[openstack-dev] [Murano][Congress] Application placement use case
Filip Blaha
filip.blaha at hp.com
Tue Jul 7 15:58:40 UTC 2015
Hi Nikolay,
I am not sure about that. I mentioned it because bellow described
usecase could be argument to continue work on that.
Filip
On 07/07/2015 05:29 PM, Nikolay Starodubtsev wrote:
> 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
> <vkdrtechsavvy at gmail.com <mailto:vkdrtechsavvy at gmail.com>>:
>
> vemana.kanakadurgarao at gmail.com
> <mailto:vemana.kanakadurgarao at gmail.com>
>
>
> On Tue, 7 Jul 2015 10:24 Filip Blaha <filip.blaha at hp.com
> <mailto:filip.blaha at 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 <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 <mailto:OpenStack-dev-request at 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
>
>
> __________________________________________________________________________
> 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://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/ed6bb45e/attachment-0001.html>
More information about the OpenStack-dev
mailing list