newly installed clondmonkey 5.3.3 won't run

[Yiping Zhang]

Hi, there:

I just installed the latest cloudmonkey (version 5.3.3) with pip on a RHEL 6.7 
VM, but when I run it, it throws a stack trace:

# pip install cloudmonkey
DEPRECATION: Python 2.6 is no longer supported by the Python core team, please 
upgrade your Python. A future version of pip will drop support for Python 2.6
Collecting cloudmonkey
/usr/lib/python2.6/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:318:
 SNIMissingWarning: An HTTPS request has been made, but the SNI (Subject Name 
Indication) extension to TLS is not available on this platform. This may cause 
the server to present an incorrect TLS certificate, which can cause validation 
failures. You can upgrade to a newer version of Python to solve this. For more 
information, see 
https://urllib3.readthedocs.io/en/latest/security.html#snimissingwarning.
  SNIMissingWarning
/usr/lib/python2.6/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:122:
 InsecurePlatformWarning: A true SSLContext object is not available. This 
prevents urllib3 from configuring SSL appropriately and may cause certain SSL 
connections to fail. You can upgrade to a newer version of Python to solve 
this. For more information, see 
https://urllib3.readthedocs.io/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
  Using cached cloudmonkey-5.3.3.tar.gz
Requirement already satisfied: Pygments>=1.5 in 
/usr/lib/python2.6/site-packages (from cloudmonkey)
Requirement already satisfied: argcomplete in /usr/lib/python2.6/site-packages 
(from cloudmonkey)
Requirement already satisfied: dicttoxml in /usr/lib/python2.6/site-packages 
(from cloudmonkey)
Requirement already satisfied: prettytable>=0.6 in 
/usr/lib/python2.6/site-packages (from cloudmonkey)
Requirement already satisfied: requests in /usr/lib/python2.6/site-packages 
(from cloudmonkey)
Requirement already satisfied: requests-toolbelt in 
/usr/lib/python2.6/site-packages (from cloudmonkey)
Requirement already satisfied: chardet<3.1.0,>=3.0.2 in 
/usr/lib/python2.6/site-packages (from requests->cloudmonkey)
Requirement already satisfied: certifi>=2017.4.17 in 
/usr/lib/python2.6/site-packages (from requests->cloudmonkey)
Requirement already satisfied: urllib3<1.23,>=1.21.1 in 
/usr/lib/python2.6/site-packages (from requests->cloudmonkey)
Requirement already satisfied: idna<2.7,>=2.5 in 
/usr/lib/python2.6/site-packages (from requests->cloudmonkey)
Installing collected packages: cloudmonkey
  Running setup.py install for cloudmonkey ... done
Successfully installed cloudmonkey-5.3.3
#
#
# cloudmonkey
Traceback (most recent call last):
  File "/usr/bin/cloudmonkey", line 5, in 
from pkg_resources import load_entry_point
  File "/usr/lib/python2.6/site-packages/pkg_resources.py", line 2655, in 

working_set.require(__requires__)
  File "/usr/lib/python2.6/site-packages/pkg_resources.py", line 648, in require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.6/site-packages/pkg_resources.py", line 546, in resolve
raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: requests-toolbelt
#

I have verified that requests-toolbelt (0.8.0) is installed.   How do I fix 
this?

Thanks

Yiping

Re: why instance must be stopped in order to update its affinity groups?

[Yiping Zhang]

Paul, Marc:

Thanks for clarifying.

As cloud admin/operator, I do care about the instance’s placement and that is 
why I’d like to apply affinity groups to all instances whenever possible.

It sounds like there is no fundamental technical reasons that a running 
instance’s affinity group membership can’t be updated.  Then why not allow this 
operation?  The logic could be as simple as follows:

If current host placement is compatible with new affinity group’s placement:
then 
   let the update succeed
else
   if auto-migration is true && there is a suitable host to migrate to
   then
  live migrate instance to new host and update instance’s affinity group 
membership
   else
  raise an exception
   end
end

Here “auto-migrate” is controlled by a new global setting parameter, and it is 
for migrating VM to another host in the same cluster. IOW, it does not involve 
storage migration.  If for some technical reasons that live migration can’t be 
done here, then that inner “if ... else ... end” block can be reduced to just 
“raise an exception”.

Is this reasonable?

Yiping

On 1/11/18, 12:19 AM, "Marc-Aurèle Brothier"  wrote:

Hi Yiping,

To add to Paul's comment, you also need to understand the goal of the
anti-affinity groups. If they don't care, you should simply block the
command so that your users don't use it (you should list the
createAffinityGroup command as a root admin call in the commands.properties
file by changing it's flag value).
The goal is to spread a group of VMs, a cluster of a service, so that in
case of a hardware failure on one hyperisor, the cluster can be sure that
only 1 of its instances will go down and the srvice can keep running.

On Thu, Jan 11, 2018 at 9:01 AM, Paul Angus 
wrote:

> Hi Yiping,
>
> Anti-affinity groups deal with the placement of VMs when they are started,
> but doesn't/can't 'move' running VMs (it isn't like vSphere DRS).  If you
> change a VM's anti-affinity group, it's current placement on a host may
> suddenly become invalid.  As the Anti-Affinity group code isn't designed 
to
> move VMs, the safest option is to ensure that the VM is stopped when its
> group is changed so that when it is started again, CloudStack can then
> properly decide where it can/should go.
>
>
>
> Kind regards,
>
> Paul Angus
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>
> -Original Message-
> From: Yiping Zhang [mailto:yzh...@marketo.com]
> Sent: 10 January 2018 19:51
> To: users@cloudstack.apache.org
> Subject: why instance must be stopped in order to update its affinity
> groups?
>
> Hi, List:
>
> Can someone please explain why a VM instance must be in stopped state when
> updating its affinity group memberships?   This requirement is in “Feature
> assumptions” section of the original 4.2 design document (
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/
> FS+-+Affinity-Anti-affinity+groups).
>
> My users either don’t understand or don’t care about affinity groups and I
> see a large number of instances with sub-optimal host placement (from
> anti-host affinity group point of view).  But it is too much trouble for 
me
> to coordinate with so many users to shut them down in order to fix their
> host placement.  What bad things would happen if a running instance’s
> affinity group is changed?
>
> Thanks,
>
> Yiping
>
>

Re: [PROPOSE] EOL for supported OSes & Hypervisors

[Will Stevens]

I like this initiative.  I think this would be valuable to set an
expectation around supportability.

Cheers,

*Will Stevens*
CTO



On Thu, Jan 11, 2018 at 12:11 PM, Paul Angus 
wrote:

> I've cross-posted this as it ultimately effects users more than developers.
>
> I've created a wiki page with the EOL dates from the respective 'vendors'
> of our main supported hypervisors and mgmt. server OSes.
> I've taken End Of Life to be the end of 'mainstream' support i.e. the
> point at which updates to packages will no longer be available.  And part
> of the discussion should be whether this EOL date should be moved out to
> consider end of security patching instead.
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/
> WIP+-+UNOFFICIAL+-+PROPOSAL+-+EOL+Dates
>
> I would like to propose, that as part of the release notes for the
> forthcoming 4.11 release and as a general announcement, that we declare
> that:
>
>
>   *   For any OSes/Hypervisors that are already EOL - we will no longer
> test/support them from the first release after June 2018 (6 months from
> now). And they will be removed from codebase (mainly the database) in the
> first release after Sept 2018 (9 months from now).
>   *   We set End Of Support dates and Removal from Code dates for the
> remaining OSes/Hypervisors.  I propose that End Of Support should be the
> first release after EOL from the vendor, with code removal taking place in
> the first release which occurs after 6 months from 'vendor' EOL date.
>
> Thoughts please
>
>
> Kind regards,
>
> Paul Angus
>
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>

[PROPOSE] EOL for supported OSes & Hypervisors

[Paul Angus]

I've cross-posted this as it ultimately effects users more than developers.

I've created a wiki page with the EOL dates from the respective 'vendors' of 
our main supported hypervisors and mgmt. server OSes.
I've taken End Of Life to be the end of 'mainstream' support i.e. the point at 
which updates to packages will no longer be available.  And part of the 
discussion should be whether this EOL date should be moved out to consider end 
of security patching instead.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/WIP+-+UNOFFICIAL+-+PROPOSAL+-+EOL+Dates

I would like to propose, that as part of the release notes for the forthcoming 
4.11 release and as a general announcement, that we declare that:


  *   For any OSes/Hypervisors that are already EOL - we will no longer 
test/support them from the first release after June 2018 (6 months from now). 
And they will be removed from codebase (mainly the database) in the first 
release after Sept 2018 (9 months from now).
  *   We set End Of Support dates and Removal from Code dates for the remaining 
OSes/Hypervisors.  I propose that End Of Support should be the first release 
after EOL from the vendor, with code removal taking place in the first release 
which occurs after 6 months from 'vendor' EOL date.

Thoughts please


Kind regards,

Paul Angus


paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Re: why instance must be stopped in order to update its affinity groups?

[Marc-Aurèle Brothier]

Hi Yiping,

To add to Paul's comment, you also need to understand the goal of the
anti-affinity groups. If they don't care, you should simply block the
command so that your users don't use it (you should list the
createAffinityGroup command as a root admin call in the commands.properties
file by changing it's flag value).
The goal is to spread a group of VMs, a cluster of a service, so that in
case of a hardware failure on one hyperisor, the cluster can be sure that
only 1 of its instances will go down and the srvice can keep running.

On Thu, Jan 11, 2018 at 9:01 AM, Paul Angus 
wrote:

> Hi Yiping,
>
> Anti-affinity groups deal with the placement of VMs when they are started,
> but doesn't/can't 'move' running VMs (it isn't like vSphere DRS).  If you
> change a VM's anti-affinity group, it's current placement on a host may
> suddenly become invalid.  As the Anti-Affinity group code isn't designed to
> move VMs, the safest option is to ensure that the VM is stopped when its
> group is changed so that when it is started again, CloudStack can then
> properly decide where it can/should go.
>
>
>
> Kind regards,
>
> Paul Angus
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>
> -Original Message-
> From: Yiping Zhang [mailto:yzh...@marketo.com]
> Sent: 10 January 2018 19:51
> To: users@cloudstack.apache.org
> Subject: why instance must be stopped in order to update its affinity
> groups?
>
> Hi, List:
>
> Can someone please explain why a VM instance must be in stopped state when
> updating its affinity group memberships?   This requirement is in “Feature
> assumptions” section of the original 4.2 design document (
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/
> FS+-+Affinity-Anti-affinity+groups).
>
> My users either don’t understand or don’t care about affinity groups and I
> see a large number of instances with sub-optimal host placement (from
> anti-host affinity group point of view).  But it is too much trouble for me
> to coordinate with so many users to shut them down in order to fix their
> host placement.  What bad things would happen if a running instance’s
> affinity group is changed?
>
> Thanks,
>
> Yiping
>
>

RE: why instance must be stopped in order to update its affinity groups?

[Paul Angus]

Hi Yiping,

Anti-affinity groups deal with the placement of VMs when they are started, but 
doesn't/can't 'move' running VMs (it isn't like vSphere DRS).  If you change a 
VM's anti-affinity group, it's current placement on a host may suddenly become 
invalid.  As the Anti-Affinity group code isn't designed to move VMs, the 
safest option is to ensure that the VM is stopped when its group is changed so 
that when it is started again, CloudStack can then properly decide where it 
can/should go. 



Kind regards,

Paul Angus

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Yiping Zhang [mailto:yzh...@marketo.com] 
Sent: 10 January 2018 19:51
To: users@cloudstack.apache.org
Subject: why instance must be stopped in order to update its affinity groups?

Hi, List:

Can someone please explain why a VM instance must be in stopped state when 
updating its affinity group memberships?   This requirement is in “Feature 
assumptions” section of the original 4.2 design document 
(https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups).

My users either don’t understand or don’t care about affinity groups and I see 
a large number of instances with sub-optimal host placement (from anti-host 
affinity group point of view).  But it is too much trouble for me to coordinate 
with so many users to shut them down in order to fix their host placement.  
What bad things would happen if a running instance’s affinity group is changed?

Thanks,

Yiping