[Microservice] Port Manager #180

chenpiaoping · 2020-04-29T09:00:39Z

This PR contains the following features:

Basic operations such as get, create, update and delete of port.
Rollback is supported when the operation of port failed.
Add async executor to the lib/executor directory.
Add microservice rest clients to the web/restclient directory.
Move the entities of each microservice to the web/entity directory so that it can be used when communicating between microservices.

lib/src/main/java/com/futurewei/alcor/common/entity/HostState.java

...manager/src/main/java/com/futurewei/alcor/portmanager/exception/AllocateIpAddrException.java

xieus · 2020-04-30T23:27:49Z

...manager/src/main/java/com/futurewei/alcor/portmanager/service/implement/PortServiceImpl.java

+        return "range1";
+    }
+
+    private void allocateIpAddress(PortState portState, Stack<PortStateRollback> rollbacks) throws Exception {


The idea of using a rollback stack to keep track of potential rollback call is good.

The issue, however, is that it might not work in current implementation. If an exception is thrown before rollbacks.push(ipAddressRollback), then the stack doesn't have ipAddressRollback therefore won't be able to trigger rollback during exception handling.

Yes, we can consider it in two cases. First, if an exception occurs before receiving the rest response, there is no need to roll back. Second, if an exception occurs after receiving the rest response, it needs to be rolled back, so we need to ensure that there is no exception between the rest response and rollbacks.push (). In fact, rollbacks.push () is executed after receiving the rest response, so we can assume that there will be no exception between them.

I want to deal with the rollbacks of various operations in a unified way by a common method. This method does not need to judge whether the operation needs to be rolled back, and does not need to care about what to be rolled back, this should be concerned by the operation itself. There may be a better way, do you have any good suggestions?

@chenpiaoping I miss your previous comment in this thread. Unifying the rollback is a good idea but depending on how we are going to do it.

Regarding the first case, let us say Service A => Service B, and the modify (POST or PUT or DELETE) request has been sent but no yet received a response, an exception is received at this time. It is still necessary that Service A send roolback to Service B.

Oh, this is indeed a big problem. Does subnet manager have the same problem?

https://github.com/futurewei-cloud/alcor/pull/180/commits/0a4c96a05592534af52680abe72f9d5d6f364d28，This commit is going to solve this problem.

Thanks let me check it.

xieus · 2020-04-30T23:34:41Z

...manager/src/main/java/com/futurewei/alcor/portmanager/service/implement/PortServiceImpl.java

+        }
+    }
+
+    private PortStateJson tryCreatePortState(String projectId, PortState portState, Stack<PortStateRollback> rollbacks) throws Exception {


The calls into various downstream microservices remain serial and sync.

One recommended way is to async call into multiple microservices in parallel. See the implementation of Subnet Manager for an example.

https://github.com/futurewei-cloud/alcor/blob/a4db5c2b368e1a500f4defd62de174d375419392/services/subnet_manager/src/main/java/com/futurewei/alcor/subnet/controller/SubnetController.java

Okay, I will do that.

Nice work on support Async with a generic AsyncExecutor class. Like it!

If this mechanism is approved by you, I will move it to the lib directory

Sure. Go for it :-)

lib/src/main/java/com/futurewei/alcor/common/entity/DeviceOwner.java

services/port_manager/src/main/java/com/futurewei/alcor/portmanager/utils/Ipv4AddrUtil.java

xieus · 2020-05-08T05:17:13Z

...manager/src/main/java/com/futurewei/alcor/portmanager/service/implement/PortServiceImpl.java

+    }
+
+    private void tryCreatePortState(PortState portState, Stack<PortStateRollback> rollbacks) throws Exception {
+        //Verify VPC ID


We should verify Subnet ID, instead of Vpc Id here.

@xieus But port may not have a Subnet ID. In this case, we need to find a suitable subnet for port, and assign an ip address to port from that subnet.

Correct. We have multiple cases to cover, most of the cases would require to verify subnet ID.

https://docs.openstack.org/api-ref/network/v2/?expanded=create-port-detail#ports

(1) If a user specifies a subnet ID in the optional fixed_ips field, then we have to verify that subnet Id
(2) If the user doesn't give any fixed_ips, we handle it as you suggested.

@xieus For the first case, I think we need to get the range ID by Subnet ID (At this point, the Subnet ID will be verified), and then assign an ip address from the ip range. At present, Subnet manager have not provided an interface to obtain the Range ID by the Subnet ID. I discussed this with kevin, and he said he would think about it.

I think we could make this verification simple by calling the regular Get /subnets/{subnet_id} and the response includes the range ids. @kevin-zhonghao

One discipline is that we follow the same workflows for both case (1) and case (2).

You could either go to SubnetManager to verify subnetId or vpcId, retrieve the range id, and then go to IP manager,
OR, build a mapping in IP manager from VpcId to rangeID as well as SubnetId to RangeId, and only need go to IP manager.

Yes, for the case of going to SubnetManager to retrieve a range id, Since SubnetManager do not know whether there is an available ip address in the range, we may need to go to SubnetManager many times to obtain a available range.

@xieus Ip manager provides an interface that randomly assigns ip addresses according to vpcId. Is this solution okay? I'm ready to develop.

@chenpiaoping Rethinking the issue, we might have to pick the option of " go to SubnetManager to verify subnetId or vpcId, retrieve the range id, and then go to IP manager".

The reason is that PortManager needs to visit both RouteManager and IPManager to retrieve routes and to allocate ip, respectively. SubnetManger is the source of truth to retrieve the routes under the subnet and to get the ip range id under the same subnet.

Therefore, the workflow is like this:

Port Manager => SubnetManager
1.1 If Subnet Id is known, send and verify subnet Id, retrieve routes under the subnet (as SubnetManager has the latest routes) and to get range Id
1.2 Otherwise, send vpc id to SubnetManager, SubnetManager picks one subnet, and the rest is the same as Step 1.1

Port Manager => Ip Manager, send the range id from Step 1, and allocate ip from the given range.

Currently, Step 1.1 needs a new API from SubnetManager. @kevin-zhonghao and I will work to create one in a parallel PR (#181).

@xieus I have submitted the code, but it is a little different from what you described. Can you review it?

xieus · 2020-05-08T05:26:23Z

...manager/src/main/java/com/futurewei/alcor/portmanager/service/implement/PortServiceImpl.java

+        //Verify security group
+
+        //If port binds host, to send it's information to host
+


Need two more calls:
(1) One into RouteManager to get the routing rules of the subnet that this port belong to. The list of routing rules is the superset of Neutron router and could include SNAT/DNAT rules.

For now, I would recommend you to look into Subnet implementation regarding how to call RouteManager.

alcor/services/subnet_manager/src/main/java/com/futurewei/alcor/subnet/service/implement/SubnetServiceImp.java

Line 120 in 2ae412f

@Override

(2) The other into NodeManager which is under development.
PR: https://github.com/futurewei-cloud/alcor/pull/185/files

The API you could be interested in is GET /nodes/{nodeid}.

Should I get route info from RouteManager or from SubnetManager? I found that RouteManager only has the interface to get route info by Vpc ID(/ vpcs/ {vpcId} / routes/ {routeId}), and there is no interface to get route info by Subnet ID. However, SubnetManager will store route info, which will be stored in RouteManager, VpcManager. Will it take up too much memory?

For the interaction with node manager, Can i come back to do it after the development of node manager finish?

@chenpiaoping Regarding NodeManager, PR #185 is under review and should be merged pretty soon so I would recommend to write the codes based on the current APIs. You could comment out for now and test only when NodeManager is merged. Should be soon.

Regarding routing rules, I suggest to still go to RouteManager as that is the ultimate source of truth for routing information.
I think your point is very good. We possibly need to add a new API in RouteManager to allow query by SubnetId. Add @kevin-zhonghao for awareness.

Regarding memory usage of storing routes in SubnetManager and VpcManager that might occupy too much memory, we haven't seen that case yet so storing routes in the upstream microservices could cut the latency for GET.

If you find such a case, let me know and we could quickly revisit this design.

okay, xieus.

xieus · 2020-05-09T14:15:13Z

Question: the latest MockServer will auto generate a new Ingite sub-directory under private_ip_manager after mvn test. What is it used for? We likely need to add the whole sub-directory to .gitignore.

xieus · 2020-05-09T14:21:55Z

After turning on ip manager UTs (commit #5c598ab), some of UTs failed as it tried to connect to Redis.

https://jenkins.alkaidcloud.io/job/alcor-controller-pr-test/298/console

+---------------------------------------------------------------------------------+
Ignite ver. 2.8.0#20200226-sha1:341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6 stopped OK
+---------------------------------------------------------------------------------+
Grid uptime: 00:00:00.529

[�[1;31mERROR�[m] �[1;31mTests �[0;1mrun: �[0;1m14�[m, Failures: 0, �[1;31mErrors: �[0;1;31m13�[m, Skipped: 0, Time elapsed: 3.438 s�[1;31m <<< FAILURE!�[m - in com.futurewei.alcor.privateipmanager.controller.�[1mIpAddrControllerTest�[m
[�[1;31mERROR�[m] Test01_createIpAddrRangeTest Time elapsed: 0.319 s <<< ERROR!
org.springframework.web.util.NestedServletException: Request processing failed; nested exception is com.futurewei.alcor.common.db.CacheException: Unable to connect to Redis; nested exception is io.lettuce.core.RedisConnectionException: Unable to connect to localhost:6379
at com.futurewei.alcor.privateipmanager.controller.IpAddrControllerTest.Test01_createIpAddrRangeTest(IpAddrControllerTest.java:63)
Caused by: com.futurewei.alcor.common.db.CacheException: Unable to connect to Redis; nested exception is io.lettuce.core.RedisConnectionException: Unable to connect to localhost:6379
at com.futurewei.alcor.privateipmanager.controller.IpAddrControllerTest.Test01_createIpAddrRangeTest(IpAddrControllerTest.java:63)

chenpiaoping · 2020-05-11T01:49:37Z

services/private_ip_manager/pom.xml

Question: the latest MockServer will auto generate a new Ingite sub-directory under private_ip_manager after mvn test. What is it used for? We likely need to add the whole sub-directory to .gitignore.

After turning on ip manager UTs (commit #5c598ab), some of UTs failed as it tried to connect to Redis.

https://jenkins.alkaidcloud.io/job/alcor-controller-pr-test/298/console

+---------------------------------------------------------------------------------+
Ignite ver. 2.8.0#20200226-sha1:341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6 stopped OK
+---------------------------------------------------------------------------------+
Grid uptime: 00:00:00.529

[�[1;31mERROR�[m] �[1;31mTests �[0;1mrun: �[0;1m14�[m, Failures: 0, �[1;31mErrors: �[0;1;31m13�[m, Skipped: 0, Time elapsed: 3.438 s�[1;31m <<< FAILURE!�[m - in com.futurewei.alcor.privateipmanager.controller.�[1mIpAddrControllerTest�[m
[�[1;31mERROR�[m] Test01_createIpAddrRangeTest Time elapsed: 0.319 s <<< ERROR!
org.springframework.web.util.NestedServletException: Request processing failed; nested exception is com.futurewei.alcor.common.db.CacheException: Unable to connect to Redis; nested exception is io.lettuce.core.RedisConnectionException: Unable to connect to localhost:6379
at com.futurewei.alcor.privateipmanager.controller.IpAddrControllerTest.Test01_createIpAddrRangeTest(IpAddrControllerTest.java:63)
Caused by: com.futurewei.alcor.common.db.CacheException: Unable to connect to Redis; nested exception is io.lettuce.core.RedisConnectionException: Unable to connect to localhost:6379
at com.futurewei.alcor.privateipmanager.controller.IpAddrControllerTest.Test01_createIpAddrRangeTest(IpAddrControllerTest.java:63)

I have deleted the maven-surefire-plugin package in this commit: 8c4831b, do we need to add it back again?

chenpiaoping · 2020-05-11T01:59:36Z

does this set of UTs have to run in order?

Yes, I annotated @ FixMethodOrder (MethodSorters.NAME_ASCENDING), and all the UT's name is prefixed with TESTxx_, which ensures the order they run.

chenpiaoping · 2020-05-11T02:06:56Z

We likely need to add the whole sub-directory to .gitignore.

Is the working directory that contains information that ignite nodes need, let me add it to .gitignore.

chenpiaoping · 2020-05-11T02:11:02Z

After turning on ip manager UTs (commit #5c598ab), some of UTs failed as it tried to connect to Redis.

https://jenkins.alkaidcloud.io/job/alcor-controller-pr-test/298/console

+---------------------------------------------------------------------------------+
Ignite ver. 2.8.0#20200226-sha1:341b01dfd8abf2d9b01d468ad1bb26dfe84ac4f6 stopped OK
+---------------------------------------------------------------------------------+
Grid uptime: 00:00:00.529

[�[1;31mERROR�[m] �[1;31mTests �[0;1mrun: �[0;1m14�[m, Failures: 0, �[1;31mErrors: �[0;1;31m13�[m, Skipped: 0, Time elapsed: 3.438 s�[1;31m <<< FAILURE!�[m - in com.futurewei.alcor.privateipmanager.controller.�[1mIpAddrControllerTest�[m
[�[1;31mERROR�[m] Test01_createIpAddrRangeTest Time elapsed: 0.319 s <<< ERROR!
org.springframework.web.util.NestedServletException: Request processing failed; nested exception is com.futurewei.alcor.common.db.CacheException: Unable to connect to Redis; nested exception is io.lettuce.core.RedisConnectionException: Unable to connect to localhost:6379
at com.futurewei.alcor.privateipmanager.controller.IpAddrControllerTest.Test01_createIpAddrRangeTest(IpAddrControllerTest.java:63)
Caused by: com.futurewei.alcor.common.db.CacheException: Unable to connect to Redis; nested exception is io.lettuce.core.RedisConnectionException: Unable to connect to localhost:6379
at com.futurewei.alcor.privateipmanager.controller.IpAddrControllerTest.Test01_createIpAddrRangeTest(IpAddrControllerTest.java:63)

I tried to add maven-surefire-plugin back in the pom.xml file, it's ok in my IDEA env.

xieus

A few comments on the restWrap and rest classes. I like those classes in general.

xieus · 2020-05-13T15:47:54Z

services/port_manager/src/main/java/com/futurewei/alcor/portmanager/utils/BeanUtil.java

+import org.springframework.stereotype.Component;
+
+@Component
+public class BeanUtil implements ApplicationContextAware {


It would fit into the scope of AlcorLib. Let us move it there.

yes, I thought too, but it didn't work.

Is this because of "@component" that you will need to launch this bean within the scope of AlcorPortManager?

Oh, maybe, Let me have a try.

web/src/main/java/com/futurewei/alcor/web/rest/AbstractRest.java

web/src/main/java/com/futurewei/alcor/web/rest/VpcRest.java

...s/port_manager/src/main/java/com/futurewei/alcor/portmanager/restwrap/IpAddressRestWrap.java

xieus · 2020-05-14T05:34:03Z

...s/port_manager/src/main/java/com/futurewei/alcor/portmanager/restwrap/IpAddressRestWrap.java

+
+    public List<IpAddrRequest> verifyIpAddresses(Object args) throws Exception {
+        List<IpAddrRequest> ipAddrRequests = new ArrayList<>();
+        List<PortState.FixedIp> fixedIps = (List<PortState.FixedIp>)args;


In general, direct type casting is not recommended for downcasting.

Could you try cast() and isInstance() methods for safer downcasting?

A reference: https://www.baeldung.com/java-type-casting

Don't worry, an exception will be thrown if there is a type conversion error, which is exactly what I expected when the type conversion failed.

xieus · 2020-05-14T05:41:10Z

...s/port_manager/src/main/java/com/futurewei/alcor/portmanager/restwrap/IpAddressRestWrap.java

+        List<IpAddrRequest> ipAddrRequests = new ArrayList<>();
+        PortState portState = (PortState)args;
+
+        IpAddrRequest result = ipAddressRest.allocateIpAddress(IpVersion.IPV4,


How about Ipv6? Could we use sth like "portState.IpVersion" instead of fixing with IPv4?

There is no ipVersion field in portState, do you think only ipv4 address is assigned to port by default, or both ipv4 and ipv6 addresses are assigned?

I see. Ipv4v6 is something we need to support as well. Maybe put it in your backlog and do it when you get a chance.

xieus · 2020-05-14T05:42:52Z

...manager/src/main/java/com/futurewei/alcor/portmanager/service/implement/PortServiceImpl.java

+            if (portState.getFixedIps() == null) {
+                executor.runAsync(ipAddressRestWrap::allocateIpAddress, portState);
+            } else {
+                executor.runAsync(ipAddressRestWrap::verifyIpAddresses, portState.getFixedIps());


allocateIpAddress => allocateRandomIpAddress
verifyIpAddresses=> allocateFixedIpAddress

sounds reasonable.

xieus · 2020-05-14T05:45:55Z

...manager/src/main/java/com/futurewei/alcor/portmanager/service/implement/PortServiceImpl.java

+            if (portState.getMacAddress() == null) {
+                executor.runAsync(macAddressRestWrap::allocateMacAddress, portState);
+            } else {
+                executor.runAsync(macAddressRestWrap::verifyMacAddress, portState);


allocateMacAddress => allocateRandomMacAddress
verifyMacAddress => allocateFixedMacAddress

xieus · 2020-05-14T05:54:12Z

.../port_manager/src/main/java/com/futurewei/alcor/portmanager/restwrap/MacAddressRestWrap.java

+
+    public MacStateJson verifyMacAddress(Object args) {
+        //FIXME: Not support yet
+        return null;


API (2) in Mac manager actually could set a fixed mac address in the rest body (the impl might not be there but at least the interface has that).

Ref: https://github.com/futurewei-cloud/alcor/blob/master/docs/design/mac_manager.adoc

that would be nice.

xieus · 2020-05-14T06:03:31Z

...manager/src/main/java/com/futurewei/alcor/portmanager/service/implement/PortServiceImpl.java

+            portRepository.addItem(portState);
+        } catch (Exception e) {
+            /**
+            When an exception occurs, we need to roll back all asynchronous operations,


Hmm, this is really tricky. We will need a good Timeout story to upper bound the rollback.

xieus

One last comment: We need to add comments for each and every important method in Controller, Service, Service Impl and Repo.

RestWrap and Rollback is not straightforward therefore would require some level of comments as well.

xieus · 2020-05-14T06:14:42Z

...manager/src/main/java/com/futurewei/alcor/portmanager/service/implement/PortServiceImpl.java

+
+    }
+
+    public PortStateJson updatePortState(String projectId, String portId, PortStateJson portStateJson) throws Exception {


Looks like we'll need a bit more time for updatePortState. It is fine and let us do it in next PR.

xieus · 2020-05-14T06:15:35Z

services/port_manager/src/main/java/com/futurewei/alcor/portmanager/service/PortService.java

+import java.util.List;
+
+@Service
+public interface PortService {


We will need the bulk create API.

...ort_manager/src/test/java/com/futurewei/alcor/portmanager/controller/PortControllerTest.java

...s/port_manager/src/main/java/com/futurewei/alcor/portmanager/restwrap/IpAddressRestWrap.java

...es/port_manager/src/main/java/com/futurewei/alcor/portmanager/controller/PortController.java

xieus · 2020-05-14T11:58:53Z

services/port_manager/src/main/java/com/futurewei/alcor/portmanager/proxy/IpManagerProxy.java

+     * Allocate a random ipv4 and ipv6 address from ip manager service
+     * @param args PortState
+     * @return A list of IpAddrRequest
+     * @throws Exception Rest request exception


@chenpiaoping, my previous comment may not be 100% clear. I meant that IPv4 only and Ipv4v6 should both be supported, with IPv4 only the default option.

I see, should i revert it?

Those are good change. Maybe by default we only trigger Ipv4 allocation, but add one more flag to trigger additional Ipv6 allocation.

Neutron may or may not have this field. Let me quickly check.

I think if there is ipv6 subnet in the vpc, the ipv6 address will be assigned.

My current implementation may not be very reasonable.

It is totally fine, we do the development and design in an iterative/agile way: When we find it something not right, we change it quickly.

My current thinking is: This should be a consistent behavior on VPC level. If a VPC allows Ipv6, every of its Subnets will have Ipv6 ranges therefore trigger Ipv4v6 allocation here.

In our Subnet Object, there is a Ipv4RangeId and a Ipv6RangeId. Therefore our logic could be that if the Ipv6RangeId is not null, we allocate Ipv6 here. Does this make sense?

Agree with you, but i think i need to make some changes in ip manager.

It's time for me to get off work, will do it tomorrow.

I see. Might not be a small change considering here requires a full set of UTs.

Let us comment out Ipv6 allocation part in this PR, and continue to improve it in next PR.

xieus · 2020-05-14T12:06:35Z

web/src/main/java/com/futurewei/alcor/web/restclient/MacManagerRestClient.java

@@ -40,11 +40,12 @@ public void releaseMacAddress(String macAddress) throws Exception {
        restTemplate.delete(url);
    }

-    public MacStateJson allocateMacAddress(String projectId, String vpcId, String portId) throws Exception {
+    public MacStateJson allocateMacAddress(String projectId, String vpcId, String portId, String mac) throws Exception {


is this a macAddress or macId?

Let me rename it.

No worries. I made changes to expedite the merge.

xieus

Approved! This PR provides a solid foundation for port manager. We could continue to polish it for a few pending items, like ip allocation, bulk port creation, and update port.

xieus · 2020-05-14T15:34:21Z

@chenpiaoping UTs are partially turned on with six commented out for now. Please take a look.

chenpiaoping changed the title ~~Port manager~~ [Micro-service] Port Manager Apr 29, 2020

xieus requested review from xieus, haboy52581, kimeunju108 and kevin-zhonghao April 29, 2020 16:56

xieus assigned chenpiaoping Apr 29, 2020

xieus added feature feature development unit test Unit test labels Apr 29, 2020

xieus added this to the Version 0.4.2020.04.30 milestone Apr 29, 2020

xieus linked an issue Apr 29, 2020 that may be closed by this pull request

[Micro-service] Port Manager #159

Closed

xieus reviewed Apr 29, 2020

View reviewed changes

lib/src/main/java/com/futurewei/alcor/common/entity/HostState.java Outdated Show resolved Hide resolved

...manager/src/main/java/com/futurewei/alcor/portmanager/exception/AllocateIpAddrException.java Outdated Show resolved Hide resolved

xieus reviewed Apr 30, 2020

View reviewed changes

lib/src/main/java/com/futurewei/alcor/common/entity/DeviceOwner.java Outdated Show resolved Hide resolved

xieus reviewed May 1, 2020

View reviewed changes

services/port_manager/src/main/java/com/futurewei/alcor/portmanager/utils/Ipv4AddrUtil.java Outdated Show resolved Hide resolved

chenpiaoping force-pushed the port-manager branch 2 times, most recently from 550316e to 6fefe46 Compare May 7, 2020 08:36

xieus reviewed May 8, 2020

View reviewed changes

chenpiaoping force-pushed the port-manager branch 4 times, most recently from 7edcb4e to 8c4831b Compare May 9, 2020 09:37

chenpiaoping force-pushed the port-manager branch from dd5d2ea to b3f39f0 Compare May 11, 2020 02:40

rebase from master and add Dockerfile for port manager

dbb419c

chenpiaoping force-pushed the port-manager branch 5 times, most recently from 885c7ec to 0a23e9a Compare May 13, 2020 12:56

move entities to web service(conflict with entities of subnet manager)

0a23e9a

xieus reviewed May 14, 2020

View reviewed changes

...s/port_manager/src/main/java/com/futurewei/alcor/portmanager/restwrap/IpAddressRestWrap.java Outdated Show resolved Hide resolved

chenpiaoping force-pushed the port-manager branch 3 times, most recently from 5b84398 to aa8c0f9 Compare May 14, 2020 11:35

made some optimizations according to the review suggestions

aa8c0f9

xieus reviewed May 14, 2020

View reviewed changes

...es/port_manager/src/main/java/com/futurewei/alcor/portmanager/controller/PortController.java Show resolved Hide resolved

Merge branch 'master' into port-manager

3394dd3

xieus reviewed May 14, 2020

View reviewed changes

xieus approved these changes May 14, 2020

View reviewed changes

Liguang Xie added 3 commits May 14, 2020 07:25

Add Swagger doc/ui support

c5060b0

Turn on partial UTs and change rest field from port_state to port

b08ac39

Rename mac to macAddress in MacManagerRestClient and MacManagerProxy

7a61860

xieus changed the title ~~[Micro-service] Port Manager~~ [Microservice] Port Manager May 14, 2020

xieus merged commit bfc9d9d into futurewei-cloud:master May 14, 2020

This was referenced May 15, 2020

[Port Manager] Fix bug where rest client is unachievable from SpringContextUtil #196

Merged

[Port Manager] Add Bulk operation & Integrate with Route/SGM #197

Merged

		//Verify security group

		//If port binds host, to send it's information to host


		}

		public PortStateJson updatePortState(String projectId, String portId, PortStateJson portStateJson) throws Exception {

[Microservice] Port Manager #180

[Microservice] Port Manager #180

Conversation

chenpiaoping commented Apr 29, 2020 • edited by xieus Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xieus commented May 9, 2020

xieus commented May 9, 2020

chenpiaoping commented May 11, 2020

chenpiaoping commented May 11, 2020

chenpiaoping commented May 11, 2020

chenpiaoping commented May 11, 2020 • edited Loading

xieus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xieus May 14, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xieus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

xieus left a comment

Choose a reason for hiding this comment

xieus commented May 14, 2020

chenpiaoping commented Apr 29, 2020 •

edited by xieus

Loading

chenpiaoping commented May 11, 2020 •

edited

Loading

xieus May 14, 2020 •

edited

Loading