Re: [openstack-dev] [Nova] - do we need .start and .end notifications in all cases ?

2014-10-16 Thread Matt Riedemann



On 9/25/2014 11:09 AM, Day, Phil wrote:

Hi Jay,

So just to be clear, are you saying that we should generate 2
notification messages on Rabbit for every DB update?   That feels
like a big overkill for me.   If I follow that login then the current
state transition notifications should also be changed to Starting to
update task state / finished updating task state  - which seems just
daft and confuisng logging with notifications.
Sandy's answer where start /end are used if there is a significant
amount of work between the two and/or the transaction spans multiple
hosts makes a lot more sense to me.   Bracketing a single DB call
with two notification messages rather than just a single one on
success to show that something changed would seem to me to be much
more in keeping with the concept of notifying on key events.


I can see your point, Phil. But what about when the set of DB calls takes a
not-insignificant amount of time? Would the event be considered significant
then? If so, sending only the I completed creating this thing notification
message might mask the fact that the total amount of time spent creating
the thing was significant.


Sure, I think there's a judgment call to be made on a case by case basis on 
this.   In general thought I'd say it's tasks that do more than just update the 
database that need to provide this kind of timing data.   Simple object 
creation / db table inserts don't really feel like they need to be individually 
timed by pairs of messages - if there is value in providing the creation time 
that could just be part of the payload of the single message, rather than 
doubling up on messages.



That's why I think it's safer to always wrap tasks -- a series of actions that
*do* one or more things -- with start/end/abort context managers that send
the appropriate notification messages.

Some notifications are for events that aren't tasks, and I don't think those
need to follow start/end/abort semantics. Your example of an instance state
change is not a task, and therefore would not need a start/end/abort
notification manager. However, the user action of say, Reboot this server
*would* have a start/end/abort wrapper for the REBOOT_SERVER event.
In between the start and end notifications for this REBOOT_SERVER event,
there may indeed be multiple SERVER_STATE_CHANGED notification
messages sent, but those would not have start/end/abort wrappers around
them.

Make a bit more sense?
-jay


Sure - it sounds like we're agreed in principle then that not all operations 
need start/end/abort messages, only those that are a series of operations.

So in that context the server group operations to me still look like they fall 
into the first groups.

Phil



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



Just for closure, we went with the single notification in the server 
groups create/update/delete calls:


https://review.openstack.org/#/c/107954/

--

Thanks,

Matt Riedemann


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


Re: [openstack-dev] [Nova] - do we need .start and .end notifications in all cases ?

2014-09-25 Thread Day, Phil
  Hi Jay,
 
  So just to be clear, are you saying that we should generate 2
  notification messages on Rabbit for every DB update?   That feels
  like a big overkill for me.   If I follow that login then the current
  state transition notifications should also be changed to Starting to
  update task state / finished updating task state  - which seems just
  daft and confuisng logging with notifications.
  Sandy's answer where start /end are used if there is a significant
  amount of work between the two and/or the transaction spans multiple
  hosts makes a lot more sense to me.   Bracketing a single DB call
  with two notification messages rather than just a single one on
  success to show that something changed would seem to me to be much
  more in keeping with the concept of notifying on key events.
 
 I can see your point, Phil. But what about when the set of DB calls takes a
 not-insignificant amount of time? Would the event be considered significant
 then? If so, sending only the I completed creating this thing notification
 message might mask the fact that the total amount of time spent creating
 the thing was significant.

Sure, I think there's a judgment call to be made on a case by case basis on 
this.   In general thought I'd say it's tasks that do more than just update the 
database that need to provide this kind of timing data.   Simple object 
creation / db table inserts don't really feel like they need to be individually 
timed by pairs of messages - if there is value in providing the creation time 
that could just be part of the payload of the single message, rather than 
doubling up on messages.
 
 
 That's why I think it's safer to always wrap tasks -- a series of actions that
 *do* one or more things -- with start/end/abort context managers that send
 the appropriate notification messages.
 
 Some notifications are for events that aren't tasks, and I don't think those
 need to follow start/end/abort semantics. Your example of an instance state
 change is not a task, and therefore would not need a start/end/abort
 notification manager. However, the user action of say, Reboot this server
 *would* have a start/end/abort wrapper for the REBOOT_SERVER event.
 In between the start and end notifications for this REBOOT_SERVER event,
 there may indeed be multiple SERVER_STATE_CHANGED notification
 messages sent, but those would not have start/end/abort wrappers around
 them.
 
 Make a bit more sense?
 -jay
 
Sure - it sounds like we're agreed in principle then that not all operations 
need start/end/abort messages, only those that are a series of operations.

So in that context the server group operations to me still look like they fall 
into the first groups.

Phil



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


Re: [openstack-dev] [Nova] - do we need .start and .end notifications in all cases ?

2014-09-25 Thread Dolph Mathews
On Wed, Sep 24, 2014 at 9:48 AM, Day, Phil philip@hp.com wrote:

  
   I think we should aim to /always/ have 3 notifications using a pattern
   of
  
  try:
 ...notify start...
  
 ...do the work...
  
 ...notify end...
  except:
 ...notify abort...
 
  Precisely my viewpoint as well. Unless we standardize on the above, our
  notifications are less than useful, since they will be open to
 interpretation by
  the consumer as to what precisely they mean (and the consumer will need
 to
  go looking into the source code to determine when an event actually
  occurred...)
 
  Smells like a blueprint to me. Anyone have objections to me writing one
 up
  for Kilo?
 
  Best,
  -jay
 
 Hi Jay,

 So just to be clear, are you saying that we should generate 2 notification
 messages on Rabbit for every DB update ?   That feels like a big overkill
 for me.   If I follow that login then the current state transition
 notifications should also be changed to Starting to update task state /
 finished updating task state  - which seems just daft and confuisng
 logging with notifications.

 Sandy's answer where start /end are used if there is a significant amount
 of work between the two and/or the transaction spans multiple hosts makes a
 lot more sense to me.   Bracketing a single DB call with two notification
 messages rather than just a single one on success to show that something
 changed would seem to me to be much more in keeping with the concept of
 notifying on key events.


+1 Following similar thinking, Keystone recently dropped a pending
notification that proceeded a single DB call, which was always followed by
either a success or failure notification.



 Phil


 ___
 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] [Nova] - do we need .start and .end notifications in all cases ?

2014-09-24 Thread Day, Phil
 
  I think we should aim to /always/ have 3 notifications using a pattern
  of
 
 try:
...notify start...
 
...do the work...
 
...notify end...
 except:
...notify abort...
 
 Precisely my viewpoint as well. Unless we standardize on the above, our
 notifications are less than useful, since they will be open to interpretation 
 by
 the consumer as to what precisely they mean (and the consumer will need to
 go looking into the source code to determine when an event actually
 occurred...)
 
 Smells like a blueprint to me. Anyone have objections to me writing one up
 for Kilo?
 
 Best,
 -jay
 
Hi Jay,

So just to be clear, are you saying that we should generate 2 notification 
messages on Rabbit for every DB update ?   That feels like a big overkill for 
me.   If I follow that login then the current state transition notifications 
should also be changed to Starting to update task state / finished updating 
task state  - which seems just daft and confuisng logging with notifications.

Sandy's answer where start /end are used if there is a significant amount of 
work between the two and/or the transaction spans multiple hosts makes a lot 
more sense to me.   Bracketing a single DB call with two notification messages 
rather than just a single one on success to show that something changed would 
seem to me to be much more in keeping with the concept of notifying on key 
events.

Phil


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


Re: [openstack-dev] [Nova] - do we need .start and .end notifications in all cases ?

2014-09-24 Thread Jay Pipes

On 09/24/2014 09:48 AM, Day, Phil wrote:

I think we should aim to /always/ have 3 notifications using a
pattern of

try: ...notify start...

...do the work...

...notify end... except: ...notify abort...


Precisely my viewpoint as well. Unless we standardize on the above,
our notifications are less than useful, since they will be open to
interpretation by the consumer as to what precisely they mean (and
the consumer will need to go looking into the source code to
determine when an event actually occurred...)

Smells like a blueprint to me. Anyone have objections to me writing
one up for Kilo?

Best, -jay


Hi Jay,

So just to be clear, are you saying that we should generate 2
notification messages on Rabbit for every DB update?   That feels
like a big overkill for me.   If I follow that login then the current
state transition notifications should also be changed to Starting to
update task state / finished updating task state  - which seems just
daft and confuisng logging with notifications.
Sandy's answer where start /end are used if there is a significant
amount of work between the two and/or the transaction spans multiple
hosts makes a lot more sense to me.   Bracketing a single DB call
with two notification messages rather than just a single one on
success to show that something changed would seem to me to be much
more in keeping with the concept of notifying on key events.


I can see your point, Phil. But what about when the set of DB calls 
takes a not-insignificant amount of time? Would the event be considered 
significant then? If so, sending only the I completed creating this 
thing notification message might mask the fact that the total amount of 
time spent creating the thing was significant.


That's why I think it's safer to always wrap tasks -- a series of 
actions that *do* one or more things -- with start/end/abort context 
managers that send the appropriate notification messages.


Some notifications are for events that aren't tasks, and I don't think 
those need to follow start/end/abort semantics. Your example of an 
instance state change is not a task, and therefore would not need a 
start/end/abort notification manager. However, the user action of say, 
Reboot this server *would* have a start/end/abort wrapper for the 
REBOOT_SERVER event. In between the start and end notifications for 
this REBOOT_SERVER event, there may indeed be multiple 
SERVER_STATE_CHANGED notification messages sent, but those would not 
have start/end/abort wrappers around them.


Make a bit more sense?
-jay

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


Re: [openstack-dev] [Nova] - do we need .start and .end notifications in all cases ?

2014-09-22 Thread Daniel P. Berrange
On Mon, Sep 22, 2014 at 11:03:02AM +, Day, Phil wrote:
 Hi Folks,
 
 I'd like to get some opinions on the use of pairs of notification
 messages for simple events.   I get that for complex operations on
 an instance (create, rebuild, etc) a start and end message are useful
 to help instrument progress and how long the operations took. However
 we also use this pattern for things like aggregate creation, which is
 just a single DB operation - and it strikes me as kind of overkill and
 probably not all that useful to any external system compared to a
 single event .create event after the DB operation.

A start + end pair is not solely useful for timing, but also potentially
detecting if it completed successfully. eg if you receive an end event
notification you know it has completed. That said, if this is a use case
we want to target, then ideally we'd have a third notification for this
failure case, so consumers don't have to wait  timeout to detect error.

 There is a change up for review to add notifications for service groups
 which is following this pattern (https://review.openstack.org/#/c/107954/)
 - the author isn't doing  anything wrong in that there just following that
 pattern, but it made me wonder if we shouldn't have some better guidance
 on when to use a single notification rather that a .start/.end pair.
 
 Does anyone else have thoughts on this , or know of external systems that
 would break if we restricted .start and .end usage to long-lived instance
 operations ?

I think we should aim to /always/ have 3 notifications using a pattern of

  try:
 ...notify start...

 ...do the work...

 ...notify end...
  except:
 ...notify abort...

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

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


Re: [openstack-dev] [Nova] - do we need .start and .end notifications in all cases ?

2014-09-22 Thread Day, Phil
Hi Daniel,


 -Original Message-
 From: Daniel P. Berrange [mailto:berra...@redhat.com]
 Sent: 22 September 2014 12:24
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Nova] - do we need .start and .end
 notifications in all cases ?
 
 On Mon, Sep 22, 2014 at 11:03:02AM +, Day, Phil wrote:
  Hi Folks,
 
  I'd like to get some opinions on the use of pairs of notification
  messages for simple events.   I get that for complex operations on
  an instance (create, rebuild, etc) a start and end message are useful
  to help instrument progress and how long the operations took. However
  we also use this pattern for things like aggregate creation, which is
  just a single DB operation - and it strikes me as kind of overkill and
  probably not all that useful to any external system compared to a
  single event .create event after the DB operation.
 
 A start + end pair is not solely useful for timing, but also potentially 
 detecting
 if it completed successfully. eg if you receive an end event notification you
 know it has completed. That said, if this is a use case we want to target, 
 then
 ideally we'd have a third notification for this failure case, so consumers 
 don't
 have to wait  timeout to detect error.
 

I'm just a tad worried that this sounds like its starting to use notification 
as a replacement for logging.If we did this for every CRUD operation on an 
object don't we risk flooding the notification system.


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


Re: [openstack-dev] [Nova] - do we need .start and .end notifications in all cases ?

2014-09-22 Thread Sandy Walsh
Hey Phil, (sorry for top-post, web client)

There's no firm rule for requiring .start/.end and I think your criteria 
defines it well. Long running transactions (or multi complex-step transactions).

The main motivator behind .start/.end code was .error notifications not getting 
generated in many cases. We had no idea where something was failing. Putting a 
.start before the db operation let us know well, at least the service got the 
call

For some operations like resize, migrate, etc., the .start/.end is good for 
auditing and billing. Although, we could do a better job by simply managing the 
launched_at, deleted_at times better.

Later, we found that by reviewing .start/.end deltas we were able to predict 
pending failures before timeouts actually occurred.

But no, they're not mandatory and a single notification should certainly be 
used for simple operations.

Cheers!
-S



From: Day, Phil [philip@hp.com]
Sent: Monday, September 22, 2014 8:03 AM
To: OpenStack Development Mailing List (openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [Nova] - do we need .start and .end notifications in 
all cases ?

Hi Folks,

I’d like to get some opinions on the use of pairs of notification messages for 
simple events.   I get that for complex operations on an instance (create, 
rebuild, etc) a start and end message are useful to help instrument progress 
and how long the operations took.However we also use this pattern for 
things like aggregate creation, which is just a single DB operation – and it 
strikes me as kind of overkill and probably not all that useful to any external 
system compared to a a single event “.create” event after the DB operation.

There is a change up for review to add notifications for service groups which 
is following this pattern (https://review.openstack.org/#/c/107954/) – the 
author isn’t doing  anything wrong in that there just following that pattern, 
but it made me wonder if we shouldn’t have some better guidance on when to use 
a single notification rather that a .start/.end pair.

Does anyone else have thoughts on this , or know of external systems that would 
break if we restricted .start and .end usage to long-lived instance operations ?

Phil

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


Re: [openstack-dev] [Nova] - do we need .start and .end notifications in all cases ?

2014-09-22 Thread Sandy Walsh
+1, the high-level code should deal with top-level exceptions and generate 
.error notifications (though it's a little spotty). Ideally we shouldn't need 
three events for simple operations. 

The use of .start/.end vs. logging is a bit of a blurry line. At its heart a 
notification should provide context around an operation: What happened? Who did 
it? Who did they do it to? Where did it happen? Where is it going to? etc.  
Stuff that could be used for auditing/billing. That's their main purpose.

But for mission critical operations (create instance, etc) notifications give 
us a hot-line to god. Something is wrong! vs. having to pour through log 
files looking for problems. Real-time. Low latency.  

I think it's a case-by-case judgement call which should be used.




From: Day, Phil [philip@hp.com]

I'm just a tad worried that this sounds like its starting to use notification 
as a replacement for logging.If we did this for every CRUD operation on an 
object don't we risk flooding the notification system.


___
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] [Nova] - do we need .start and .end notifications in all cases ?

2014-09-22 Thread Jay Pipes

On 09/22/2014 07:24 AM, Daniel P. Berrange wrote:

On Mon, Sep 22, 2014 at 11:03:02AM +, Day, Phil wrote:

Hi Folks,

I'd like to get some opinions on the use of pairs of notification
messages for simple events.   I get that for complex operations on
an instance (create, rebuild, etc) a start and end message are useful
to help instrument progress and how long the operations took. However
we also use this pattern for things like aggregate creation, which is
just a single DB operation - and it strikes me as kind of overkill and
probably not all that useful to any external system compared to a
single event .create event after the DB operation.


A start + end pair is not solely useful for timing, but also potentially
detecting if it completed successfully. eg if you receive an end event
notification you know it has completed. That said, if this is a use case
we want to target, then ideally we'd have a third notification for this
failure case, so consumers don't have to wait  timeout to detect error.


There is a change up for review to add notifications for service groups
which is following this pattern (https://review.openstack.org/#/c/107954/)
- the author isn't doing  anything wrong in that there just following that
pattern, but it made me wonder if we shouldn't have some better guidance
on when to use a single notification rather that a .start/.end pair.

Does anyone else have thoughts on this , or know of external systems that
would break if we restricted .start and .end usage to long-lived instance
operations ?


I think we should aim to /always/ have 3 notifications using a pattern of

   try:
  ...notify start...

  ...do the work...

  ...notify end...
   except:
  ...notify abort...


Precisely my viewpoint as well. Unless we standardize on the above, our 
notifications are less than useful, since they will be open to 
interpretation by the consumer as to what precisely they mean (and the 
consumer will need to go looking into the source code to determine when 
an event actually occurred...)


Smells like a blueprint to me. Anyone have objections to me writing one 
up for Kilo?


Best,
-jay

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


Re: [openstack-dev] [Nova] - do we need .start and .end notifications in all cases ?

2014-09-22 Thread Jay Pipes

On 09/22/2014 07:35 AM, Day, Phil wrote:

I'm just a tad worried that this sounds like its starting to use
notification as a replacement for logging.If we did this for
every CRUD operation on an object don't we risk flooding the
notification system.


Notifications of this sort aren't a replacement for logging. In fact, 
you'll notice that in many cases, a notification is sent at the same 
time a particular logging event is written to the log streams. The 
difference is that logging isn't consumable by the same systems that 
notifications are. They serve a different audience.


Both need to be standardized and cleaned up, though! :)

Best,
-jay

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


Re: [openstack-dev] [Nova] - do we need .start and .end notifications in all cases ?

2014-09-22 Thread Jay Pipes

On 09/22/2014 07:37 AM, Sandy Walsh wrote:

For some operations like resize, migrate, etc., the .start/.end is
good for auditing and billing. Although, we could do a better job by
 simply managing the launched_at, deleted_at times better.


I'm sure I'll get no real disagreement from you or Andrew Laski on
this... but the above is one of the reasons we really should be moving
with pace towards a fully task-driven system, both internally in Nova 
and externally via the Compute REST API. This would allow us to get rid 
of the launched_at, deleted_at, created_at, updated_at, etc fields in 
many of the database tables and instead have a data store for tasks 
RDBMS or otherwise) that had start and end times in the task record, 
along with codified task types.


You can see what I had in mind for the public-facing side of this here:

http://docs.oscomputevnext.apiary.io/#schema

See the schema for server task and server task item.

Best,
-jay

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


Re: [openstack-dev] [Nova] - do we need .start and .end notifications in all cases ?

2014-09-22 Thread Jay Lau
Hi Jay,

There was actually a discussion about file a blueprint for object
notification http://markmail.org/message/ztehzx2wc6dacnk2

But for patch https://review.openstack.org/#/c/107954/ , I'd like we keep
it as it is now to resolve the requirement of server group notifications
for 3rd party client.

Thanks.

2014-09-22 22:41 GMT+08:00 Jay Pipes jaypi...@gmail.com:

 On 09/22/2014 07:24 AM, Daniel P. Berrange wrote:

 On Mon, Sep 22, 2014 at 11:03:02AM +, Day, Phil wrote:

 Hi Folks,

 I'd like to get some opinions on the use of pairs of notification
 messages for simple events.   I get that for complex operations on
 an instance (create, rebuild, etc) a start and end message are useful
 to help instrument progress and how long the operations took. However
 we also use this pattern for things like aggregate creation, which is
 just a single DB operation - and it strikes me as kind of overkill and
 probably not all that useful to any external system compared to a
 single event .create event after the DB operation.


 A start + end pair is not solely useful for timing, but also potentially
 detecting if it completed successfully. eg if you receive an end event
 notification you know it has completed. That said, if this is a use case
 we want to target, then ideally we'd have a third notification for this
 failure case, so consumers don't have to wait  timeout to detect error.

  There is a change up for review to add notifications for service groups
 which is following this pattern (https://review.openstack.org/
 #/c/107954/)
 - the author isn't doing  anything wrong in that there just following
 that
 pattern, but it made me wonder if we shouldn't have some better guidance
 on when to use a single notification rather that a .start/.end pair.

 Does anyone else have thoughts on this , or know of external systems that
 would break if we restricted .start and .end usage to long-lived instance
 operations ?


 I think we should aim to /always/ have 3 notifications using a pattern of

try:
   ...notify start...

   ...do the work...

   ...notify end...
except:
   ...notify abort...


 Precisely my viewpoint as well. Unless we standardize on the above, our
 notifications are less than useful, since they will be open to
 interpretation by the consumer as to what precisely they mean (and the
 consumer will need to go looking into the source code to determine when an
 event actually occurred...)

 Smells like a blueprint to me. Anyone have objections to me writing one up
 for Kilo?

 Best,
 -jay


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




-- 
Thanks,

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


Re: [openstack-dev] [Nova] - do we need .start and .end notifications in all cases ?

2014-09-22 Thread Sandy Walsh


From: Jay Pipes [jaypi...@gmail.com]
Sent: Monday, September 22, 2014 11:51 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Nova] - do we need .start and .end notifications 
in all cases ?

On 09/22/2014 07:37 AM, Sandy Walsh wrote:
 For some operations like resize, migrate, etc., the .start/.end is
 good for auditing and billing. Although, we could do a better job by
  simply managing the launched_at, deleted_at times better.

I'm sure I'll get no real disagreement from you or Andrew Laski on
this... but the above is one of the reasons we really should be moving
with pace towards a fully task-driven system, both internally in Nova
and externally via the Compute REST API. This would allow us to get rid
of the launched_at, deleted_at, created_at, updated_at, etc fields in
many of the database tables and instead have a data store for tasks
RDBMS or otherwise) that had start and end times in the task record,
along with codified task types.

You can see what I had in mind for the public-facing side of this here:

http://docs.oscomputevnext.apiary.io/#schema

See the schema for server task and server task item.

Totally agree. Though I would go one step further and say the Task state
transitions should be managed by notifications.

Then oslo.messaging is reduced to the simple notifications interface (no RPC).
Notification follow proper retry semantics and control Tasks. 
Tasks themselves can restart/retry/etc.

(I'm sure I'm singing to the choir)

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


Re: [openstack-dev] [Nova] - do we need .start and .end notifications in all cases ?

2014-09-22 Thread Jay Pipes

On 09/22/2014 11:42 AM, Sandy Walsh wrote:

Totally agree. Though I would go one step further and say the Task state
transitions should be managed by notifications.

Then oslo.messaging is reduced to the simple notifications interface (no RPC).
Notification follow proper retry semantics and control Tasks.
Tasks themselves can restart/retry/etc.

(I'm sure I'm singing to the choir)


Yep. I'm loving the music.

-jay

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


Re: [openstack-dev] [Nova] - do we need .start and .end notifications in all cases ?

2014-09-22 Thread Jay Pipes

On 09/22/2014 11:22 AM, Jay Lau wrote:

Hi Jay,

There was actually a discussion about file a blueprint for object
notification http://markmail.org/message/ztehzx2wc6dacnk2

But for patch https://review.openstack.org/#/c/107954/ , I'd like we
keep it as it is now to resolve the requirement of server group
notifications for 3rd party client.


Sure, no problem. I'll review the above shortly.

Best,
-jay

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