On 08/11/2016 11:02 AM, Jóhann B. Guðmundsson wrote:
On 08/11/2016 02:14 PM, Stephen Gallagher wrote:
>> > Tying this to single CM be it Ansible, Puppet or Chief will immediately
exclude
>> > participation from administrators that are using the other two popularly
used CM
>> > that's a fact and as obvious as it can be so in the end of the day the
>> > discussion is about implementing and supporting all three of them or none,
not
>> > just single one be it Ansible, Puppet or Chief it does not matter.
>> >
> Using Ansible to solve a set of constrained, specific problems does not preclude
> using other tools. However, we have finite resources and so it makes the most
> sense to focus on doing one thing well *first*. We have available resources and
> expertise among the Ansible crowd, which makes it a great place to start.
>
> I think that's where our disconnect has always been, Jóhann. You are an idealist
> (which I respect), but we don't live in an idealistic world. In a perfect world,
> yes we would support every possible technology out there, it would all work
> without conflicting and everyone would have a pet unicorn. It's good to have
> idealistic goals (and I share them), but it's also important to have realistic
> milestones. This is an attempt to get closer to that ideal by taking smaller steps.
I do believe my perception of the world is far greater than yours, and this is
not about ideals, this is about maximizing community participation which in the
long run will help the community to grow and to sustain itself, in which failure
to exactly that can be directly seen here otherwise we would not be having this
discussion in the first place. ( those finite resources you refer to are self
inflicting wounds. )
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 community
participation. You're skipping an important intermediate step and I can't make
that same leap.
The way I look at it, there's an old saying that fits: "The fox that chases two
rabbits will catch neither." Interacting with an upstream community requires a
lot of domain-specific knowledge and focus; it really means that someone has to
be dedicated to doing so. Asking that person to also become an expert on two
other similar ways of doing something leads to confusion and being spread too thin.
So show me how you would do it. I'm not trying to be antagonistic; if you have
ideas on *how* such a thing could be accomplished with the resources available,
I'm certainly willing to listen.
There tools to migrate between CM's so this boils down to making
the same effort
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 CMs?
Anyway before my "ideals" or your "limited"
approach**to
implementation/integration with CM or anyone else ideas for that matter, the
question what benefit(s) it will bring administrators partaking in and using
Fedora server will need to have been answered.
This again comes back somewhat to limiting our scope. When we set out originally
to build Fedora Server, we set up a number of Personas and user stories that we
were going to target. Unfortunately (similar to Fedora Workstation
historically), we set our sights too broadly. We were going to address the needs
of everyone from the home storage server all the way to a massive datacenter.
Well, that was too much for a small group to handle. At Flock and on the Server
meetings, we've been talking a lot about cutting back our target audience *for
the short term* to address small-to-medium business cases. So instead of
focusing on datacenter environments that need massive orchestration engines,
we'll look into helping small businesses and home users get started. We can
probably leave the massive deployments to the RHELs and CentOSes of the world
for a while; they're doing just fine there.
So if we look at things through that lens (which I admit I probably should have
been more clear when describing previously), then it *does* make sense to limit
our implementations. Ideally, the technical implementation would be largely
hidden from these SMB users; they'd use a guided UI from Cockpit or a repurposed
`rolectl` tool and the details of how the changes actually got applied would be
opaque to them unless they went looking for documentation.