On 11/10/2011 08:12 AM, Jay Dobies wrote:
Perhaps 'rebooted' being past tense suggests that the machine has
already been rebooted but what it means is the the 'shutdown -r <delay>'
command has been executed. The delay is designed to allow time for the
RMI reply to occur. Maybe the return should be:
{ installed : [], reboot_scheduled : <bool> }
Ahhh, ok, I get it.
I don't know much about the server-side of things. Where do we store that
returned
information? Is that just persisted in the task's return value or is there a
more formal
consumer audit trail concept?
Currently, we just grab it out of the task 'result' which has concerned me lately. The
more I work with katello and other external (non pulp CLI) users of our REST API, the more
I notice these kinds of things. For the package (and package group) install flows which
include errata, we pass data back to the REST API call through the task which exposes our
internal tasking and manager layer to the REST caller. This has concerned me for the past
few days. I'm in the process of raising this for discussion separately.
I know this is about to fall under scope creep, but would we want to enhance
this later to
lay down a one-time run script that would ping the Pulp server after the reboot
to say it
completed? It's a neat idea but may be delving way more into the monitoring
aspect than
Pulp is looking to handle.
Yeah, let's look into this.
I kind of lean toward putting the units in the comments along with all
the other information about the property (I know, big surprise). But,
since you took the time to review this and comment ... how about I make it:
delay_minutes
Nah, it's totally up to you, comments are fine too. I was just throwing out a
stylistic
alternative.
_______________________________________________
Pulp-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/pulp-list
