Re: [openstack-dev] [kuryr][kuryr-kubernetes] Propose to support Kubernetes Network Custom Resource Definition De-facto Standard Version 1
Cool. I'll start to prepare a BP for this, so we can have more detailed discussion. On Wed, Jun 6, 2018 at 11:08 PM, Antoni Segura Puimedon wrote: > On Wed, Jun 6, 2018 at 2:37 PM, Irena Berezovsky > wrote: > > Sounds like a great initiative. > > > > Lets follow up on the proposal by the kuryr-kubernetes blueprint. > > I fully subscribe what Irena said. Let's get on this quick! > > > > > BR, > > Irena > > > > On Wed, Jun 6, 2018 at 6:47 AM, Peng Liu wrote: > >> > >> Hi Kuryr-kubernetes team, > >> > >> I'm thinking to propose a new BP to support Kubernetes Network Custom > >> Resource Definition De-facto Standard Version 1 [1], which was drafted > by > >> network plumbing working group of kubernetes-sig-network. I'll call it > NPWG > >> spec below. > >> > >> The purpose of NPWG spec is trying to standardize the multi-network > effort > >> around K8S by defining a CRD object 'network' which can be consumed by > >> various CNI plugins. I know there has already been a BP VIF-Handler And > Vif > >> Drivers Design, which has designed a set of mechanism to implement the > >> multi-network functionality. However I think it is still worthwhile to > >> support this widely accepted NPWG spec. > >> > >> My proposal is to implement a new vif_driver, which can interpret the > PoD > >> annotation and CRD defined by NPWG spec, and attach pod to additional > >> neutron subnet and port accordingly. This new driver should be mutually > >> exclusive with the sriov and additional_subnets drivers.So the endusers > can > >> choose either way of using mult-network with kuryr-kubernetes. > >> > >> Please let me know your thought, any comments are welcome. > >> > >> > >> > >> [1] > >> https://docs.google.com/document/d/1Ny03h6IDVy_e_vmElOqR7UdTPAG_ > RNydhVE1Kx54kFQ/edit#heading=h.hylsbqoj5fxd > >> > >> > >> Regards, > >> > >> -- > >> Peng Liu > >> > >> > __ > >> 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 > > > > __ > 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 > -- Peng Liu __ 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] [kuryr][kuryr-kubernetes] Propose to support Kubernetes Network Custom Resource Definition De-facto Standard Version 1
Hi Kuryr-kubernetes team, I'm thinking to propose a new BP to support Kubernetes Network Custom Resource Definition De-facto Standard Version 1 [1], which was drafted by network plumbing working group of kubernetes-sig-network. I'll call it NPWG spec below. The purpose of NPWG spec is trying to standardize the multi-network effort around K8S by defining a CRD object 'network' which can be consumed by various CNI plugins. I know there has already been a BP VIF-Handler And Vif Drivers Design, which has designed a set of mechanism to implement the multi-network functionality. However I think it is still worthwhile to support this widely accepted NPWG spec. My proposal is to implement a new vif_driver, which can interpret the PoD annotation and CRD defined by NPWG spec, and attach pod to additional neutron subnet and port accordingly. This new driver should be mutually exclusive with the sriov and additional_subnets drivers.So the endusers can choose either way of using mult-network with kuryr-kubernetes. Please let me know your thought, any comments are welcome. [1] https://docs.google.com/document/d/1Ny03h6IDVy_e_vmElOqR7UdTPAG_ RNydhVE1Kx54kFQ/edit#heading=h.hylsbqoj5fxd Regards, -- Peng Liu __ 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] [neutron][l2gw] Preventing DB out-of-sync
Hi Michael, Yes, it's a similar issue but different aspect. Actually, the case for l2gw is worse, considering we have to deal with 2 existing back-end driver which have different understanding for the interfaces. But I think the proposed approach for networking-ovn is inspiring and helpful for l2gw. Thanks, On Fri, Dec 8, 2017 at 11:59 PM, Michael Bayer <mba...@redhat.com> wrote: > On Wed, Dec 6, 2017 at 3:46 AM, Peng Liu <p...@redhat.com> wrote: > > Hi, > > > > During working on this patch[0], I encounter some DB out-of-sync > problem. I > > think maybe the design can be improved. Here is my thought, all comments > are > > welcome. > > > see also https://review.openstack.org/#/c/490834/ which I think is > dealing with a similar (if not the same) issue. > > > > > In plugin code, I found all the resource operations follow the pattern in > > [1]. It is a very misleading design compare to [2]. > > > > "For every action that can be taken on a resource, the mechanism driver > > exposes two methods - ACTION_RESOURCE_precommit, which is called within > the > > database transaction context, and ACTION_RESOURCE_postcommit, called > after > > the database transaction is complete." > > > > In result, if we focus on the out-of-sync between plugin DB and > > driver/backend DB: > > > > 1) In RPC driver, only methods Action_Resource and are implemented. Which > > means the action is token before it was written in plugin DB. In case of > > action partial succeed (especially for update case) or plugin DB > operation > > failure, it will cause DB out-of-sync. > > 2) In ODL driver, only methods Action_Resource_postcommit are > implemented, > > which means there is no validation in ODL level before the record is > written > > in the plugin DB. In case of, ODL side failure, there is no rollback for > > plugin DB. > > > > So, to fix this issue is costly. Both plugin and driver sides need to be > > altered. > > > > The other side of this issue is a period db monitor mechanism between > plugin > > and drivers, and it is another story. > > > > > > [0] https://review.openstack.org/#/c/516256 > > [1] > > ... > > def Action_Resource > > self.validate_Resource_for_Action > > self.driver.Action_Resource > > with context.session.begin(subtransactions=True): > > super.Action_Resource > > self.driver.Action_Resource_precommit > > try: > > self.driver.Action_Resource_postcommit > > ... > > [2] https://wiki.openstack.org/wiki/Neutron/ML2 > > > > -- > > Peng Liu > > > > > __ > > 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 > -- Peng Liu | Senior Software Engineer Tel: +86 10 62608046 (direct) Mobile: +86 13801193245 Red Hat Software (Beijing) Co., Ltd. 9/F, North Tower C, Raycom Infotech Park, No.2 Kexueyuan Nanlu, Haidian District, Beijing, China, POC 100190 __ 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] [neutron][l2gw] Preventing DB out-of-sync
Hi, During working on this patch[0], I encounter some DB out-of-sync problem. I think maybe the design can be improved. Here is my thought, all comments are welcome. In plugin code, I found all the resource operations follow the pattern in [1]. It is a very misleading design compare to [2]. "For every action that can be taken on a resource, the mechanism driver exposes two methods - ACTION_RESOURCE_precommit, which is called within the database transaction context, and ACTION_RESOURCE_postcommit, called after the database transaction is complete." In result, if we focus on the out-of-sync between plugin DB and driver/backend DB: 1) In RPC driver, only methods Action_Resource and are implemented. Which means the action is token before it was written in plugin DB. In case of action partial succeed (especially for update case) or plugin DB operation failure, it will cause DB out-of-sync. 2) In ODL driver, only methods Action_Resource_postcommit are implemented, which means there is no validation in ODL level before the record is written in the plugin DB. In case of, ODL side failure, there is no rollback for plugin DB. So, to fix this issue is costly. Both plugin and driver sides need to be altered. The other side of this issue is a period db monitor mechanism between plugin and drivers, and it is another story. [0] https://review.openstack.org/#/c/516256 [1] ... def Action_Resource self.validate_Resource_for_Action self.driver.Action_Resource with context.session.begin(subtransactions=True): super.Action_Resource self.driver.Action_Resource_precommit try: self.driver.Action_Resource_postcommit ... [2] https://wiki.openstack.org/wiki/Neutron/ML2 -- Peng Liu __ 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] [qa] [patrole] Question regarding Patrole API coverage
Hi Team, I have a question regarding to the API coverage of Patrole. Currently, Patrole as a Tempest plugin heavily relys on the Tempest code. However, Tempest only contains the API tests for the most common APIs of the most common projects(Nova, Neutron, Cinder, Glance, Swift, Keystone). So I want to know if it is possible to extend Patrole to: 1) test the APIs of the common projects which was not yet covered in Tempest. 2) test projects which was not covered in Tempest? Thanks, -- Peng Liu __ 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] [glance] Image encryption
Hi, I've been looking at the bp[1], which used to be named 'Glance Image Signing and Encryption' at beginning. But encryption was remove after a meet-up according [2]. Could anyone tell me 1) why the the image encryption was removed? 2) if it still makes sense for Glance to have such functionality? [1] https://blueprints.launchpad.net/glance/+spec/image-signing-and-verification-support [2] https://etherpad.openstack.org/p/liberty-glance-image-signing-and-encryption Thanks, -- Peng Liu __ 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] [tripleo] Consistent way of integrating services with different backends
I think the option 1) is a better choice. Since: 1. The api and agent talk through RPC. So it is unnecessarily to have both the api and agent service on the same node. Separate composable service is more appropriate here. 2. In the l2gw_plugin.ini file, it suggests that the service_provider could have more than one line. which means the odl and ovs agent might coexisted. On Thu, Apr 6, 2017 at 9:15 PM, Giulio Fidente <gfide...@redhat.com> wrote: > On Thu, 2017-04-06 at 13:07 +0200, Ricardo Noriega De Soto wrote: > > Hi owls! > > > > This is something that I've been discussing in the IRC channel but > > still I > > think we should define a consistent way of integrating services which > > support different backends. In this case, I'm refering to BGPVPN and > > L2GW > > Neutron services, but it could be applied to any other type of > > service. > > yes indeed there is a similar issue with the storage services and thei > supported backends > > > These two Neutron service plugins support different backends such an > > agent > > and a SDN controller (OpenDaylight). Usually the reference > > architecture > > will use the agents. > > > > My main question is about how to model this into THT properly. > > > > It is clear that we have to create two different composable services: > > one > > for the API and one for the agent. However, how many environment > > files we > > should have and which should be the content? > > currently for cinder we use a tht service for each backend; multiple > backends can be enabled at the same time; having multiple instances of > the same backend is a bit trickier and requires some yaml editing > > > i.e. L2GW project > > > > Option 1: > > > >- neutron-l2gw-api.yaml enabling the corresponding API composable > >service. > >- neutron-l2gw-agent.yaml enabling the corresponding agent > > composable > >service. > > > > openstack overcloud deploy -e neutron-l2gw-api.yaml -e > > neutron-l2gw-agent.yaml (with agent) > > openstack overcloud deploy -e neutron-l2gw-api.yaml -e > > neutron-opendaylight-l3.yaml (with ODL) > > > > Option 2: > > > >- neutron-l2gw.yaml enabling the API and the agent as a reference > >architecture scenario. > >- neutron-l2gw-odl.yaml enabling the API with OpenDaylight as > >service_provider > > > > openstack overcloud deploy -e neutron-l2gw.yaml (with agent) > > openstack overcloud deploy -e neutron-l2gw-odl.yaml -e > > neutron-opendaylight-l3.yaml (with ODL) > > > > > > I'm not really pushing for any option, but I'm just concern from the > > user > > experience point of view. As a user, which way is more friendly? or > > understandable? Where in the documentation is this reflected? > > I am not sure there is a single answer; option 2) seems to me more user > friendly and easier to consume in the UI > > Yet when working on the integration of CephMDS and the Manila/CephFS > backend, we decided to use two different environment files, one to > enable CephMDS and one to enable the CephFS backend in Manila. This was > so that operators could deploy CephMDS without Manila, to provide > CephFS to the overcloud or connect the Manila/CephFS backend to an > external unmanaged Ceph cluster and use only one or the other > environment file. > > My conclusion, if there aren't reasons to deploy the two services > indepedently, I'd probably go with option 2), if there are reasons to > deploy only one of them, option 1) is the only one which seems to allow > that avoiding yaml edits to the users. > > __ > 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 > -- Peng Liu | Senior Software Engineer Tel: +86 10 62608046 (direct) Mobile: +86 13801193245 Red Hat Software (Beijing) Co., Ltd. 9/F, North Tower C, Raycom Infotech Park, No.2 Kexueyuan Nanlu, Haidian District, Beijing, China, POC 100190 __ 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
