Open Stack

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

> vemana.kanakadurgarao at gmail.com
>
> On Tue, 7 Jul 2015 10:24 Filip Blaha <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> 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> 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> 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]
>>>>>> *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-request at 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-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://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-request at 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-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://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/3b53075c/attachment.html>