controlling package updates

[craig mcmillan]

hi,

i have a cluster of machines in various roles, which are installed and
configured by pallet : https://github.com/trampoline/clustermap-mesos

so far, so good

now, the things i mostly seem to want to do with pallet are :

1. instantiate, install and configure new instances into the cluster
2. update package versions on existing instances
3. update configuration on existing instances

i would like to be able to

- do [1] without doing [2] across the cluster (though [1] may often
involve some element of [3], so that cluster peers, such as
elasticsearch or zookeeper masters, are aware of each other)
- do [3] without doing [2], since i want to make minimal changes to a
running production cluster

but i'm a bit stuck on how to achieve this :

currently i've got everything in a :configure phase, which causes [2] to
be run whenever i converge or lift, so [2] is always done whenever i do
[1] or [3]

how do other folks achieve this ?

i can see that if i put package updates into a separate phase then i
could do [3] without [2], but i would still have the problem of [1]
causing [2] across the cluster, since i would need to specify the update
phase when converging

thanks

:craig

[Michael Jerger]

Hi,

as you said, distributing your steps to different phases is a good way in any case.
The dependencies between [1] and [2] you can disperse in two dimensions:

1. functional dependecies: Your'e free to define functions which can be used from both phases [1] and [2]. So you will have no code redundancy ..
   
2. data depenencies: There are several contexts, serving for data share. I'm learning too at this point, so I can just enumerate them - maybe someone else can give an short comment about my assumptions?
1. pallet.context - provides an overview over different contexts - I've not further used this
   
2. pallet.environment - maybe access to pallets execution environment?
   
3. pallet.session - I used this to access to pallets current execution run informations. You can get information from target node (use the node interface to access information). Maybe you can transport runtime-information (e.g. for cluster config or from one crate to an other crate) at this place?
   
4. pallet.parameter - maybe can be used to handover information to some crates?

As we are talking about contexts, maybe someone could give me some hints at the following additional questions, I'm currently thinking about?

1. There is mentioned a way, to configure projects / server-groups - how should I configure my server groups, ip's, names?
2. For files being copied as remote-file to the target nodes. I figured out how to serve files from local file system, but assume there are more ways to serve from. May I serve files
   
1. From classpath?
2. Is there an way I missed?
   

Best Regards,
Michael