# Provisioning Modules

**URL:** <https://forum.ansible.com/t/provisioning-modules/11978>\
**Category:** Ansible Project\
**Created:** [October 13, 2012, 6:15pm UTC](https://forum.ansible.com/t/provisioning-modules/11978 "2012-10-13T18:15:40Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jeroen\_Hoekx](https://avatars.discourse-cdn.com/v4/letter/j/ba9def/32.png) [@Jeroen\_Hoekx](https://forum.ansible.com/u/Jeroen_Hoekx)\
**Post date:** [October 13, 2012, 6:15pm UTC](https://forum.ansible.com/t/provisioning-modules/11978/1 "2012-10-13T18:15:40Z")

</div>

So,

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.

Any thoughts?

Jeroen

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [October 13, 2012, 6:44pm UTC](https://forum.ansible.com/t/provisioning-modules/11978/2 "2012-10-13T18:44:33Z")

</div>

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

Sounds good!

--Michael

---

<div class="post-metadata">

**Author:** ![Collin\_Allen](https://avatars.discourse-cdn.com/v4/letter/c/7993a0/32.png) [@Collin\_Allen](https://forum.ansible.com/u/Collin_Allen)\
**Post date:** [October 13, 2012, 6:44pm UTC](https://forum.ansible.com/t/provisioning-modules/11978/3 "2012-10-13T18:44:58Z")

</div>

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.

~ Collin

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [October 13, 2012, 7:06pm UTC](https://forum.ansible.com/t/provisioning-modules/11978/4 "2012-10-13T19:06:16Z")

</div>

Several reasons, not all related.

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.

--Michael

---

<div class="post-metadata">

**Author:** ![Tim\_Bielawa](https://avatars.discourse-cdn.com/v4/letter/t/ed8c4c/32.png) [@Tim\_Bielawa](https://forum.ansible.com/u/Tim_Bielawa)\
**Post date:** [October 13, 2012, 7:21pm UTC](https://forum.ansible.com/t/provisioning-modules/11978/5 "2012-10-13T19:21:02Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Collin\_Allen](https://avatars.discourse-cdn.com/v4/letter/c/7993a0/32.png) [@Collin\_Allen](https://forum.ansible.com/u/Collin_Allen)\
**Post date:** [October 13, 2012, 9:54pm UTC](https://forum.ansible.com/t/provisioning-modules/11978/6 "2012-10-13T21:54:00Z")

</div>

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.

~ Collin

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [October 13, 2012, 11:17pm UTC](https://forum.ansible.com/t/provisioning-modules/11978/7 "2012-10-13T23:17:59Z")

</div>

That all sounds fantastic.

--Michael

---

<div class="post-metadata">

**Author:** ![Jeroen\_Hoekx](https://avatars.discourse-cdn.com/v4/letter/j/ba9def/32.png) [@Jeroen\_Hoekx](https://forum.ansible.com/u/Jeroen_Hoekx)\
**Post date:** [October 14, 2012, 6:51am UTC](https://forum.ansible.com/t/provisioning-modules/11978/8 "2012-10-14T06:51:34Z")

</div>

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

Greetings,

Jeroen

---

<div class="post-metadata">

**Author:** ![Jeroen\_Hoekx](https://avatars.discourse-cdn.com/v4/letter/j/ba9def/32.png) [@Jeroen\_Hoekx](https://forum.ansible.com/u/Jeroen_Hoekx)\
**Post date:** [October 14, 2012, 7:09am UTC](https://forum.ansible.com/t/provisioning-modules/11978/9 "2012-10-14T07:09:19Z")

</div>

Collin and Tim,

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

---

<div class="post-metadata">

**Author:** ![Dag\_Wieers](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@Dag\_Wieers](https://forum.ansible.com/u/Dag_Wieers)\
**Post date:** [October 14, 2012, 8:31am UTC](https://forum.ansible.com/t/provisioning-modules/11978/10 "2012-10-14T08:31:26Z")

</div>

Collin,

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.

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [October 14, 2012, 1:53pm UTC](https://forum.ansible.com/t/provisioning-modules/11978/11 "2012-10-14T13:53:48Z")

</div>

"ansible-provisioning" it will be then.

Creating soon.

I have some ideas about multi-source inventory.

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.

--Michael

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [October 14, 2012, 11:23pm UTC](https://forum.ansible.com/t/provisioning-modules/11978/12 "2012-10-14T23:23:27Z")

</div>

Done.

[https://github.com/ansible/ansible-provisioning](https://github.com/ansible/ansible-provisioning)

Dag and Jeroen are have repository admin privileges and can be in  
charge of merging pull requests.

Please fill it with stuff!

I'd expect a separate modules, plugins, examples, and docs directory, etc.

--Michael

---

<div class="post-metadata">

**Author:** ![Dag\_Wieers](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@Dag\_Wieers](https://forum.ansible.com/u/Dag_Wieers)\
**Post date:** [October 15, 2012, 10:18am UTC](https://forum.ansible.com/t/provisioning-modules/11978/13 "2012-10-15T10:18:48Z")

</div>

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/](http://ansible.cc/) too. This is an important facet of getting more users and contributors for the provisioning part.

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [October 15, 2012, 12:36pm UTC](https://forum.ansible.com/t/provisioning-modules/11978/14 "2012-10-15T12:36:25Z")

</div>

> Question is where we plan to host any documentation we will create. I would  
> prefer this to be on [http://ansible.cc/](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  
"../"

---

<div class="post-metadata">

**Author:** ![Dag\_Wieers](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@Dag\_Wieers](https://forum.ansible.com/u/Dag_Wieers)\
**Post date:** [October 15, 2012, 3:13pm UTC](https://forum.ansible.com/t/provisioning-modules/11978/15 "2012-10-15T15:13:11Z")

</div>

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 ?

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [October 15, 2012, 3:15pm UTC](https://forum.ansible.com/t/provisioning-modules/11978/16 "2012-10-15T15:15:55Z")

</div>

Please don’t assume I’m out to get you 🙂

I want to move links to useful community resources into the docs project as it’s own page, as I’ve started earlier.

---

<div class="post-metadata">

**Author:** ![Dag\_Wieers](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@Dag\_Wieers](https://forum.ansible.com/u/Dag_Wieers)\
**Post date:** [October 15, 2012, 3:27pm UTC](https://forum.ansible.com/t/provisioning-modules/11978/17 "2012-10-15T15:27:17Z")

</div>

> > > > Question is where we plan to host any documentation we will create. I
> > 
> > would
> > 
> > > > prefer this to be on [http://ansible.cc/](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.
> > 
> > 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 :-/

---

<div class="post-metadata">

**Author:** ![jpmens1](https://avatars.discourse-cdn.com/v4/letter/j/e9c0ed/32.png) [@jpmens1](https://forum.ansible.com/u/jpmens1)\
**Post date:** [October 16, 2012, 9:35am UTC](https://forum.ansible.com/t/provisioning-modules/11978/18 "2012-10-16T09:35:56Z")

</div>

Dag,

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

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-JP

---

<div class="post-metadata">

**Author:** ![Dag\_Wieers](https://avatars.discourse-cdn.com/v4/letter/d/45deac/32.png) [@Dag\_Wieers](https://forum.ansible.com/u/Dag_Wieers)\
**Post date:** [October 17, 2012, 7:05pm UTC](https://forum.ansible.com/t/provisioning-modules/11978/19 "2012-10-17T19:05:31Z")

</div>

That would be great !

---

<div class="post-metadata">

**Author:** ![jpmens1](https://avatars.discourse-cdn.com/v4/letter/j/e9c0ed/32.png) [@jpmens1](https://forum.ansible.com/u/jpmens1)\
**Post date:** [October 18, 2012, 5:40am UTC](https://forum.ansible.com/t/provisioning-modules/11978/20 "2012-10-18T05:40:18Z")

</div>

Dag,

> \>would you like me to add Markdown output to the module\_formatter? Pretty  
> \>easy to do ...
> 
> That would be great !

I've added Github-flavored Markdown to module\_formatter with PR  
[https://github.com/ansible/ansible/pull/1367](https://github.com/ansible/ansible/pull/1367), which also contains a link  
to a live example on Github.

Regards,

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;-JP
