<div dir="ltr"><div>Hi Scott,<br><br></div><div><div><div style="margin-left:40px">but there are no short term plans to change anything about our 
installation process and there are no apparent resources from TIER to do
 so, so what are we really talking about?<br><br></div>I have two distinct things to say in response:<br><br>1) There's absolutely a resource from TIER!   Paul Caskey. <br><br></div><div>How much of his time is available is not decided.  If there are specific tasks he could do that improve the install/initial config/test-along-the-way experience, he could estimate the hours, and then Steve Z and Ann West could decide on whether he can go forward.<br><br></div><div>Given this, what can "we" do that improves the install/initial config/test-along-the-way experience?<br><br></div><div>Paul: Please weigh in here.<br></div><div><br></div><div>2) You seemed to agree to the "success factors" I put forth in the <a href="https://docs.google.com/document/d/13CQyHMD0ZAvLwZLD6RZSQ03ebrB5K-qE8DlsHhxwzNw/edit?usp=sharing">Success Factors</a> doc that was input to the last Dev call:  Here are both what I wrote as "factors"  and my notes on what people said:<br><br><ul style="margin-top:0pt;margin-bottom:0pt" id="gmail-docs-internal-guid-9e4ca845-8c41-fff4-f8f6-7171a1f039ba"><li dir="ltr" style="list-style-type:disc;font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Test application for LDAP and database connectivity. Application retrieves and then displays a set of attributes. </span></font></p></li><ul style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:circle;font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Looks like IdP hosted tool can meet this (as per Scott and others)</span></font></p></li></ul></ul><font size="2"><br></font><ul style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:disc;font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Test SP with "hello world" application. Should display attributes from the IdP.  This allows for testing of attribute filter rules and attribute resolver transformations. </span></font></p></li><ul style="margin-top:0pt;margin-bottom:0pt"><li dir="ltr" style="list-style-type:circle;font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Installation of the V3 IDP also installs its metadata in the test SP, and vice versa. Whether this is done as part of keygen or later doesn’t matter (to me). ‘</span></font></p></li><li dir="ltr" style="list-style-type:circle;font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><font size="2"><span style="font-family:arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline">Looks like IdP hosted tool can meet this (as per Scott and others)</span></font></p></li></ul></ul></div><div><div><font size="2">
<br>If you are saying "yes" to this but aren't calling it a change to the installation procedure, then that's another matter.  If you are saying "no," then what has changed?<br><br>**<br></font></div><div><div style="margin-left:40px"><font size="2"><br></font>
Perhaps "getting started" is the term of art you want here.</div></div></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Thank you for the suggestion but that phrase seems to imply the inclusion of "Concepts & Basics Info" -- which as you know is a task awaiting funding :-). <br></div><div class="gmail_extra"><br>**<br></div><div class="gmail_extra">I'm going to leave aside comment on your other responses until we can get some clarity on how the overall install/config/test-along-the-way process can be enhanced -- with Paul as a resource.  <br><br></div><div class="gmail_extra">I'm pretty set on having the "Success Factors" above met (e.g. "test ldap" capability) so that may be a point of contention, but let's see!  I'm hoping we just have a misunderstanding about what "enhance the installation procedure means."   To clarify, I mean enhance the overall overall install/config/test-along-the-way process.  I don't care which piece is "in" the installer and which piece is separate.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Thanks,<br></div><div class="gmail_extra">Marlena<br><br><br></div><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 28, 2017 at 8:06 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2/28/17, 4:21 PM, "dev on behalf of Marlena Merrin-Erdos" <<a href="mailto:dev-bounces@shibboleth.net">dev-bounces@shibboleth.net</a> on behalf of <a href="mailto:marlena.erdos@gmail.com">marlena.erdos@gmail.com</a>> wrote:<br>
<br>
> Our big problems (IMO) are:<br>
<br>
> * deciding on "audience": what type of user and institution are we targeting; who are we consciously leaving out<br>
> * deciding what the installer does that might make an audience member's life easier.<br>
> * differentiating  what's a Quick Start Guide, and what's in a System Administration Guide<br>
<br>
I think there's a more fundamental issue here that I'm missing. I can understand asking what should be in a Deployer's (or Installer's) Guide, but if we're talking software here, I don't see how that's in scope for this conversation. We have a long term plan to look at how we can integrate better with the CANARIE installer, but there are no short term plans to change anything about our installation process and there are no apparent resources from TIER to do so, so what are we really talking about?<br>
<br>
What we have is what we have. That's it. And I don't think that's a problem. People don't have problems installing Shibboleth, the problems come with the next steps. They just get lost. That's a documentation problem, and doesn't really require new code.<br>
<br>
> This is a great point -- but not a damning one given that TIER is funding the work.   A "Quick Start Guide for TIER<br>
> Institutions" would likely suit TIER just fine.  This is especially so given that TIER is expecting an influx of community<br>
> colleges and K-12 schools who will want IdPs (according to Paul Caskey).<br>
<br>
Only insofar as TIER accepts the responsibility to maintain it. I have no problem with that, but I do have a problem with more community-specific documentation that is stale and that I have to tell people to ignore if they want my help. So that's my only real concern over it. If we're expected to maintain it, then it would be non-specific to InCommon.<br>
<br>
I'm fine with either outcome but I don't think it's an unreasonable position for us to take.<br>
<br>
> * Most of this ongoing maintenance of the IdP belongs in a System Administration Guide, not a Deployment Guide (IMO).<br>
> (The "Deployer's Guide" really should be called "Installer's Guide" to avoid confusion due to the larger meaning of<br>
> "deploy" vs"install."  I might advocate for this.)<br>
<br>
Perhaps "getting started" is the term of art you want here.<br>
<br>
> * If a school brings up an IdP and demonstrates its value --- say by allowing for a connection to HathiTrust (a library<br>
> resource) -- then the school might (might) be able to get funds to support "doing the IdP right" in an ongoing way<br>
<br>
My experience is that if you adopt the software internally at scale, you're forced to care about doing it well, and if not, you tend to have a lot of trouble devoting the necessary time to it. That's the dividing line I've routinely encountered: federation-only vs. enterprise. It doesn't grow out of supporting isolated use cases.<br>
<br>
> Given that, the question (it seems to me) is "what is the installation process that goes along with the Quick Start<br>
> Installation Guide"?<br>
<br>
If you're asking us, the answer is that it's the current installation process, and I don't think that materially inhibits your exercise.<br>
<br>
You asked about the CANARIE installer. I think it's useful and I think TIER should be reusing it if they want to go in a similar direction functionally, but I don't think it is in scope for your documentation effort unless you want to have that conversation with TIER and couple the proposal to an additional, currently unspecified, piece of work.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
-- Scott<br>
<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:dev-unsubscribe@shibboleth.net">dev-unsubscribe@shibboleth.net</a><br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">617-216-6563 (cell via Google Voice) or 857-308-6986 (direct cell)<br></div></div></div></div>
</div></div>