Hi, If the obsolete hardware profiles can't be used, I think the "listHardwareProfiles" should not return them (which is approach (a)).
This, however, has some implications: how should the "listNodes" behave if there are existing nodes that were created using that hardware profiles? The NodeMetadata [1] class defines its "hardware" property as "nullable", so if the "listHardwareProfiles" method does not return the obsolete hardware profiles, one can assume that the nodes created using obsolete hardawre profiles won't have that property set. There has been a recent discussion on a similar topic in the DigitalOcean provider [2], and this is the way it is being addressed. Furthermore, that node can't be deployed again with the exact same configuration, as the hardware profile is obsolete, so I think this approach would make sense. Would love to hear more opinions on this, though! :) Regarding your question about the "fromHardware" method (here are the definition [3] and the default implementation [4], for reference), my understanding is that the "fromHardware" method's purpose is to define a template that has an "equivalent" hardware configuration, but there's no need for it to be exactly the same one. If one wants a concrete hardware profile, the "hardwareId" method in the TemplateBuilder should be used instead. Does this make sense to you? Ignasi [1] https://github.com/jclouds/jclouds/blob/master/compute/src/main/java/org/jclouds/compute/domain/NodeMetadata.java#L82-L87 [2] https://github.com/jclouds/jclouds-labs/pull/58 [3] https://github.com/jclouds/jclouds/blob/master/compute/src/main/java/org/jclouds/compute/domain/TemplateBuilder.java#L41-L44 [4] https://github.com/jclouds/jclouds/blob/master/compute/src/main/java/org/jclouds/compute/domain/internal/TemplateBuilderImpl.java#L540-L552 On 25 April 2014 15:27, Andrea Turli <[email protected]> wrote: > Hi, > > I've issued a PR to fix that issue: > https://github.com/jclouds/jclouds-labs-google/pull/24 > > Please review it and merge, if ok. > > Thanks, > Andrea > > On Fri, Apr 25, 2014 at 1:49 PM, Andrea Turli <[email protected]> wrote: >> Hi Mikolaj, >> >> thanks for reporting that. I think the best approach would be to make >> jclouds aware of the obsolete machineTypes by considering the >> deprecated field in the MachineType domain object, so (b) if I get you >> right. >> >> I've already a patch that deals with it that I can submit asap. >> >> Best, >> Andrea >> >> >> >> On Fri, Apr 25, 2014 at 1:26 PM, Mikołaj Zalewski <[email protected]> >> wrote: >>> Hi, >>> When working with jclouds I've stumbled on a problem during GCE VM >>> creation. If I specify machine hardware by constraints, the framework can >>> find an obsolete hardware profile and the creation will fail (an obsolete >>> hardware profile in GCE means that one can't create new instance of this >>> platform, but there may still be instances running). I've opened JIRA >>> 550<https://issues.apache.org/jira/browse/JCLOUDS-550>for it. What's >>> the recommended way to fix this? I can think of three ways: >>> (a) don't advertise obsolete (and deleted) machine types in >>> computeService.listHardwareProfiles() >>> at all. >>> (b) add the notion of an obsolete (as well as deleted and deprecated?) >>> profile to the base Hardware object and use it in TemplateBuilderImpl to >>> filter out these profiles. >>> (c) try to use some subclassing/injections for the TemplateBuilder to >>> work differently for GCE than for others and to know about the hardware >>> states. >>> I personally don't like (c) while as for (a) and (b) I don't have the >>> experience about possible side-effects to choose one. What's you advise >>> which solution is the best? >>> >>> Mikołaj Zalewski >>> >>> PS: choosing one of the hardware profiles from >>> computeService.listHardwareProfiles() >>> and passing it to TemplateBuilder.fromHardware() doesn't necessarily lead >>> to this profile being chosen, as only some fields from the parameter are >>> used as constraints and the id is not one of them. Is this a bug or a >>> feature?
