VM Creation #8990
closed
new instance of FusionRegistry in production
Added by Ciro Formisano almost 8 years ago. Updated over 7 years ago.
100%
A local mysql database is needed.
gCubeApps/TabularDataLab
Description
Dear Infra Manager,
as agreed at the TCOM, we need to bring in production the new version of Fusion Registry (8.x) currently deployed in Dev.
As suggested by @pasquale.pagano@isti.cnr.it, we should deploy a new clean instance leaving the old one (v 7.x) up and running since, for the moment, it is very difficult to distinguish valid data from noise.
My personal suggestion is to detach the old version from TabMan leaving the service up and running and asking the communities (starting from FAO) to decide which data should be moved before a certain deadline.
Please, remember to add username and password on the Information System, as done for dev environment
Related issues
Updated by Pasquale Pagano almost 8 years ago
- Tracker changed from Task to VM Creation
- Project changed from 8 to D4Science Infrastructure
- Category deleted (
Default) - Priority changed from Normal to High
- Target version changed from WP05 to TabMan
- RAM set to 4
- CPU set to 2
- DiskSpace set to 40
- Smartgears set to Yes
- Smartgears scopes updated (diff)
- Number of VMs set to 1
- Infrastructure Production added
Please @ciro.formisano@eng.it revise the information that are required to create the VM. I put indicative information for RAM, CPU and all the other information.
Updated by Ciro Formisano almost 8 years ago
Dear Lino,
actually I did not find any hardware requirement in official documentation. About software Tomcat is needed and, obviously, Java, so I think that your features are OK: anyway I would take into account the VM containing the dev instance as reference, in which I am not sure that Fusion Registry is on SmartGears, but I think that Infrastructure Management Group knows it very well.
Updated by Andrea Dell'Amico almost 8 years ago
OK. I didn't know that the actual VM was a development one, so it's not properly named. The new one will be fusionregistry.d4science.org.
Updated by Andrea Dell'Amico almost 8 years ago
- Application Instructions updated (diff)
Updated by Ciro Formisano almost 8 years ago
Dear Andrea,
actually I don't know if the original target of that VM was only dev environment. However it is currently (extensively) used for dev operations in dev environment, so I suppose that it can be considered as a dev VM
Updated by Andrea Dell'Amico almost 8 years ago
- Status changed from New to In Progress
Updated by Andrea Dell'Amico almost 8 years ago
smartgears is not running on tabulardata-d4s.d4science.org, btw. Do we need it?
Updated by Pasquale Pagano almost 8 years ago
Yes, i think so. It should bee the default on all production instances.
Updated by Andrea Dell'Amico almost 8 years ago
Pasquale Pagano wrote:
Yes, i think so. It should bee the default on all production instances.
OK. I'm adding a gcube-app.xml to fusiondirectory too.
Updated by Andrea Dell'Amico almost 8 years ago
- % Done changed from 0 to 80
The service is on line, but there's a problem with the authorization.
The gcube-app.xml file reads:
<application mode="online">
<name>FusionRegistry</name>
<group>FusionRegistry</group>
<version>8.4.15</version>
</application>
and the log:
14:31:28.438 [catalina-exec-2] WARN RequestValidator: rejecting call to FusionRegistry, authorization required
@lucio.lelii@isti.cnr.it any hints?
Updated by Lucio Lelii almost 8 years ago
You must exclude gcube authorization in gcube-app.xml file adding this tag
<exclude>/*</exclude>
Updated by Andrea Dell'Amico almost 8 years ago
- Status changed from In Progress to Feedback
Lucio Lelii wrote:
You must exclude gcube authorization in gcube-app.xml file adding this tag
<exclude>/*</exclude>
Thanks, it worked.
The node is online. FusionSecurity is also installed, the fusionregistry root password will be communicated privately.
Updated by Ciro Formisano almost 8 years ago
- Status changed from Feedback to In Progress
Dear Andrea,
probably some more steps are needed to obtain the same configuration of the dev instance (https://fusionregistry-d4s.d4science.org/FusionRegistry/). In the new instance the request of username and password to upload objects is not present: furthermore if I use the root credentials you provided me privately on the maintainance tool it seems that they don't work. For the second aspect, please consider that it does not work on the dev instance as well, probably because authentication on HTTP (that is the only supported by the maintainance tool) is disabled and the only authentication enabled is on the home page. So I guess that, by enabling the authentication on https://fusionregistry.d4science.org/FusionRegistry/, as done in https://fusionregistry-d4s.d4science.org/FusionRegistry/ should solve the problem.
Updated by Andrea Dell'Amico almost 8 years ago
I checked the static configuration and it's identical on the two instances. It has been provisioned so it's what I expected, but I checked for any manual changes.
I also checked the story of #7192 and I didn't report any operation by me on the GUI, so maybe it's something that @g.panichi@isti.cnr.it configured from the Fusion Security interface?
Updated by Andrea Dell'Amico over 7 years ago
- Status changed from In Progress to Feedback
@g.panichi@isti.cnr.it any news about it?
Updated by Giancarlo Panichi over 7 years ago
TabMan is ready to upgrade to the new version of FusionRegistry.
You can copy the development configuration with FunsionRegistry and FusionSecurity to have a configuration for the production.
You should coordinate with @ciro.formisano@eng.it, to copy data from the old to the new registry.
Updated by Ciro Formisano over 7 years ago
I can confirm that everything is OK and we are ready for bringing into production the new version. However, according to some discussion had at FAO during last months, I would involve @anton.ellenbroek@fao.org and @aymen.charef@fao.org who probably would like to discuss about whether and which data should be moved.
Updated by Giancarlo Panichi over 7 years ago
The only configuration that was made is on FusionSecurity where I added the user tabulardata as you see in
https://fusionregistry-d4s.d4science.org/FusionSecurity/secure/index.html
Updated by Andrea Dell'Amico over 7 years ago
Giancarlo Panichi wrote:
The only configuration that was made is on FusionSecurity where I added the user tabulardata as you see in
https://fusionregistry-d4s.d4science.org/FusionSecurity/secure/index.html
@g.panichi@isti.cnr.it Can you replicate the configuration in production and document the steps somewhere?
Updated by Giancarlo Panichi over 7 years ago
@andrea.dellamico@isti.cnr.it in FusionSecurity you can export and import the configuration directly from the graphical interface, there is a button, it creates an xml file with all the data. This file contains users and passwords, so it must be kept in a safe place.
Updated by Giancarlo Panichi over 7 years ago
- Related to Task #9585: FusionRegistry - Update data in new FusionRegistry 8.4.15 in prod added
Updated by Giancarlo Panichi over 7 years ago
The new version of FusionRegistry 8.4.15 is available for production on:
https://fusionregistry.d4science.org/FusionRegistry/
I open a new ticket for moving data between the old and the new registry: Task #9585
Updated by Giancarlo Panichi over 7 years ago
- Status changed from Feedback to Closed
Updated by Andrea Dell'Amico over 7 years ago
I wrote down the steps required to actually activate FusionSecurity inside FusionRegistry here: https://support.d4science.org/projects/aginfraplut/wiki/FusionRegistry_with_FusionSecurity so that we will not waste another 6 hours when we will need to install another instance.
