Comments (7)
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 banana.
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 banana.
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 banana.
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 banana.
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 banana.
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 banana.
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 banana.
Related Issues (20)
- haproxy db users always created HOT 2
- Should be able to limit setup plays to a set of hosts or containers
- Configuration generation is inconsistent HOT 1
- All Package repos need to be replaced with the frozen repo HOT 4
- All git repos should be set to a TAG or SHA. HOT 2
- Glance requires an entry for snet endpoint even when not using swift for the image backend. HOT 1
- Repo generator should be able to generate config containing all available packages
- [kibana] kibana is redirecting to internal lb elasticsearch vip when accessing from external vip, causing dashboard to fail HOT 2
- Heat MaaS api metric names are incorrect HOT 2
- mass_scheme duplicate variable causing issues for horizon_maas_scheme HOT 2
- Glance image replication, or other such mechanisms HOT 2
- Time out on initial Network check is probably too long HOT 1
- Rabbit FQDN Issues returning HOT 1
- [Cinder] iSCSI doesn't require running nova-compute outside of a container after all! HOT 3
- Frozen repos - raxmon HOT 3
- Ensure hostname referenced in rabbitmq check in maas_local.yml playbook is correct HOT 5
- README out of date
- Pinned Repo broken for linux-image-extra-virtual HOT 2
- dnsmasq package not available in pinned apt repo HOT 23
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from banana.