AWS Elasticsearch domain deployed through CloudFormation. How to update ES version without replacement? - aws-cloudformation

We have an AWS Elasticsearch domain we created through CloudFormation running version 6.3 of ES. When we update the ElasticsearchVersion property in the template, it replaces the Elasticsearch domain with a new one running the new version instead of updating the existing one.
How does anyone upgrade their Elasticsearch domains that were deployed with CF if it doesn't do an in-place upgrade? I am almost thinking at this point I need to create and manage my ES domains through boto3.
Any insight or ideas would be greatly appreciated.

This is now possible (as of 25/11/2019) by setting an UpdatePolicy with EnableVersionUpgrade: True.
For example:
ElasticSearchDomain:
Type: AWS::Elasticsearch::Domain
Properties: ...
UpdatePolicy:
EnableVersionUpgrade: true
https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-updatepolicy.html#cfn-attributes-updatepolicy-upgradeelasticsearchdomain

Received correspondence back from AWS Support regarding an ES in-place upgrade through CloudFormation.
tl;dr It is currently not supported but a feature request is already active for this functionality.
You are correct in saying that ES in-place upgrade is not supported by CFN at this moment. Thus upgrading ES from 6.3 to 6.4 can be done via CLI or AWS Console will keep the existing domain, but with CloudFormation, it will launch a new domain and discard the existing one.
I see that there is already an active feature request for this. I will go ahead and pass your sentiment regards to our internal team about this matter as well.
Unfortunately, AWS Support does not have visibility to service enhancement implementation roadmap, so I would not be able to provide you with an exact time frame.

Related

Confluence migration from cloud to server

We have migrated a space from cloud instance to server instance,in cloud instance we were using "Plantuml diagrams for confluence" but in server we are using "Confluence PlantUML Plugin" .so macro name are different in both cloud and server ,so macro name for cloud is "plantumlcloud" but for server it is "plantuml".so ,in pages after migration it is showing "plantumlcloud" not a valid macro ,kindly help to resolve.
In general, migration of confluence spaces to another application which is not running the same plugins will cause any functionality of that plugin to break.
If you migrate hosting platforms, and have the equivalent version of the plugin for your new platform, created by the same developer, in most cases you will retain functionality, however there will often be differences between versions.
These differences are found especially when downgrading, and moving from cloud to server is a very definite example of a downgrade, as cloud will always run the latest version.
In general I would reccomend against a migration from cloud to server, and when it must be done, time should be spent to ensure compatability with all plugins, and migration guides and plans should be made and followed.
As commented by #tgdavies, there seems to be an equivelent version of the plugin you were using on cloud, so hopefully that can resolve your issue.

Azure ApplicationInsights Application Map doesn't show PostgreSql dependency by default

In the Application Map feature of Azure ApplicationInsights, it seems that the PostgreSql db dependency is not shown by default, whereas Azure storage queues, blobs are shown, and so are other http dependencies. This doc by Microsoft doesn't explain why either.
Does anyone know why and when this feature will be available?
I believe it's bc for .Net, PostgreSql is not an auto-collected dependency. You will have to manually wire it up, according to this article.

Is kubebuilder/controller-runtime still maintained

I used to define my custom resources using apiserver-builder, which is currently deprecated and recommended to use kubebuilder instead.
I tried to generate my resources using kubebuilder, but i found sigs.k8s.io/controller-runtime version in Gopkg.toml is v0.1.1, which is based on k8s 1.10.1 .
Then i searched in controller-runtime repository, the latest version is v0.1.7, which is based on k8s 1.11.2 .
I am wondering when could kubebuilder/controller-runtime update to k8s 1.12.x? Or if kubebuilder still maintained?
Yes, the kubernetes-sigs/controller-runtime is still actively being developed on and is maintained.
I am wondering when could kubebuilder/controller-runtime update to k8s 1.12.x?
The best way to ask the maintainers to make this happen would be to ask on the #kubebuilder channel on the Kubernetes Slack, or create an issue on the repo.

What is the proper procedure for upgrading a multi-node Crate cluster?

I have a crate cluster consisting of multiple nodes. The cluster is currently running 0.39.1 utilizing the Ubuntu stable repository. I would like to upgrade to 0.40.2 with no down time on the cluster.
Is it wise to simply use the ES rolling upgrade process (given that we have the ES API enabled) referenced here: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/setup-upgrade.html#rolling-upgrades
We cannot give any guarantees that the ES rolling update works in every case and for every setup and dataset. We have to do extensive testing to verify that. Additionally, you have to enable the ES Rest API for that to work.
Nonetheless the following is true:
crate uses ES 1.X since version 0.24.0
there are no breaking changes in crate between 0.38.3 and current stable relase 0.40.2
according to the ES documentation you referenced, rolling upgrades should be supported on all minor/maintenance releases since 1.0
We've put making rolling upgrades (without using the ES API) on our backlog.
Stay tuned.
Update:
Since release 0.44.0 Crate supports zero downtime upgrades using a rolling upgrade with strong data availability guarantees. You don't have to enable the ES REST API. See the documentation about Zero Downtime Upgrades.

Azure deployment versions

I will try to make it simplify. I am using windows azure cloud to host our web services and databases. and these web services are accessible via URL: "https://server.mydomain.com"
now we made a few major changes to our model and hence web services as a whole. This breaks the API interface for older users. Now we want to deploy the latest version on URL: "https://server.mydomain.com/v2" so that old users can still access the older version.
I searched around SO and other resources but i couldnt find a definite answer how to deploy new version without messing up the old version.
Anything in right direction will be helpful.
In one of the projects I was working on, we built in a versioning scheme on top of our Web API. We used this tutorial to get started. I would recommend starting there.
Sorry for the generic answer, if you post some more specifics I will make some updates.
I'd suggest to deploy separate cloud service and use "v2.server.mydomain.com"