Re: [openstack-dev] Your suggestions in the BP
Hi ya'll! Comments inline: On Sun, Jun 1, 2014 at 1:09 PM, Brandon Logan brandon.lo...@rackspace.com wrote: Hi Eugene and Sam, On Sun, 2014-06-01 at 12:07 +0400, Eugene Nikanorov wrote: Hi Sam, Eugene, please comment on the migration process bellow. I think that closing down the status handling should be done in phase 1. I don't mind. If you're talking about provisioning status then such status (if we're still going to maintain it per each kind of object) goes to various associations: loadbalancer-listener, or loadbalancer-listener-pool, etc. Not a big deal of course, it was just my initial intent to limit phase #1 as much as possible. I was hoping to limit it as well to keep it focused on just the refactoring portion. I didn't want the scope to include all new features and changes under the sun. It also makes reviewing much simpler. I'm OK with limiting scope here so long as we don't implement something that is effectively forward compatible with whatever we will probably want to do in the future. (So, having a discussion around this is probably worthwhile.) To phrase this another way, what consumes the 'status' information, and what do they really want to know? Missing to do so, will create tests and other depending workflows that assume the current status field, which will add a technology debt to this new code. I'd say it would depend on the strategy options you're suggestion below. As far as bw compatibility is concerned (if it's concerned at all), we have to support existing status field, so that would not be any additional debt. Migration and co-existence: I think that it would be better to have the new object model and API done in a way that does not break existing code, and then switch the old api to redirect to the new api. Basically this means creating another lbaas plugin, that expose existing lbaas api extension. I'm not sure how this can be done considering the difference between new proposed api and existing api. This might be done in one of the two ways bellow: 1. Rename all objects in the new api so you have a clear demarcation point. This might be sufficient. I'm not sure how this could be done, can you explain? I actually would consider changing the prefix to /v3/ to not to deal with any renamings, that would require some minor refactoring on extension framework side. His suggestion in the BP was to rename pool, healthmonitor, and member to group, healthcheck, and node respectively. Since loadbalancer and listener are already new those don't have to be renamed. This way the old object models and db tables remain intact and the old API can still function as before. 2. Copy the existing LBaaS extension and create a new-lbaas extension with new object names, then create a new old lbaas extension that has the old API but redirect to the new API I also don't fully understand this, please explain. I need more clarification on this as well. Sounds like you're saying to create a lbaas extension v2 with the new object names. Then copy the existing lbaas extension and change it to redirect to the v2 extension. If that is the case, why create a new old lbaas and just change the old lbaas extension? Doing 2, can allow co-existence of old code with old drivers until new code with new drivers can take its place. New extension + new plugin, is that what you are suggesting? To me it would be the cleanest and the most simple way to execute the transition, but... i'm not sure it was a consensus on design session. I agree this would be the cleanest but I was under the impression this was not an accepted way to go. I'd honestly prefer a v2 extension and v2 plugin. This would require different names for the object model and db tables since you don't want the old api and new api sharing the same tables. We can either append v2 to the names or rename them entirely. Sam suggested group for pool, healthcheck for healthmonitor, and node for member. I'd prefer nodepool for pool myself. nodepool isn't a bad name, eh. To throw this into the pot, too: How about 'backend' for the renamed pool (or does that imply too much)? Either way, I need to know if we can go with this route or not. I've started on writing the code a bit but relationship conversations has stalled that some. I think if we can go with this route it will make the code much more clear. Thanks, Brandon Yep, knowing this is going to be key to where we need to put engineering time into this, eh. Stephen -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Your suggestions in the BP
Hi Brandon Eugene and Everyone, Eugene, please comment on the migration process bellow. I think that closing down the status handling should be done in phase 1. Missing to do so, will create tests and other depending workflows that assume the current status field, which will add a technology debt to this new code. Migration and co-existence: I think that it would be better to have the new object model and API done in a way that does not break existing code, and then switch the old api to redirect to the new api. This might be done in one of the two ways bellow: 1. Rename all objects in the new api so you have a clear demarcation point. This might be sufficient. 2. Copy the existing LBaaS extension and create a new-lbaas extension with new object names, then create a new old lbaas extension that has the old API but redirect to the new API Doing 2, can allow co-existence of old code with old drivers until new code with new drivers can take its place. Regards, -Sam. -Original Message- From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Friday, May 30, 2014 6:38 PM To: Samuel Bercovici Subject: Your suggestions in the BP Hi Sam! Thanks for the suggestions. I don't think the different statuses should be addressed in the blueprint. I think it would be better left to have its own focus in its own blueprint. I feel the same way about the subnet_id. I think if this blueprint focuses just on the object model change and the migration to it, it would be better. As for having a v2 version of all the table or entirely new tables. Are you suggesting just keeping the old API going to the old object models and database tables? Also, if say I renamed the pool object to nodepool (I prefer that over group), then are you also suggesting the new API will have a /nodepools resource along with the object model NodePool and database table nodepool? I'm intrigued by this idea, but wasn't totally clear on what you were suggesting. Thanks, Brandon ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Your suggestions in the BP
Hi Sam, Eugene, please comment on the migration process bellow. I think that closing down the status handling should be done in phase 1. I don't mind. If you're talking about provisioning status then such status (if we're still going to maintain it per each kind of object) goes to various associations: loadbalancer-listener, or loadbalancer-listener-pool, etc. Not a big deal of course, it was just my initial intent to limit phase #1 as much as possible. Missing to do so, will create tests and other depending workflows that assume the current status field, which will add a technology debt to this new code. I'd say it would depend on the strategy options you're suggestion below. As far as bw compatibility is concerned (if it's concerned at all), we have to support existing status field, so that would not be any additional debt. Migration and co-existence: I think that it would be better to have the new object model and API done in a way that does not break existing code, and then switch the old api to redirect to the new api. Basically this means creating another lbaas plugin, that expose existing lbaas api extension. I'm not sure how this can be done considering the difference between new proposed api and existing api. This might be done in one of the two ways bellow: 1. Rename all objects in the new api so you have a clear demarcation point. This might be sufficient. I'm not sure how this could be done, can you explain? I actually would consider changing the prefix to /v3/ to not to deal with any renamings, that would require some minor refactoring on extension framework side. 2. Copy the existing LBaaS extension and create a new-lbaas extension with new object names, then create a new old lbaas extension that has the old API but redirect to the new API I also don't fully understand this, please explain. Doing 2, can allow co-existence of old code with old drivers until new code with new drivers can take its place. New extension + new plugin, is that what you are suggesting? To me it would be the cleanest and the most simple way to execute the transition, but... i'm not sure it was a consensus on design session. Thanks, Eugene. Regards, -Sam. -Original Message- From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Friday, May 30, 2014 6:38 PM To: Samuel Bercovici Subject: Your suggestions in the BP Hi Sam! Thanks for the suggestions. I don't think the different statuses should be addressed in the blueprint. I think it would be better left to have its own focus in its own blueprint. I feel the same way about the subnet_id. I think if this blueprint focuses just on the object model change and the migration to it, it would be better. As for having a v2 version of all the table or entirely new tables. Are you suggesting just keeping the old API going to the old object models and database tables? Also, if say I renamed the pool object to nodepool (I prefer that over group), then are you also suggesting the new API will have a /nodepools resource along with the object model NodePool and database table nodepool? I'm intrigued by this idea, but wasn't totally clear on what you were suggesting. Thanks, Brandon ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Your suggestions in the BP
Hi Eugene and Sam, On Sun, 2014-06-01 at 12:07 +0400, Eugene Nikanorov wrote: Hi Sam, Eugene, please comment on the migration process bellow. I think that closing down the status handling should be done in phase 1. I don't mind. If you're talking about provisioning status then such status (if we're still going to maintain it per each kind of object) goes to various associations: loadbalancer-listener, or loadbalancer-listener-pool, etc. Not a big deal of course, it was just my initial intent to limit phase #1 as much as possible. I was hoping to limit it as well to keep it focused on just the refactoring portion. I didn't want the scope to include all new features and changes under the sun. It also makes reviewing much simpler. Missing to do so, will create tests and other depending workflows that assume the current status field, which will add a technology debt to this new code. I'd say it would depend on the strategy options you're suggestion below. As far as bw compatibility is concerned (if it's concerned at all), we have to support existing status field, so that would not be any additional debt. Migration and co-existence: I think that it would be better to have the new object model and API done in a way that does not break existing code, and then switch the old api to redirect to the new api. Basically this means creating another lbaas plugin, that expose existing lbaas api extension. I'm not sure how this can be done considering the difference between new proposed api and existing api. This might be done in one of the two ways bellow: 1. Rename all objects in the new api so you have a clear demarcation point. This might be sufficient. I'm not sure how this could be done, can you explain? I actually would consider changing the prefix to /v3/ to not to deal with any renamings, that would require some minor refactoring on extension framework side. His suggestion in the BP was to rename pool, healthmonitor, and member to group, healthcheck, and node respectively. Since loadbalancer and listener are already new those don't have to be renamed. This way the old object models and db tables remain intact and the old API can still function as before. 2. Copy the existing LBaaS extension and create a new-lbaas extension with new object names, then create a new old lbaas extension that has the old API but redirect to the new API I also don't fully understand this, please explain. I need more clarification on this as well. Sounds like you're saying to create a lbaas extension v2 with the new object names. Then copy the existing lbaas extension and change it to redirect to the v2 extension. If that is the case, why create a new old lbaas and just change the old lbaas extension? Doing 2, can allow co-existence of old code with old drivers until new code with new drivers can take its place. New extension + new plugin, is that what you are suggesting? To me it would be the cleanest and the most simple way to execute the transition, but... i'm not sure it was a consensus on design session. I agree this would be the cleanest but I was under the impression this was not an accepted way to go. I'd honestly prefer a v2 extension and v2 plugin. This would require different names for the object model and db tables since you don't want the old api and new api sharing the same tables. We can either append v2 to the names or rename them entirely. Sam suggested group for pool, healthcheck for healthmonitor, and node for member. I'd prefer nodepool for pool myself. Either way, I need to know if we can go with this route or not. I've started on writing the code a bit but relationship conversations has stalled that some. I think if we can go with this route it will make the code much more clear. Thanks, Brandon Thanks, Eugene. Regards, -Sam. -Original Message- From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Friday, May 30, 2014 6:38 PM To: Samuel Bercovici Subject: Your suggestions in the BP Hi Sam! Thanks for the suggestions. I don't think the different statuses should be addressed in the blueprint. I think it would be better left to have its own focus in its own blueprint. I feel the same way about the subnet_id. I think if this blueprint focuses just on the object model change and the migration to it, it would be better. As for having a v2 version of all the table or entirely new tables. Are you suggesting just keeping the old API going to the old object models and database tables? Also,
