Re: [openstack-dev] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that
Boris Pavlovic wrote: Sean, Nobody is able to track and know *everything*. Friendly reminder that Heat is going to be removed and not installed by default would help to avoid such situations. Doesn't keystone have a service listing? Use that in rally (and elsewhere?), if keystone had a service and each service had a API discovery ability, there u go, profit! ;) Best regards, Boris Pavlovic On Thu, May 7, 2015 at 8:06 PM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: On 05/07/2015 12:51 PM, Boris Pavlovic wrote: Hi stackers, Recently was merged patch that removes Heat from list of service that are installed by default DevStack Please next time make sure that all PTL of all projects in OpenStack know about such big not backward compatible changes. P.S This change paralyzed work on Rally for 2 days. =( This should in no way impact gate jobs, they should all be explicitly setting service lists themselves for their environments. The ensure devstack-gate model is built around that. If they are not, then that is a bug in how they were built. This has also been a long time coming, we merged the direction patch for this in Feb in the FUTURE.rst document. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://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 __ 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] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that
On 05/07/2015 02:29 PM, Joshua Harlow wrote: Boris Pavlovic wrote: Sean, Nobody is able to track and know *everything*. Friendly reminder that Heat is going to be removed and not installed by default would help to avoid such situations. Doesn't keystone have a service listing? Use that in rally (and elsewhere?), if keystone had a service and each service had a API discovery ability, there u go, profit! ;) Service listing for test jobs is actually quite dangerous, because then something can change something about which services are registered, and you automatically start skipping 30% of your tests because you react correctly to this change. However, that means the job stopped doing what you think it should do. *This has happened multiple times in the past*. And typically days, weeks, or months go by before someone notices in investigating an unrelated failure. And then it's days, weeks, or months to dig out of the regressions introduced. So... test jobs should be extremely explicit about what they setup and what they expect. -Sean -- Sean Dague http://dague.net __ 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] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that
On Thu, May 07, 2015 at 01:40:53PM EDT, Sean Dague wrote: On 05/07/2015 01:37 PM, Boris Pavlovic wrote: Sean, Nobody is able to track and know *everything*. Friendly reminder that Heat is going to be removed and not installed by default would help to avoid such situations. Sure, but that misses the first point, that gate jobs should really be explicit about the services they run. It's a vast surprise that anything running in our gate just runs with defaults. So I would suggest now is an excellent time to make the rally jobs work like the grenade and tempest jobs and be explicit about such things. -Sean I'd like to +1 this - that gate jobs should be also explicit about their configuration. For example, on the network side I've been listening to my own advice and making the Ironic job explicitly set the OVS agent for Neutron. -- Sean M. Collins __ 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] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that
So... test jobs should be extremely explicit about what they setup and what they expect. +2 Best regards, Boris Pavlovic On Thu, May 7, 2015 at 9:44 PM, Sean Dague s...@dague.net wrote: On 05/07/2015 02:29 PM, Joshua Harlow wrote: Boris Pavlovic wrote: Sean, Nobody is able to track and know *everything*. Friendly reminder that Heat is going to be removed and not installed by default would help to avoid such situations. Doesn't keystone have a service listing? Use that in rally (and elsewhere?), if keystone had a service and each service had a API discovery ability, there u go, profit! ;) Service listing for test jobs is actually quite dangerous, because then something can change something about which services are registered, and you automatically start skipping 30% of your tests because you react correctly to this change. However, that means the job stopped doing what you think it should do. *This has happened multiple times in the past*. And typically days, weeks, or months go by before someone notices in investigating an unrelated failure. And then it's days, weeks, or months to dig out of the regressions introduced. So... test jobs should be extremely explicit about what they setup and what they expect. -Sean -- Sean Dague http://dague.net __ 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] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that
On May 7, 2015, at 10:40, Sean Dague s...@dague.net wrote: On 05/07/2015 01:37 PM, Boris Pavlovic wrote: Sean, Nobody is able to track and know *everything*. Friendly reminder that Heat is going to be removed and not installed by default would help to avoid such situations. Sure, but that misses the first point, that gate jobs should really be explicit about the services they run. It's a vast surprise that anything running in our gate just runs with defaults. So I would suggest now is an excellent time to make the rally jobs work like the grenade and tempest jobs and be explicit about such things. Huge +1. Gate jobs absolutely should be explicit. Guessing what is being tested is no fun. -Sean -- Sean Dague http://dague.net __ 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] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that
Joshua, Doesn't keystone have a service listing? Use that in rally (and elsewhere?), if keystone had a service and each service had a API discovery ability, there u go, profit! ;) Exactly that happened. We were running benchmarks against Heat and Rally task validation start failing saying that there is no heat service=) Best regards, Boris Pavlovic On Thu, May 7, 2015 at 9:29 PM, Joshua Harlow harlo...@outlook.com wrote: Boris Pavlovic wrote: Sean, Nobody is able to track and know *everything*. Friendly reminder that Heat is going to be removed and not installed by default would help to avoid such situations. Doesn't keystone have a service listing? Use that in rally (and elsewhere?), if keystone had a service and each service had a API discovery ability, there u go, profit! ;) Best regards, Boris Pavlovic On Thu, May 7, 2015 at 8:06 PM, Sean Dague s...@dague.net mailto:s...@dague.net wrote: On 05/07/2015 12:51 PM, Boris Pavlovic wrote: Hi stackers, Recently was merged patch that removes Heat from list of service that are installed by default DevStack Please next time make sure that all PTL of all projects in OpenStack know about such big not backward compatible changes. P.S This change paralyzed work on Rally for 2 days. =( This should in no way impact gate jobs, they should all be explicitly setting service lists themselves for their environments. The ensure devstack-gate model is built around that. If they are not, then that is a bug in how they were built. This has also been a long time coming, we merged the direction patch for this in Feb in the FUTURE.rst document. -Sean -- Sean Dague http://dague.net __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://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 __ 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] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that
Joshua, Makes sense, perhaps all the test (and/or test-like) frameworks could share some code + common config that does this, seems to be something simple (and something that all could use for pre-testing validation of all the expected services being alive/active/up/responding...)? In Rally this is part of life cycle of running task. Not sure that it is possible to share it, because it is thigh related to checking what did you write in task. =) Best regards, Boris Pavlovic On Thu, May 7, 2015 at 9:54 PM, Joshua Harlow harlo...@outlook.com wrote: Sean Dague wrote: On 05/07/2015 02:29 PM, Joshua Harlow wrote: Boris Pavlovic wrote: Sean, Nobody is able to track and know *everything*. Friendly reminder that Heat is going to be removed and not installed by default would help to avoid such situations. Doesn't keystone have a service listing? Use that in rally (and elsewhere?), if keystone had a service and each service had a API discovery ability, there u go, profit! ;) Service listing for test jobs is actually quite dangerous, because then something can change something about which services are registered, and you automatically start skipping 30% of your tests because you react correctly to this change. However, that means the job stopped doing what you think it should do. *This has happened multiple times in the past*. And typically days, weeks, or months go by before someone notices in investigating an unrelated failure. And then it's days, weeks, or months to dig out of the regressions introduced. So... test jobs should be extremely explicit about what they setup and what they expect. Makes sense, perhaps all the test (and/or test-like) frameworks could share some code + common config that does this, seems to be something simple (and something that all could use for pre-testing validation of all the expected services being alive/active/up/responding...)? ^^ Just an idear, -Josh -Sean __ 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] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that
On 05/07/2015 01:37 PM, Boris Pavlovic wrote: Sean, Nobody is able to track and know *everything*. Friendly reminder that Heat is going to be removed and not installed by default would help to avoid such situations. Sure, but that misses the first point, that gate jobs should really be explicit about the services they run. It's a vast surprise that anything running in our gate just runs with defaults. So I would suggest now is an excellent time to make the rally jobs work like the grenade and tempest jobs and be explicit about such things. -Sean -- Sean Dague http://dague.net __ 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] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that
Sean, Thank you for advice. We are going to fix jobs ASAP. Here is the patch: https://review.openstack.org/#/c/181088/ But seems like it's not ready yet. Best regards, Boris Pavlovic On Thu, May 7, 2015 at 8:40 PM, Sean Dague s...@dague.net wrote: On 05/07/2015 01:37 PM, Boris Pavlovic wrote: Sean, Nobody is able to track and know *everything*. Friendly reminder that Heat is going to be removed and not installed by default would help to avoid such situations. Sure, but that misses the first point, that gate jobs should really be explicit about the services they run. It's a vast surprise that anything running in our gate just runs with defaults. So I would suggest now is an excellent time to make the rally jobs work like the grenade and tempest jobs and be explicit about such things. -Sean -- Sean Dague http://dague.net __ 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] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that
Sean Dague wrote: On 05/07/2015 02:29 PM, Joshua Harlow wrote: Boris Pavlovic wrote: Sean, Nobody is able to track and know *everything*. Friendly reminder that Heat is going to be removed and not installed by default would help to avoid such situations. Doesn't keystone have a service listing? Use that in rally (and elsewhere?), if keystone had a service and each service had a API discovery ability, there u go, profit! ;) Service listing for test jobs is actually quite dangerous, because then something can change something about which services are registered, and you automatically start skipping 30% of your tests because you react correctly to this change. However, that means the job stopped doing what you think it should do. *This has happened multiple times in the past*. And typically days, weeks, or months go by before someone notices in investigating an unrelated failure. And then it's days, weeks, or months to dig out of the regressions introduced. So... test jobs should be extremely explicit about what they setup and what they expect. Makes sense, perhaps all the test (and/or test-like) frameworks could share some code + common config that does this, seems to be something simple (and something that all could use for pre-testing validation of all the expected services being alive/active/up/responding...)? ^^ Just an idear, -Josh -Sean __ 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] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that
As a heads up, here is a patch to remove Sahara from the default configuration as well. This is part of the effort to further decouple the 'integrated gate' so we don't have to gate every project on the tests for every project. https://review.openstack.org/#/c/181230/ On Thu, May 7, 2015 at 11:58 AM, Boris Pavlovic bo...@pavlovic.me wrote: So... test jobs should be extremely explicit about what they setup and what they expect. +2 Best regards, Boris Pavlovic On Thu, May 7, 2015 at 9:44 PM, Sean Dague s...@dague.net wrote: On 05/07/2015 02:29 PM, Joshua Harlow wrote: Boris Pavlovic wrote: Sean, Nobody is able to track and know *everything*. Friendly reminder that Heat is going to be removed and not installed by default would help to avoid such situations. Doesn't keystone have a service listing? Use that in rally (and elsewhere?), if keystone had a service and each service had a API discovery ability, there u go, profit! ;) Service listing for test jobs is actually quite dangerous, because then something can change something about which services are registered, and you automatically start skipping 30% of your tests because you react correctly to this change. However, that means the job stopped doing what you think it should do. *This has happened multiple times in the past*. And typically days, weeks, or months go by before someone notices in investigating an unrelated failure. And then it's days, weeks, or months to dig out of the regressions introduced. So... test jobs should be extremely explicit about what they setup and what they expect. -Sean -- Sean Dague http://dague.net __ 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 __ 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] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that
On 05/07/2015 12:51 PM, Boris Pavlovic wrote: Hi stackers, Recently was merged patch that removes Heat from list of service that are installed by default DevStack Please next time make sure that all PTL of all projects in OpenStack know about such big not backward compatible changes. P.S This change paralyzed work on Rally for 2 days. =( This should in no way impact gate jobs, they should all be explicitly setting service lists themselves for their environments. The ensure devstack-gate model is built around that. If they are not, then that is a bug in how they were built. This has also been a long time coming, we merged the direction patch for this in Feb in the FUTURE.rst document. -Sean -- Sean Dague http://dague.net __ 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] [be nice] Before doing big non backardcompabitle changes in how gates work make sure that all PTL are informed about that
Sean, Nobody is able to track and know *everything*. Friendly reminder that Heat is going to be removed and not installed by default would help to avoid such situations. Best regards, Boris Pavlovic On Thu, May 7, 2015 at 8:06 PM, Sean Dague s...@dague.net wrote: On 05/07/2015 12:51 PM, Boris Pavlovic wrote: Hi stackers, Recently was merged patch that removes Heat from list of service that are installed by default DevStack Please next time make sure that all PTL of all projects in OpenStack know about such big not backward compatible changes. P.S This change paralyzed work on Rally for 2 days. =( This should in no way impact gate jobs, they should all be explicitly setting service lists themselves for their environments. The ensure devstack-gate model is built around that. If they are not, then that is a bug in how they were built. This has also been a long time coming, we merged the direction patch for this in Feb in the FUTURE.rst document. -Sean -- Sean Dague http://dague.net __ 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
