Open Stack

Hi Suro,

Yes, I did not see a strong reason for adding "service-list" to show all of
magnum system services, but it is nice to have.

But I did see a strong reason to rename "service-list" to
"coe-service-list" or others which might be more meaningful as I was often
asked by someone why does "magnum service-list" is showing some services in
kubernetes but not magnum system itself? This command always make people
confused.

Thanks!

2015-08-03 15:36 GMT-04:00 SURO <suro.patz at gmail.com>:

> Hi Jay,
>
> Thanks for clarifying the requirements further.
>
> I do agree with the idea of having 'magnum service-list' and 'magnum
> coe-service-list' to distinguish that coe-service is a different concept.
> BUT, in openstack space, I do not see 'service-list' as a standardized
> function across other APIs -
>
>    1.  'nova service-list' => Enlists services like api, conductor etc.
>    2.  neutron does not have this option.
>    3.  'heat service-list' => Enlists available engines.
>    4.  'keystone service-list' => Enlists services/APIs who consults
>    keystone.
>
> Now in magnum, we may choose to model it after nova, but nova really has a
> bunch of backend services, viz. nova-conductor, nova-cert, nova-scheduler,
> nova-consoleauth, nova-compute[x N], whereas magnum not.
>
> For magnum, at this point creating 'service-list' only for api/conductor -
> do you see a strong need?
>
> Regards,
> SURO
> irc//freenode: suro-patz
>
> On 8/3/15 12:00 PM, Jay Lau wrote:
>
> Hi Suro and others, comments on this? Thanks.
>
> 2015-07-30 5:40 GMT-04:00 Jay Lau <jay.lau.513 at gmail.com>:
>
>> Hi Suro,
>>
>> In my understanding, even other CoE might have service/pod/rc concepts in
>> future, we may still want to distinguish the "magnum service-list" with
>> "magnum coe-service-list".
>>
>> service-list is mainly for magnum native services, such as magnum-api,
>> magnum-conductor etc.
>> coe-service-list mainly for the services that running for the CoEs in
>> magnum.
>>
>> Thoughts? Thanks.
>>
>> 2015-07-29 17:50 GMT-04:00 SURO <suro.patz at gmail.com>:
>>
>>> Hi Hongbin,
>>>
>>> What would be the value of having COE-specific magnum command to go and
>>> talk to DB? As in that case, user may use the native client itself to fetch
>>> the data from COE, which even will have latest state.
>>>
>>> In a pluggable architecture there is always scope for common abstraction
>>> and driver implementation. I think it is too early to declare
>>> service/rc/pod as specific to k8s, as the other COEs may very well converge
>>> onto similar/same concepts.
>>>
>>> Regards,
>>> SURO
>>> irc//freenode: suro-patz
>>>
>>> On 7/29/15 2:21 PM, Hongbin Lu wrote:
>>>
>>> Suro,
>>>
>>>
>>>
>>> I think service/pod/rc are k8s-specific. +1 for Jay’s suggestion about
>>> renaming COE-specific command, since the new naming style looks consistent
>>> with other OpenStack projects. In addition, it will eliminate name
>>> collision of different COEs. Also, if we are going to support pluggable
>>> COE, adding prefix to COE-specific command is unavoidable.
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Hongbin
>>>
>>>
>>>
>>> *From:* SURO [ <suro.patz at gmail.com>mailto:suro.patz at gmail.com
>>> <suro.patz at gmail.com>]
>>> *Sent:* July-29-15 4:03 PM
>>> *To:* Jay Lau
>>> *Cc:* <suro at yahoo-inc.com>suro at yahoo-inc.com; OpenStack Development
>>> Mailing List (not for usage questions)
>>> *Subject:* Re: [openstack-dev] [magnum][blueprint] magnum-service-list
>>>
>>>
>>>
>>> Hi Jay,
>>>
>>> 'service'/'pod'/'rc' are conceptual abstraction at magnum level. Yes,
>>> the abstraction was inspired from the same in kubernetes, but the data
>>> stored in DB about a 'service' is properly abstracted and not k8s-specific
>>> at the top level.
>>>
>>> If we plan to change this to 'k8s-service-list', the same applies for
>>> even creation and other actions. This will give rise to COE-specific
>>> command and concepts and which may proliferate further. Instead, we can
>>> abstract swarm's service concept under the umbrella of magnum's 'service'
>>> concept without creating k8s-service and swarm-service.
>>>
>>> I suggest we should keep the concept/abstraction at Magnum level, as it
>>> is.
>>>
>>> Regards,
>>>
>>> SURO
>>>
>>> irc//freenode: suro-patz
>>>
>>> On 7/28/15 7:59 PM, Jay Lau wrote:
>>>
>>> Hi Suro,
>>>
>>> Sorry for late. IMHO, even the "magnum service-list" is getting data
>>> from DB, but the DB is actually persisting some data for Kubernetes
>>> service, so my thinking is it possible to change "magnum service-list" to
>>> "magnum k8s-service-list", same for pod and rc.
>>>
>>> I know this might bring some trouble for backward compatibility issue,
>>> not sure if it is good to do such modification at this time. Comments?
>>>
>>> Thanks
>>>
>>>
>>>
>>> 2015-07-27 20:12 GMT-04:00 SURO < <suro.patz at gmail.com>
>>> suro.patz at gmail.com>:
>>>
>>> Hi all,
>>> As we did not hear back further on the requirement of this blueprint, I
>>> propose to keep the existing behavior without any modification.
>>>
>>> We would like to explore the decision on this blueprint on our next
>>> weekly IRC meeting[1].
>>>
>>>
>>> Regards,
>>>
>>> SURO
>>>
>>> irc//freenode: suro-patz
>>>
>>>
>>>
>>> [1] - https://wiki.openstack.org/wiki/Meetings/Containers
>>>
>>> 2015-07-28
>>>
>>> UTC 2200 Tuesday
>>>
>>>
>>>
>>> On 7/21/15 4:54 PM, SURO wrote:
>>>
>>> Hi all, [special attention: Jay Lau] The bp[1] registered, asks for the
>>> following implementation -
>>>
>>>    - 'magnum service-list' should be similar to 'nova service-list'
>>>    - 'magnum service-list' should be moved to be ' magnum
>>>    k8s-service-list'. Also similar holds true for 'pod-list'/'rc-list'
>>>
>>> As I dug some details, I find -
>>>
>>>    - 'magnum service-list' fetches data from OpenStack DB[2], instead
>>>    of the COE endpoint. So technically it is not k8s-specific. magnum is
>>>    serving data for objects modeled as 'service', just the way we are catering
>>>    for 'magnum container-list' in case of swarm bay.
>>>    - If magnum provides a way to get the COE endpoint details, users
>>>    can use native tools to fetch the status of the COE-specific objects, viz.
>>>    'kubectl get services' here.
>>>    - nova has lot more backend services, e.g. cert, scheduler,
>>>    consoleauth, compute etc. in comparison to magnum's conductor only. Also,
>>>    not all the api's have this 'service-list' available.
>>>
>>> With these arguments in view, can we have some more
>>> explanation/clarification in favor of the ask in the blueprint? [1] -
>>> <https://blueprints.launchpad.net/magnum/+spec/magnum-service-list>
>>> https://blueprints.launchpad.net/magnum/+spec/magnum-service-list [2] -
>>> <https://github.com/openstack/magnum/blob/master/magnum/objects/service.py#L114>
>>> https://github.com/openstack/magnum/blob/master/magnum/objects/service.py#L114
>>>
>>> --
>>>
>>> Regards,
>>>
>>> SURO
>>>
>>> irc//freenode: suro-patz
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Jay Lau (Guangya Liu)
>>>
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> 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
>>>
>>>
>>
>>
>> --
>> Thanks,
>>
>> Jay Lau (Guangya Liu)
>>
>
>
>
> --
> Thanks,
>
> Jay Lau (Guangya Liu)
>
>
> __________________________________________________________________________
> 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
>
>


-- 
Thanks,

Jay Lau (Guangya Liu)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150803/8b491388/attachment.html>