I have a tool which requires boto3's direct connect functionality. However I cannot tell from which version onwards boto3 includes this functionality.
Is there any way to obtain the older version of the docs to see at which point direct connects were added?
At this point in time the latest is 1.4.4.
boto3 development is an open source initiative. So you can always checkout botocre development repository for the release notes, or ask question there.
changelog.rst will show a brief list of changes.
Then use following command to switch to specify tag version and look for the date of commit.
git checkout tags/<version_name>
Related
We're using AWS's elasticsearch service. We have a custom synonyms package associated with the elasticsearch domain. The file lives in an s3 bucket, when the file is updated it triggers a lambda that updates the package version in AWS. We followed the documentation at https://docs.aws.amazon.com/elasticsearch-service/latest/developerguide/custom-packages.html and so far that all works great for uploading and updating a new version of the package. However, the way aws elasticsearch custom packages work, each domain that uses the custom package stores its own copy of the file as well. To keep search behavior predictable, domains continue to use their current package version until you explicitly update them.
The problem is that I can't find any way to programmatically tell the domain to use the new version of the package. It's like 2 clicks in the console, but I cannot for the life of me find a way to do it from my automation code. The update_package method just updates the package version, it doesn't tell the associated domains to use the new version.
We're looking for a way to programatically tell an AWL elasticsearch domain to update the version of an associated custom synonyms file.
So after banging my head on this for days and I finally figured it out 5 minutes after posting this question. You just need to call the associate_package method again after you update the package. I had actually tried that previously and it failed, but it turns out it fails if there is no new version of the package available. I think I was calling associate_package again before the update_package method was completed, so the new version wasn't available yet.
Anyway, hope this helps someone in the future.
Correct, you have to specifically call associate_package to link to the latest version of that package
I am trying out AWS CodePipeline and currently have it hooked up to our Github account where it can checkout the master branch no issues, as this is set in the Source settings.
However, this is obviously quite restrictive, and I'd like to be able to specific a version tag from Github to checkout, but canot see anyway of achieveing this?
Ideally, I want to specify a version number (tag in Github) before the Pipeline runs, so I can use 1 Pipeling to checkout, build, test, deploy the codebase for a specific version tag. Again, I cannot find any information on how to achieve this.
This is not natively supported at the moment.
But you could configure your CodePipeline to create a Full Git Clone instead of just an artifact, and then pass that to a CodeBuild where you can use git to checkout the specific tag as outlined in the AWS documentation.
I couldn't stomach purchasing the $150 for GCP's support service for this one question. I'm just looking to understand the schedule for Cloud Build Node.js versions. It's still stuck on Node.js v10.10 and my projects are starting to require higher versions to build. According to Cloud Build's changelog, I don't believe the Node.js version has updated in years. Any ideas?
As per the official Github repository:
Our client libraries follow the Node.js release schedule. Libraries are compatible with all current active and maintenance versions of Node.js.
So, this means it should work with Node.js 12 and the updates should be more constant. In addition to that, in here, it says that if you are using a Cloud Build config file, you can use Node.js 12, so the Node.js' latest version should be compatible with Cloud Build.
To summarize, by the repository, it should follow Node.js schedule. However, in case you think this is not occurring, I would recommend you to raise a bug on the Google's Issue Tracker - it's free, by the way - so they can assess this.
Dialogflow has a Versions and Environments BETA. I understand that creating a version captures the current state of your agent. I would like to know if this includes training phrases? When I tried to revert to a different version it did not rollback the changes changes to the training phrases
Secondly, if anyone can answer this question - what is the point of creating a version without publishing?
Quoting the docs:
A version is an immutable copy of the current state of your agent, which you can then publish to an environment. When a new version is created, a snapshot of the intents and entities in your current agent is used.
So it should work, but you would also have to publish an environment. Please note that this is currently a beta feature, so it might have some issues.
Personally I am using option to export agent data to zip file through API and version through this data in a separate repository.
The Sitecore documentation provides some pretty clear instructions on how to configure a Sitecore instance as a processing server:
https://doc.sitecore.net/sitecore_experience_platform/xdb_configuration/configure_a_processing_server
However, many of those steps require enabling/disabling of files manually on the installed server. Has anybody seen or built a patch file (similar to SwitchMasterToWeb) that can disable/enable the appropriate functionality as a patch? I would rather not touch the default Sitecore install and instead rely on automated deployment of configuration patches.
I haven't seen this as a patch and not sure if its possible to do this with just one patch (would love to be proved wrong), but for something like this I've used a Powershell script.
I set up Octopus Deploy to run a Powershell script step after deploy to disable files and change settings if patch files can't do the job.
I can highly recommend the Powercore tools for this kind of thing.
https://github.com/adoprog/Sitecore-PowerCore/tree/master/Framework/ConfigUtils
If anybody else winds up looking for this, I've posted some work up on GitHub for patch files for a variety of versions for 8.0:
https://github.com/jst-cyr/Sitecore-Role-Configs
The patches there will do the 'disable/enable/change' for authoring, delivery, or processing. I don't have one for the reporting server.
Sitecore has evaluated POC for same. At this point of time applciable for Sitecore CMS 8.1 rev. 160302 (Update-2). See here-
https://github.com/Sitecore/Sitecore-Configuration-Roles