I would invite you to provide a git patch for this, I am sure it would be considered :)

Thanks!

Okai so I did a patch for all 3 inventory files
Currently there is still room for improvement due to the fact that some hosts won't follow a good naming scheme.
Also sometimes hosts got named like that:

{{{
ns02.fedoraproject.org
ns03.phx2.fedoraproject.org
ns04.phx2.fedoraproject.org
ns05.fedoraproject.org
}}}

which is bad. it would've be better to have:

{{{
ns01.fedoraproject.org
ns02.fedoraproject.org
ns01.phx.fedoraproject.org
ns02.phx.fedoraproject.org
}}}

so the groups would be easier:

{{{
ns[01:02].fedoraproject.org
ns[01:02].phx.fedoraproject.org
}}}

removing and adding a host would be way easier this way. okai removing isn't done easily if you remove a host in between. but most of the time you replace a host so you would've that dns entry anyway.

attachment
hosts.diff

One suggested fix, on the first list you have it indexed starting at 00, it should start at 01 :)

oh damit, yes. i'will update it ;) btw. i still think there is room for improvement. the inventory file still looks messy. maybe i've missing some things to rewrite that a little bit better.

attachment
hosts.diff-update1.diff

I'm not sure I am in favor... we do sometimes want to comment out instances in the middle of the range.

For example, we often have arm SOCs that have drive or other issues, and we need to comment out just that one in the middle.

One better change might be to sort things by group and split out the qa machines into another inventory file, which is one thing that I have been meaning to do.

When you change your inventory files on runtime, why don't we create a small website where the hosts could be configured?
so it would be way easier to add hosts or delete them or just make them unusable?

Example:
http://jpmens.net/2013/06/18/adapting-inventory-for-ansible/

Still I think that maintaining such a big inventory list isn't that suitable.
Also it won't be too hard to make a good webgui / commandline programm to do that. there could be also a way to create the native files then or import the files

Still I think that maintaining such a big inventory list isn't that suitable.

Could you expand on this?

We've been maintaining this file manually just fine until now and since our hosts are not changing that often it's been fine so far.

Having a tool to maintain a text file sounds a little bit like over-engineering to me. Looking at the link you sent, I see some examples relying on a database, so between maintaining a text file that our admins can edit in git whose changes are broadcasted to everyone for review, vs maintaining a sqlite/db, the text file sounds simpler to me.

When we would have all hosts in a database it would be way easier to "disable" certain hosts.
And yes it sounds a little bit over-engineering but if we add more hosts to ansible it gets harder and harder to maintain that file.
The more line's a file has the more errors could raise, especially when commenting out.

Still the best solution is my patched file but when we need to disable some hosts in between it would be really hard since we can't exclude some patterns. So if we have like 50 hosts that following the same pattern we would have something like that:

{{{
[builders]
arm[00:50].builders.fedora.org
}}}

which is really nice but if we now need to exclude 26, 30 and 21 this pattern wouldn't work since we would need to write (especially with two hosts this would be aweful)

{{{
[builders]
arm[00:20]...

arm21...

arm[22:25]...

arm 26...

arm[27:50]...

arm30...

}}}

and when that would happen more often it would be better to combine a static and a dynamic inventory, where we put the hosts that change more often into a database as the examples and the hosts that won't change into the static one.
the dynamic inventory could then be maintained over a web application or a command line tool.
but that would only be suitable to often changed hosts.

i mean the best way would be something like that:

{{{
arm[00:50].builders.fedora.org ansible_exclude: 21, 26, 30
}}}

but i don't think that ansible supports something like that.

but if we add more hosts to ansible it gets harder and harder to maintain that file.

I still don't see how it gets harder :)

Between removing/commenting a line in a file and running a SQL query on a database, the first sounds simpler and like I said, as bonus the change is broadcasted to everyone in infra.

hm yeah maybe you are right.

but that wouldn't clear up if it is better to have a file with patterns or without.

I don't think we are going to make this change at this time. There's just not enough advantage in my mind.

Sorry.