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 <g...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev