I have a FAST API based Rest Application where I need to have some scheduled tasks that needs to run every 30 mins. This application will run on Kubernetes as such the number of instances are not fixed. I want the Scheduled Jobs to only trigger from one of the available instance and not from all the running instances creating a Race condition, as such I need some kind of locking mechanism that will prevent the schedulers to fire if one is already running. My App does connect to a MySql compatible Aurora DB running on AWS. Can I achieve this with ApScheduler, if not are there any alternatives available?
So we have an environment that can't be accessed without a VPN and we want to use drone there but at this situation we can't use webhooks. Is it possible to make drone periodically check our scm and if there's new commit it should start doing its work?
You can use the CRON feature to periodically build. The documentation has more details here: https://docs.drone.io/cron/.
Alternatively, if the Drone server and runner are inside of a VPN, you could publish events to something like Amazon Web Services SQS to push the messages and then poll the SQS queue from inside of the VPN to ping the internal Drone server.
Any REST endpoint which prioritize/update the bamboo build queue?
http://host:8085/rest/api/latest/queue?expand=queuedBuilds
want to automate this process using python for release builds to reduce the waiting time.
Checked above endpoint , but it only add/delete builds from queue. want to move up the bamboo builds which has high priority.
Per the latest Bamboo REST API documentation (6.10.3) there is not a way to do this without creating something custom or using a third party plugin.
I'm using RTC plain java library to make an API call to the Jazz server to fetch components, projects, etc. Is there any way to monitor the database queries triggered on the server-side either through UI or by using any tool and kill them after a timeout.
Although we can see the active queries under 'Activr Service' page on UI, there isn't a way to kill them.
Using Vagrant+Chef Solo I'm setting up two VMs: #1 is a TeamCity server, #2 is a TeamCity agent. Provisioning is done by first installing the TeamCity server package on VM #1, then the agent VM is booted and requests data from the server which is used to install the agent. That whole thing works fine.
But now I want to alter the server after the agent is done provisioning. I want to modify the server's database directly, to change an attribute that is only available after the agent has spun up. But is there a way for one VM's provisioning to trigger another VM? Once the agent is done I'd like to somehow resume provisioning the server, so I can make the database edit..
Any thoughts, recommendations, or feedback welcomed. I'm new to Vagrant, Chef, and TeamCity, so there's a chance I'm missing a much easier solution.
* Why do I want to edit the DB directly you may be wondering? TeamCity agents must be authorized before they can be used, and I want to do this programmatically. The solution I've found is to directly edit the DB, because authorization functionality is not exposed via the TeamCity REST API (as far as I can tell)
If you can test the agent is installed/answering, you may add a ruby block looping over this test before continuing the recipe execution.
This loop should have a sleep and a counter to avoid infinite loops.
I've no knowledge of teamcity, so can't tell if it's the best way.
In general, Chef is designed to manage your system, not simply provision it (though this is less true in the modern Cloud world with "golden image" strategies). Nonetheless, in your case, you best bet is to just setup chef-client as a service that runs every 15 minutes. Once the client has finished provisioning, the next run of the server will be able to authorize it.
If you really want to "trigger" the one from the other, you'd need either do that externally with something like etcd or consul, or you would need to setup an ssh keypair between the boxes and add a ruby_block on the client that either does the database modification directly, or calls chef-client on the server.