Is it possible to clear the parquet metadata cache in Apache Drill?
I'm finding that when you version files and use maxdir(), it holds on to old versions which may be deleted.
It seems like there should be a "clear metadata cache" command to cancel out the "refresh metadata cache" command.
Unfortunately, there is no such functionality in Drill so far.
Please log Jira for improvement [1]. Contributions always welcome.
[1] https://issues.apache.org/jira/projects/DRILL
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.
When trying to configure connected assets in AEM, on the Sites instance, the connected configuration save option gets disabled after the initial setup.
Not able to save subsequent edits to the configuration, even when trying with admin credentials.
Is there any configuration to check why the save is disabled? Where under the jcr is this configuration stored?
The configuration is stored under the node /conf/global/settings/dam/remotedam/configuration/jcr:content
We can directly make edits to the properties under this node. However the remote assets instance password is stored as encrypted value. In case edit is required on the password filed, the best option as of now seems to be delete the jcr:content node at this path and reconfigure it through the UI.
Deleting the jcr:content node at this path is the only option I could find to enable the save option on the UI.
This certainly is a bug in this newly introduced feature in AEM 6.5. Hopefully will get addressed in a service pack.
As indicated in the answer - https://stackoverflow.com/a/56945996/1592801,
You don't need to delete the configuration node
Re-entering the password works - and that is working as designed.
The save button is disabled, because there have been no edits in the form to save. Once you make a change, you should be able to see the button enabled.
I have implemented backup/restore local couchbase lite database with google drive. I done database file upload and download process, When this download completed means then i need to restoring to mobile. After that how to implement?
You should be able to just close out the database, replace it with the backup, then reopen it. See this github repo for an example of using a pre-packaged database, which does essentially the same thing: https://github.com/couchbaselabs/mobile-training-todo
Backing up may be a little more involved than you're expecting. Couchbase Lite has a main database, but there are also two other database related files that are transient. Most likely you want to be sure to stop operations for the backup, then copy the one main file.
The easier thing might be to not back up the database yourself, but to use the Couchbase Mobile stack sync capabilities.
Using phpStorm 9.0, i often end-up having to invalidate caches and restart (because REST api performance degrades over time). Is there a way/configuration i did not see to restore my terminal window tools upon restart (the tool itself, window title, and hopefully the working directory)
tia
At the moment such functionality does not exist.
https://youtrack.jetbrains.com/issue/IDEA-117946 -- watch this ticket (star/vote/comment) to get notified on progress.
P.S. You may also be interested in these related tickets:
https://youtrack.jetbrains.com/issue/IDEA-118868
https://youtrack.jetbrains.com/issue/IDEA-134884
Is there a way to encrypt the data file that mysql uses? I have a mysql server on an open machine, and I would like to encrypt the data file so even if someone copies the data files, they cannot read the data.
Thanks
To anyone researching a transparent MySQL encryption solution for Linux, there's a relatively new product on the block that we've been working with:
http://www.gazzang.com/
I am not affiliated with Gazzang... just a happy customer.
I am not sure what do you mean when you say that your machine is open. If people have access to the console, or to your account it is much harder of a task to encrypt the file.
Did you look at Truecrypt? It works for most popular operating systems and allows to create a virtual encrypted partition, lock down a hard drive partition,an external drive or a usb device.
MySQL doesn't support data file encryption natively. There are 3rd products out there such as:
http://www.vormetric.com/products/vormetric_database_encryption_expert.html
There's a 'white paper' on the topic here:
http://www.vormetric.com/documents/FINALPart2DatabaseEncryptionCoreGuardvsColumnLevelWhitePaper7.pdf
To be honest, if the database content has any commercial value or contains personal data about individuals, you should really control who has access to the datafiles (whether encrypted or not). In the UK, leaving such data files open to casual passers-by, would be a data protection no no.
You can use an encrypted filesystem, like the native one for NTFS on Windows or one of the various options for linux. In addition you can store the data encrypted.
If you are using windows EFS and starting MySQL as a service, you will need to do the following:
go to Services and find the MySQL service
stop the service
right-click -> properties -> LogON TAB
check "This account"
fill your windows account name eg. ".\username"
provide your password
start the service
The MySQL service should now start without errors.
To use the windows EFS encryption:
http://windows.microsoft.com/en-us/windows/encrypt-decrypt-folder-file#1TC=windows-7
Read more obout it:
http://www.petri.co.il/how_does_efs_work.htm#
!!! Don't forget to export the certificate !!!
you could encrypt the data within mysql using the built in encryption functionality.
as for the files, any file solution should work fine.