I think the code is already used in production (that being the reason it is already marked as production-ready).
________________________________________ From: Ignasi Barrera [[email protected]] Sent: Thursday, March 27, 2014 12:12 PM To: <[email protected]> Cc: dev Subject: Re: proposed neutron refactoring in jclouds-labs-openstack I'm in general in favour of any code cleanup that simplifies things and makes it easier to evolve the providers. The only problem I see here is the deprecation path: we can have the old and new methods in the api, one accepting the old CreateNetworkOptions and the new one using the new class. But we can't, if I've understood properly, deprecate the Network class and use it in both methods, so there's no happy deprecation path. Being in labs allows us to break some stuff, but that doesn't mean we can go ahead with all we want. I'm personally OK with the refactor but I'd first send an email to the user list to see who is currently using the Neutron api. I. El 26/03/2014 22:01, "Zack Shoylev" <[email protected]> escribió: > I think the current neutron implementation could benefit from some > refactoring. It is however already marked as production ready and used, so > some of the changes might break user code. So this is a big problem, > obviously - I need some help figuring out if it is worth it. > Other upcoming neutron work is of course adding the extension code from > previous PRs that were not merged completely (such as [1]), as well as the > rest of the extensions. There are quite a few. > > Things currently already merged that I am considering for changes: > > Remove Reference and ReferenceWithName [2]; > These will be refactored by moving the name/id/tenant_id fields to the > respective classes (such as Network or Port in the examples I use here). > This is needed for the next step. > > Ensure class inheritance follows, for example, > Network extends CreateNetwork > where CreateNetwork or List<CreateNetwork> would be the parameter object > in NetworkApi.create (instead of CreateNetworkOptions) and Network, again, > will be the result. > In this example Network extends CreateNetwork to add fields such as id, > tenant_id, name (these were mentioned above) as well as *other* fields that > the service returns. > This change might also improve on an issue mentioned here [3] > > The two steps above will help move validation to the domain objects > constructors, and hopefully remove the need to use explicit JSON binders > and options code. > > Also (I could be missing something) I don't see the need for BulkPort and > BulkNetwork - these should be similar enough to the refactored > CreateNetwork and CreatePort. > > Example: > > Network Create json request: > { > "network": > { > "name": "sample_network", > "admin_state_up": false > } > } > > bulk network create: > { > "networks":[ > { > "name":"sample_network_1", > "admin_state_up":false > }, > { > "name":"sample_network_2", > "admin_state_up":false > } > ] > } > > The questions is: is this worth it? The code seems functional enough. > Thanks! > > [1] https://github.com/jclouds/jclouds-labs-openstack/pull/44 > [2] > https://github.com/jclouds/jclouds-labs-openstack/blob/master/openstack-neutron/src/main/java/org/jclouds/openstack/neutron/v2_0/domain/ReferenceWithName.java > [3] http://www.mail-archive.com/[email protected]/msg04384.html
