Re: [openstack-dev] [nova][libvirt][baremetal] Nova Baremetal's Usage of Components from Libvirt
The second option would be to make a copy of the old ImageCacheManager in the Baremetal directory, and have the Baremetal driver use that. This seems to me to be the better option, since it means that when the Baremetal driver is removed, the old ImageCacheManager code goes with it, without someone having to manually remove it. I might get shot in the head, but I think option 2 makes the most sense. There is no need to do _new_ work in support of a dead codebase. Agreed, making a copy isn't the end of the world, and we know we're going to delete it soonish anyway. We've asked the ironic folks to do a lot to make the baremetal transition easy and I see no reason to add a refactor dependency to the list so it can be deleted in six months :) --Dan signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][libvirt][baremetal] Nova Baremetal's Usage of Components from Libvirt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/05/2014 02:49 PM, Dan Smith wrote: The second option would be to make a copy of the old ImageCacheManager in the Baremetal directory, and have the Baremetal driver use that. This seems to me to be the better option, since it means that when the Baremetal driver is removed, the old ImageCacheManager code goes with it, without someone having to manually remove it. I might get shot in the head, but I think option 2 makes the most sense. There is no need to do _new_ work in support of a dead codebase. Agreed, making a copy isn't the end of the world, and we know we're going to delete it soonish anyway. We've asked the ironic folks to do a lot to make the baremetal transition easy and I see no reason to add a refactor dependency to the list so it can be deleted in six months :) +1. Just copy it. More work seems like wasted effort. - -- Russell Bryant -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPhMYwACgkQFg9ft4s9SAb2OgCcDiyXhV55P9++SBcM9iCouw8L nroAnRkPDFPkLRlsqa/dEr5HUaBbIAeF =1h0p -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][libvirt][baremetal] Nova Baremetal's Usage of Components from Libvirt
On Tue, Aug 5, 2014 at 11:49 AM, Dan Smith d...@danplanet.com wrote: The second option would be to make a copy of the old ImageCacheManager in the Baremetal directory, and have the Baremetal driver use that. This seems to me to be the better option, since it means that when the Baremetal driver is removed, the old ImageCacheManager code goes with it, without someone having to manually remove it. I might get shot in the head, but I think option 2 makes the most sense. There is no need to do _new_ work in support of a dead codebase. Agreed, making a copy isn't the end of the world, and we know we're going to delete it soonish anyway. We've asked the ironic folks to do a lot to make the baremetal transition easy and I see no reason to add a refactor dependency to the list so it can be deleted in six months :) ++ -Deva ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][libvirt][baremetal] Nova Baremetal's Usage of Components from Libvirt
On 08/04/2014 03:54 PM, Solly Ross wrote: Hello All, So, I'm working on https://review.openstack.org/#/c/111459/, and have encountered an issue. It seems that the Nova Baremetal driver uses the ImageCacheManager from the Libvirt driver. For various reasons (see the commit), the ImageCacheManager has been refactored to require a libvirt connection to function properly. However, the Nova Baremetal driver cannot provide such a connection. Bearing in mind that Baremetal is deprecated and slated to be replaced by Ironic, the question is such: what to do about the ImageCacheManager. One option would be to make it so that the ImageCacheManager can function without a libvirt connection. This might make sense if the Baremetal driver were around to stay; there would be somewhat less duplication than a wholesale copying of the code. However, in light of Baremetal's impending this seems to me to be a poor choice since it would involve lots of duplicate functionality, would complicate the ImageCacheManager code, and would later need to be manually removed once the Baremetal driver is removed. The second option would be to make a copy of the old ImageCacheManager in the Baremetal directory, and have the Baremetal driver use that. This seems to me to be the better option, since it means that when the Baremetal driver is removed, the old ImageCacheManager code goes with it, without someone having to manually remove it. I might get shot in the head, but I think option 2 makes the most sense. There is no need to do _new_ work in support of a dead codebase. I am not, however, the ruler of the universe... Monty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
