Moving ansible-provisioning project...

Archives Ansible Project
1

Hi everyone,

I've suggested to dag that we migrate ansible-provisioning to
something like <dag>/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 :slight_smile:

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

2

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 :slight_smile:

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

3

I've suggested to dag that we migrate ansible-provisioning to
something like <dag>/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 :slight_smile:

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 ?

4

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

5

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.

6

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.

7

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

thanks,

-sv

8

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

Absolutely!