Canarie Installer suitability for Shib "quick start"? (response to Scott)

[Marlena Merrin-Erdos]

Hi Scott,

Thank you for the thoughts on the Canarie installer.

> It may be that eventually we need to dump ant and start fresh with a new
installer strategy, but for now that's what we've got, and it works on all
platforms, so I think that's the foundation we have to work from.
>

OK.  Your take is that we should stick with the current installer.

Paul C: Thoughts?

Rod W: Thoughts?

Anyone else?

Even if we stay with the current installer,  the QI Guide project still
needs to have "test LDAP connection" and "test attr resolve/filter" and
"pretend SP" (to test the overall path even if there's canned authN).  I
understand that these functions can be separate from the installer, but I
still need to document them.

I know you've created a ticket on this already.

**
> The other thing CANARIE has is a self-contained test environment that
spins up with Vagrant with an IdP, SP, LDAP, and discovery tool. That is
very interesting to me, and I can see the value of pointing people to that
as a learning tool. In a perfect world I'd like to have something like that
ourselves, so it's possible that could happen, but it would mean dedicating
some resources to that.
>

Let's assume that Paul Caskey is an available resource -- for some amount
of cycles.  Let's get specific.   If this is the "best" thing for him to
work on, what would it take to create a self-contained test environment?
If it's not, what is (as related to to a QI Guide in some way)?

**
> If the newbie has a non-vanilla LDAP or other "interesting" configuration
> issue, then s/he is not part of the target audience for the "Quick Start"
> installation and "Quick Start" Deployer's Guide.

This is where I will say that this idea that there are a lot of
non-vanilla, non-interesting configurations is a fantasy of people who
don't know how this stuff works. But it highlights that one of our goals
needs to be to make some of the non-vanilla things become vanilla. We need
standard ways of doing things, and some of that is just a matter of
documentation. Just because there are 10 ways to do something doesn't mean
we have to document all 10 equally.

I understand your point that there aren't a lot of non-vanilla
configurations.  But there are some -- and given the predicted influx of
K-12 schools and community colleges, there may be more upcoming.

Also, working in even an "artificial vanilla" kind of way  -- easily -- may
give a leg up to institutions that have more complex situations.  As I
wrote to Rod, an IT department or person who can show some functionality
even if not the whole (or correct) enchilada, may be able to get funding
for a better circumstance.

If this is "wrong headed," feel free to tell me.

Here's the thing:  I need us collectively to get to specifics on who the
target audience is, and what situations the QI Guide will cover, and what
it will leave out.

We can assume it won't be perfect, so let's aim for "good" and also "help
some meaningful set of users meaningfully more than they are being helped
now."

It's OK for us to have multiple scenarios to present to Steve Z for
"TIER's" decision on how much he wants to spend -- and use of Paul C's time
--  but we must "get down to brass tacks."  Soon.  (I'm being pressed for a
schedule and milestones -- which I can't give given so many key issues
still in the air .)

Personally, I would have liked to do the three well-defined projects that
Scott wanted and that we together proposed.  In light of TIER wanting a
"Deployer's Guide" (really "Installer's Guide), I'm trying to find a way --
with your collective assistance -- that helps some set of users and helps
TIER given the limited resources and a limited time-frame (albeit a
not-entirely-specified one).

Thx!
Marlena

On Mon, Feb 27, 2017 at 10:56 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> > I'm writing to get your thoughts about the Canarie Installer.   What's
> good,
> > what's "not good,"  what's missing?    Other issues?  (Here's a web
> page.  It
> > offers a "test drive" of the installer rather than describing it. I
> haven't tried
> > doing the test drive (yet).
>
> I had a good conversation with Chris Phillips about it after running some
> tests with it myself to get a feel for it, and the feedback I had was that
> I see it really as consisting of two separate pieces, one of which is
> something we need to work with more closely and eventually perhaps include,
> and the other that I think is best left out of our sphere for now.
>
> The front-end GUI is the piece I'm interested in us both being able to
> leverage, but also (as Rod said) that I think we should try and more
> formally support by standardizing the property interface between our
> current installer and that front-end with an eye toward eventually
> expanding that set of properties and implementing additional features in
> the installer to take over some of the work that's currently being done by
> including hardcoded example files in the CANARIE tool.
>
> The part I'm not as comfortable with is the "back-end" of it, which is a
> set of non-trivial shell scripts that actually provision a VM and install
> all the software. That's just too limiting in terms of platform for us to
> maintain all that, and I just don't think that's where our time is best
> spent. I think we should try and make our installer do more, so that those
> bits can do less, and then over time we can re-evaluate where that boundary
> should be.
>
> It may be that eventually we need to dump ant and start fresh with a new
> installer strategy, but for now that's what we've got, and it works on all
> platforms, so I think that's the foundation we have to work from.
>
> The other thing CANARIE has is a self-contained test environment that
> spins up with Vagrant with an IdP, SP, LDAP, and discovery tool. That is
> very interesting to me, and I can see the value of pointing people to that
> as a learning tool. In a perfect world I'd like to have something like that
> ourselves, so it's possible that could happen, but it would mean dedicating
> some resources to that.
>
> > If the newbie has a non-vanilla LDAP or other "interesting" configuration
> > issue, then s/he is not part of the target audience for the "Quick Start"
> > installation and "Quick Start" Deployer's Guide.
>
> This is where I will say that this idea that there are a lot of
> non-vanilla, non-interesting configurations is a fantasy of people who
> don't know how this stuff works. But it highlights that one of our goals
> needs to be to make some of the non-vanilla things become vanilla. We need
> standard ways of doing things, and some of that is just a matter of
> documentation. Just because there are 10 ways to do something doesn't mean
> we have to document all 10 equally.
>
> -- Scott
>
>
> --
> To unsubscribe from this list send an email to
> dev-unsubscribe at shibboleth.net
>



-- 
617-216-6563 (cell via Google Voice) or 857-308-6986 (direct cell)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20170228/9229d87b/attachment.html>