Re: [openstack-dev] [Ceilometer][Tempest]Tracking of blueprints and changes

2014-01-06 Thread Doug Hellmann
On Mon, Dec 30, 2013 at 2:53 PM, David Kranz dkr...@redhat.com wrote:

  On 12/27/2013 05:27 AM, Nadya Privalova wrote:

   Hello guys!

  I hope all of you are enjoying the holidays! But I'd like to raise a
 Tempest question. Again. I hope this email will not be lost after vacations
 :)
  After the summit we decided to track all tests that are being created for
 Ceilometer in Tempest here:
 https://blueprints.launchpad.net/tempest/+spec/add-basic-ceilometer-tests.
 Besides, we've created an etherpad page with a test plan
 https://etherpad.openstack.org/p/ceilometer-test-plan.

  But it turned out that it works very bad. Now we have at least 3 change
 requests that have common functionality implemented. So we definitely need
 more reliable mechanism for tracking any changes.
 That's why I suggest to create a separate blueprint for each
 functionality. E.g. Ceilometer client for Tempest, Notification testing
 with several bps that depend on it (Swift notifications, Glance
 notifications, Nova notifications) and so on. In future we may vary the
 detail level of blueprints but now we need very detailed ones because
 different people have started to work on e.g. notifications.
  So there are the following action items:
  1. Resolve all conflicts in changes that are on review now (see my
 comment to https://review.openstack.org/#/c/39237/ patch set 21 for more
 details)
  2. Create set of blueprints from the testplan we have
  3. Add Tempest discussions to Ceilometer weekly meeting agenda (done)

  I may take care of all the items above. I need only ok from PTLs and
 Cores.
  Anyway, we've started working on 1st item, because it is urgent. The
 second one may be postponed due to holidays.

  And one more important thing. Code review for Ceilometer tests in Tempest
 is too slow. Some of change requests are created almost a half a year ago!
 Ceilometer guys, please be informed. I think all of us are interested in
 good tests.

  Thank you for attention,
  Nadya


  So the tempest patches for ceilometer are still not a coherent set. Can
 you please mark anything that is not ready for review as Work In Progress,
 or abandon until there is really something to review?

 Also, having looked at a few of these, I am confused about the usage of
 ceilometer, metering, telemetry. Is there an explanation for the
 context in which each of these terms is to be used?


Ceilometer is the code name for the project, like neutron and nova.

OpenStack Telemetry is the official name for ceilometer, like OpenStack
Networking and OpenStack Compute.

Doug





  -David



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ceilometer][Tempest]Tracking of blueprints and changes

2013-12-30 Thread David Kranz

On 12/27/2013 05:27 AM, Nadya Privalova wrote:

Hello guys!

I hope all of you are enjoying the holidays! But I'd like to raise a 
Tempest question. Again. I hope this email will not be lost after 
vacations :)
After the summit we decided to track all tests that are being created 
for Ceilometer in Tempest here: 
https://blueprints.launchpad.net/tempest/+spec/add-basic-ceilometer-tests. 
Besides, we've created an etherpad page with a test plan 
https://etherpad.openstack.org/p/ceilometer-test-plan.


But it turned out that it works very bad. Now we have at least 3 
change requests that have common functionality implemented. So we 
definitely need more reliable mechanism for tracking any changes.
That's why I suggest to create a separate blueprint for each 
functionality. E.g. Ceilometer client for Tempest, Notification 
testing with several bps that depend on it (Swift notifications, 
Glance notifications, Nova notifications) and so on. In future we 
may vary the detail level of blueprints but now we need very detailed 
ones because different people have started to work on e.g. notifications.

So there are the following action items:
1. Resolve all conflicts in changes that are on review now (see my 
comment to https://review.openstack.org/#/c/39237/ patch set 21 for 
more details)

2. Create set of blueprints from the testplan we have
3. Add Tempest discussions to Ceilometer weekly meeting agenda (done)

I may take care of all the items above. I need only ok from PTLs and 
Cores.
Anyway, we've started working on 1st item, because it is urgent. The 
second one may be postponed due to holidays.


And one more important thing. Code review for Ceilometer tests in 
Tempest is too slow. Some of change requests are created almost a half 
a year ago! Ceilometer guys, please be informed. I think all of us are 
interested in good tests.


Thank you for attention,
Nadya


So the tempest patches for ceilometer are still not a coherent set. Can 
you please mark anything that is not ready for review as Work In 
Progress, or abandon until there is really something to review?


Also, having looked at a few of these, I am confused about the usage of 
ceilometer, metering, telemetry. Is there an explanation for the 
context in which each of these terms is to be used?


 -David


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ceilometer][Tempest]Tracking of blueprints and changes

2013-12-30 Thread Nadya Privalova
Hello all,

Thank you for your suggestions about tracking bps. I'll create a
spreadsheet.

David,

1. https://review.openstack.org/#/c/55276/ is ready for review
2. We decided to move base.py to a separate change request:
https://review.openstack.org/#/c/64304/ to make it merged ASAP. But now I
see that reviewers want to see an example of usage. We didn't wanted to add
any examples there. There are several changes that are abandoned now but
will be restored soon with dependency on 64304 (
https://review.openstack.org/#/c/43481/,
https://review.openstack.org/#/c/46745/). What do you think is it OK to
keep 64304 as a separate one?
3. https://review.openstack.org/#/c/39237/ is In Progress because it should
be depended on 2.
4. Not sure why https://review.openstack.org/#/c/64299/ is a separate one.
It is a part of 1 now. I think it should be abandoned.

And about ceilometer, metering, telemetry. Originally 'metering' was
used, but official was changed to 'telemetry'. I'm not the person who
resolved such questions but I guess that 'telemetry' is the final solution.
Anyway, I will discuss it with Julien.

Thanks,
Nadya


On Mon, Dec 30, 2013 at 11:53 PM, David Kranz dkr...@redhat.com wrote:

  On 12/27/2013 05:27 AM, Nadya Privalova wrote:

   Hello guys!

  I hope all of you are enjoying the holidays! But I'd like to raise a
 Tempest question. Again. I hope this email will not be lost after vacations
 :)
  After the summit we decided to track all tests that are being created for
 Ceilometer in Tempest here:
 https://blueprints.launchpad.net/tempest/+spec/add-basic-ceilometer-tests.
 Besides, we've created an etherpad page with a test plan
 https://etherpad.openstack.org/p/ceilometer-test-plan.

  But it turned out that it works very bad. Now we have at least 3 change
 requests that have common functionality implemented. So we definitely need
 more reliable mechanism for tracking any changes.
 That's why I suggest to create a separate blueprint for each
 functionality. E.g. Ceilometer client for Tempest, Notification testing
 with several bps that depend on it (Swift notifications, Glance
 notifications, Nova notifications) and so on. In future we may vary the
 detail level of blueprints but now we need very detailed ones because
 different people have started to work on e.g. notifications.
  So there are the following action items:
  1. Resolve all conflicts in changes that are on review now (see my
 comment to https://review.openstack.org/#/c/39237/ patch set 21 for more
 details)
  2. Create set of blueprints from the testplan we have
  3. Add Tempest discussions to Ceilometer weekly meeting agenda (done)

  I may take care of all the items above. I need only ok from PTLs and
 Cores.
  Anyway, we've started working on 1st item, because it is urgent. The
 second one may be postponed due to holidays.

  And one more important thing. Code review for Ceilometer tests in Tempest
 is too slow. Some of change requests are created almost a half a year ago!
 Ceilometer guys, please be informed. I think all of us are interested in
 good tests.

  Thank you for attention,
  Nadya


  So the tempest patches for ceilometer are still not a coherent set. Can
 you please mark anything that is not ready for review as Work In Progress,
 or abandon until there is really something to review?

 Also, having looked at a few of these, I am confused about the usage of
 ceilometer, metering, telemetry. Is there an explanation for the
 context in which each of these terms is to be used?

  -David



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ceilometer][Tempest]Tracking of blueprints and changes

2013-12-27 Thread David Kranz

On 12/27/2013 05:27 AM, Nadya Privalova wrote:

Hello guys!

I hope all of you are enjoying the holidays! But I'd like to raise a 
Tempest question. Again. I hope this email will not be lost after 
vacations :)
After the summit we decided to track all tests that are being created 
for Ceilometer in Tempest here: 
https://blueprints.launchpad.net/tempest/+spec/add-basic-ceilometer-tests. 
Besides, we've created an etherpad page with a test plan 
https://etherpad.openstack.org/p/ceilometer-test-plan.


But it turned out that it works very bad. Now we have at least 3 
change requests that have common functionality implemented. So we 
definitely need more reliable mechanism for tracking any changes.
That's why I suggest to create a separate blueprint for each 
functionality. E.g. Ceilometer client for Tempest, Notification 
testing with several bps that depend on it (Swift notifications, 
Glance notifications, Nova notifications) and so on. In future we 
may vary the detail level of blueprints but now we need very detailed 
ones because different people have started to work on e.g. notifications.

So there are the following action items:
1. Resolve all conflicts in changes that are on review now (see my 
comment to https://review.openstack.org/#/c/39237/ patch set 21 for 
more details)

2. Create set of blueprints from the testplan we have
3. Add Tempest discussions to Ceilometer weekly meeting agenda (done)

I may take care of all the items above. I need only ok from PTLs and 
Cores.
Anyway, we've started working on 1st item, because it is urgent. The 
second one may be postponed due to holidays.


And one more important thing. Code review for Ceilometer tests in 
Tempest is too slow. Some of change requests are created almost a half 
a year ago! Ceilometer guys, please be informed. I think all of us are 
interested in good tests.


Thank you for attention,
Nadya
Thanks, Nadya. A similar issue came up with heat. The problem is that 
tempest really has two parts: the tempest infrastructure itself, and all 
the test files for the various projects. The tempest team needs to 
manage its blueprints and we can't do that if there are dozens of 
blueprints about test implementation across projects. This problem is 
exacerbated by the fact that launchpad is not a good tool for project 
management which is the issue you are dealing with. For now, the best 
thing would be to have a master blueprint in tempest. If you want it to 
point to sub-blueprints for various test areas, use blueprints in the 
ceilometer project rather than tempest.


 -David




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Ceilometer][Tempest]Tracking of blueprints and changes

2013-12-27 Thread Christopher Yeoh
On Fri, Dec 27, 2013 at 8:57 PM, Nadya Privalova nprival...@mirantis.comwrote:

 Hello guys!

 I hope all of you are enjoying the holidays! But I'd like to raise a
 Tempest question. Again. I hope this email will not be lost after vacations
 :)
 After the summit we decided to track all tests that are being created for
 Ceilometer in Tempest here:
 https://blueprints.launchpad.net/tempest/+spec/add-basic-ceilometer-tests.
 Besides, we've created an etherpad page with a test plan
 https://etherpad.openstack.org/p/ceilometer-test-plan.

 But it turned out that it works very bad. Now we have at least 3 change
 requests that have common functionality implemented. So we definitely need
 more reliable mechanism for tracking any changes.
 That's why I suggest to create a separate blueprint for each
 functionality. E.g. Ceilometer client for Tempest, Notification testing
 with several bps that depend on it (Swift notifications, Glance
 notifications, Nova notifications) and so on. In future we may vary the
 detail level of blueprints but now we need very detailed ones because
 different people have started to work on e.g. notifications.
 So there are the following action items:
 1. Resolve all conflicts in changes that are on review now (see my comment
 to https://review.openstack.org/#/c/39237/ patch set 21 for more details)
 2. Create set of blueprints from the testplan we have
 3. Add Tempest discussions to Ceilometer weekly meeting agenda (done)


So you might want to consider setting up something like this:

https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWcusp=drive_web#gid=0

which was done for the Nova API testing where we have lots of people
working on tests simultaneously but don't want people accidentally
duplicating effort.

Chris
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev