Code Monkey home page Code Monkey logo

Comments (8)

mancdaz avatar mancdaz commented on July 21, 2024

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).

from ansible-lxc-rpc.

mancdaz avatar mancdaz commented on July 21, 2024

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?

from ansible-lxc-rpc.

mancdaz avatar mancdaz commented on July 21, 2024

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.

from ansible-lxc-rpc.

mancdaz avatar mancdaz commented on July 21, 2024

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?

from ansible-lxc-rpc.

mancdaz avatar mancdaz commented on July 21, 2024

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!

from ansible-lxc-rpc.

mancdaz avatar mancdaz commented on July 21, 2024

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.

from ansible-lxc-rpc.

mancdaz avatar mancdaz commented on July 21, 2024

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.

from ansible-lxc-rpc.

mancdaz avatar mancdaz commented on July 21, 2024

Solved by the use of the password gen script, and documentation

from ansible-lxc-rpc.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.