My application needs EclipseLink, thus after I created my WildFly cart I ssh to the account and do:
jboss-cli.sh -c --controller=$OPENSHIFT_WILDFLY_IP:$OPENSHIFT_WILDFLY_MANAGEMENT_HTTP_PORT
/system-property=eclipselink.archive.factory:add(value=org.jipijapa.eclipselink.JBossArchiveFactoryImpl)
the system property is defined fine. However it is lost after
ctl_app restart
It is the same for a newly defined datasource.
It looks like Openshift resets everything and deploys the cart from scratch.
Any opinions why?
The recommended way to make configuration changes is to update the standalone.xml configuration file that exists inside your OpenShift application .openshift/config directory.
Every OpenShift application has .openshift directory that contains configuration files that you can update. Everytime you push the source code OpenShift takes your standalone.xml file and apply it. So when you restart the application your changes are overridden. Refer to documentation https://community.jboss.org/wiki/JBossAS7SystemProperties to learn how to add system properties to standalone.xml
Related
I'm running jira in openshift using the basic image from atlassian: https://hub.docker.com/r/atlassian/jira-software
So far most things work fine.
I installed a plugin using the web ui which worked as well.
But now I'm running into an issue when a pod is restarted. The pod uses the image and naturally (as specified) my plugin is not installed anymore. I can install the plugin via webservice calls and register it as an osgi module for jira. But I don't want to do this manually. Building a pipeline or jon for this is quite easy (I'm thinking jenkins or ansible tower). But I so far I didn't find a way to trigger this pipeline after the pod is started (or better after jira is started).
Anyone got an idea how to handle this?
Thanks and best regards. Sebastian
Why not create a custom image based on the Atlassian image with everything you need installed?
As far as I know, there isn't a way to trigger a pipeline when a Pod is started; only Webhook, Image Change, and Config Change triggers are available. You'll need to write a Jenkinsfile to script all of the installation and setup you want, but then that can be triggered in one of the three ways mentioned.
I'm thinking an Image Change trigger would work best for you, so when the latest version of Atlassian's image comes out, you can run your pipeline to set everything up on the latest version.
Also, just curious, but do you have some persistent storage attached to the Jira pod? If not, you'll lose everything in Jira if the Pod dies; that means tickets, boards, comments, everything.
Update:
Looking at this page, it looks like most of the stuff you're trying to persist is stored in jira-home, so maybe mounting that as a persistent volume will be a good solution for you.
You're correct that the tickets are stored in the database, but I'm guessing the database connection settings are getting wiped when the Pod is cycled.
The jira-home directory stores your application and database connection settings, as well as a subdirectory for your plugins.
dbconfig.xml
This file (located at the root of your JIRA home directory) defines
all details for JIRA's database connection. This file is typically
created by running the JIRA setup wizard on new installations of JIRA
or by configuring a database connection using the JIRA configuration
tool.
You can also create your own dbconfig.xml file. This is useful if you
need to specify additional parameters for your specific database
configuration, which are not generated by the setup wizard or JIRA
configuration tool. For more information, refer to the 'manual'
connection instructions of the appropriate database configuration
guide in Connecting JIRA to a database.
jira-config.properties
This file (also located at the root of your JIRA home directory)
stores custom values for most of JIRA's advanced configuration
settings. Properties defined in this file override the default values
defined in the jpm.xml file (located in your JIRA application
installation directory). See Advanced JIRA configuration for more
information.
In new JIRA installations, this file may not initially exist and if
so, will need to be created manually. See Making changes to the
jira-config.properties file for more information. This file is
typically present in JIRA installations upgraded from version 4.3 or
earlier, whose advanced configuration options had been customized
(from their default values).
plugins/
This is the directory where plugins built on Atlassian's Plugin
Framework 2 (i.e. 'Plugins 2' plugins) are stored. If you are
installing a new 'Plugins 2' plugin, you will need to deploy it into
this directory under the installed-plugins sub-directory.
'Plugins 1' plugins should be stored in the JIRA application
installation directory.
This directory is created on JIRA startup, if it does not exist
already.
I have never used PhpStorm before for remote development because I used to work locally.
I am wondering if there is a method to set PhpStorm to work in such a way so it will be identical, in terms of functionality, to local development?
At least, debugging and jumping to functions/variables declaration across the whole project?
Tried to google it but found nothing. Maybe someone knows?
There are two ways to work with remote server development :
With a physically server
With a Virtual Machine locally
Those 2 ways are identical workflow parameters for working with this.
In PHPStorm the main area for parameters workflow deployement on remote server is : PHPStorm > Settings > Build, Execution, Deployement > Deployement
In this area you config the connection on your remote server (you before must config access on your remote server). SFTP is the best way to use this connection.
Most important to select where you want to send/push your modified code with Root path. Upload manually or use the sync auto functionality of PHPStorm use this parameter.
Mappings tabs is not very important you can keep this without change except for 'Deployement path on server' which just type '/' character if you have selected the good 'Root Path' in tab before.
For starting you can forget the Excluded Paths tab. after if you work on symfony framework you use this to exclude the vendor directory.
Don't forget to set the options 'use as Default' if you want to upload or sync auto more fastly and friendly.
Now you must parameters and config correctly your remote server for server be able to run the code which send it with PHPStorm. Dependly on your framework or other technologies you use.
Finally you have :
PHPStorm config OK for send correctly your modification code (auto or manually)
remote server config OK for executing and running correctly the code you are before sending from PHPStorm to your server remote
WARNING : you never run your website into your local OS.
IMPORTANT : config a web server on your remote server and don't forget to install layer for PHP executing script.
I have a project in PHPStorm which I've set up a deployment location on an Amazon EC2 server. When I right click on a HTML file now, I get the following option:
"amazon" is the name of the deployment location I've configured.
Before I added a deployment location, the same option above used to open my file on my localhost.
Is there a way to do the same now that I've added a deployment location? I would like to have a short-cut that allows me to look at my files in real-time without having to upload them onto my deployment machine first.
I ended up taking off the default marker from the deployment profile which allowed me to run a local server using the shortcut mentioned above and still sync with the remote server using my normal keyboard binding.
I'm forced to use a Websphere Application Server 6.1.
I configured some system properties using the admin console, but now the application server doesn't start at all. Which also means I can't access the admin console to remove the system properties which probably cause the problem.
How can I remove the system properties without actually starting the application server?
In case it is of any relevance, the system properties are:
-Dcom.sun.management.jmxremote.port=3333
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
If finally found the file where this kind of configuration is stored. On my machine it is
C:\Program Files\IBM\SDP\runtimes\base_v61\profiles\was61profile1\config\cells\ddea1846Node01Cell\nodes\ddea1846Node01\servers\server1\server.xml
In that file one can find the setting in question and remove it.
Is there a way to change the configuration store location for the OSGi Configuration Admin service? I'd like to have the properties files exist in another bundle so they'd exist in source control & in the deployment rather than the OSGi store.
In the end I decided to use Apache Felix File Install to update the configuration properties of a Configuration Admin ManagedService. This seems to work passably well.
It's a little kludgy because when the files are updated the new configuration properties get pushed to the managed service without regard to their being correct values. This means that on next startup the values will still be bad & need to be set to defaults.
It should work for now.
The Config Admin implementations cannot do this, at least not in a portable way via the specification. Instead you need a "management agent" that pushes configuration data into Config Admin via the API; it can derive that configuration data from any source it wishes.
FileInstall is a very simple example of a management agent. If it does not do exactly what you want then it is not too difficult to write your own.
The ManagedServices will still need to perform validation of incoming configuration data and dynamically react to new configuration data. OSGi is a dynamic platform and Config Admin is designed to allow for on-the-fly reconfiguration of a running system.