[Yum] Not quite an idea.

[Carwyn Edwards]

seth vidal wrote:

>>These kind of considerations come into the frame when you are thinking 
>>about accountability and traceability - e.g. an ISP that want's to show 
>>that it _did_ have a security patch installed when that DDoS happened.
>>    
>>
>
>That's what logs are for and specifically the rpm cron job which dumps
>rpm -qa to a file nightly.
>  
>
We're thinking a bit more about the theoretical side - specifically in 
terms of being able to do things like meeting SLAs.  Logs are fine for 
after the event and assume that your logs have not been tampered with. 
In addition what happens on a machine is quite often not exaclty what 
you think happened. Comparing Logs against a declarative statement of 
what you acually wanted to happen makes it much simpler to spot the bit 
that went wrong.

If you give your client a "machine configuration definition" along with 
an SLA things get, erm, interesting (I'm not saying it's sensible :-)).

>> As long as you can do things like rollback updates and uninstall 
>> software then functionally it would do most things we have found useful.
>  
>
>
>do you mean rpm rollbacks? Have you done them?
>
No, I mean be able to make a machine into a web server on a monday, then 
into a database server on a tuesday, then back to being a web server on 
wednesday. Why? Think about IBM's computing power as a utility project. 
We want to be able to hold configuration definitions for a "development 
environment" that has all the data required to configure a network of 
machines and all the software. Just like you do something like 
File->New->Project in a development IDE, we want to be able to do 
Config->New->Software Development Team and have all the infrastructure 
allocated from a pool of hot swap office workstations. No human 
intervention required. We sort of have this ability already, but it's 
not very clean in implementation terms.

Using a procedural model means having to "code" the logic of the state 
transitions from Webserver (A) to Database Server(B) back to WebServer 
(A) =  A -> B -> A.

A declarative model describing information about the states is much 
simpler than describing the transitions (the procedure required to move 
from A to B). Writing a tool to do the hard work is better. It gets 
really complicated when you consider that a transition contains ordering 
information.

install foo, install bar, uninstall foo, uninstall bar

can have different results to

install foo, install bar, uninstall bar, uninstall foo

This is not such a problem on a single machine, but if you have two 
machines that you want to make 100% identcal a tool will be more 
consistent than a human when it comes to "coding" the transition.


>So you want to make a list of what the machine should look like and have
>the client tool figure out what needs to happen to make that so?
>  
>
Yes :-)

Is this what I'm hearing gridweaver does?

Yes - although that's not gridweaver - gridweaver is a research project 
between HP, Informatics and EPCC. Updaterpms is the software tool, LCFG 
and SmartFrog are the configuration tools.

>It seems a pain to keep up with specific version numbers in this file
>though. That's one of the reasons I like just being able to say 'this
>package, whatever version is newest and available'
>
At the moment we do both:

foo-1.2.3-4
bar-*-*

.. * wildcard match on the latest version.

Yes, keeping the version numbers matched _is_ a pain :-) This is why I'm 
looking for other ways of doing fine grain controls on updates. What we 
have is very fine grain, but not very user friendly. We'd rather 
contribute our ideas (and effort when I have time) to a good general 
tool like yum than keep maintaining our tool though.

I must admit that some of my comments only really start to hold strength 
when combined with using a central system for configuration information 
not just centralised software management.

Carwyn