Re: [openstack-dev] [Magnum] Obtain the objects from the bay endpoint
Hi Stdake and Vilobh, If I get what you proposed below, you means pod/rc/service would not be stored in magnum side, Just retrieved and updated in k8s side ? For now, if magnum not add any specific logic to pod/rc/service, that can be OK. Thanks Best Wishes, Kai Qiang Wu (吴开强 Kennan） IBM China System and Technology Lab, Beijing E-mail: wk...@cn.ibm.com Tel: 86-10-82451647 Address: Building 28(Ring Building), ZhongGuanCun Software Park, No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193 Follow your heart. You are miracle! From: Steven Dake (stdake) std...@cisco.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: 08/12/2015 11:52 PM Subject:Re: [openstack-dev] [Magnum] Obtain the objects from the bay endpoint From: Akash Gangil akashg1...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Date: Wednesday, August 12, 2015 at 1:37 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Magnum] Obtain the objects from the bay endpoint Hi, I have a few questions. inline. Problem :- Currently objects (pod/rc/service) are read from the database. In order for native clients to work, they must be read from the ReST bay endpoint. To execute native clients, we must have one truth of the state of the system, not two as in its current state of art. What is meant by the native clients here? Can you give an example? Native client is docker binary or kubectl from those various projects. We also need to support python-magnumclient operations to support further Heat integration, which allows Magnum to be used well with proprietary software implementations that may be doing orchestration via Heat. A] READ path needs to be changed : 1. For python clients :- python-magnum client-rest api-conductor-rest-endpoint-k8s-api handler In its present state of art this is python-magnum client-rest api-db 2. For native clients :- native client-rest-endpoint-k8s-api If native client can get all the info through the rest-endpoint-k8s handler, why in case of magnum client do we need to go through rest-api- conductor? Do we parse or modify the k8s-api data before responding to the python-magnum client? Kubernetes has a rest API endpoint running in the bay. This is different from the Magnum rest API. This is what is referred to above. B] WRITE operations need to happen via the rest endpoint instead of the conductor. If we completely bypass the conductor, is there any way to keep a track of trace of how a resource was modified? Since I presume now magnum doesn't have that info, since we talk to k8s-api directly? Or is this irrelevant? C] Another requirement that needs to be satisfied is that data returned by magnum should be the same whether its created by native client or python-magnum client. I don't understand why is the information duplicated in the magnum db and k8s data source in first place? From what I understand magnum has its own database which is with k8s-api responses? The reason it is duplicated is because when I wrote the original code, I didn’t forsee this objective. Essentially I’m not perfect ;) The fix will make sure all of the above conditions are met. Need your input on the proposed approach. ACK accurate of my understanding of the proposed approach :) -Vilobh [1] https://blueprints.launchpad.net/magnum/+spec/objects-from-bay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Akash __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Magnum] Obtain the objects from the bay endpoint
From: Akash Gangil akashg1...@gmail.commailto:akashg1...@gmail.com Reply-To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Wednesday, August 12, 2015 at 1:37 AM To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Magnum] Obtain the objects from the bay endpoint Hi, I have a few questions. inline. Problem :- Currently objects (pod/rc/service) are read from the database. In order for native clients to work, they must be read from the ReST bay endpoint. To execute native clients, we must have one truth of the state of the system, not two as in its current state of art. What is meant by the native clients here? Can you give an example? Native client is docker binary or kubectl from those various projects. We also need to support python-magnumclient operations to support further Heat integration, which allows Magnum to be used well with proprietary software implementations that may be doing orchestration via Heat. A] READ path needs to be changed : 1. For python clients :- python-magnum client-rest api-conductor-rest-endpoint-k8s-api handler In its present state of art this is python-magnum client-rest api-db 2. For native clients :- native client-rest-endpoint-k8s-api If native client can get all the info through the rest-endpoint-k8s handler, why in case of magnum client do we need to go through rest-api- conductor? Do we parse or modify the k8s-api data before responding to the python-magnum client? Kubernetes has a rest API endpoint running in the bay. This is different from the Magnum rest API. This is what is referred to above. B] WRITE operations need to happen via the rest endpoint instead of the conductor. If we completely bypass the conductor, is there any way to keep a track of trace of how a resource was modified? Since I presume now magnum doesn't have that info, since we talk to k8s-api directly? Or is this irrelevant? C] Another requirement that needs to be satisfied is that data returned by magnum should be the same whether its created by native client or python-magnum client. I don't understand why is the information duplicated in the magnum db and k8s data source in first place? From what I understand magnum has its own database which is with k8s-api responses? The reason it is duplicated is because when I wrote the original code, I didn’t forsee this objective. Essentially I’m not perfect ;) The fix will make sure all of the above conditions are met. Need your input on the proposed approach. ACK accurate of my understanding of the proposed approach :) -Vilobh [1] https://blueprints.launchpad.net/magnum/+spec/objects-from-bay__ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Akash __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Magnum] Obtain the objects from the bay endpoint
Hi Vilobh, Do we need to do something similar for a Swarm bay? Ton Ngo, From: Vilobh Meshram vilobhmeshram.openst...@gmail.com To: OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org, OpenStack Mailing List (not for usage questions) openst...@lists.openstack.org Date: 08/11/2015 08:50 PM Subject:[openstack-dev] [Magnum] Obtain the objects from the bay endpoint Hi All, As discussed in today's Magnum weekly meeting I had shown interest to work on [1]. Problem :- Currently objects (pod/rc/service) are read from the database. In order for native clients to work, they must be read from the ReST bay endpoint. To execute native clients, we must have one truth of the state of the system, not two as in its current state of art. sdake and I discussed about it on IRC and we plan to propose following solution :- Approach to solve the problem :- A] READ path needs to be changed : 1. For python clients :- python-magnum client-rest api-conductor-rest-endpoint-k8s-api handler In its present state of art this is python-magnum client-rest api-db 2. For native clients :- native client-rest-endpoint-k8s-api B] WRITE operations need to happen via the rest endpoint instead of the conductor. C] Another requirement that needs to be satisfied is that data returned by magnum should be the same whether its created by native client or python-magnum client. The fix will make sure all of the above conditions are met. Need your input on the proposed approach. -Vilobh [1] https://blueprints.launchpad.net/magnum/+spec/objects-from-bay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Magnum] Obtain the objects from the bay endpoint
Hi, I have a few questions. inline. Problem :- Currently objects (pod/rc/service) are read from the database. In order for native clients to work, they must be read from the ReST bay endpoint. To execute native clients, we must have one truth of the state of the system, not two as in its current state of art. What is meant by the native clients here? Can you give an example? A] READ path needs to be changed : 1. For python clients :- python-magnum client-rest api-conductor-rest-endpoint-k8s-api handler In its present state of art this is python-magnum client-rest api-db 2. For native clients :- native client-rest-endpoint-k8s-api If native client can get all the info through the rest-endpoint-k8s handler, why in case of magnum client do we need to go through rest-api- conductor? Do we parse or modify the k8s-api data before responding to the python-magnum client? B] WRITE operations need to happen via the rest endpoint instead of the conductor. If we completely bypass the conductor, is there any way to keep a track of trace of how a resource was modified? Since I presume now magnum doesn't have that info, since we talk to k8s-api directly? Or is this irrelevant? C] Another requirement that needs to be satisfied is that data returned by magnum should be the same whether its created by native client or python-magnum client. I don't understand why is the information duplicated in the magnum db and k8s data source in first place? From what I understand magnum has its own database which is with k8s-api responses? The fix will make sure all of the above conditions are met. Need your input on the proposed approach. -Vilobh [1] *https://blueprints.launchpad.net/magnum/+spec/objects-from-bay* https://blueprints.launchpad.net/magnum/+spec/objects-from-bay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Akash __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Magnum] Obtain the objects from the bay endpoint
Hi All, As discussed in today's Magnum weekly meeting I had shown interest to work on [1]. Problem :- Currently objects (pod/rc/service) are read from the database. In order for native clients to work, they must be read from the ReST bay endpoint. To execute native clients, we must have one truth of the state of the system, not two as in its current state of art. sdake and I discussed about it on IRC and we plan to propose following solution :- Approach to solve the problem :- A] READ path needs to be changed : 1. For python clients :- python-magnum client-rest api-conductor-rest-endpoint-k8s-api handler In its present state of art this is python-magnum client-rest api-db 2. For native clients :- native client-rest-endpoint-k8s-api B] WRITE operations need to happen via the rest endpoint instead of the conductor. C] Another requirement that needs to be satisfied is that data returned by magnum should be the same whether its created by native client or python-magnum client. The fix will make sure all of the above conditions are met. Need your input on the proposed approach. -Vilobh [1] https://blueprints.launchpad.net/magnum/+spec/objects-from-bay __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
