syncope-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Smits <>
Subject Re: [DISCUSS] Syncope for ASF identity management
Date Wed, 09 Dec 2015 14:44:08 GMT
Hi All,

The PoC is just a means to get questions raised (from various perspectives)
and - potentially - answered. But as this is intended for the ASF, it can't
be a one pony trick. Multiple parties have to be involved, not only
Francesco (who also seems to be allocating dedicated Syncope contributors).
Maybe even parties from the board.

I suggest we start off  with a first JIRA issue at the space of INFRA, e.g.
called simply: IAM PoC, with an interested party from INFRA as the
Assignee, and everybody else interested as watchers. That way everybody
will get notifications and stay in the loop. And for each new aspect a
subtask can be raised and followed up.

In the end, in stead of digging through mail archives at various places, we
have somewhat of initial PoC result documentation that then can be
transferred into wiki pages.

+1 on various steps defined already. I am willing to help.

Best regards,

Pierre Smits

OFBiz based solutions & services

OFBiz Extensions Marketplace

On Wed, Dec 9, 2015 at 3:16 PM, Francesco Chicchiriccò <>

> 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:
>>>>>>     -  (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
>>>>>> 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 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
> Involved at The Apache Software Foundation:
> member, Syncope PMC chair, Cocoon PMC, Olingo PMC, CXF committer

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message