Open Stack

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 [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; 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 [2] -
>> 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150803/7e5041e1/attachment.html>