[Fotress] JIRA import...
Hi guys, it seems that importing some cloud JIRA issues into a JIRA server is quite a burden. The process is mainly manual, with a lot of steps to follow (see https://confluence.atlassian.com/display/JIRA/Migrating+from+JIRA+Cloud+to+JIRA+Server). At this point, we have a choice to make. We can decide to not importing the existing JIRA at all, and start with a brand new JIRA, for instance. The reason I'm suggesting this approach is that if you look at the existing JIRA's, there are only two people who have opened issues : Shawn and me. That means they were mainly issues regarding bugs we both found during a development phase. If we consider that JIRA is a tool allowing users to fill issues they found, as much as a developpers tool, we can consider that we can start from a blank page as we don't have any users atm. We can also decide to migrate by hand the few issues that might interest a user (ie, those users are likely to face when using Fortress, and where they can find an answer). Creating the 4 required JIRAs would be quite quick. Migrating all the existing issues would take at least one more week, assuming we do a part of the migration process on our side (ie migrating from cloud to a local server). So, wdyt ? Starting from a blank JIRA does sound reasonnable to you ?
[fortress] Accelerator import
Hi Shawn, we might have to import the accelerator project too. It's implicitely called in the ApacheDsDataProvider class : System.setProperty( StandaloneLdapApiService.EXTENDED_OPERATIONS_LIST, org.openldap.accelerator.impl.createSession.RbacCreateSessionFactory, + org.openldap.accelerator.impl.checkAccess.RbacCheckAccessFactory, + org.openldap.accelerator.impl.addRole.RbacAddRoleFactory, + org.openldap.accelerator.impl.dropRole.RbacDropRoleFactory, + org.openldap.accelerator.impl.deleteSession.RbacDeleteSessionFactory, + org.openldap.accelerator.impl.sessionRoles.RbacSessionRolesFactory ); It's also used in the AcceleratorDAO class : import org.openldap.accelerator.api.addRole.RbacAddRoleRequest; import org.openldap.accelerator.api.addRole.RbacAddRoleRequestImpl; import org.openldap.accelerator.api.addRole.RbacAddRoleResponse; import org.openldap.accelerator.api.checkAccess.RbacCheckAccessRequest; import org.openldap.accelerator.api.checkAccess.RbacCheckAccessRequestImpl; import org.openldap.accelerator.api.checkAccess.RbacCheckAccessResponse; import org.openldap.accelerator.api.createSession.RbacCreateSessionRequest; import org.openldap.accelerator.api.createSession.RbacCreateSessionRequestImpl; import org.openldap.accelerator.api.createSession.RbacCreateSessionResponse; import org.openldap.accelerator.api.deleteSession.RbacDeleteSessionRequest; import org.openldap.accelerator.api.deleteSession.RbacDeleteSessionRequestImpl; import org.openldap.accelerator.api.deleteSession.RbacDeleteSessionResponse; import org.openldap.accelerator.api.dropRole.RbacDropRoleRequest; import org.openldap.accelerator.api.dropRole.RbacDropRoleRequestImpl; import org.openldap.accelerator.api.dropRole.RbacDropRoleResponse; what's your take on that ?
Re: [Fotress] JIRA import...
It does sound reasonable. And given that you two know about all the issues in the Cloud JIRA you can point creators of issues in the new JIRAs to the equivalent so that content can be references. Depending of course on how long the Cloud JIRA will exists. Regards, Pierre Smits *ORRTIZ.COM http://www.orrtiz.com* Services Solutions for Cloud- Based Manufacturing, Professional Services and Retail Trade http://www.orrtiz.com On Thu, Oct 23, 2014 at 9:31 AM, Emmanuel Lécharny elecha...@symas.com wrote: Hi guys, it seems that importing some cloud JIRA issues into a JIRA server is quite a burden. The process is mainly manual, with a lot of steps to follow (see https://confluence.atlassian.com/display/JIRA/Migrating+from+JIRA+Cloud+to+JIRA+Server ). At this point, we have a choice to make. We can decide to not importing the existing JIRA at all, and start with a brand new JIRA, for instance. The reason I'm suggesting this approach is that if you look at the existing JIRA's, there are only two people who have opened issues : Shawn and me. That means they were mainly issues regarding bugs we both found during a development phase. If we consider that JIRA is a tool allowing users to fill issues they found, as much as a developpers tool, we can consider that we can start from a blank page as we don't have any users atm. We can also decide to migrate by hand the few issues that might interest a user (ie, those users are likely to face when using Fortress, and where they can find an answer). Creating the 4 required JIRAs would be quite quick. Migrating all the existing issues would take at least one more week, assuming we do a part of the migration process on our side (ie migrating from cloud to a local server). So, wdyt ? Starting from a blank JIRA does sound reasonnable to you ?
[jira] [Commented] (DIRSERVER-2009) ERR_04274 Can't find an OID for the name ads-base after configuring replication
[
https://issues.apache.org/jira/browse/DIRSERVER-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14181288#comment-14181288
]
Paul Simpkins commented on DIRSERVER-2009:
--
Hi there,
I have been able to import the ldif into the consumer - and then successfully
restart the consumer.
In order to do this I removed the line :
objectclass: ads-base
After restarting I was able to see the consumer settings under.
dn:
ads-replConsumerId=1,ou=replConsumers,ads-serverId=ldapServer,ou=servers,ads-directoryServiceId=default,ou=config
However the replication isn't working still.
ERR_04274 Can't find an OID for the name ads-base after configuring
replication
-
Key: DIRSERVER-2009
URL: https://issues.apache.org/jira/browse/DIRSERVER-2009
Project: Directory ApacheDS
Issue Type: Bug
Components: ldap
Affects Versions: 2.0.0-M17
Reporter: Rubèn-Dario Castañé
Labels: ldap, replication
Attachments: ads-base.png, ads-replconsumer.png
I'm working on multi-master replication between two servers, following these
instructions: http://joacim.breiler.com/apacheds/ch08s02.html
In a nutshell, I did the following configuration in both servers. First, I
activated the replication handler:
{code}
dn:
ads-serverId=ldapServer,ou=servers,ads-directoryServiceId=default,ou=config
changetype: modify
add: ads-replReqHandler
ads-replReqHandler:
org.apache.directory.server.ldap.replication.provider.SyncReplRequestHandler
{code}
Second, I created a consumer in both servers, each entry pointing to each
other:
{code}
dn:
ads-replConsumerId=1,ou=replConsumers,ads-serverId=ldapServer,ou=servers,ads-directoryServiceId=default,ou=config
objectClass: ads-base
objectClass: ads-replConsumer
objectClass: top
ads-replAliasDerefMode: never
ads-replAttributes: *
ads-replConsumerId: 1
ads-replProvHostName: ldap-server2.engisoft.com
ads-replProvPort: 10389
ads-replRefreshInterval: 6
ads-replRefreshNPersist: true
ads-replSearchFilter: (objectClass=*)
ads-replSearchScope: sub
ads-replSearchSizeLimit: 0
ads-replSearchTimeOut: 0
ads-replUserDn: uid=repl,ou=system
ads-replUserPassword:: xxx
ads-searchBaseDN: dc=engisoft,dc=com
{code}
I restart the ApacheDS service, in order to reload the changes, but it fails
with this stacktrace (from wrapper.log):
{code}
INFO | jvm 1| 2014/09/30 14:37:18 | [14:37:18] ERROR
[org.apache.directory.server.config.ConfigPartitionReader] - An error occured
while reading the configuration DN
'ou=replConsumers,ads-serverId=ldapServer,ou=servers,ads-directoryServiceId=default,ou=config'
for the objectClass 'ads-replConsumer':
INFO | jvm 1| 2014/09/30 14:37:18 | ERR_04274 Can't find an OID for the
name ads-base
INFO | jvm 1| 2014/09/30 14:37:18 | [14:37:18] DEBUG
[org.apache.directory.CURSOR_LOG] - Closing ListCursor SetCursor :
INFO | jvm 1| 2014/09/30 14:37:18 | Index : 0
INFO | jvm 1| 2014/09/30 14:37:18 | Size : 1
INFO | jvm 1| 2014/09/30 14:37:18 | IndexEntry[ null,
9a111f0d-cef5-4251-93ba-b06960f05af6 ]
INFO | jvm 1| 2014/09/30 14:37:18 |
INFO | jvm 1| 2014/09/30 14:37:18 | [14:37:18] DEBUG
[org.apache.directory.CURSOR_LOG] - Closing ListCursor SetCursor :
INFO | jvm 1| 2014/09/30 14:37:18 | Index : 0
INFO | jvm 1| 2014/09/30 14:37:18 | Size : 4
INFO | jvm 1| 2014/09/30 14:37:18 | IndexEntry[ null,
75244beb-84ee-4bab-8185-cffb650efa95 ]
INFO | jvm 1| 2014/09/30 14:37:18 | IndexEntry[ null,
0ce41868-ad39-4af1-a027-392ddc41dead ]
INFO | jvm 1| 2014/09/30 14:37:18 | IndexEntry[ null,
7f11fd1f-efb6-4ce7-9c32-377092729f08 ]
INFO | jvm 1| 2014/09/30 14:37:18 | IndexEntry[ null,
9f915798-a812-4b8b-9633-104d6a33a1d6 ]
INFO | jvm 1| 2014/09/30 14:37:18 |
INFO | jvm 1| 2014/09/30 14:37:18 | [14:37:18] DEBUG
[org.apache.directory.CURSOR_LOG] - Closing ListCursor SetCursor :
INFO | jvm 1| 2014/09/30 14:37:18 | Index : 0
INFO | jvm 1| 2014/09/30 14:37:18 | Size : 1
INFO | jvm 1| 2014/09/30 14:37:18 | IndexEntry[ null,
73b98b4e-b99e-41af-9e05-e10c570d0f0f ]
INFO | jvm 1| 2014/09/30 14:37:18 |
INFO | jvm 1| 2014/09/30 14:37:18 | [14:37:18] ERROR
[org.apache.directory.server.wrapper.ApacheDsTanukiWrapper] - Failed to start
the service.
INFO | jvm 1| 2014/09/30 14:37:18 |
org.apache.directory.server.config.ConfigurationException: An error occured
while reading the configuration DN
'ou=replConsumers,ads-serverId=ldapServer,ou=servers,ads-directoryServiceId=default,ou=config'
for the objectClass 'ads-replConsumer':
INFO | jvm 1| 2014/09/30 14:37:18 |
Re: [fortress] Accelerator import
On 10/23/2014 03:25 AM, Emmanuel Lécharny wrote: Hi Shawn, we might have to import the accelerator project too. It's implicitely called in the ApacheDsDataProvider class : It's also used in the AcceleratorDAO class : what's your take on that ? I'm not opposed but don't believe it is required to move. What is the drawback of leaving it where it sits?
Re: [Fotress] JIRA import...
On 10/23/2014 03:35 AM, Pierre Smits wrote: It does sound reasonable. And given that you two know about all the issues in the Cloud JIRA you can point creators of issues in the new JIRAs to the equivalent so that content can be references. Depending of course on how long the Cloud JIRA will exists. I am ok with starting over, though would prefer not. As Emmanuel said, most of the issues are bugs either reported externally or found during tests. The cloud jira will remain operational for the forseeable future so yes we can always reference to the old system for historical purposes. The one drawback is we lose the transparent history of the project, i.e. when others come look they will think we've just started tracking issues which reflects poorly on project maturity.
Re: [fortress] Accelerator import
Le 23/10/14 15:44, Shawn McKinney a écrit : On 10/23/2014 03:25 AM, Emmanuel Lécharny wrote: Hi Shawn, we might have to import the accelerator project too. It's implicitely called in the ApacheDsDataProvider class : It's also used in the AcceleratorDAO class : what's your take on that ? I'm not opposed but don't believe it is required to move. What is the drawback of leaving it where it sits? None atm. It's OpenLDAP license, which is compatible with AL 2, it's present in Maven repository, so there is no urgency. I was thinking about moving it later, if we decide to add the server implementation in ApacheDS. Let's focus on Fortress-core atm !
Re: [Fotress] JIRA import...
Le 23/10/14 15:55, Shawn McKinney a écrit : On 10/23/2014 03:35 AM, Pierre Smits wrote: It does sound reasonable. And given that you two know about all the issues in the Cloud JIRA you can point creators of issues in the new JIRAs to the equivalent so that content can be references. Depending of course on how long the Cloud JIRA will exists. I am ok with starting over, though would prefer not. As Emmanuel said, most of the issues are bugs either reported externally or found during tests. The cloud jira will remain operational for the forseeable future so yes we can always reference to the old system for historical purposes. The one drawback is we lose the transparent history of the project, i.e. when others come look they will think we've just started tracking issues which reflects poorly on project maturity. I'm also thinking that we need to reflect the project past life on the fortress front page. We would need a big of history there... Shawn ?
Re: [Fotress] JIRA import...
Le 23/10/14 15:55, Shawn McKinney a écrit : On 10/23/2014 03:35 AM, Pierre Smits wrote: It does sound reasonable. And given that you two know about all the issues in the Cloud JIRA you can point creators of issues in the new JIRAs to the equivalent so that content can be references. Depending of course on how long the Cloud JIRA will exists. I am ok with starting over, though would prefer not. As Emmanuel said, most of the issues are bugs either reported externally or found during tests. The cloud jira will remain operational for the forseeable future so yes we can always reference to the old system for historical purposes. The one drawback is we lose the transparent history of the project, i.e. when others come look they will think we've just started tracking issues which reflects poorly on project maturity. Infra suggest that we upload the existing issues into a text file, that is stored on our web site. This could be a good way to mitigate with the current problem. wdyt ?
Re: [Fotress] JIRA import...
On 10/23/2014 01:46 PM, Emmanuel Lécharny wrote: Infra suggest that we upload the existing issues into a text file, that is stored on our web site. This could be a good way to mitigate with the current problem. wdyt ? That would be fine.
Re: [Fotress] JIRA import...
On 10/23/2014 01:47 PM, Emmanuel Lécharny wrote: I'm also thinking that we need to reflect the project past life on the fortress front page. We would need a big of history there... Shawn ? Good idea. How about a link on the fortress page to the project history?
Re: [Fotress] JIRA import...
Le 23/10/14 21:17, Shawn McKinney a écrit : On 10/23/2014 01:46 PM, Emmanuel Lécharny wrote: Infra suggest that we upload the existing issues into a text file, that is stored on our web site. This could be a good way to mitigate with the current problem. wdyt ? That would be fine. Ok, let's do that then. I'll ask for the creation of the empty JIRA, and will work tomorow on moving the export to a page on our site.
[jira] [Created] (FC-1) Complete teh removal of the UnboundId library
Emmanuel Lecharny created FC-1: -- Summary: Complete teh removal of the UnboundId library Key: FC-1 URL: https://issues.apache.org/jira/browse/FC-1 Project: FORTRESS-CORE Issue Type: Task Reporter: Emmanuel Lecharny Priority: Blocker We need to get rid of the UnboundID library. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
