Hi, On Fri, Jul 13, 2012 at 9:20 PM, Andrew Clay Shafer <a...@parvuscaptus.com>wrote:
> [...] > In this particular case, I chose option 1 under the following assumptions > (which may be wrong): > > - the api for the end user would not change > - the code for the service is essentially the same, it is just being > renamed > - option 2 doesn't lower risk or burden for anyone, it just postpones > them, while increasing complexity, confusion and future burdens for core > development and probably operators as well > > I disagree with your last point, it is true if we look only into this particular problem, but if you look into the whole ecosystem you'll realize that the code removal of nova-volumes is not the only change from essex to folsom.. if we had deprecated all other changes, this particular one would not be painful at all. > > > [...] > On the question of compatibility, my assumption is this a non-issue for > the moment. > I believe it wouldn't be an issue if people were not using OpenStack, but we are.. On the question of an upgrade path and the relative ease of deployment, my > assumption is this is no worse than any of the other upgrades. > It doesn't really mean a good thing, since I don't think that the others upgrades were good, based on what I heard and experienced with sysadmins from my team... > [...] > In specific, I think getting more information from operators and users is > generally good. Ultimately, if OpenStack cannot be operated and utilized, > the mission will fail. > I agree! (finally :P) I also think that it's our responsibility (as developers) to ask for input from operators, it's not because they are not complaining that things are going smoothly. We should ask for every one we know who's working with OpenStack and do our best to get feedback. Regards, -- Flavia
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
