Re: New L2 nework types are not shared

[Boris Stoyanov]

Hi Jean-Francois, I don’t know if you’re following dev@ list, there’s an open 
thread for voting on release candidates. If you reply to that thread with your 
findings it’ll be more visible to devs and release management.

Bobby. 


boris.stoya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

> On 23 Jan 2018, at 16:23, Jean-Francois Nadeau  wrote:
> 
> Thank you both Boris and Nux!
> 
> I'll keep an eye 4.11.1.   If I may get your attention on another issue
> that blocks me from further testing on 4.11, I filled CLOUDSTACK-10239 :-)
> 
> best regards,
> 
> Jean-Francois
> 
> 
> 
> 
> 
> 
> On Tue, Jan 23, 2018 at 8:55 AM, Boris Stoyanov <
> boris.stoya...@shapeblue.com> wrote:
> 
>> Thanks for bringing this up Jean-Francois,
>> One of our devs has addressed this and with the following PR it’s now
>> fixed. It turned out a constraint was violated when deploying a VM in a
>> project. This will likely get merged in 4.11.1.0
>> https://github.com/apache/cloudstack/pull/2420
>> 
>> Please let keep us posted if you find any further issues.
>> 
>> Regards,
>> Boris.
>> 
>> On 19 Jan 2018, at 17:57, Nux! >
>> wrote:
>> 
>> Hi,
>> 
>> Might be worth sending this to dev@ as well, especially now that we are
>> doing testing for 4.11.
>> 
>> HTH
>> 
>> --
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
>> www.nux.ro
>> 
>> 
>> boris.stoya...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
>> 
>> 
>> 
>> - Original Message -
>> From: "Jean-Francois Nadeau" 
>> To: "users" 
>> Sent: Wednesday, 17 January, 2018 21:09:19
>> Subject: New L2 nework types are not shared
>> 
>> Hi all,
>> 
>> I'm testing 4.11-rc1 and the new L2 network type feature as shown at
>> http://www.shapeblue.com/layer-2-networks-in-cloudstack/
>> 
>> I want to use this as a replacement to a shared network offering with no
>> DHCP which works to support an external DHCP server but still required to
>> fill some CIDR information.
>> 
>> I thought the intent was that L2 network type was to replace the previous
>> approach when required to integrate an existing network.
>> 
>> If I attempt to provision a VM in a project as the root admin using the L2
>> network I get denied... apparently because they are not shared and I can't
>> make them public.
>> 
>> ('HTTP 531 response from CloudStack', , {u'errorcode': 531,
>> u'uuidList': [], u'cserrorcode': 4365, u'errortext': u'Unable to use
>> network with id= 7712102b-bbdf-4c54-bdbf-9fddfa16de46, permission
>> denied'})
>> 
>> Provisioning in the root project works just fine  but really I want to
>> use L2 networks in user projects even if only the admin can do so.
>> 
>> Thoughts ?
>> 
>> 

RE: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)

[Paul Angus]

Hey Nux,

There is quite a bit of tuning you can do, to speed or slow CloudStack's 
decision making, but we need to be sure that when we lose contact with a host 
agent, that the VMs themselves really are dead.  By default host-ha is set to 
be super sure.

There are various timeouts which can be configured to decide how long to wait 
for a host to restart before deciding that it is not going to start as well as 
how many times we should check for disk activity from the resident VMs of a 
suspect host.

The parameters are detailed here.
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Host+HA

Honestly, the aim of Host HA was to fix the particular issue that you are 
describing as we can't remember a time when it did work reliably.



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


-Original Message-
From: Nux! [mailto:n...@li.nux.ro] 
Sent: 23 January 2018 19:08
To: users 
Cc: dev 
Subject: Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)

Hi Paul,

To be honest I do not remember when I last saw this, as I have not been testing 
ACS in 2017.
You'd kill a HV, the VMs would pop up on another after a few minutes.

Even with Host HA, the VMs remain down until the hypervisor is back up, 
restarted by OOBM - however if that HV has suffered a HW fault and needs to be 
removed, then those VM will be down for a long time ...

Unless I got things quite wrong, (VM) HA - one of the big selling points of ACS 
- is essentially broken?

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Paul Angus" 
> To: "users" , "dev" 
> 
> Sent: Tuesday, 23 January, 2018 16:02:54
> Subject: RE: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)

> Hi Nux,
> 
> When have you seen the VMs on KVM behaving in the manner which you are 
> expecting?  I recall it didn’t work that way in the mid 4.5 versions 
> (we found out the hard way in front of a customer) and it doesn't 
> behave the way you are expecting 4.9 - I've just tested it.
> 
> You need host-ha enabled to get reliable HA in the event of a host 
> crash, that is why we developed the host ha feature.
> 
> Kind regards,
> 
> Paul Angus
> 
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
>  
> 
> 
> 
> -Original Message-
> From: Nux! [mailto:n...@li.nux.ro]
> Sent: 23 January 2018 15:06
> To: dev 
> Cc: users 
> Subject: Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)
> 
> Rohit,
> 
> I'll also have to insist with the VM HA issue.
> https://issues.apache.org/jira/browse/CLOUDSTACK-10246
> 
> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
>> From: "Rohit Yadav" 
>> To: "dev" , "users"
>> 
>> Sent: Tuesday, 23 January, 2018 14:28:34
>> Subject: Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)
> 
>> All,
>> 
>> 
>> Given we've outstanding blockers and PRs in review/testing, I'll cut
>> RC2 only after we manage to get them reviewed, tested and merged.
>> 
>> 
>> The outstanding PRs considered for RC2 are:
>> 
>> https://github.com/apache/cloudstack/pull/2418 (Properly parse rules 
>> for security groups)
>> 
>> https://github.com/apache/cloudstack/pull/2419 (Password server 
>> issue)
>> 
>> 
>> In addition we've following issues to receive fixes:
>> 
>> - VR - DHCP/dnsmasq leases issue (reported by Ozhan)
>> 
>> - Dynamic roles upgrade fixes:
>> https://issues.apache.org/jira/browse/CLOUDSTACK-10249
>> 
>> 
>> Please share any other issues you've found, or I've missed. Thanks, 
>> and continue testing RC1.
>> 
>> 
>> - Rohit
>> 
>> 
>> 
>> 
>> 
>> 
>> From: Rohit Yadav 
>> Sent: Monday, January 22, 2018 11:18:27 AM
>> To: Paul Angus; users@cloudstack.apache.org; 
>> d...@cloudstack.apache.org
>> Subject: Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)
>> 
>> The same issue applies to any 4.9, 4.10 release. In case of 4.9, we 
>> had discussed this as a doc bug and so it must be documented part of 
>> the 4.11 release notes as well.
>> 
>> 
>> There are two ways admin can migrate to dynamic roles post-upgrade:
>> 
>> 
>>  1.  Enable dynamic.apichecker.enabled to true which will use the 
>> default api  mapping of rules from 4.8 commands.properties and 
>> automatic annotation based  and (db-backed) dynamic rules from 4.9+.
>> Or,
>> 
>>  2.  The migration script is only useful where admins were not using 
>> the default  api rule mappings and they strictly want to 
>> check/migrate each API. This  approach requires admins to go through 
>> new APIs and fix 

Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)

[Nux!]

Hi Paul,

To be honest I do not remember when I last saw this, as I have not been testing 
ACS in 2017.
You'd kill a HV, the VMs would pop up on another after a few minutes.

Even with Host HA, the VMs remain down until the hypervisor is back up, 
restarted by OOBM - however if that HV has suffered a HW fault and needs to be 
removed, then those VM will be down for a long time ...

Unless I got things quite wrong, (VM) HA - one of the big selling points of ACS 
- is essentially broken?

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Paul Angus" 
> To: "users" , "dev" 
> Sent: Tuesday, 23 January, 2018 16:02:54
> Subject: RE: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)

> Hi Nux,
> 
> When have you seen the VMs on KVM behaving in the manner which you are
> expecting?  I recall it didn’t work that way in the mid 4.5 versions (we found
> out the hard way in front of a customer) and it doesn't behave the way you are
> expecting 4.9 - I've just tested it.
> 
> You need host-ha enabled to get reliable HA in the event of a host crash, that
> is why we developed the host ha feature.
> 
> Kind regards,
> 
> Paul Angus
> 
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>  
> 
> 
> 
> -Original Message-
> From: Nux! [mailto:n...@li.nux.ro]
> Sent: 23 January 2018 15:06
> To: dev 
> Cc: users 
> Subject: Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)
> 
> Rohit,
> 
> I'll also have to insist with the VM HA issue.
> https://issues.apache.org/jira/browse/CLOUDSTACK-10246
> 
> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
>> From: "Rohit Yadav" 
>> To: "dev" , "users"
>> 
>> Sent: Tuesday, 23 January, 2018 14:28:34
>> Subject: Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)
> 
>> All,
>> 
>> 
>> Given we've outstanding blockers and PRs in review/testing, I'll cut
>> RC2 only after we manage to get them reviewed, tested and merged.
>> 
>> 
>> The outstanding PRs considered for RC2 are:
>> 
>> https://github.com/apache/cloudstack/pull/2418 (Properly parse rules
>> for security groups)
>> 
>> https://github.com/apache/cloudstack/pull/2419 (Password server issue)
>> 
>> 
>> In addition we've following issues to receive fixes:
>> 
>> - VR - DHCP/dnsmasq leases issue (reported by Ozhan)
>> 
>> - Dynamic roles upgrade fixes:
>> https://issues.apache.org/jira/browse/CLOUDSTACK-10249
>> 
>> 
>> Please share any other issues you've found, or I've missed. Thanks,
>> and continue testing RC1.
>> 
>> 
>> - Rohit
>> 
>> 
>> 
>> 
>> 
>> 
>> From: Rohit Yadav 
>> Sent: Monday, January 22, 2018 11:18:27 AM
>> To: Paul Angus; users@cloudstack.apache.org; d...@cloudstack.apache.org
>> Subject: Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)
>> 
>> The same issue applies to any 4.9, 4.10 release. In case of 4.9, we
>> had discussed this as a doc bug and so it must be documented part of
>> the 4.11 release notes as well.
>> 
>> 
>> There are two ways admin can migrate to dynamic roles post-upgrade:
>> 
>> 
>>  1.  Enable dynamic.apichecker.enabled to true which will use the
>> default api  mapping of rules from 4.8 commands.properties and
>> automatic annotation based  and (db-backed) dynamic rules from 4.9+.
>> Or,
>> 
>>  2.  The migration script is only useful where admins were not using
>> the default  api rule mappings and they strictly want to check/migrate
>> each API. This  approach requires admins to go through new APIs and
>> fix commands.properties  before running the migration scriopt (we've
>> been sharing the new/change API  list in release notes, for example:
>>  
>> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.9.3.0/api-changes.html#new-api-commands).
>>  (for reference, doc:
>>  
>> http://docs.cloudstack.apache.org/projects/cloudstack-administration/e
>> n/latest/accounts.html#using-dynamic-roles)
>> 
>> 
>> Unlike the dynamic API checker, the static checker does not even allow
>> the root API to access all the APIs which is why post upgrade, if the
>> UI calls any API that is not allowed for the root admin (in this case
>> the quotaIsEnabled API) the UI will logout the user on API unauthorized 
>> failure
>> which is what happened.
>> 
>> 
>> So, we can discuss two fixes:
>> 
>> - Like dynamic checker, let the static checker allow all APIs only to
>> the root admin (id=1) (I would not prefer to change the legacy
>> behaviour though)
>> 
>> - During upgrade, if commands.properties is missing we set the global
>> setting to true, i.e. switch to dynamic roles (which would happen if
>> 

RE: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)

[Paul Angus]

Hi Nux,

When have you seen the VMs on KVM behaving in the manner which you are 
expecting?  I recall it didn’t work that way in the mid 4.5 versions (we found 
out the hard way in front of a customer) and it doesn't behave the way you are 
expecting 4.9 - I've just tested it.

You need host-ha enabled to get reliable HA in the event of a host crash, that 
is why we developed the host ha feature.

Kind regards,

Paul Angus

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


-Original Message-
From: Nux! [mailto:n...@li.nux.ro] 
Sent: 23 January 2018 15:06
To: dev 
Cc: users 
Subject: Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)

Rohit,

I'll also have to insist with the VM HA issue.
https://issues.apache.org/jira/browse/CLOUDSTACK-10246

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Rohit Yadav" 
> To: "dev" , "users" 
> 
> Sent: Tuesday, 23 January, 2018 14:28:34
> Subject: Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)

> All,
> 
> 
> Given we've outstanding blockers and PRs in review/testing, I'll cut 
> RC2 only after we manage to get them reviewed, tested and merged.
> 
> 
> The outstanding PRs considered for RC2 are:
> 
> https://github.com/apache/cloudstack/pull/2418 (Properly parse rules 
> for security groups)
> 
> https://github.com/apache/cloudstack/pull/2419 (Password server issue)
> 
> 
> In addition we've following issues to receive fixes:
> 
> - VR - DHCP/dnsmasq leases issue (reported by Ozhan)
> 
> - Dynamic roles upgrade fixes:
> https://issues.apache.org/jira/browse/CLOUDSTACK-10249
> 
> 
> Please share any other issues you've found, or I've missed. Thanks, 
> and continue testing RC1.
> 
> 
> - Rohit
> 
> 
> 
> 
> 
> 
> From: Rohit Yadav 
> Sent: Monday, January 22, 2018 11:18:27 AM
> To: Paul Angus; users@cloudstack.apache.org; d...@cloudstack.apache.org
> Subject: Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)
> 
> The same issue applies to any 4.9, 4.10 release. In case of 4.9, we 
> had discussed this as a doc bug and so it must be documented part of 
> the 4.11 release notes as well.
> 
> 
> There are two ways admin can migrate to dynamic roles post-upgrade:
> 
> 
>  1.  Enable dynamic.apichecker.enabled to true which will use the 
> default api  mapping of rules from 4.8 commands.properties and 
> automatic annotation based  and (db-backed) dynamic rules from 4.9+. 
> Or,
> 
>  2.  The migration script is only useful where admins were not using 
> the default  api rule mappings and they strictly want to check/migrate 
> each API. This  approach requires admins to go through new APIs and 
> fix commands.properties  before running the migration scriopt (we've 
> been sharing the new/change API  list in release notes, for example:
>  
> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.9.3.0/api-changes.html#new-api-commands).
>  (for reference, doc:
>  
> http://docs.cloudstack.apache.org/projects/cloudstack-administration/e
> n/latest/accounts.html#using-dynamic-roles)
> 
> 
> Unlike the dynamic API checker, the static checker does not even allow 
> the root API to access all the APIs which is why post upgrade, if the 
> UI calls any API that is not allowed for the root admin (in this case 
> the quotaIsEnabled API) the UI will logout the user on API unauthorized 
> failure which is what happened.
> 
> 
> So, we can discuss two fixes:
> 
> - Like dynamic checker, let the static checker allow all APIs only to 
> the root admin (id=1) (I would not prefer to change the legacy 
> behaviour though)
> 
> - During upgrade, if commands.properties is missing we set the global 
> setting to true, i.e. switch to dynamic roles (which would happen if 
> someone tries to upgrade from 4.5->4.11 using a new mgmt server if 
> they fail to copy the commands.properties file from /usr/share or /etc paths).
> 
> 
> Thoughts?
> 
> 
> - Rohit
> 
> 
> 
> 
> 
> 
> 
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
> 
> 
> 
> 
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
>  
> 
> 
> From: Paul Angus
> Sent: Monday, January 22, 2018 9:24:25 AM
> To: users@cloudstack.apache.org
> Cc: Rohit Yadav; d...@cloudstack.apache.org; Daan Hoogland
> Subject: RE: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)
> 
> If I've understood the issue correctly, "not being able to log in if upgrading
> from 4.5" is a blocker in my book.   I don't think that it should be the duty
> of the Admin, to fix our oversights.  Migration to the 

Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)

[Nux!]

Rohit,

I'll also have to insist with the VM HA issue.
https://issues.apache.org/jira/browse/CLOUDSTACK-10246

Lucian

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Rohit Yadav" 
> To: "dev" , "users" 
> Sent: Tuesday, 23 January, 2018 14:28:34
> Subject: Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)

> All,
> 
> 
> Given we've outstanding blockers and PRs in review/testing, I'll cut RC2 only
> after we manage to get them reviewed, tested and merged.
> 
> 
> The outstanding PRs considered for RC2 are:
> 
> https://github.com/apache/cloudstack/pull/2418 (Properly parse rules for
> security groups)
> 
> https://github.com/apache/cloudstack/pull/2419 (Password server issue)
> 
> 
> In addition we've following issues to receive fixes:
> 
> - VR - DHCP/dnsmasq leases issue (reported by Ozhan)
> 
> - Dynamic roles upgrade fixes:
> https://issues.apache.org/jira/browse/CLOUDSTACK-10249
> 
> 
> Please share any other issues you've found, or I've missed. Thanks, and 
> continue
> testing RC1.
> 
> 
> - Rohit
> 
> 
> 
> 
> 
> 
> From: Rohit Yadav 
> Sent: Monday, January 22, 2018 11:18:27 AM
> To: Paul Angus; users@cloudstack.apache.org; d...@cloudstack.apache.org
> Subject: Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)
> 
> The same issue applies to any 4.9, 4.10 release. In case of 4.9, we had
> discussed this as a doc bug and so it must be documented part of the 4.11
> release notes as well.
> 
> 
> There are two ways admin can migrate to dynamic roles post-upgrade:
> 
> 
>  1.  Enable dynamic.apichecker.enabled to true which will use the default api
>  mapping of rules from 4.8 commands.properties and automatic annotation based
>  and (db-backed) dynamic rules from 4.9+. Or,
> 
>  2.  The migration script is only useful where admins were not using the 
> default
>  api rule mappings and they strictly want to check/migrate each API. This
>  approach requires admins to go through new APIs and fix commands.properties
>  before running the migration scriopt (we've been sharing the new/change API
>  list in release notes, for example:
>  
> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.9.3.0/api-changes.html#new-api-commands).
>  (for reference, doc:
>  
> http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/accounts.html#using-dynamic-roles)
> 
> 
> Unlike the dynamic API checker, the static checker does not even allow the 
> root
> API to access all the APIs which is why post upgrade, if the UI calls any API
> that is not allowed for the root admin (in this case the quotaIsEnabled API)
> the UI will logout the user on API unauthorized failure which is what 
> happened.
> 
> 
> So, we can discuss two fixes:
> 
> - Like dynamic checker, let the static checker allow all APIs only to the root
> admin (id=1) (I would not prefer to change the legacy behaviour though)
> 
> - During upgrade, if commands.properties is missing we set the global setting 
> to
> true, i.e. switch to dynamic roles (which would happen if someone tries to
> upgrade from 4.5->4.11 using a new mgmt server if they fail to copy the
> commands.properties file from /usr/share or /etc paths).
> 
> 
> Thoughts?
> 
> 
> - Rohit
> 
> 
> 
> 
> 
> 
> 
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 
> 
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>  
> 
> 
> From: Paul Angus
> Sent: Monday, January 22, 2018 9:24:25 AM
> To: users@cloudstack.apache.org
> Cc: Rohit Yadav; d...@cloudstack.apache.org; Daan Hoogland
> Subject: RE: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)
> 
> If I've understood the issue correctly, "not being able to log in if upgrading
> from 4.5" is a blocker in my book.   I don't think that it should be the duty
> of the Admin, to fix our oversights.  Migration to the use of dynamic roles is
> also broken as the command will be missing from commands.properties in the
> first place, so the 'migrated' commands will not be complete.
> 
> As there will need to be an RC2, IMO this upgrade issue should be fixed as 
> part
> of it.
> 
> 
> 
> Kind regards,
> 
> Paul Angus
> 
> 
> VP Technology
> paul.an...@shapeblue.com
> www.shapeblue.com
> 
> 
> 
> 
> -Original Message-
> From: Boris Stoyanov [mailto:boris.stoya...@shapeblue.com]
> Sent: 22 January 2018 07:31
> To: users@cloudstack.apache.org
> Cc: Rohit Yadav ; d...@cloudstack.apache.org; Daan
> Hoogland 
> Subject: Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)
> 
> Hi Paul,
> Migration script 

Re: [DISCUSS] Freezing master for 4.11

[Rohit Yadav]

Kristian,


4.11+ has migrated to embedded Jetty. Can you share which environment you've 
upgraded your environment from, i.e. Java version, ACS version etc. The log 
you're seeing is not a failure.


If you wait for some time, the management server should run. Tail for the 
management server logs for details, or journalctl -f.


- Rohit






From: Kristian Liivak 
Sent: Monday, January 22, 2018 6:59:11 PM
To: users
Subject: Re: [DISCUSS] Freezing master for 4.11

Hello,

I just installed RC1 for testing from centos packages but there is problem 
starting it in centos7 enviroment
Clodustack won´t start and i can see in management log
[o.e.j.w.StandardDescriptorProcessor] (main:null) (logid:) NO JSP Support for 
/client, did not find org.eclipse.jetty.jsp.JettyJspServlet

Can anyone suggest a fix/workaround ?


Lugupidamisega / Regards

Kristian Liivak
CTO

WaveCom As
Endla 16, 10142 Tallinn
Estonia
Tel: +3726850001
Gsm: +37256850001
E-mail: k...@wavecom.ee
Skype: kristian.liivak
http://www.wavecom.ee
http://www.facebook.com/wavecom.ee


rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

- Original Message -
From: "rohit yadav" 
To: "users" 
Cc: "dev" 
Sent: Friday, January 19, 2018 11:13:49 AM
Subject: Re: [DISCUSS] Freezing master for 4.11

Hi Kristian,


I looked at https://issues.apache.org/jira/browse/CLOUDSTACK-10141


If the new VM is deployed with a password and/or ssh-key enabled VM template, 
then VR should get new password and the user/account specific ssh-public key so 
the mentioned issues don't affect such new VMs. However, I agree VMs may have 
access to old VM's password (if not consumed) and ssh-public key if are not 
password/ssh-public-key enabled - but they may be useless/stale information and 
I feel they are more of a GC issue than a security issue.


Are you able to reproduce a case when a new VM deployed using old VM's IP and 
with a password and/or public-key enabled template is getting the password 
and/or ssh-public-key from old VM (and the old user/account)? I think if yes, 
then it's a security issue.


Thoughts, comments?


- Rohit






From: Kristian Liivak 
Sent: Monday, January 15, 2018 4:19:03 PM
To: users
Cc: d...@cloudstack.apache.org
Subject: Re: [DISCUSS] Freezing master for 4.11

Hello,

I have created issue in jira 2 month ago.
https://issues.apache.org/jira/browse/CLOUDSTACK-10141

In version 4.10 VR password and ssh key distribution don´t work on instance 
creation.
When instance is allreay excisting reset function is operational.

Also there is major security hole. When instance is destroyd and expunged and 
new instance is created with old IP all old data is unaffected in VR
New instance will get then old root password and  ssh key if they were present 
in VR

In my knowledege cloudstack older versions are not affected.

Lugupidamisega / Regards

Kristian Liivak

CTO

WaveCom As
Endla 16, 10142 Tallinn
Estonia
Tel: +3726850001
Gsm: +37256850001
E-mail: k...@wavecom.ee
Skype: kristian.liivak
http://www.wavecom.ee
http://www.facebook.com/wavecom.ee


rohit.ya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue



- Original Message -
From: "Rohit Yadav" 
To: d...@cloudstack.apache.org, "users" 
Sent: Sunday, January 14, 2018 8:41:15 PM
Subject: Re: [DISCUSS] Freezing master for 4.11

All,


To give you update, all feature PRs have been reviewed, tested and merged 
towards the 4.11.0.0. I'll engage with Mike and others for any post-merge 
regressions (smoketest to be kicked shortly).


I see an outstanding PR that may be a critical/blocker PR, please advise and 
also review:

https://github.com/apache/cloudstack/pull/2402


If anyone has any blocker to report, please do so. Thanks.


I'll cut RC1 as planned by EOD today (Mon/15 Jan 2018).


- Rohit






From: Tutkowski, Mike 
Sent: Saturday, January 13, 2018 3:23:40 AM
To: d...@cloudstack.apache.org
Subject: Re: [DISCUSS] Freezing master for 4.11

I’m investigating these now. I have found and fixed two of them so far.


rohit.ya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue



> On Jan 12, 2018, at 2:49 PM, Rohit Yadav  wrote:
>
> Thanks Rafael and Daan.
>
>
>> From: Rafael Weingärtner 
>>
>> I believe there is no problem in merging Wido’s and Mike’s PRs, they have
>> been extensively discussed and improved (specially Mike’s one).
>
> Thanks, Mike's 

Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)

[Rohit Yadav]

All,


Given we've outstanding blockers and PRs in review/testing, I'll cut RC2 only 
after we manage to get them reviewed, tested and merged.


The outstanding PRs considered for RC2 are:

https://github.com/apache/cloudstack/pull/2418 (Properly parse rules for 
security groups)

https://github.com/apache/cloudstack/pull/2419 (Password server issue)


In addition we've following issues to receive fixes:

- VR - DHCP/dnsmasq leases issue (reported by Ozhan)

- Dynamic roles upgrade fixes: 
https://issues.apache.org/jira/browse/CLOUDSTACK-10249


Please share any other issues you've found, or I've missed. Thanks, and 
continue testing RC1.


- Rohit






From: Rohit Yadav 
Sent: Monday, January 22, 2018 11:18:27 AM
To: Paul Angus; users@cloudstack.apache.org; d...@cloudstack.apache.org
Subject: Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)

The same issue applies to any 4.9, 4.10 release. In case of 4.9, we had 
discussed this as a doc bug and so it must be documented part of the 4.11 
release notes as well.


There are two ways admin can migrate to dynamic roles post-upgrade:


  1.  Enable dynamic.apichecker.enabled to true which will use the default api 
mapping of rules from 4.8 commands.properties and automatic annotation based 
and (db-backed) dynamic rules from 4.9+. Or,

  2.  The migration script is only useful where admins were not using the 
default api rule mappings and they strictly want to check/migrate each API. 
This approach requires admins to go through new APIs and fix 
commands.properties before running the migration scriopt (we've been sharing 
the new/change API list in release notes, for example: 
http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.9.3.0/api-changes.html#new-api-commands).
 (for reference, doc: 
http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/accounts.html#using-dynamic-roles)


Unlike the dynamic API checker, the static checker does not even allow the root 
API to access all the APIs which is why post upgrade, if the UI calls any API 
that is not allowed for the root admin (in this case the quotaIsEnabled API) 
the UI will logout the user on API unauthorized failure which is what happened.


So, we can discuss two fixes:

- Like dynamic checker, let the static checker allow all APIs only to the root 
admin (id=1) (I would not prefer to change the legacy behaviour though)

- During upgrade, if commands.properties is missing we set the global setting 
to true, i.e. switch to dynamic roles (which would happen if someone tries to 
upgrade from 4.5->4.11 using a new mgmt server if they fail to copy the 
commands.properties file from /usr/share or /etc paths).


Thoughts?


- Rohit







rohit.ya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue




rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

From: Paul Angus
Sent: Monday, January 22, 2018 9:24:25 AM
To: users@cloudstack.apache.org
Cc: Rohit Yadav; d...@cloudstack.apache.org; Daan Hoogland
Subject: RE: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)

If I've understood the issue correctly, "not being able to log in if upgrading 
from 4.5" is a blocker in my book.   I don't think that it should be the duty 
of the Admin, to fix our oversights.  Migration to the use of dynamic roles is 
also broken as the command will be missing from commands.properties in the 
first place, so the 'migrated' commands will not be complete.

As there will need to be an RC2, IMO this upgrade issue should be fixed as part 
of it.



Kind regards,

Paul Angus


VP Technology
paul.an...@shapeblue.com
www.shapeblue.com




-Original Message-
From: Boris Stoyanov [mailto:boris.stoya...@shapeblue.com]
Sent: 22 January 2018 07:31
To: users@cloudstack.apache.org
Cc: Rohit Yadav ; d...@cloudstack.apache.org; Daan 
Hoogland 
Subject: Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)

Hi Paul,
Migration script considers only what’s in the command.properties file, so if 
the ‘missing’ quotaIsEnabled=15 is not there it will not create a rule for it. 
As Rohit mentioned it’s a duty of the admin to take care of aligning this up. 
I’m also not big fan of having this described in release notes, but would like 
to be included automatically during upgrade. Main argument against it, its not 
a blocker.

Bobby.


boris.stoya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue



> On 19 Jan 2018, at 19:04, Paul Angus  wrote:
>
> OK, just to confirm ‘we’ the community have basically deprecated the use of 
> commands.properties?
>
> But for people 

Re: New L2 nework types are not shared

[Jean-Francois Nadeau]

Thank you both Boris and Nux!

I'll keep an eye 4.11.1.   If I may get your attention on another issue
that blocks me from further testing on 4.11, I filled CLOUDSTACK-10239 :-)

best regards,

Jean-Francois






On Tue, Jan 23, 2018 at 8:55 AM, Boris Stoyanov <
boris.stoya...@shapeblue.com> wrote:

> Thanks for bringing this up Jean-Francois,
> One of our devs has addressed this and with the following PR it’s now
> fixed. It turned out a constraint was violated when deploying a VM in a
> project. This will likely get merged in 4.11.1.0
> https://github.com/apache/cloudstack/pull/2420
>
> Please let keep us posted if you find any further issues.
>
> Regards,
> Boris.
>
> On 19 Jan 2018, at 17:57, Nux! >
> wrote:
>
> Hi,
>
> Might be worth sending this to dev@ as well, especially now that we are
> doing testing for 4.11.
>
> HTH
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
>
> boris.stoya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
> - Original Message -
> From: "Jean-Francois Nadeau" 
> To: "users" 
> Sent: Wednesday, 17 January, 2018 21:09:19
> Subject: New L2 nework types are not shared
>
> Hi all,
>
> I'm testing 4.11-rc1 and the new L2 network type feature as shown at
> http://www.shapeblue.com/layer-2-networks-in-cloudstack/
>
> I want to use this as a replacement to a shared network offering with no
> DHCP which works to support an external DHCP server but still required to
> fill some CIDR information.
>
> I thought the intent was that L2 network type was to replace the previous
> approach when required to integrate an existing network.
>
> If I attempt to provision a VM in a project as the root admin using the L2
> network I get denied... apparently because they are not shared and I can't
> make them public.
>
> ('HTTP 531 response from CloudStack', , {u'errorcode': 531,
> u'uuidList': [], u'cserrorcode': 4365, u'errortext': u'Unable to use
> network with id= 7712102b-bbdf-4c54-bdbf-9fddfa16de46, permission
> denied'})
>
> Provisioning in the root project works just fine  but really I want to
> use L2 networks in user projects even if only the admin can do so.
>
> Thoughts ?
>
>

Cloudstack meetup - Germany

[Giles Sirett]

https://www.meetup.com/german-CloudStack-user-group/events/246861772/?eventId=246861772

Hi all - from Maria (in CC)

We are currently planning our next German CS Meetup in Frankfurt. The event 
will take place on February the 28th and will be hosted by proIO GmbH.

Since our last event had limited community participation we are hoping to reach 
more people this time. As always we would appreciate any support to promote the 
upcoming Meetup and your participation/visit would be more than welcome :) :)

Currently we have three potential speakers who would be very interested in 
presenting their topics:

  1.  Rene Moser, SWISS TXT AG
  2.  Swen Brüseke, proIO GmbH
  3.  Sebastian Bretschneider, itelligence Global Managed Services GmbH

Swen is also talking to additional candidates from the Netherlands and the UK 
but could not yet confirm their attendance.

This location is:Telehouse Deutschland GmbH
Kleyerstrasse 75-87
60326 Frankfurt am Main

The event has already been posted on Meetup : 
https://www.meetup.com/de-DE/german-CloudStack-user-group/events/246861772/

So please let us know if you are able to join us and if we could also announce 
the meetup (once the final agenda is set) on the LinkedIn CloudStack User group?

Looking forward to hearing from you soon


Kind regards
Giles


giles.sir...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Re: New L2 nework types are not shared

[Boris Stoyanov]

Thanks for bringing this up Jean-Francois,
One of our devs has addressed this and with the following PR it’s now fixed. It 
turned out a constraint was violated when deploying a VM in a project. This 
will likely get merged in 4.11.1.0
https://github.com/apache/cloudstack/pull/2420

Please let keep us posted if you find any further issues.

Regards,
Boris.

On 19 Jan 2018, at 17:57, Nux! > wrote:

Hi,

Might be worth sending this to dev@ as well, especially now that we are doing 
testing for 4.11.

HTH

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro


boris.stoya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

- Original Message -
From: "Jean-Francois Nadeau" 
To: "users" 
Sent: Wednesday, 17 January, 2018 21:09:19
Subject: New L2 nework types are not shared

Hi all,

I'm testing 4.11-rc1 and the new L2 network type feature as shown at
http://www.shapeblue.com/layer-2-networks-in-cloudstack/

I want to use this as a replacement to a shared network offering with no
DHCP which works to support an external DHCP server but still required to
fill some CIDR information.

I thought the intent was that L2 network type was to replace the previous
approach when required to integrate an existing network.

If I attempt to provision a VM in a project as the root admin using the L2
network I get denied... apparently because they are not shared and I can't
make them public.

('HTTP 531 response from CloudStack', , {u'errorcode': 531,
u'uuidList': [], u'cserrorcode': 4365, u'errortext': u'Unable to use
network with id= 7712102b-bbdf-4c54-bdbf-9fddfa16de46, permission denied'})

Provisioning in the root project works just fine  but really I want to
use L2 networks in user projects even if only the admin can do so.

Thoughts ?

External DNS

[mm]

Hello guys,

After installation and configuration cloudstack we got lil problem.

We can't use external DNS in our VM's. Every VM's is going up with our 
internal DNS and Google Public. We are interested to start VM's only 
with GP DNS.


We change settings: use.external.dns	Bypass internal dns, use external 
dns1 and dns2	true
We restart management server, VR and all other systems, but do not 
having effect. It's still using our internal DNS and GP.It's very 
laggy with our DNS, internet speed only 10Mbps


CloudStack: 4.8.0
XenServer 6.5

Anyone have solution?