[Pulp-list] Sanity Check

[Jason Dobies]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Last, and most significant, is how the API classes leverage (1-3).  The
> API methods such as ConsumerApi.installpackages() need to do something
> on the agent and then update consumer history if the agent (RMI) was
> successful.  This is what makes this kind of tricky.  So, what I decided
> to implement this by subclassing the AsyncTask as
> pulp.server.api.consumer.InstallPackages.  This specialized task is
> created/enqueued and returned by ConsumerApi.installpackages() giving
> InstallPackages.install() as the task's target callable.  When invoked,
> it sends the RMI.  Then, when the reply comes in and Task.succeeded() is
> called by the queue.  This method is overridden in InstallPackages which
> calls super.succeeded() and then updates the consumer history.

We might want to update consumer history even if the install was
unsuccessful. It can be argued either way:
- - Since the install failed, nothing changed, hence there's nothing to
report about in the history.
- - Since an attempt to change the client was made, we should record that.

I tend to lean towards the latter. In terms of the async RMI, it
shouldn't be too difficult of a hook to add in, we'd just check for
Task.failed as well.

However before we even get there, this is something I hadn't exactly
accounted for in the consumer history. We could either:
- - Add a new event type ("package_install_failed")
- - Add a flag to all events that say if it was successful or failed (may
not make sense in all cases)
- - Add a flag just to package installed/uninstalled to indicate if it was
successful or not, and also information on why it failed. This fits in
with the current model of each event type having a blob of event type
specific stuff.

I'm kinda threadjacking this with that history event discussion though,
so let's not go too far down that path. To keep on track, am I correct
in assuming it'd be a pretty simple hook to tie into the task failing as
well as succeeding?

> It looks like this:
> 
> WS(controller)-->ConsumerApi.installpackages()-->FIFOQueue.enqueue(task)
>   [ task runs Task.callable() ]
> InstallPackages.install()-->AsyncAgent.packages.install()
>   [ RMI to agent ]
>   [ agent reply received on QPID queue ]
> ReplyListener.succeeded(reply)
>   -->FIFOQueue.find(taskid)
>   -->InstallPackages.succeeded(reply)
>   -->Super.succeeded(reply)
>   -->ConsumerHistoryApi.packages_installed()
> 
> Done.
> 
> The goal was to provide for arbitrary complexity on how the API was
> implemented which includes doing the async RMI to the agent and then
> following up with calls to update the consumer history and so forth. 
> Mixing synchronous and asynchronous logic within the API implementation
> makes it a little trickier.  I also wanted to minimize the async
> (tasking & RMI) plumbing in the API files.
> 
> 
> Hope this makes sense.  It's pretty straight forward but we can discuss
> on a call if we need to.  Thoughts?

I didn't dig into the code, but the approach sounds solid and I'm pretty
confident it translates over to the code closely.

> -jeff
> 
> 
> 
> _______________________________________________
> Pulp-list mailing list
> Pulp-list at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-list


- -- 
Jason Dobies
RHCE# 805008743336126
Freenode: jdob
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJMm3AYAAoJEOMmcTqOSQHCPLAH/RTg8sE2WZ+cGh5/ldtTjXnH
He42/I8H2bklZEShT2LTs4AO49GAyimeufBusXkT5xZYuEySIHy+XcHWwA5wP4hY
p/eRcPJRFJFnoewitL+RcVidoVRW2ZWTvDDvXCEvF68ni53RhrkuFN/ZRxn5rAb0
WkAao46mDdA97tUGMDnaOwSstpbzSDZxmGNEfoK/dLzRuCG8S7OGnF/58B0YR/tQ
Oy6Udl6TT/nM5fC+eQnl2k9qGeLhYSWiAdG65sn97kUx4fM79aie3baJLAsYLTYm
jeq6ad8N27oQ+HGhVGMXqHJoBwtyq5/BmL9wo9XoRRW3QXB7jw14HnKGvrLD3iQ=
=L2VO
-----END PGP SIGNATURE-----