Open Stack

Hi,

I think removing options from the API requires version bump. So if we plan to do this, that should be introduced in v3 as opposed to v2, which should remain the same and maintained for two cycles (assuming that we still have this policy in OpenStack). It this is achievable by removing the old code and relying on the new repo that would be the best, if not then we need to figure out how to freeze the old code.

Best Regards,
Ildikó

> -----Original Message-----
> From: Nadya Shakhat [mailto:nprivalova at mirantis.com]
> Sent: June 29, 2015 21:52
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
> 
> I'm afraid user experience will change because of API. Do we have a plan about it?
> 
> Will we interact with Aodh through ceilometer-api first? Or make user to go to aodh-api service?
> 
> So I agree with Gordon that code-cleanup is more preferred option because we can't maintain two version simultaneously. But we
> need to think more about end users: is it appropriate just remove options from ceilometer-api?
> 
> 
> On Mon, Jun 29, 2015 at 10:47 PM, gordon chung <gord at live.ca> wrote:
> 
> 
> 
> 
> 	On 29/06/2015 11:40 AM, Chris Dent wrote:
> 
> 
> 		On Mon, 29 Jun 2015, Julien Danjou wrote:
> 
> 
> 
> 			Hi team,
> 
> 			Aodh has been imported and is now available at:
> 
> 			 https://git.openstack.org/cgit/openstack/aodh/
> 
> 
> 
> 		woot!
> 
> 
> 
> 			I'm pretty clear about the next steps for Aodh and what we need to
> 			build, but something is still not clear to me. Do we go ahead and bite
> 			the bullet and remove ceilometer-alarming from ceilometer in Liberty?
> 
> 
> 
> 	i think we should follow up with the packagers. if i understand correctly, the location of the code is not known from a
> user pov, it's the packagers that build the appropriate packages for them to use.
> 
> 	if from packagers pov, they just need to work against Aodh, then i would lean more to removing alarming from
> Ceilometer repo asap to avoid maintaining duplicate code bases and the eventual diversion of the two.
> 
> 
> 
> 
> 		This is the big question and is one of the things listed on the
> 		potential agenda for the mid-cylce. When we do the splits do we
> 		deprecate or delete the old code. Given the high chance of us
> 		missing some of potential issues it seems like hasing it some before
> 		the mid-cylce is a good idea.
> 
> 		The two big overarching issues (that inform a lot of the details)
> 		that I'm aware of are:
> 
> 		* If we delete then we need to make sure we're working hand in hand
> 		  with all of: downstream packagers, tempest, grenade, devstack,
> 		  etc.
> 
> 		* If we deprecate will people bother to use the new stuff?
> 
> 
> 
> 	i would think/hope the experience from end user doesn't actually change. ie. all the same packaged services remain.
> 
> 
> 
> 
> 		I'm sure there are plenty of others.
> 
> 
> 
> 
> 	--
> 	gord
> 
> 
> 
> 	__________________________________________________________________________
> 	OpenStack Development Mailing List (not for usage questions)
> 	Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 	http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
>