search

mancdaz / banana

test issue import
0 stars 0 forks source link

We should abort installation if passwords aren't set in user_variables.yml #9

Open mancdaz opened 10 years ago

mancdaz commented 10 years ago

Issue by miguelgrinberg Thursday Aug 21, 2014 at 02:06 GMT Originally opened as https://github.com/rcbops/ansible-lxc-rpc-orig/issues/427

When the passwords aren't set in user_variables.yml an obscure failure occurs when restarting rabbitmq due to the cookie being empty. Probably better to check for non-empty passwords and abort with a meaningful error message.

mancdaz commented 10 years ago

Comment by andymcc Wednesday Aug 27, 2014 at 10:38 GMT

Agree - do we think this should go in the install script though? @johnmarkschofield what do you think? I think it might be impractical to set this in a "play" because that play may not get run (depending on what playbook you run) and additionally, the plays are very much "go do this work", so as individual units will fail if the vars aren't set, but a whole bunch that don't require these values will succeed (as expected - and it seems wrong to create a play to specifically check this).

mancdaz commented 10 years ago

Comment by johnmarkschofield Wednesday Aug 27, 2014 at 18:08 GMT

@andymcc Why does it seem wrong to create a play specifically to check this? (Hmm. Because some passwords aren't required in all circumstances?)

My first thought was to create a play that checked all required passwords, and include it at the start of any play that referenced those passwords.

However, I don't think the use case for this is "I'm rerunning just the cinder playbooks, so I want to check in case all my passwords somehow became blank."

I think the use case for this is "I'm running this for the first time, and I don't want to discover after 40 minutes of my ansible run that it bombs out because I forgot to set passwords."

In that case, checking for required passwords somewhere in the host setup playbook (or another playbook that executes early) would probably be a good idea.

I'd say make it a separate play that checks passwords so it can be included in other places if we desire later.

Your thoughts, @andymcc and @miguelgrinberg?

mancdaz commented 10 years ago

Comment by andymcc Wednesday Aug 27, 2014 at 18:17 GMT

@johnmarkschofield I'm thinking of the following scenario:

We opensource only the openstack bits at some point - it goes into some upstream repository, and not the whole lxc bit (which we probably wouldn't). In which case the check would need to take place at the beginning of the openstack play, and not the overall run. It would be impractical for now though, otherwise you would end up setting up everything only to fail at the openstack bit.

We could create a play for that which we can just include before the openstack bits if necessary, and run as the first play initially - that would work.

I just thought perhaps checking this kinda thing would be more an "install script" thing. My thinking is, we're asking a play to do x y z and it does those things. So if you haven't specified a password its not really the playbook/plays fault, and you almost expect it to fail at the point where it needs to use those values, but of course guarding against this is sensible.

I'm happy for a play to be the thing though, we'd just need to include it as part of the "setup" thing, if you guys think thats the best way (we can then also include that same play in the openstack section if people are doing this on "not LXC") Either that or the install script.

mancdaz commented 10 years ago

Comment by miguelgrinberg Wednesday Aug 27, 2014 at 18:38 GMT

It seems a single check that runs through all the passwords and ensures they are not empty may not be a big help, since you will need to remember to run it, as @andymcc pointed out.

But how about checking each individual password in the proper place?

The rabbit playbook can fail if there is no rabbit password set. This makes a lot of sense to me, since not having a password prevents the thing from even starting. So I think what I'm now proposing is if we should check that each password variable is not empty at the point it is used. That way you can go set the missing password and rerun the playbooks from that point on.

Thoughts?

mancdaz commented 10 years ago

Comment by andymcc Wednesday Aug 27, 2014 at 19:13 GMT

If the plays are completing successfully without passwords - meaning it won't actually work post "successful" run (and not failing out) I'd say thats a bug, so I'm in favour of that!

mancdaz commented 10 years ago

Comment by miguelgrinberg Wednesday Aug 27, 2014 at 20:36 GMT

Not exactly. The rabbit play fails, but due to a downstream failure that in my opinion is pretty obscure, something about the "cookie being too short". Trying to start rabbit manually (i.e. service rabbitmq start) would also fail with the same error.

Not having used rabbit before I had to go dig into logs, google the error, with the bad luck that it happens for other conditions besides having an empty password, so only after a few false leads I ended up realizing the error was directly related to having an empty password.

If the rabbit playbook had failed in a "password not empty" check pre-installation then all that time would have been saved.

mancdaz commented 10 years ago

Comment by andymcc Thursday Aug 28, 2014 at 07:32 GMT

I think checking required variables within the play itself (e.g. rabbit play checks a specific required variable is set) sounds good and sensible, unless there is a sane default that can be used, for passwords that isn't the case so I'm in favour.