[openstack-dev] [magnum][blueprint] magnum-service-list
SURO
suro.patz at gmail.com
Mon Aug 3 19:36:32 UTC 2015
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
> <mailto: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
> <mailto: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]
>> *Sent:* July-29-15 4:03 PM
>> *To:* Jay Lau
>> *Cc:* suro at yahoo-inc.com <mailto: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
>> <mailto: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://OpenStack-dev-request@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: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/20150803/25aee293/attachment-0001.html>
More information about the OpenStack-dev
mailing list