[openstack-dev] [neutron]load service provider dynamically

Germy Lure germy.lure at gmail.com
Fri Oct 24 07:26:10 UTC 2014


Hi,
Can anyone give me some suggestion?

Thanks.
Germy

On Tue, Oct 21, 2014 at 2:25 PM, Germy Lure <germy.lure at gmail.com> wrote:

> Hi all,
>
> Maybe my description is not clear enough.
> As is known to everyone, service provider provides ability for plugins to
> schedule a different vendor. It is just a factor of scheduling. We should
> integrate this into a United Schedule Module(USM) which provides scheduling
> service for every plugins. This scheduling service can be based on
> capability, resource, vendor, user-specific requirement and so on.
> So how to get those information from back-ends? Statically configuring or
> dynamically reporting? And those info are changing should be taken into
> consideration. It's important to note that we have reported something in
> current agent report implementation.
> My suggestion is that agents (and controllers in phase 2) report their
> capability, vendor, and other info to the USM in core. Every plugin invokes
> the USM to schedule not dose it by their selves. We can even wrap
> scheduling into agent-calling method(aka service driver), plugins can be
> standardized and do not care vendors, agent or controller and other things.
>
> BR,
> Germy
>
>
> On Mon, Oct 20, 2014 at 2:59 PM, Germy Lure <germy.lure at gmail.com> wrote:
>
>> Hi Mathieu,
>>
>> Thanks for your response.
>> I'm so sorry to reply you util today.(I was on a vacation)
>> I have some comments inline.
>>
>> BR,
>> Germy
>>
>> On Wed, Oct 8, 2014 at 7:34 PM, Mathieu Rohon <mathieu.rohon at gmail.com>
>> wrote:
>>
>>> Hi germy,
>>>
>>> thanks for this interesting proposal.
>>> To go further, It would be interesting to insert in your framework the
>>> capacity to load service plugin dynamically, not only service providers.
>>>
>> Thanks for your suggestion. I think this has been included in the
>> evolution part.
>>
>>> It as been discussed here [1][2]f or GBP needs, but it's something
>>> interesting for other service plugin which want to be hosted in a
>>> independent (stackforge) project.
>>>
>> It is different. My proposal targets agent and controller not plugin.
>>
>>> There is a line in the etherpad for kilo design summit about that [3]. I
>>> hope this will be discussed.
>>>
>> Yes, I also hope.
>>
>>>
>>> [1]https://review.openstack.org/#/c/116996/
>>> [2]https://review.openstack.org/#/c/123620/
>>> [3]https://etherpad.openstack.org/p/kilo-neutron-summit-topics
>>>
>>> Mathieu
>>>
>>> On Tue, Oct 7, 2014 at 3:51 PM, Germy Lure <germy.lure at gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I have an idea about service provider framework. Anyone interested in
>>>> this topic can give me some suggestions.
>>>>
>>>> My idea is that providers report their services capability dynamically
>>>> not configured in neutron.conf. See details by the link below.
>>>>
>>>> https://docs.google.com/presentation/d/1_uNF0JEDyoFor8xj-MaaacPL334hiWJWB7NzfRrcVJg/edit?usp=sharing
>>>>
>>>> Everyone can comment this doc.
>>>>
>>>> Here are the main pages.
>>>>
>>>>
>>>>
>>>>>>>>
>>>>
>>>>
>>>>>>>>
>>>>
>>>>
>>>> ​BR,
>>>> Germy
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> 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/20141024/19b0db17/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4.png
Type: image/png
Size: 35588 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141024/19b0db17/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.png
Type: image/png
Size: 37611 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141024/19b0db17/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3.png
Type: image/png
Size: 52202 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141024/19b0db17/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.png
Type: image/png
Size: 43224 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141024/19b0db17/attachment-0007.png>


More information about the OpenStack-dev mailing list