service unit deployment removal should clean up unit workflow state files

[Kapil Thangavelu]

as well as unit relation workflows. jim and i discussed this.. at minimum we'll just remove unit internal id prefixed files from the state directory.

[Kapil Thangavelu (hazmat)]

Particularly this causes a problem when destroying a service and then redeploying a new service with the same name and the same unit name to a particular machine, as the agent will pickup the old on disk files as its current state.

[Gustavo Niemeyer (niemeyer)]

We should probably enforce the non-reuse of old unit ids in this case too.

[Kapil Thangavelu (hazmat)]

On 03/09/2011 09:54 AM, Gustavo Niemeyer wrote:
> We should probably enforce the non-reuse of old unit ids in this case
> too.
>

How so? the internal unit id sequence is globally unique. i discussed
this with jim yesterday, to encode a prefix for state files of unit
internal-id on all the relevant state files on disk, which will
effectively result in proper identification of state.

There is some opportunity for ambiguity here if the machine agent
service unit deployment fails, the unit gains independent state changes
while on another machine, and then is re-associated to its original
machine. but that's quite a chain of supposition.

[Gustavo Niemeyer (niemeyer)]

> How so?

Not reusing unit ids means not allowing mysql/1 to exist twice, ever.

> the internal unit id sequence is globally unique. i discussed
> this with jim yesterday, to encode a prefix for state files of unit
> internal-id on all the relevant state files on disk, which will
> effectively result in proper identification of state.

I don't really understand what this means. Do you have a better write
up on the proposal?

[Kapil Thangavelu (hazmat)]

On 03/09/2011 11:35 AM, Gustavo Niemeyer wrote:
>> How so?
>
> Not reusing unit ids means not allowing mysql/1 to exist twice, ever.

ic. so no ambiguity even in the face of a user reallocating a service
name across multiple service instances.

>
>> the internal unit id sequence is globally unique. i discussed
>> this with jim yesterday, to encode a prefix for state files of unit
>> internal-id on all the relevant state files on disk, which will
>> effectively result in proper identification of state.
>
> I don't really understand what this means. Do you have a better write
> up on the proposal?
>

I was talking more towards just solving the immediate issue of
code/agents being able to uniquely identify state and perform cleanup.

[Gustavo Niemeyer (niemeyer)]

>> Not reusing unit ids means not allowing mysql/1 to exist twice, ever.
>
> ic. so no ambiguity even in the face of a user reallocating a service
> name across multiple service instances.

Not sure about what you mean here. I will guess that you mean
renaming a service A => B, and a service C => A.

If that's the case, we have to define if renaming services at all is
allowed or not. It feels like it shouldn't be allowed, in principle.
We can review that decision later, but it creates a lot of complexity
and potential for confusion for no great benefit.

> I was talking more towards just solving the immediate issue of
> code/agents being able to uniquely identify state and perform cleanup.

Sorry, I'm not following you. code/agents are already able to
uniquely identify state, as I understand it.

--
Gustavo Niemeyer
http://niemeyer.net
http://niemeyer.net/blog
http://niemeyer.net/twitter

[Clint Byrum (clint-fewbar)]

This one really slows formula dev and upgrade-by-deploying. Have to make sure to terminate machines every time between destroy/deploy. :-/