On Thu, Aug 11, 2016 at 9:25 AM, Jóhann B. Guðmundsson
On 08/11/2016 03:53 PM, Stephen Gallagher wrote:
> On 08/11/2016 11:02 AM, Jóhann B. Guðmundsson wrote:
> The thing I'm missing from your statement is *how* you think splitting our
> attention to a variety of different tools somehow leads to a maximized
> participation. You're skipping an important intermediate step and I can't
> that same leap.
Because you are exposing Fedora and the work of the server WG to a larger
audience by doings so ( three upstream CM communities four if you add salt
in the mix ).
Not sure about the relevance of that old saying if yours but my saying is
you are more likely to catch a fish if there are more of them in the pond or
why fish with an pole when you can use a net ( or a dynamite ) ;)
> So show me how you would do it.
You would do so by using the same method/methodology you intended to do with
Ansible Galaxy it would apply to all.
>> There tools to migrate between CM's so this boils down to making the same
>> and *presence* in Ansible Galaxy, The puppet forge etc.
> If there are tools to automated this stuff, then what's wrong with
> focusing our
> efforts in one place, getting it right and then later expanding to other
What's wrong with focusing on all the CM at the time. "Divide and conquer"
It's like I never left :)
There's nothing wrong with that. But, here's the thing:
Does the server WG want to provide optimal, best practices ways to do
ongoing configuration management of different stacks of stuff on
Or does the server WG want to be able to provide people with a quick
and easy way to *try something out*, and have the ability to easily
grow that ecosystem of Things to Try out on Fedora, that are high
quality, known to work, and managed by Fedora as an organization? (Or
even not, but encourage folks to make those quick and easy ways to try
Honestly: I suspect that very few people take stuff from Galaxy,
Puppet Forge, Chef Supermarket, or Salt $whatever, and keep that as a
permanent thing. It's a base from which to grow. I don't know if the
server WG aspires to have this be "multi-server" arrangements, or
everything on a single server, but if it's multi-server, that's a
harder nut to crack, esp. with a 13-month time to EOL. It can be done
with Galaxy as much as it can be done with the other tools, but
certainly that requires more careful detail to things.
I also suspect that very few people, particularly when they want to
try something out, select their distro before they select the software
they're running on that distro. They want things to be optimized to
try out successfully. You make it easy to try out, make sure stuff
automatically *just works as expected*: that person has a decently
high likelihood of sticking with Fedora. Work with upstream projects
and make sure that "you can install this super easy in Fedora by doing
That said, let me reiterate this particular point for the bazillionth
time: Ansible is an orchestration tool, that happens to do
configuration management. You can set things up with Ansible and NEVER
EVER USE ANSIBLE AGAIN to manage that stuff. You can use Puppet, or
Chef, or whatever, or heck, you can use Ansible to manage Puppet's
management of that stack for you.
This does not force a permanent choice of Ansible down anyone's
throat. It is literally orchestrating some bits onto a machine that
never ever have to be touched by Ansible again.
The big difference is: Ansible is way easier. This is not me talking
as an Ansible human, this is me talking as a human who has tried all
three things and was able to do useful things in a very short period
of time with Ansible. This was my experience when I was at
Elasticsearch for a hot second. This is me talking as a human who has
had very pointed discussions with employees of those other CM
companies who widely acknowledge that it is far, far easier to get
started with Ansible. It is far easier to learn how to write a role
for Ansible and put it in Galaxy. And what you're talking about seems
to be even obscuring the galaxy interface, so it's not like you're
making an end user learn one tool over another. It's mostly getting
folks up to speed on how to write a role for galaxy. That's not long.
Does that help the Galaxy ecosystem more than Fedora's? Maybe. Maybe
not. I don't know that finding out means doing all three CMs equally
at once -- you can certainly go and pick one, and see if that provides
any meaningful uptick, or surge in interest, or growth in numbers of
contributors. It certainly helps the Ansible / Galaxy pitch when you
consider that all of Fedora's infrastructure is Ansible-y these days,
which means that, in some magical universe where there is continuous
integration of things, it would be very, very easy to automatically
test those roles over and over again, update them as needed in Galaxy,
etc. (To be fair: because there is a puppet module, it is also super
easy to execute puppet things, but I digress.)
My main point here is that using Ansible as a tool to orchestrate the
deployment of simple stacks of stuff on to a server does not preclude
the ability to to perform CM on it all on an ongoing basis with the
tool of the users' choice. And really, if this was envisioned to be a
multi-server thing, then you're going to have to either bake puppet or
chef into those machine images, or figure out how to get a puppet
agent onto those machines. Super popular way to do that: Ansible.
A secondary point: you all can choose to do this, or not, as a
community. But for the love of God, choose something, anything, and
try it, and measure it, and decide if you want to keep going. You
don't have to be married to it. You don't have to live with it for
more than 6 months. And if you do choose to do it: It's a perfectly
legit way to get folks who may not otherwise be able to contribute to
Fedora Server... a way to contribute to Fedora server. That's
potentially a big thing and a new way to get new contributors, get
more eyeballs on the server mailing list and project, etc.
Or we can have this discussion again in 6 months. :)
>> Well, that was too much for a small group to handle. At Flock and on the
>> meetings, we've been talking a lot about cutting back our target audience
>> the short term* to address small-to-medium business cases.
> This comes a bit as backwards to me since the small to medium business cases
> are more or less all running ( and maintained ) in the ( office365 ) "cloud2
> these days so fail to see how a) you are going to penetrate that target
> audience/market and b) with what to grab their attention with.
> What will this target audience gain from running Fedora server which is not
> already in the "cloud"?
> server mailing list