We have a need to set some directives in the snappy config files for the various components (servers, locators, etc).
The snappy_ec2 scripts do a good job at creating all of the config's and keeping them in sync across the cluster, but I need to find a serviceable method to add directives to the auto generated scripts.
What is the preferred method using this script?
Example: Add the following to the 'servers' file:
-gemfirexd.disable-getall-local-index=true
Or perhaps I should add these strings to an environments file such as
snappy-env.sh
TIA
-doug
Have you tried adding the directives directly in the servers (or locators or leads) file and placing this file under (SNAPPY_DIR)/ec2/deploy/home/ec2-user/snappydata/? The script would read the conf files under this dir at the time of launching the cluster.
You'll need to specify it for each server you want to launch, with the name of server as shown below. See 'Specifying properties' section in README, if you have not already done so. e.g.
{{SERVER_0}} -heap-size=4096m -locators={{LOCATOR_0}}:9999,{{LOCATOR_1}}:9888 -J-Dgemfirexd.disable-getall-local-index=true
{{SERVER_1}} -heap-size=4096m -locators={{LOCATOR_0}}:9999,{{LOCATOR_1}}:9888 -J-Dgemfirexd.disable-getall-local-index=true
If you want it to be applied for all the servers, simply put it in snappy-env.sh as you mentioned (as SERVER_STARTUP_OPTIONS) and place the file under directory mentioned above.
We could have read the conf files directly from (SNAPPY_DIR)/conf/ instead of making users copy it to above location, but we may release the ec2 scripts as a separate package, in future, so that the users do not have to download the entire distribution.
Related
I think what I am looking to do is fairly simple - I just can't wrap my head around it.
I've got a repo in AzDo. This repo contains configuration files for firewalls. This is how we manage changes in these configurations.
I've got a simple build pipeline that copies the relevant files and creates an artifact.
I have a release pipeline that gets the files onto the on-prem machine in my Deployment Group. The files show up in c:\azagent\r1\_work\<artifact folder>.
As part of this pipeline I am looking to copy the files from c:\azagent\r1\_work\<artifact folder> to e:\shares\<artifact name>. This is the part that I cannot figure out how to make work.
What strategy could I use to put this together? I've looked into the documentation but it seems like this is somewhat of an edge case (not deploying an app or web site, etc). Ideally, I'd love to do this in a multi-stage YAML pipeline - but from what I've read, it appears as if these do not yet support Deployment Groups. So a classic pipeline is fine for now.
You can add a copy file task(Click the plus sign(+) on the agent job and search for copy files) in your release pipeline to copy the files to a different place on your local machine.
Then you can specify the source folder(ie. $(System.DefaultWorkingDirectory)), and the contents to copy and the target folder(ie. e:\shares\). In below example all contents in $(System.DefaultWorkingDirectory)(ie. C:\agent\_work\r1\a) will be copied to folder D:\Test\New folder
Please check the prefined variables for more information about its map to the local folders.
I've been playing around with Jekyll lately and recently discovered that S3 wouldn't allow me to have enough buckets to have one bucket per website.
So I'm struggling to figure out two things
1) How do I specify that I want a 'child' subdirectory to be created, and all the generated website's files to be in it ?
2) How do I use a variable as the 'child' subdirectory's name ? (since it will be different for each website)
The baseurl config option doesn't seem to do anything about that. Any idea will be welcome :-)
Thanks a lot, and have a great day !
I'm not sure about the variable option, however, for child sub-directories:
A) If you can put the content into "child" folders directly within the jekyll content, then use different configuration files to manage each site through build properties. See the examples under the example below.
B) If you just want to put the same content in different places, perhaps you could use different baseurl or destination properties in different config files? Use the same config file approach as below, but with different versions of those properties instead of/in combination with the exclude property (see https://jekyllrb.com/docs/configuration/#serve-command-options).
Example: Use different config files
Use the exclude config property to exclude folders (and all of that folder's contents) when running a build. You could also specify different output folder locations per site, base URLs, and so on. I'll focus on the exclude property, but you can find other useful properties in the documentation: https://jekyllrb.com/docs/configuration/#global-configuration
For example, you could have the following files/folders:
/siteA-folder/siteA-content/blah.html
/siteB-folder/siteB=content/meh.html
/siteC-folder/siteC=content/foo.html
config.yaml
config_buildA.yaml
config buildB.yaml
Use the build option --config FILE1[,FILE2...] (https://jekyllrb.com/docs/configuration/#build-command-options) to explicitly call your custom config file A or B, each of which has its own version of the exclude property.
Snippet from config_buildA.yaml:
exclude:
- /siteB-folder/ # While building A, you want to exclude the siteB folder and contents
- /siteC-folder/ # Similarly, exclude siteC contents
Snippet from config_buildB.yaml:
exclude:
- /siteA-folder/ # While building B, you want to exclude the siteA folder and contents
- /siteC-folder/ # Similarly, exclude siteC contents
Building A from the command line:
jekyll build --config config_buildA.yaml
Building B from the command line:
jekyll build --config config_buildB.yaml
By managing excludes in the config file, you can re-use the common templates and css, and keep everything together (using less disk space overall).
If there's shared content, you could also look into using a more advanced feature, includes (see https://jekyllrb.com/docs/includes/), to manage the shared content in the includes folder, referenced within the html or markdown files (but that's getting a little of the beaten track for your question, so I'll stop there...)
EDIT: I see you've edited the question specifying the baseurl property doesn't do what you're looking for.
I've used a combination of the url site property baseurl and destination similar to below. In my case, I have different destinations depending on whether it's an archive or latest content, but you could use this to build to different web folders if you wanted.
Ex: config for latest content
url: http://example.com
baseurl: "/latest/"
destination: /path/to/latest/output/
Ex: config for archived content
url: http://example.com
baseurl: "/archive/content/"
destination: /path/to/archive/output/
Then, using the multiple versions of the config file, I can just call whichever one applies.
In the documentation for app-indexeddb-mirror at https://elements.polymer-project.org/elements/app-storage?active=app-indexeddb-mirror there is a section I've copied below. I think I'm running into an error because the indicated file isn't loading, but I'm not sure how to fix the issue. Do I add a reference in staticFileGlobs in sw-precache-config.js or somewhere else?
In order to ensure that operations on IndexedDB block the main browser thread as little as possible, app-indexeddb-mirror relies on a WebWorker to operate on its corresponding IndexedDB database. If you are vulcanizing or otherwise combining your source files before your app is deployed, make sure that you include the corresponding worker script (app-indexeddb-mirror-worker.js) among your deployable files. You can configure the path to the worker script with the worker-url attribute.
The error I'm getting:
GET https://example.com/src/common-worker-scope.js?https://example.com/bower_components/app-storage/app-indexeddb-mirror/app-indexeddb-mirror-worker.js net::ERR_INTERNET_DISCONNECTED
I want to reexecute some targets when the configuration changes.
Consider this example:
I have a configuration variable (that is either read from environment variables or a config.local file):
CONF:=...
Based on this variable CONF, I assemble a header file conf.hpp like this:
conf.hpp:
buildConfHeader $(CONF)
Now, of course, I want to rebuild this header if the configuration variable changes, because otherwise the header would not reflect the new configuration. But how can I track this with make? The configuration variable is not tied to a file, as it may be read from environment variables.
Is there any way to achieve this?
I have figured it out. Hopefully this will help anyone having the same problem:
I build a file name from the configuration itself, so if we have
CONF:=a b c d e
then I create a configuration identifier by replacing the spaces with underscores, i.e.,
null:=
space:= $(null) #
CONFID:= $(subst $(space),_,$(strip $(CONF))).conf
which will result in CONFID=a_b_c_d_e.conf
Now, I use this $(CONFID) as dependency for the conf.hpp target. In addition, I add a rule for $(CONFID) to delete old .conf files and create a new one:
$(CONFID):
rm -f *.conf #remove old .conf files, -f so no error when no .conf files are found
touch $(CONFID) #create a new file with the right name
conf.hpp: $(CONFID)
buildConfHeader $(CONF)
Now everything works fine. The file with name $(CONFID) tracks the configuration used to build the current conf.hpp. If the configuration changes, then $(CONFID) will point to a non-existant .conf file. Thus, the first rule will be executed, the old conf will be deleted and a new one will be created. The header will be updated. Exactly what I want :)
There is no way for make to know what to rebuild if the configuration changed via a macro or environment variable.
You can, however, use a target that simply updates the timestamp of conf.hpp, which will force it to always be rebuilt:
conf.hpp: confupdate
buildConfHeader $(CONF)
confupdate:
#touch conf.hpp
However, as I said, conf.hpp will always be built, meaning any targets that depend upon it will need rebuilt as well. A much more friendly solution is to generate the makefile itself. CMake or the GNU Autotools are good for this, except you sacrifice a lot of control over the makefile. You could also use a build script that creates the makefile, but I'd advise against this since there exist tools that will allow you to build one much more easily.
I'm using the Maven Appassembler plugin to package my application. I'd like to package some configuration files with the application. I've found the configurationDirectory and includeConfigurationDirectoryInClasspath parameters, but I haven't found how I should create (and populate) that configuration directory. I've tried putting the files in src/main/resources, but that just puts them in the jar file for my project.
What is the "proper" way to do this, using maven?
Unfortunately this is a limitation of the appassembler plugin in the current release version. Typically, the plugin is used in conjunction with the assembly plugin to produce the final artifact, in which you can include the reference to your configuration directory. However, if you'd like to have a functional structure from just the appassembler plugin you need to manually copy the files into place. An example using the antrun plugin with a src/main/conf directory can be found here: http://svn.apache.org/viewvc/archiva/trunk/archiva-jetty/
By default, the plugin uses the directory src/main/config.
Is possible to change the source for the config files using the parameter <configurationSourceDirectory>src/main/config</configurationSourceDirectory>
When I include the copyConfigurationDirectory property, it copies the config files and bundles them properly.
<configurationDirectory>etc</configurationDirectory>
<configurationSourceDirectory>src/main/config</configurationSourceDirectory>
<copyConfigurationDirectory>true</copyConfigurationDirectory>
I have a different problem though. I would like to filter my config files before copying, which is giving me some trouble.
Apart from that is does not generate the bin scripts for different platforms. The maven-assembly-plugin can create (package(s) {tar.gz, zip}) for distribution. These are configured through a assemble.xml. You specify which files go in (with what options (chmod)), etc. It can also filter files (search/replace values within them). etc.
Years later and in version 1.10 of the plugin there is now a preAssembleDirectory configuration option. Unfortunately I don't find it flexible enough for my needs because it copies directly into assembleDirectory and does not allow to specify a target directory path within assembleDirectory.