[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Pulp-list] Automatic Updates



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]