On 09/12/2015 15:00, Tony Stevenson wrote:
On Wed, 9 Dec 2015, at 01:46 PM, Francesco Chicchiriccò wrote:
On 09/12/2015 14:33, Tony Stevenson wrote:
On Wed, 9 Dec 2015, at 12:52 PM, Francesco Chicchiriccò wrote:
On 09/12/2015 13:16, Tony Stevenson wrote:
Francesco,

As I said in HipChat, I'd love to be able to say that we can do this.
But the fact is right now infra are tied up for at least 6 months.

I think the best way to gain any traction on this is for the Syncope PMC
to stand up a PoC that replaces 1 (or more) of the components used.
As anticipated via HipChat, this is actually the deep sense of my
proposal, e.g. the direct engagement of Syncope PMC - not only,
actually, but anyone interested - for supporting the infra team.

A PoC sounds like a straight, concrete and limited way to start
approaching IdM at ASF with Syncope.

i.e.  these might include:

    - https://id.apache.org  (The end-user part of it)
    - acreq - The user account request workflow
    - Identity Management as a whole.
    - PMC karma management

I will be more than happy to help guide the PMC, and give you an ASF VM
on which you can stand up your PoC, and guide you on the business logic
already in place for any of these tools.
That's good - IMO we need:

    1. a place where to ask for information, provide feedback, etc. (shall
we keep crossposting infra@ and dev@syncope?)
Keep infra@ in the loop.  If we start crossing into anything sensitive
we will move that part of the thread to a more sensible location.
Understand: what about JIRA notifications (see below)?
JIRA notifications are a harder one, but the current set go to infra@ -
so you will see them if you are sub'd to the list.

Agree: we'll need to ask other people that want to get involved to subscribe infra@ as well, no problems.
I'd like to keep dev@syncope in CC for any discussion on the topic, though.
We might use some fancy [Syncope-PoC] subject prefix as well.

    2. VM
Open a JIRA issue for this, and one can be provisioned for you.
Fine.

    3. SCM
Ideally you'd work by submitting patches against the
infrastructure-puppet repo for the deployment and config.
Not sure:  a Syncope deployment is an actual Maven project which
produces one or two WAR files to be deployed on a supported Java EE
container (Tomcat is fine), which requires a dedicated DBMS (PostgreSQL
or MySQL are fine, naturally).

So I'd say we eventually need to patch infrastructure-puppet for
deploying Syncope, but we still require a git-wip repo for the actual
project sources (which will depend of official Syncope artifacts but
also embed all the configuration, business logic, ...).
Infra have a hard rule that all deployments must be managed snd
configured via puppet.  if the only way to configure these things is via
a UI, then we must find a way to back it up.  but we will not deploy
anything in production without it being 100% reproducible, (assume we
have the DB dump too).  This allows us to move services as required, and
guarantee we can bring it up again if needed.

As already briefly discussed via HipChat, I must admit I am not very confident with Puppet - but we are actually doing two different things:

(1) implement what we call a IAM project, that is work on a Syncope overlay - e.g. an actual Maven project whose sources need to be versioned, which in turn requires a dev env, and will produce some artifacts (WAR files actually) (2) implement provisioning to ASF infrastructure of such WAR files into Tomcat, with DBMS support

About the latter, it seems it is possible to have Jenkins pushing them to bintray for deployment, and that .deb packaging is desirable - again, no problems.

One of the objectives is clearly, once the actual development is over, easily being able to move it to production, with few likes in puppet.

    4. (possibly) some issue tracker (not necessarily JIRA, something
simpler would fit the job as well)
JIRA is the infra preference as in we use that today. I'd just use the
JIRA project and move on. Less hassle.
Fine: wouldn't it be better to feature a dedicated mailing list for
notifications? Even fosslists.org as Daniel suggested in HipChat.
For now, no, I dont think so. We do not have a dedicated list for the
huge MM3 PoC we are doing.

Fine.

    5. (nice to have) some wiki (not necessarily Confluence, something
simpler would fit the job as well)
Again, you can use the infra space on cwiki.

--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC, CXF committer
http://home.apache.org/~ilgrosso/


Reply via email to