Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
On Thu, Jul 16 2015, Angus Salkeld wrote: Hi Angus, I just saw this, and I am concerned this is going to kill Heat's gate (and user's templates). Will this be hidden within the client so that as long as we have aodh enabled in our gate's devstack this will just work? As Gordon said, don't worry, we'll do everything to not break Heat's gate, managing transition. We're setting up a plan and I think Mehdi already has patches doing magic so it's transparent and painless for everyone. -- Julien Danjou # Free Software hacker # http://julien.danjou.info signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
On Fri, Jul 17, 2015 at 8:52 PM, Julien Danjou jul...@danjou.info wrote: On Thu, Jul 16 2015, Angus Salkeld wrote: Hi Angus, I just saw this, and I am concerned this is going to kill Heat's gate (and user's templates). Will this be hidden within the client so that as long as we have aodh enabled in our gate's devstack this will just work? As Gordon said, don't worry, we'll do everything to not break Heat's gate, managing transition. We're setting up a plan and I think Mehdi already has patches doing magic so it's transparent and painless for everyone. OK, thanks - phew. -Angus -- Julien Danjou # Free Software hacker # http://julien.danjou.info __ 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
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
On 16/07/2015 12:05 AM, Angus Salkeld wrote: Will this be hidden within the client so that as long as we have aodh enabled in our gate's devstack this will just work? yes, we discussed this last week during our midcycle. the plan going forward is to allow current existing Ceilometer alarm functionality to persist as is until we have a document process to transition over to split Aodh service. We are currently looking at the existing integration cases and have them prioritised. Once we have integrations all resolved we will announce code removal. It is currently targeted to be removed in M* cycle, dependent on current integration work. __ 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
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
On Tue, Jun 30, 2015 at 6:09 PM, Julien Danjou jul...@danjou.info wrote: On Mon, Jun 29 2015, Ildikó Váncsa wrote: 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. This is not an API change as we're not modifying anything in the API. It's just the endpoint *potentially* split in two. But you can also merge them as they are 2 separate entities (/v2/alarms and /v2/*). So there's no need for a v3 here. Hi Julien, I just saw this, and I am concerned this is going to kill Heat's gate (and user's templates). Will this be hidden within the client so that as long as we have aodh enabled in our gate's devstack this will just work? -Angus As the consensus goes toward removal, I'll work on a patch for that. -- Julien Danjou /* Free Software hacker http://julien.danjou.info */ __ 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
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
I'd agree with Angus. 在 2015-07-16 12:05:25，Angus Salkeld asalk...@mirantis.com 写道： On Tue, Jun 30, 2015 at 6:09 PM, Julien Danjou jul...@danjou.info wrote: On Mon, Jun 29 2015, Ildikó Váncsa wrote: 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. This is not an API change as we're not modifying anything in the API. It's just the endpoint *potentially* split in two. But you can also merge them as they are 2 separate entities (/v2/alarms and /v2/*). So there's no need for a v3 here. Hi Julien, I just saw this, and I am concerned this is going to kill Heat's gate (and user's templates). Will this be hidden within the client so that as long as we have aodh enabled in our gate's devstack this will just work? -Angus As the consensus goes toward removal, I'll work on a patch for that. -- Julien Danjou /* Free Software hacker http://julien.danjou.info */ __ 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
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
Hi, I'd like to see how we can develop new alarm features, since I'm working on event-alarm. Having duplicated code bases may confuse developer too, so we should have some policies like: * aodh focus on making sure that it provides existing API and functionality as of kilo to end users * ceilometer/alarm is open to develop new experimental features until L2/L3 * having a merge window to move those new features to aodh from ceilometer/alarm around L3 What do you think? Thanks, Ryota -Original Message- From: gordon chung [mailto:g...@live.ca] Sent: Tuesday, June 30, 2015 3:48 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps 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
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
On 02/07/2015 4:43 AM, Ryota Mibu wrote: Hi, I'd like to see how we can develop new alarm features, since I'm working on event-alarm. Having duplicated code bases may confuse developer too, so we should have some policies like: * aodh focus on making sure that it provides existing API and functionality as of kilo to end users * ceilometer/alarm is open to develop new experimental features until L2/L3 * having a merge window to move those new features to aodh from ceilometer/alarm around L3 What do you think? this sounds like a good idea, we should probably adopt something similar to the graduation process for oslo libs. at quick glance, the code is all structured the same -- under different main folder -- so i believe it should be a easy port if coding against current ceilometer repo to move it under aodh afterwards. Thanks, Ryota -Original Message- From: gordon chung [mailto:g...@live.ca] Sent: Tuesday, June 30, 2015 3:48 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps 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 -- 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
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
On 02/07/2015 4:43 AM, Ryota Mibu wrote: Hi, I'd like to see how we can develop new alarm features, since I'm working on event-alarm. Having duplicated code bases may confuse developer too, so we should have some policies like: * aodh focus on making sure that it provides existing API and functionality as of kilo to end users * ceilometer/alarm is open to develop new experimental features until L2/L3 * having a merge window to move those new features to aodh from ceilometer/alarm around L3 What do you think? this sounds like a good idea, we should probably adopt something similar to the graduation process for oslo libs. at quick glance, the code is all structured the same -- under different main folder -- so i believe it should be a easy port if coding against current ceilometer repo to move it under aodh afterwards. Thanks, Ryota -Original Message- From: gordon chung [mailto:g...@live.ca] Sent: Tuesday, June 30, 2015 3:48 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps 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 -- 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
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
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. This is not an API change as we're not modifying anything in the API. It's just the endpoint *potentially* split in two. But you can also merge them as they are 2 separate entities (/v2/alarms and /v2/*). So there's no need for a v3 here. Will this be accessible in the same way as currently or it needs changes on client side? How about ceilometer-api service returns 301 'Moved Permanently' for any requests to /v2/alarms, redirecting to the new Aodh endpoint? Being a standard HTTP response code, this should be handled gracefully by any (non-broken) HTTP client. Cheers, Eoghan __ 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
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
On Mon, Jun 29 2015, Julien Danjou wrote: FTR today I've copied the members of ceilometer-core to aodh-core. We'll be able to manage to the team independently like we do with Gnocchi, based on who is doing what in the different repositories. Hi team, Aodh has been imported and is now available at: https://git.openstack.org/cgit/openstack/aodh/ You should add it to your review list on Gerrit I guess. 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? -- Julien Danjou // Free Software hacker // http://julien.danjou.info signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
On Mon, Jun 29 2015, Ildikó Váncsa wrote: 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. This is not an API change as we're not modifying anything in the API. It's just the endpoint *potentially* split in two. But you can also merge them as they are 2 separate entities (/v2/alarms and /v2/*). So there's no need for a v3 here. As the consensus goes toward removal, I'll work on a patch for that. -- Julien Danjou /* Free Software hacker http://julien.danjou.info */ signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
On Tue, Jun 30 2015, Ildikó Váncsa wrote: Will this be accessible in the same way as currently or it needs changes on client side? You may just need to pass more options to the client to force another endpoint to be used when talking to the alarming part. We could make this change in the client by default though. -- Julien Danjou # Free Software hacker # http://julien.danjou.info signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
Hmm, as it is a change that affects the user, in my opinion it is still an API change. Have we decided about the client, whether the alarming module will have a separate client or we will keep the current ceilometer-client? I guess more the latter one at least as a starting point, I just wanted to double check. Ildikó Sent from my iPad On 30 Jun 2015, at 14:18, Julien Danjou jul...@danjou.info wrote: On Tue, Jun 30 2015, Ildikó Váncsa wrote: Will this be accessible in the same way as currently or it needs changes on client side? You may just need to pass more options to the client to force another endpoint to be used when talking to the alarming part. We could make this change in the client by default though. -- Julien Danjou # Free Software hacker # http://julien.danjou.info __ 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
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
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? 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'm sure there are plenty of others. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ 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
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
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
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 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
Re: [openstack-dev] [ceilometer] Aodh has been imported, next steps
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:nprival...@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 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
