[Pulp-list] Automatic Updates

[Todd B Sanders]

On 12/23/2010 09:41 AM, Bryan Kearney wrote:
> On 12/22/2010 01:26 PM, Todd B Sanders wrote:
>> On 12/22/2010 11:02 AM, Jay Dobies wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 12/21/2010 05:51 PM, Todd B Sanders wrote:
>>>> Beginning to think about Automatic Updates....
>>>>
>>>> https://fedorahosted.org/pulp/wiki/AutomaticUpdates
>>>>
>>>> Comments Please....
>>>>
>>>> -Todd
>>> I like option 2. I think having it driven by the pulp APIs makes sense
>>> given the rest of the functionality pulp provides.
>> I agree. Of course this doesn't limit the ability for the customer to
>> configure some of their managed systems (i.e. dev environments) directly
>> via their configuration management solution. Just means that Pulp will
>> ignore it.
>>> The more of this type of stuff we add the more I'm starting to want an
>>> alert subsystem in place. It'd be really slick if we had a good
>>> infrastructure to set up notifications if a consumer update/repo
>>> sync/cds sync failed. There are a ton of places we could go with it, 
>>> but
>>> I'm off topic from this original email.
>>>
>>> "# We would not recommend configuring automatic updates on the client
>>> (above) and configuring a maintenance window on a client "
>>>
>>> I'm not sure I follow. The two seem to go hand in hand to me; we'd want
>>> to say "automatically update the client during its window." Or are you
>>> saying its effectively duplicate functionality that we don't want in
>>> play at the same time?
>>
>> Correct. Thinking that if you want to go through the trouble of setting
>> up a controlling maintenance window, you should not configure automatic
>> updates via client config, but rather let Pulp handle installing those
>> updates within the window in a coordinated fashion to distribute load.
>> Not to say you can't do both, but seems to be at odds with one another.
>>
>> -Todd
>>> "# For consumer groups, we need to stagger these operations to ensure
>>> that we don't create a demand spike on the server. "
>>>
>>> +1. We may even want to enhance the views on maintenance windows to be
>>> able to show something like "X% of your consumers all share the same
>>> maintenance window, you may want to rethink that."
>>>
>>>
>
> What else will run on a scheduled basis? And which of these will run 
> inside a maintenance window:
>
> Puppet Updates (MW: Yes)
> Package Updates (MW: Yes)
> SCAP (MW: No)
> Puppet no-op (MW: No)
> Package Scanning (MW: No)

Any other remote actions/scripts (i.e. system reboot, start/stop/restart 
process, etc) could run in a maintenance window if defined for the 
consumer or consumer group.

SCAP if it's only reporting; if it's also remediation...then any 
config/package updates will be handled in the window (again if defined).

-Todd
>
> Are there others?
>
> -- bk