Open Stack

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150707/8a10ce3e/attachment.html>