I upgrade TCMS from 6.3 to 6.4. when executing command "docker exec -it kiwi_web /Kiwi/manage.py migrate", I got following message:
Operations to perform:
Apply all migrations: admin, attachments, auth, contenttypes, core, django_comments, kiwi_auth, linkreference, management, sessions, sites, testcases, testplans, testruns
Running migrations:
No migrations to apply.
Your models have changes that are not yet reflected in a migration, and so won't be applied.
Run 'manage.py makemigrations' to make new migrations, and then re-run 'manage.py migrate' to apply them.
Shall I handle this? Not see this before.
This is issue with one of our dependent libraries which is being solved as we speak:
https://github.com/treyhunner/django-simple-history/issues/512
If you are working on a new Kiwi TCMS installation running ./manage.py migrate for the first time is fine, trying to run it a second time will produce the error mentioned in original comment. This doesn't affect your DB at all.
If you are trying to upgrade from a previous version of Kiwi TCMS this will break the upgrades b/c migrate will refuse to execute. You can manually apply this change to your Docker image:
https://github.com/kiwitcms/Kiwi/pull/710/commits/61368aa254073bf6189bc3821f71d190c1a18501
or wait until we release the next version.
Related
I have been running Kiwi TCMS as a Docker container, the version running is 9.0.1. Now I have seen the latest version 10.0, so like to update it. Not sure this will not break the existing data.
So, I have taken the database and uploads files backup by following it,
https://kiwitcms.org/blog/atodorov/2018/07/30/how-to-backup-docker-volumes-for-kiwi-tcms/
But, how can I downgrade to an older version image, if the latest version does not work as expected or any problem comes? I found the docker tag concept and not sure how to apply it?
Can you confirm following will restore to an older version?
Restore the DB files and uploaded files that already taken backup.
Change the image in docker-compose file to an older one? Like my case, I could want to pull the version 9.0.1 image, so changing the image: kiwitcms/kiwi:9.0.1 works?
web:
container_name: kiwi_web
depends_on:
- db
restart: always
image: kiwitcms/kiwi:9.0.1
Or how should I tag version 9.0.1, and then restore the tagged version, in case of reverting the latest upgrade?
But, how can I downgrade to an older version image, if the latest version does not work as expected or any problem comes? I found the docker tag concept and not sure how to apply it?
The easiest way would be to destroy the instance you were not happy with, start a new one (with v9.0.1) from scratch and restore the files/DB from your backup. I am assuming you made the backup before the upgrade.
image: kiwitcms/kiwi:9.0.1 works?
In theory that would work but in practice it won't because Kiwi TCMS upstream doesn't ship version tagged container images. See https://kiwitcms.org/#subscriptions, lines Only latest releases vs. Versioned releases from kiwitcms/version.
Or how should I tag version 9.0.1
Depending on what you've already done or not done this could either be possible or not possible:
Execute docker images and if you see something like
kiwitcms/kiwi latest 9f23186803d5 8 weeks ago 736MB
kiwitcms/kiwi <no tag> <another image hash> ...
this means that latest points to v10 while the untagged image is your previous image, 9.0.1 in your case. You can then use docker tag command to tag it and make use of it inside docker-compose.yml file.
If you only see a kiwitcms/kiwi:latest image this means you have removed the previous one from your system. You don't have access to it. Your options are:
Rebuild that from source using the same git tag or
Purchase a subscription to be able to access the private kiwitcms/version repository if it is critical to restore back to the old version.
As a good practice you can follow these 2 advices:
Use the "restore-from-backup" technique or maybe "clone the docker image" so that you are upgrading and experimenting with a different Kiwi TCMS instance, not the main one that you use. If you are happy with the latest version then you can upgrade the main instance. Note here that by "clone the docker image" I mean make the running image/container files available on a different machine or possibly the same host machine but launch a secondary Kiwi TCMS instance + a secondary DB. ATM I'm not sure how exactly to do this but either docker itself or other Linux tools should be able to help here.
docker tag your local kiwitcms/kiwi images when you download/deploy/upgrade them so that you can have a reference to the version at this point in time. This will avoid losing the older image.
Extra tip: with docker tag you can also provide your own customized image names and possibly upload these images to your own docker repository for later access/backup or distributing them between multiple host systems.
I've been studying "Kubernetes Up and Running" by Hightower et al (first edition) Chapter 13 where they discussed creating a Reliable MySQL Singleton (Since I just discovered that there is a second edition, I guess I'll be buying it soon).
Using their MySQL reliable singleton example as a model, I've been looking for some sample YAML files to make a similar deployment with Microsoft SQL Server (Express) on Docker Desktop for Kubernetes.
Apparently I need YAML files to deploy
Persistent Volume
Volume claim (should this be NFS?)
SQL Server (Express edition) replica set (in spite of the fact that this is just a singleton).
I've tried this example but I'm confused because it does not contain a persistent volume & claim and it does not work. I get the error
Error: unable to recognize "sqlserver.yml": no matches for kind "Deployment" in version "apps/v1beta1"
Can someone please point me to some sample YAML files that are not Azure specific that will work on Docker Desktop Kubernetes for Windows 10? After debugging my application, I'll want to deploy this to Azure (AKS).
Wed Jul 15 2020 Update
I left out the "-n namespace" for the helm install command (possibly because I'm using Helm and you are using helm v2?).
That install command still did not work. Then I did a
helm repo add stable https://kubernetes-charts.storage.googleapis.com/
Now this command works:
helm install todo-app-database stable/mssql-linux
Progress!
When I do a "k get pods" I see that my todo-app-mssql-linux database is in the pending state. So I did a
kubectl get events
and I see
Warning FailedScheduling pod/todo-app-database-mssql-linux-8668d9b88c-lsh5l 0/1 nodes are available: 1 Insufficient memory.
I've been google searching for "Kubernetes insufficient memory" and can find no match.
I suspect this is a problem specific to "Docker Desktop Kubernetes".
When I look at the output for
helm -n ns-todolistdemo template todo-app-database stable/mssql-linux
I see the deployment is asking for 2Gi. (Interesting: when I use the template command, the "-n ns-todolistdemo" does not cause an error like it does with the install command).
So I do
kubectl describe deployment todo-app-database-mssql-linux >todo-app-database-mssql-linux.yaml
I edit the yaml file to change 2Gi to 1Gi.
kubectl apply -f todo-app-database-mssql-linux.yaml
I get this error:
error: error parsing todo-app-database-mssql-linux.yaml: error converting YAML to JSON: yaml: line 9: mapping values are not allowed in this context
Hmm... that did not work. I try delete:
kubectl delete deployment todo-app-database-mssql-linux
kubectl create -f todo-app-database-mssql-linux.yaml
I get this error:
error: error validating "todo-app-database-mssql-linux.yaml": error validating data: invalid object to validate; if you choose to ignore these errors, turn validation off with --validate=false
So I try apply:
kubectl apply -f todo-app-database-mssql-linux.yaml
Same error!
Shucks.... Is there a way to adjust the memory allocation for Docker Desktop?
Thank you
Siegfried
Short answer
https://github.com/helm/charts/blob/master/stable/mssql-linux/templates/pvc-master.yaml
Detailed Answer
Docker For Desktop comes already with a default StorageClass :
This storage class is responsible for auto-provisioning of PV whenever you create a PVC.
If you have a YAML definition of PVC (persistent volume claim), you just need to keep storageClass empty, so it will use the default.
k get storageclass
NAME PROVISIONER AGE
hostpath (default) docker.io/hostpath 11d
This is fair enough as Docker-For-Desktop Cluster is a one node cluster. So if your DB crashes and the cluster opens it again , it will not move to another node, because simply, you have a single node :)
Now should write the YAML of PVC from scratch ?
No , you don't need. Because Helm should be your best friend.
( I explained below Why you have to use Helm even without deep learning curve)
Fortunately, the community provides a chart called stable/mssql-linux..
Let's run it together :
helm -n <your-namespace> install todo-app-database stable/mssql-linux
# helm -n <namespace> install <release-name> <chart-name-from-community>
If you want to check the YAML (namely PVC) that Helm computed, you can run template instead of install
helm -n <your-namespace> template todo-app-database stable/mssql-linux
Why I give you the answer with Helm ?
Writing YAML from scratch lets reinventing the wheel while others do it.
The most efficient way is to reuse what community prepare for you.
However, you may ask: How can i reuse what others doing ?
That's why Helm comes.
Helm comes to be your installer of any application on top of kubernetes regardless how much YAML does your app require.
Install it now and hit the ground choco install kubernetes-helm
I am trying to migrate my Go app to runtime go112, but dev_appserver.py throw the following error:
RuntimeError: Unknown runtime 'go112'; supported runtimes are 'custom', 'go', 'go111', 'java', 'java7', 'java8', 'php55', 'php72', 'python', 'python-compat', 'python27', 'python37'.
Current Go version is 1.12.11
Edit: I used apt-get to install the SDK.
apt-get update && apt-get install google-cloud-sdk google-cloud-sdk-app-engine-python\
google-cloud-sdk-app-engine-python-extras\
google-cloud-sdk-app-engine-java\
google-cloud-sdk-app-engine-go\
google-cloud-sdk-datalab\
google-cloud-sdk-datastore-emulator\
google-cloud-sdk-pubsub-emulator\
google-cloud-sdk-cbt\
google-cloud-sdk-cloud-build-local\
google-cloud-sdk-bigtable-emulator\
kubectl -y
That way it seems I can't use gcloud components update and the packages are not up-to-date in the repos.
Now my questions is: Does google-cloud-sdk-app-engine-go support go runtime 1.12? If not, when will it support runtime 1.12?
Update: I installed cloud SDK and run gcloud components update successfully on another computer, dev_server.py still throw the same error. Does the local SDK actually support rumtime 1.12?
go112 runtime is not available on local dev_appserver.py. This has been discussed on the App Engine Go forum at
https://groups.google.com/forum/#!topic/google-appengine-go/kHxZ9zIb_QE
The expectation is that starting from go112 runtime, there is no "appengine" way of running the go server and works normally like any go server outside GAE. There are a few open issues like dispatching urls though.
It sounds like you gcloud SDK is an old version and not recognize "runtime: go112", please run this command in order to update your SDK.
gcloud components update
After the update you can be able to deploy an app engine service using GO 1.12 runtime, check the changes that you need to perform in you App.yaml in this link
How do I setup VisualSVN Server to trigger Teamcity to build a specific project after someone commits to it while obeying the set quiet period?
Right now I am using this in the post commit hook of visual svn server:
wget http://<user name>:<user password>#<server address>/httpAuth/action.html?add2Queue=<build type Id>
The problem with this is I need the build type ID to change depending on what project was committed to and the other problem is that it starts the build right away and ignores my set quiet period of 2 minutes.
Found the answer. Use the VCSupdate plugin for teamcity and use wget on thevcsupdate url for the vcs root.
When installing DNN 04.09.02 upgrade (from DNN 4.8.4) I receive System.IndexOutOfRangeException: PermanentRedirect error and cannot install the upgrade. How do I get around this so I can install the upgrade?
This thread might help you:
It looks like you have to update it manually... steps are described there.
Also check this thread, might be due to AD if AD is used.
I've re-posted the following from the thread provided by kitsune. Source
First try the following in your browser. Replace "www.yourdomain.com" with your domain:
http://www.yourdomain.com/install/install.aspx?mode=install
If that doesn't work (which it didn't for me) then try the following steps (copied from Chris on that thread).
To manually run the SQL portion of the upgrade you'll need to run each upgrade script between your version and 4.9.2. I upgraded from 4.9.0 to 4.9.2 so I performed the following:
On the web server open the directory: \Providers\DataProviders\SqlDataProvider
Determine which files need to be run. Basically, all of the versions after your old version. In my case I needed to run the files 04.09.00.SqlDataProvider, 04.09.01.SqlDataProvider and 04.09.02.SqlDataProvider.
Open the SQL files in a text editor and replace "{databaseOwner}" (usually with "dbo.") and "{objectQualifier}" (usually with "", but sometimes "DNN4" or some other object prefix)
Run those SQL files in version order using SQL Management Studio.
Assuming those scripts ran without an error then the site should be ready to use.