cloudboltsoftware / cloudbolt-forge Goto Github PK

[root@cloudbolt tmp]# git clone https://github.com/Tintri/tintri-python-sdk.git
Initialized empty Git repository in /tmp/tintri-python-sdk/.git/
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 511 (delta 0), reused 0 (delta 0), pack-reused 510
Receiving objects: 100% (511/511), 1.10 MiB, done.
Resolving deltas: 100% (328/328), done.

[root@cloudbolt tmp]# cd tintri-python-sdk/
[root@cloudbolt tintri-python-sdk]# pip install Tintri_PySDK-1.0-py2-none-any.whl
Tintri_PySDK-1.0-py2-none-any.whl is not a supported wheel on this platform.
You are using pip version 19.0.3, however version 19.2.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

[root@cloudbolt tintri-python-sdk]# pip install --upgrade pip
Collecting pip
Downloading https://files.pythonhosted.org/packages/62/ca/94d32a6516ed197a491d17d46595ce58a83cbb2fca280414e57cd86b84dc/pip-19.2.1-py2.py3-none-any.whl (1.4MB)
100% |████████████████████████████████| 1.4MB 9.3MB/s
Installing collected packages: pip
Found existing installation: pip 19.0.3
Uninstalling pip-19.0.3:
Successfully uninstalled pip-19.0.3

Successfully installed pip-19.2.1
[root@cloudbolt tintri-python-sdk]# pip install Tintri_PySDK-1.0-py2-none-any.whl
ERROR: Tintri_PySDK-1.0-py2-none-any.whl is not a supported wheel on this platform.

Hi,

first of all, I am not quite sure if this is the right place to raise an issue with this topic.

We are setting up cloudbolt in our infrastructure and we got to know from you, that puppet environments are necessarily linked to VMware clusters.
This behavior is seen as a limitation in most real life situations (and I make this consideration based on my experience with Puppet in several organizations).
We may agree that it's better to split the production environment, but you should not force you customers to squash all their environment, because they don't have enough clusters.
This same problem arises with the test, uat, devel environments. I have never seen so many clusters per puppet environments, and it would really lack the necessary flexibility.

Possible solutions:

• linking environments to VMware folders (instead of clusters)

• behave like Foreman does (this is in my opinion the best option). With Foreman you can store the environment that the VM sends when puppet runs for the first time. Foreman will always re-use that environment (regardless of cluster and folder and avoiding that the environment can be changed on the client side). I guess that Foreman stores these information on Postgres, and you can do the same with the backend used with Cloudbolt.