# Moving ansible-provisioning project... **URL:** \ **Category:** Ansible Project\ **Created:** [October 31, 2012, 12:03pm UTC](https://forum.ansible.com/t/moving-ansible-provisioning-project/12057 "2012-10-31T12:03:22Z")\ **Posts on this page:** 8\ **Page:** 1
**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 31, 2012, 12:03pm UTC](https://forum.ansible.com/t/moving-ansible-provisioning-project/12057/1 "2012-10-31T12:03:22Z")
Hi everyone, I've suggested to dag that we migrate ansible-provisioning to something like \/ansible-provisioning on github. I'll let dag mention where the new home is once this happens, and it's up where it's at for now. Essentially there are some very cool ideas within, and I don't want to enforce my own views about how I would build a provisioning system on that project. If it's part of the core project namespace, I will have to do that, and that wouldn't be fair. Some of those things include disagreements about being able to kickstart directly off of a ks= URL, which Cobbler can do, but ansible provisioning doesn't want to do, etc. Another example is I think the manipulation of PXE configs is best served by Cobbler, etc. Basically we have slightly different visions but can still be friends 🙂 There is still a strong chance many of those guest creation modules make it back into core, but I also have ideas about how you would describe virtual clusters and how those create inventory and such, and want to build something that doesn't require an auxilliary CMDB or network facts file, and those things look differently. This is not about making anything incompatible and everything there is going to continue to work fine with all future versions of ansible, just like any other playbook. If people like ansible-provisioning, and I suspect many people will, they should totally continue using it, as it contains lots of good ideas. ---Michael ---
**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 31, 2012, 12:25pm UTC](https://forum.ansible.com/t/moving-ansible-provisioning-project/12057/2 "2012-10-31T12:25:09Z")
> Essentially there are some very cool ideas within, and I don't want to > enforce my own views about how I would build a provisioning system on > that project. If it's part of the core project namespace, I will > have to do that, and that wouldn't be fair. Some of those things > include disagreements about being able to kickstart directly off of a > ks= URL, which Cobbler can do, but ansible provisioning doesn't want > to do, etc. Another example is I think the manipulation of PXE > configs is best served by Cobbler, etc. Basically we have slightly > different visions but can still be friends 🙂 The modules in ansible-provisioning do not enforce anything. The examples are that way because that's what Dag is using and we've not had time to write less complex examples. This is my provisioning workflow: - define host with IP address in inventory - module lvol creates storage on VM host - template Libvirt host definition, create host - template kickstart file, move to provisioning server - action: virt\_boot guest=${inventory\_hostname} kernel=/tmp/virt-${inventory\_hostname}/vmlinuz initrd=/tmp/virt-${inventory\_hostname}/initrd.img cmdline='linux sshd ksdevice=eth0 ip=${mgt.ip} netmask=255.255.0.0 ks=http://${dist\_server\_ip}/mrepo/kickstart/${inventory\_hostname}.ks'   delegate\_to: ${on\_host} I guess that counts as provisioning from a ks URL? > There is still a strong chance many of those guest creation modules > make it back into core, but I also have ideas about how you would > describe virtual clusters and how those create inventory and such, and > want to build something that doesn't require an auxilliary CMDB or > network facts file, and those things look differently. I do not use an auxiliary CMDB nor network facts file. They are completely optional. I'm interested in your and any else's vision about how to provision systems you can't define beforehand though, since that's something we need to tackle anyway for cloud provisioning. Greetings, Jeroen ---
**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 31, 2012, 12:26pm UTC](https://forum.ansible.com/t/moving-ansible-provisioning-project/12057/3 "2012-10-31T12:26:10Z")
> I've suggested to dag that we migrate ansible-provisioning to > something like \/ansible-provisioning on github. I'll let dag > mention where the new home is once this happens, and it's up where > it's at for now. > > Essentially there are some very cool ideas within, and I don't want to > enforce my own views about how I would build a provisioning system on > that project. If it's part of the core project namespace, I will > have to do that, and that wouldn't be fair. Some of those things > include disagreements about being able to kickstart directly off of a > ks= URL, which Cobbler can do, but ansible provisioning doesn't want > to do, etc. Another example is I think the manipulation of PXE > configs is best served by Cobbler, etc. Basically we have slightly > different visions but can still be friends 🙂 Michael, to be fair, ansible-provisioning can kickstart from a ks= URL, the example in the README does not. There was no such disagreement, and if there was it would be pointless. Anyway, there is no such decision as 'ansible-provisioning refuses to use ks= URLs'. We don't enforce this, and the README is just an example. (Albeit one I learn that you personally dislike) > There is still a strong chance many of those guest creation modules > make it back into core, but I also have ideas about how you would > describe virtual clusters and how those create inventory and such, and > want to build something that doesn't require an auxilliary CMDB or > network facts file, and those things look differently. You don't require auxilliary CMDB or network facts. ansible-provisioning simply offers components that you can use whatever way you like. I added my modules, Jeroen addes his, Seth added his. There is not other way currently to do what network\_facts does. You opened a ticket stating you can do the same thing using vars\_files, but that is simply not true. I am interested to learn about your ideas of virtual clusters and dynamic inventories, but at the moment that's vaporware and I only picked up fragments of discussions about them. It would help if you make your ideas public so we understand where we are going... > This is not about making anything incompatible and everything there is > going to continue to work fine with all future versions of ansible, > just like any other playbook. If people like ansible-provisioning, > and I suspect many people will, they should totally continue using it, > as it contains lots of good ideas. I am very disappointed that:   - it does not happen as part of the ansible project   - it does not get mentioned anywhere on the website either   - you base all your opinions on one single example that you dislike     (as you obviously prefer cobbler yourself) That said, it will move to: dagwieers/ansible-provisioning with a lot of regret. Maybe tomorrow another decision ? ---
**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 31, 2012, 12:44pm UTC](https://forum.ansible.com/t/moving-ansible-provisioning-project/12057/4 "2012-10-31T12:44:02Z")
> - it does not get mentioned anywhere on the website either It's not? Send me a pull request to the contrib page on the main Wiki, it totally deserves to be up in those examples. > - you base all your opinions on one single example that you dislike >    (as you obviously prefer cobbler yourself) No, I'm trying to be nice and am giving just a few examples. Really, I am. I would rather not debate things as I don't think it's constructive. > That said, it will move to: dagwieers/ansible-provisioning with a lot of > regret. Maybe tomorrow another decision ? Moving it tomorrow or even later this week is fine with me, but decision is made. I don't think it's going to change after some of the tickets on issues I opened got immediately closed. I'm afraid wee're going to disagere too much, and rather than making that a point of contention, I think it needs to migrate it and let it do what it wants to do, but we will still link to it. The hard part of software is deciding who's right and what's the best way to do X, and this is especially hard in volunteer projects. In this case, I prefer to not exert my preferences, but also believe things hosted in ansible/ are things ansible says are "you should use all these things", and I'm not 100% convinced. I still want to enable all of those things, though. ---
**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 31, 2012, 1:22pm UTC](https://forum.ansible.com/t/moving-ansible-provisioning-project/12057/5 "2012-10-31T13:22:05Z")
> > That said, it will move to: dagwieers/ansible-provisioning with a lot of > > regret. Maybe tomorrow another decision ? > > Moving it tomorrow or even later this week is fine with me, but > decision is made. I don't protest, I only regret it and am disappointed. > I don't think it's going to change after some of the tickets on issues > I opened got immediately closed. Ironically, that's how you managed the project at the very start. > I'm afraid wee're going to disagere too much, and rather than making > that a point of contention, I think it needs to migrate it and let it > do what it wants to do, but we will still link to it. What do we disagree on ? Because you mention that all the time, but the only example was an incorrect statement out of confusion. Sure, there are things you would like to see changed, but why do you expect \_me\_ to change them ? That's not disagreement. ---
**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 31, 2012, 1:49pm UTC](https://forum.ansible.com/t/moving-ansible-provisioning-project/12057/6 "2012-10-31T13:49:50Z")
> Ironically, that's how you managed the project at the very start. I want to keep this civil. You do need to realize Ansible is my project, I totally welcome everyone's contributions, but this is my vision of the way I want config management and such to be. I want that vision to be cohesive and that means I am going to have preferences. > What do we disagree on ? Because you mention that all the time, but the only > example was an incorrect statement out of confusion. I'm trying to be polite by not saying it's a bad solution and why. There are lots of reasons why I don't t hink this is ready, but please, let's not dig further. I'm trying to not be a Linus. I am pretty well versed in provisioning space and could do that, and you could go back and fix all the things I want, but I don't think you'd want to. It's fine for what it is. The project can exist, I just don't think it belongs as a top-level thing. > Sure, there are things you would like to see changed, but why do you expect > \_me\_ to change them ? That's not disagreement. Anything in ansible/ is something I basically endorse and want to say "you should use this". You have seen some (but not all) of my opinions and closed them. Really, it's an impasse, and it's best if we not worry about it, and let both things evolve. I'm not saying ansible-provisioning can't exist, I'm just saying I don't endorse it as a top level ansible project yet. I originally moved it because I thought it wasn't ready and needed room to get attention and grow, and it's not growing in the shape I personally like -- but others may like it totally fine. That is basically it. ---
**Author:** ![Seth\_Vidal](https://avatars.discourse-cdn.com/v4/letter/s/7ba0ec/32.png) [@Seth\_Vidal](https://forum.ansible.com/u/Seth_Vidal)\ **Post date:** [October 31, 2012, 6:24pm UTC](https://forum.ansible.com/t/moving-ansible-provisioning-project/12057/7 "2012-10-31T18:24:16Z")
So I don't think anyone is objecting to this part at all. I think some of it is just trying to figure out what fits w/i that cohesion and what should be outside. Originally, when you first started talking about playbooks (and I finally figured out what that entirely meant) I saw ansible as a way to handle complicated multiple-systems tasks for both managing repeated tasks along with configuring systems. Examples I thought would fit w/i whayt ansible is: - config/deploy a new webserver, notify your nagios server that it exists and needs to be managed - add a new user to multiple idms components (ldap, samba, mail servers and sub-organization idms) in a single command - create and deploy multiple cloud instances as a cluster for webservices in a single playbook so you could create/recreate a testing environment trivially. I'm really not at all sure where the provisioning side of this falls vs core ansible. I have no grumpiness or anger about any of it - I just want to know if I should send PRs for things like addhost and ec2\_create to ansible or just keep them in side repos? I hope none of the above is making you grumpy, either. I also understand ansible dev is coming fast and furious so I can imagine the sheer volume of mail/requests/etc is getting to you. So if this mail needs to sit for a while, I understand. The plugin architecture of ansible benefits me tremendously b/c it means even if it isn't in upstream the modules/plugins I need I can use in my local repo. 🙂 thanks, -sv ---
**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 31, 2012, 6:47pm UTC](https://forum.ansible.com/t/moving-ansible-provisioning-project/12057/8 "2012-10-31T18:47:51Z")
> I'm really not at all sure where the provisioning side of this falls vs core > ansible. Sure. So I more issue with the nature of ansible-provisioning's provisioning modules (how they work, what things they require) than that they are doing provisioning. > I have no grumpiness or anger about any of it - I just want to know if I > should send PRs for things like addhost and ec2\_create to ansible or just > keep them in side repos? Here's what I think. The core provisioning modules like ec2\_create and other creation stuff should be included in core somehow, and namespaced so they live in their own directory and get their own docs page. Host creation and your add\_host stuff I think fits. Many people can use those. Some of other physical stuff that is site specific, maybe not. The stuff like network\_facts I find weird, and that does not seem to fit, because it's very specific to the workflow dag wants to use in his provisioning, but I think that data source should come from anywhere you want. I don't like the idea of calling mkisofs or templating PXE files with the template module and various other things, I think that is a really hard way to do it, but I am very much interested in interesting modules, particularly around cloudy things. The idea of having a "non-vapp" vapp is a cool idea, and I want to go there. I also kind of want to make it easy to be able to persist what gets created, and I don't see how that fits together yet... but I'm ok if you are ok with adding those hosts manually later. If there is a provisioning namespace for the cloudy stuff we want to do (maybe just a virt namespace?) then the temporary add host stuff could probably live there. Basically I just want it to all look well integrated, and I very much like where you are going in EC2/euca-tools land. Sorry if that's vague. A lot of this is about wanting to make sure people don't try to create Cobbler with Ansible, and don't need to store inventory in seperate files and glue a bunch of stuff together when only\_if. I don't want to say that's not going to be possible, I just want ansible to aspire to making that feel better. One thing I really want -- I want to be able to provision a node and assign it to a group in one step, and be able to continually manage it as part of that group. (basically the equivalent of koan --virt --profile foo, but for multiple hosts). > I hope none of the above is making you grumpy, either. Nah. > I also understand ansible dev is coming fast and furious so I can imagine > the sheer volume of mail/requests/etc is getting to you. So if this mail > needs to sit for a while, I understand. > > The plugin architecture of ansible benefits me tremendously b/c it means > even if it isn't in upstream the modules/plugins I need I can use in my > local repo. 🙂 Absolutely!