Since it has been decided that the provisioning modules (esx_, hpilo_,
virt_ boot/facts) will not be in the ansible core, we've been thinking
about giving them a good home where they get 'the attention they
deserve'. Especially since there are at least two companies already
using them.
I can see two options:
- we create a new project on github for them
- Michael adds a repository to the ansible project and gives us access
rights to it
I believe the second option is the best one since there is a higher
chance that someone will notice the modules. In addition, I think the
same should be done for the python and database modules. We can have
focus groups and clear maintainership without sacrificing much
visibility.
I believe the second option is the best one since there is a higher
chance that someone will notice the modules. In addition, I think the
same should be done for the python and database modules. We can have
focus groups and clear maintainership without sacrificing much
visibility.
Agreed. Contrib has not gotten a lot of traction. (I want to
change some of this by creating "Resources" as a top level page in the
docs project, so more people will find it)
I'm willing to give you access to a repo in the organization.
"ansible-provisioning" ok for a project name with you and dag with
commit access?
I will try to not express preferences where this goes, especially as I
don't have time to work on the provisioning modules, except maybe a
suggestion from time to time
I would ask that you guys, if doing this, produce some example
playbooks that show it all used in conjunction, and some READMEs about
setup/limitations/requirements/tested software versions/etc.
I didn't have room for that level of documentation on the module docs page.
Is there a strong argument for not placing these modules won't be in the core? They're extremely useful, and I think anything less than core level visibility really appears to put them on the back burner in terms of importance.
Many of these modules require a lot of infrastructure that many of us
don't have, and therefore testing them for me a challenge.
It seems to imply certain additional helper scripts, conventions,
plugins, that should be grouped together.
I think there's a requirement for more documentation beyond module docs.
I think people adopting Ansible should not feel that they have to grok
the provisioning component up front, and that they should feel like
their can provision how they want. So we really shouldn't vote
for a particular horse.
It also makes sense to have some strong module collections that are
really good to point at. Contrib isn't that. Perhaps a way to
foster that kind of add-on module development is to not absorb
everything immediately into core.
I think it would be good if they could be updated outside of the
release process.
Ultimately it's kind of a gut feeling. It will definitely allow me
to focus a lot more. We have been going really fast lately. 0.9 is
loaded with ideas. Finding ways to spread out efforts seems vitally
important.
This will help me focus more knowing we've delegated better, and it
will also allow the provisioning stuff to grow faster and keep a
seperate ticket queue.
When this takes off and eventually resembles a product we'd feel
comfortable shipping to customers (re: what Michael said;
documentation, examples, etc), I'm on board for creating an
ansible-extras (or whatever you want to call it) package to work on
including in Fedora.
Makes sense, particularly that people shouldn't feel they have to use and understand the provisioning modules when first learning Ansible. As well, additional documentation never hurts.
If you think these modules need it, I would be willing to write up some additional documentation, as I've got some ESX infrastructure that I could test against. (Don't let my mangled sentence from the previous email be an indication of quality Also considering making DRAC provisioning and facts modules, since I've got Dell hardware, not HP.
I'm willing to give you access to a repo in the organization.
"ansible-provisioning" ok for a project name with you and dag with
commit access?
Great! The name is ok for me, although Dag preferred 'ansible-provision'.
I will try to not express preferences where this goes, especially as I
don't have time to work on the provisioning modules, except maybe a
suggestion from time to time
I would ask that you guys, if doing this, produce some example
playbooks that show it all used in conjunction, and some READMEs about
setup/limitations/requirements/tested software versions/etc.
I didn't have room for that level of documentation on the module docs page.
Ok. That seems fair.
We're also planning to use these modules for automated testing of
Relax-and-Recover. That's a nice case to describe.
I think Dag's T-DOSE presentation will be about these modules.
When this takes off and eventually resembles a product we'd feel
comfortable shipping to customers (re: what Michael said;
documentation, examples, etc), I'm on board for creating an
ansible-extras (or whatever you want to call it) package to work on
including in Fedora.
That is, if people are interested in that route.
Yes, it should be our goal to have packages like
'ansible-provisioning', 'ansible-database' or 'ansible-python'
available for users to choose from.
DELL DRAC support certainly is something I would like to see as well, and also IBM RSA support. That covers the most important players in the Intel market.
Same goes for plugins for RHEV, VirtualBox, Cobbler, etc... so that it's up to the organization to decide where to get the 'complete' inventory from (probably a custom inventory script) together with facts-gathering and provisioning using these modules.
The challenge will be to have a similar set of options and option-arguments throughout the modules.
Ultimately, as I described earlier, I believe that multi-source inventory as part of core is more important because this abstraction layer solves a lot more issues (facts-based grouping, generic inventory scripts) without forcing this on new users (it can still work the easy way using INI files). It's not unlikely we'll implement multi-source inventory as part of ansible-provision as a pluggable inventory script to prove such a mechanism works. That said I understand very well the need to focus on core and not tackle all battles at once with the growing, but limited resources we have.
The reasons I would have prefered the provisioning modules to be part of core is mostly because it makes it easier to get installed, we can use the same documentation infrastructure, etc... on the other hand, having this in a separate project gives certain freedoms as well. So I am not too worried, we'll have ansible-provision packages as well and man-pages.
We should look into making group_vars and host_vars implemented by a
plugin system that forms the first example of this.
I have it on my list to clean up for 0.9 already, so this would make
it possible, getting variables from all over, and caching them
smartly.
All existing modules and plugins are now added, and at least 'make rpm' works and creates an ansible-provisioning rpm with included man-pages.
We plan to come up with an integrated real-life example.
Question is where we plan to host any documentation we will create. I would prefer this to be on http://ansible.cc/ too. This is an important facet of getting more users and contributors for the provisioning part.
Question is where we plan to host any documentation we will create. I would
prefer this to be on http://ansible.cc/ too. This is an important facet of
getting more users and contributors for the provisioning part.
This is not a part of the core, so ... we'd be back to my original
reasons for wanting this split off.
I would suggest documenting it with a series of markdown files, as
github does a very nice job about that.
BTW, I also would not copy the module formatter program, as that leads
to dual maintaince -- it's probably safe to say you would check this
out at the same level as ansible so the makefile could just reference
"../"
getting more users and contributors for the provisioning part.
This is not a part of the core, so ... we'd be back to my original
reasons for wanting this split off.
I would suggest documenting it with a series of markdown files, as
github does a very nice job about that.
So there will not be a reference to this project from the main website
either Similar to contrib not being mentioned on the main website either
?
Please don't assume I'm out to get you
I don't assume, I just know !
I want to move links to useful community resources into the docs project as
it's own page, as I've started earlier.
I guess I missed that. The current resources page has a shortened URL to the ansible/ansible-resources with a link to contrib. High probability to miss IMO.
If you have a plan to fix this, let me know and I'll move/re-edit the stuff the way you'd like it to be(come).
Gettng back to the documentation, the modules are currently documented as all the other modules, which is great for man-pages, but it does not integrate for the web if we plan to do markdown documentation :-/
Gettng back to the documentation, the modules are currently
documented as all the other modules, which is great for man-pages,
but it does not integrate for the web if we plan to do markdown
documentation :-/
would you like me to add Markdown output to the module_formatter? Pretty
easy to do ...
Also considering making DRAC provisioning and facts modules, since I've got Dell hardware, not HP.