Open Stack

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]
> *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
>     <mailto: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: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/20150729/848ab304/attachment.html>