Univention Bugzilla – Bug 39206
systemUUID handling in Docker
Last modified: 2015-11-17 12:11:26 CET
If the UCS docker container is started by the App Center, the system uuid of the UCS host system is used.
(In reply to Stefan Gohmann from comment #0) > If the UCS docker container is started by the App Center, the system uuid of > the UCS host system is used. So what? - should a different UUID be used per container? - or is this not implemented yet (is -> should)? - why is this bad?
(In reply to Philipp Hahn from comment #1) > (In reply to Stefan Gohmann from comment #0) > > If the UCS docker container is started by the App Center, the system uuid of > > the UCS host system is used. > > So what? > - should a different UUID be used per container? > - or is this not implemented yet (is -> should)? I don't know the current state. It has to be checked. I've described the target state. > - why is this bad? We need to know the real number of UCS installations for various reasons. If every App installation in a docker container is counted, the number does not match the real UCS installation number. For example if all Apps are delivered as Docker container and I've installed seven Apps on my UCS, the old count handling would count eight different systems. On the other hand, if I install a UCS DC Master and a UCS DC Backup as Docker container, these installations should be counted as two systems.
(In reply to Stefan Gohmann from comment #2) > We need to know the real number of UCS installations for various reasons. If > every App installation in a docker container is counted, the number does not > match the real UCS installation number. For example if all Apps are > delivered as Docker container and I've installed seven Apps on my UCS, the > old count handling would count eight different systems. Maybe we should just use the identifier for the differentiation. I guess it will be a problem for the current count handling if we have two different systems with the same UUID and different UCS versions.
What about a more generalized solution that takes into account, that UCS is headed for the cloud: Identify * UCS as simple host * UCS as UVMM * UCS in VM * UCS in container and in each its role. Build it as a tree: customer | +-Vmware | | | +-UCS VM (backup) | | | +-UCS VM (slave) | | | | | +-UCS container (member) | | +-UCS container (slave) | | | +-UCS VM (backup) | +-UCS host (master) | +-UCS UVMM (slave) | +-UCS container (member) +-UCS VM (member) | +-UCS container (member) Encode all as b64(json) or scheme/lisp or similar so it can fit into a URL (or however this is usually transfered). This view will allow to understand better how UCS is used by cloud providers.
(In reply to Daniel Tröder from comment #4) > What about a more generalized solution that takes into account, that UCS is > headed for the cloud: Nice idea. I guess it will be hard to get all the information, for example to determine the hypervisor but it should be possible. Nevertheless, it is a little bit out of scope. The goal of this issue is to get reliable numbers about the UCS installation basis after the release of UCS 4.1. Fixed with r63640 UUID reporting: r63641 Changelog is not needed because the docker integration is new.
hypervisor detection: http://people.redhat.com/~rjones/virt-what/
I've added 80_docker/61_app_updater_identify to test the variable. Still marked as WIP, waiting for Bug #39413.
Ok, the UCR variable updater/identify gets set to "Docker App". The reporting filters out systems identifying as such.
UCS 4.1 has been released: https://docs.software-univention.de/release-notes-4.1-0-en.html https://docs.software-univention.de/release-notes-4.1-0-de.html If this error occurs again, please use "Clone This Bug".