I have the following issue:
I use salt stack to manage my minions, which are running in different datacenters. But the package repositories are not consistent: Not all have the latest versions of salt. With Salt stack I can of course work around that, so I added to the top.sls:
'not G#saltversion:3003.1':
- fixes.saltversion
But I don't like that up there. I've tried several variants, but couldn't manage to select minions which have a specific grain less than a specific version. Like in this case: To select all minions which have an older version than 3003.1 to apply a state on them, that gets the package directly from a different repo.
How do I select "less than" of a Grain?
I've googled around already and didn't find anything matching my case. The Docs are also not helpful for my case. I've read about custom matcher: But do I really need to implement a custom matcher for that?
Thanks in advance for your help everyone
Have a look at the following grain: saltversioninfo.
This grain is a list: [ majorversion, patchversion ].
You can target minions with releases later than Fluorine (2019.2.0) like this:
'P#saltversioninfo:0:\b(?:3[0-9]{2}[0-2])\b or ( G#saltversioninfo:0:3003 and G#saltversioninfo:1:0 ):
- match: compound
- fixes.saltversion
This compound match will target minions with release between 3000 and 3003.0.
This is a bit static and you need to modify this after a new release. But I hope this will help you.
EDIT:
The matcher above is untested, I don't have minions with older version. You should test the matcher before with the following salt command:
salt -C 'P#saltversioninfo:0:\b(?:3[0-9]{2}[0-2])\b or ( G#saltversioninfo:0:3003 and G#saltversioninfo:1:0 )' test.ping
Related
https://doc.qt.io/archives/qt-4.8/qmake-environment-reference.html#installs
To help in the install process qmake has the concept of a install set.
It looks like a install set have members, i.e. path, files and extra:
documentation.path = /usr/local/program/doc
documentation.files = docs/*
Are there other members?
What members need to be set in order to consider the install set fully described?
Where the create_docs come from in the case below
unix:documentation.extra = create_docs; mv master.doc toc.doc
QMake is documented... not. Whenever you want to know something you go browse source code. In this case, it's in qmake/generators/makefile.cpp, function Makefilegenerator::writeInstalls().
As we can see, it's path, files, base, extra, CONFIG, uninstall and depends. extra (or commands) is an arbitrary line to insert at the top.
What members need to be set in order to consider the install set fully described?
QMake is Makefile generator. Whatever human does it simply outputs some Makefile. Whether it will work or not, that's a human's problem.
is there any docs / tutorial about how to setup ZRS ?
I can't find anything useful...
ZRS replicates the whole data.fs, is that right?
is there any way / solution to only replicate and keep in sync parts of the instance (folders) ?
Once you've done it, it goes from "black magic" to "not much to say", really. As you've probably noted, the latest versions are incompatible with Plone's older Zope version, so you need to pin to
zc.zrs == 2.4.4
and in the usecase I have here (which includes zlibstorage), the single stanzas in zeo-conf-additional look like this on the server:
<serverzlibstorage demo>
<zrs demo-Z>
replicate-to 41002
<filestorage demo-ZR>
path ${buildout:zeo-datadir}/filestorage/${buildout:instancename}/demo.fs
blob-dir ${buildout:zeo-datadir}/blobstorage/${buildout:instancename}/demo
</filestorage>
</zrs>
</serverzlibstorage>
like this on the replicate:
<serverzlibstorage demo>
<zrs demo-Z>
replicate-from ${buildout:zeo-host}:41002
keep-alive-delay 60
<filestorage demo-ZR>
path ${buildout:zeo-datadir}/filestorage/${buildout:instancename}/demo.fs
blob-dir ${buildout:zeo-datadir}/blobstorage/${buildout:instancename}/demo
</filestorage>
</zrs>
</serverzlibstorage>
and like this on the client in zope-conf-additional:
<zodb_db demo>
cache-size 9000
<zlibstorage>
<zeoclient>
server ${buildout:zeo-host}:${buildout:zeo-port}
# backup:
server ${buildout:clone-host}:${buildout:clone-port}
read-only-fallback True
storage demo
name demo
# [...]
</zeoclient>
</zlibstorage>
mount-point /fs-demo
</zodb_db>
But, as you remark, you can only replicate entire databases, and from what I gather, the general consensus in the Plone community is that having multiple databases (even one per Plone instance) is very much not a recommended use-case anymore.
I have Symfony2 project with Behat used for BDD tests.
Most of tests are tagged, like:
#database #user_management #admin
Scenario: Attempt .....
....
....
#product #admin
Scenario: Login ....
....
....
I would like to be able to list all scenerios tagged with specific tag, before running entire test suite. Is it possible?
I mean I can write small script which analyzes all features files, but I hope there is some behat magic switch/flag, already implemented, but not documented, which does what I need.
I'm not personally aware of a built-in way, partly because it depends on what you expect as an output.
One way to get something similar would be to dry-run the scenarios, with the full items being displayed, and then grep for 'scenario', to get the name/summary:
behat --format=pretty --tags '#domains' --dry-run | grep -i scenario
Is it possible to run a SaltStack command that, say, looks to see if a process is running on a machine, and aggregate the results of running that command on multiple minions?
Essentially, I'd like to see all the results that are returned from the minions displayed in something like an ASCII table. Is it possible to have an uber-result formatter that waits for all the results to come back, then applies the format? Perhaps there's another approach?
If you want to do this entirely within Salt, I would recommend creating an "outputter" that displays the data how you want.
A "highstate" outputter was recently created that might give you a good starting point. The highstate outputter creates a small summary table of the returned data. It can be found here:
https://github.com/saltstack/salt/blob/develop/salt/output/highstate.py
I'd recommend perusing the code of the other outputters as well.
If you want to use another tool to create this report, I would recommend adding "--out json" to your command at the cli. This will cause Salt to return the data in json format which you can then pipe to another application for processing.
This was asked a long time ago, but I stumbled across it more than once, and I thought another approach might be useful – use the survey Salt runner:
$ salt-run survey.hash '*' cmd.run 'dpkg -l python-django'
|_
----------
pool:
- machine2
- machine4
- machine5
result:
dpkg-query: no packages found matching python-django
|_
----------
pool:
- machine1
- machine3
result:
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-=================================
ii python-django 1.4.22-1+deb all High-level Python web development
I have a SSDT-project. When publishing a new version I want to publish/initialize some data in the database as well. Can that be done using SSDT?
It can be done, but could be tricky. If you set up a variable in the project that can be used for "New" releases, you could put that in your post-deploy script as a section that would run a series of inserts, but only for that "New" type.
As David mentioned, the better way would likely be to use something like Red-Gate's data compare or run the scripts after creating the database. It's possible to do it in post-deploy scripts, but could prove tricky.
Something like this could work:
IF '$(DeployType)' = 'New'
BEGIN --"New" release scripts
PRINT 'Post-Deploy Scripts for release.'
:r .\InsertScript1.sql
:r .\InsertScript2.sql
--etc
END --"New" release scripts
This isn't possible in SSDT. The current guidance is to use a post-deployment script.
Redgate ReadyRoll provides many experiences familiar to SSDT users, but has improved static data management as well as many other improvements.
We include Merge-scripts automatically, when they are placed in a specific subfolder of the Project.
depending on what you do, table valued custructors might be something to have a look at:
SELECT *
FROM
(VALUES
(101, 'Bikes'),
(102, 'Accessories'),
(103, 'Clothes')
) AS Category(CategoryID, CategoryName);
These are easily transported and compared by SSDT.
For ore information see https://www.simple-talk.com/sql/sql-training/table-value-constructors-in-sql-server-2008/