<div dir="ltr"><div><div>I'm afraid user experience will change because of API. Do we have a plan about it?<br></div>Will we interact with Aodh through ceilometer-api first? Or make user to go to aodh-api service?<br></div><div>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? <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 29, 2015 at 10:47 PM, gordon chung <span dir="ltr"><<a href="mailto:gord@live.ca" target="_blank">gord@live.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 29/06/2015 11:40 AM, Chris Dent wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, 29 Jun 2015, Julien Danjou wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi team,<br>
<br>
Aodh has been imported and is now available at:<br>
<br>
<a href="https://git.openstack.org/cgit/openstack/aodh/" rel="noreferrer" target="_blank">https://git.openstack.org/cgit/openstack/aodh/</a><br>
</blockquote>
<br>
woot!<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm pretty clear about the next steps for Aodh and what we need to<br>
build, but something is still not clear to me. Do we go ahead and bite<br>
the bullet and remove ceilometer-alarming from ceilometer in Liberty?<br>
</blockquote></blockquote>
<br></span>
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.<br>
<br>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This is the big question and is one of the things listed on the<br>
potential agenda for the mid-cylce. When we do the splits do we<br>
deprecate or delete the old code. Given the high chance of us<br>
missing some of potential issues it seems like hasing it some before<br>
the mid-cylce is a good idea.<br>
<br>
The two big overarching issues (that inform a lot of the details)<br>
that I'm aware of are:<br>
<br>
* If we delete then we need to make sure we're working hand in hand<br>
with all of: downstream packagers, tempest, grenade, devstack,<br>
etc.<br>
<br>
* If we deprecate will people bother to use the new stuff?<br>
</blockquote>
<br></span>
i would think/hope the experience from end user doesn't actually change. ie. all the same packaged services remain.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm sure there are plenty of others.<br>
<br>
</blockquote>
<br>
-- <br></span>
gord<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>