Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)

[Tutkowski, Mike]

Hi everyone,

I’ve completed running the automated (and, in some cases, manual) tests for 
managed storage against RC1. With the exception of one critical issue, all of 
the tests for all tested hypervisors (XenServer, VMware, and KVM) passed.

With regards to the critical issue, I have opened a PR for RC2:

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

This comment lists the tests I performed while running RC1 + PR 2416:

https://github.com/apache/cloudstack/pull/2416#issuecomment-359220967

Thanks,
Mike

On 1/19/18, 3:59 PM, "Tutkowski, Mike"  wrote:

Hi Rohit,

I have opened the following PR for 4.11 RC2:

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

Also, I have completed running all the tests for managed storage for KVM 
and VMware. With the exception of the PR I opened, all tests passed.

This weekend I plan to re-run the XenServer managed-storage tests. I had 
run them just prior to you creating RC1, so I expect they will all pass.

Thanks!
Mike

On 1/19/18, 6:56 AM, "Tutkowski, Mike"  wrote:

Yes, but only one (for KVM) and it is trivial to fix. I’ll open a PR.

Also, I’m almost done testing managed storage with VMware and all has 
gone well with that hypervisor.

I’ll run the tests for managed storage with XenServer over the weekend. 
I suspect they will all pass just fine.

> On Jan 19, 2018, at 1:55 AM, Rohit Yadav  
wrote:
> 
> Thanks Mike - do you see any blockers wrt to 4.11.0.0-rc1?
> 
> 
> - Rohit
> 
> 
> 
> 
> 
> 
> From: Tutkowski, Mike 
> Sent: Wednesday, January 17, 2018 8:09:50 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)
> 
> Yes: I definitely won’t be able to complete my regression tests 
within the 72-hour window. For 4.12, I plan to automate the remainder of my 
tests, but I’m not quite there with 4.11 (the vast majority of managed-storage 
tests are automated, but not yet all).
> 
> On 1/17/18, 7:34 AM, "Daan Hoogland"  
wrote:
> 
>People, People,
> 
>a lot of us are busy with meltdown fixes and a full component test 
takes about the 72 hours that we have for our voting, I propose to extend the 
vote period until at least Monday.
> 
>Is that a good idea?
> 
>On 17/01/2018, 14:33, "Kris Sterckx" 
 wrote:
> 
>4.11.0 looks like an awesome reason !  Special thanks to Rohit 
!
> 
>I vote +0
> 
>-  I vote for including CLOUDSTACK-9749 [1] into 4.11.0 still
> 
>-  And if that is accepted, I vote for including 
CLOUDSTACK-10233 [2] also
>(Nuage-internal fix)
> 
>thanks
> 
>Kris
> 
>[1] https://issues.apache.org/jira/browse/CLOUDSTACK-9749
>[2] https://issues.apache.org/jira/browse/CLOUDSTACK-10233
> 
> 
> 
>daan.hoogl...@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
> 
> 
> 
>> On 15 January 2018 at 12:32, Rohit Yadav  wrote:
>> 
>> Hi All,
>> 
>> I've created a 4.11.0.0 release, with the following artifacts up for
>> testing and a vote:
>> 
>> Git Branch and Commit SH:
>> https://gitbox.apache.org/repos/asf?p=cloudstack.git;a=
>> shortlog;h=refs/heads/4.11.0.0-RC20180115T1603
>> Commit: 1b8a532ba52127f388847690df70e65c6b46f4d4
>> 
>> Source release (checksums and signatures are available at the same
>> location):
>> https://dist.apache.org/repos/dist/dev/cloudstack/4.11.0.0/
>> 
>> PGP release keys (signed using 
5ED1E1122DC5E8A4A45112C2484248210EE3D884):
>> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>> 
>> The vote will be open for 72 hours.
>> 
>> For sanity in tallying the vote, can PMC members please be sure to 
indicate
>> "(binding)" with their vote?
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> Additional information:
>> 
>> For users' convenience, I've built packages from
>> 1b8a532ba52127f388847690df70e65c6b46f4d4 and published RC1 repository
>> here:
 

Re: [GitHub] rafaelweingartner commented on a change in pull request #2416: CLOUDSTACK-10244: KVM online storage migration fails

[Rohit Yadav]

Thanks for the discussion, I'll prefer keeping the current code as well.

Merging this based on code reviews and tests.



- Rohit






From: Rafael Weingärtner 
Sent: Saturday, January 20, 2018 11:29:38 PM
To: dev
Subject: Re: [GitHub] rafaelweingartner commented on a change in pull request 
#2416: CLOUDSTACK-10244: KVM online storage migration fails

>
> So, your official position is that declaring a variable as constant is
> typically pointless because some future programmer can always change the
> variable to not be constant


That is it! I do that a lot.. specially if I cannot find a reason to
declare a variable final. That is why quality code documentation is very
important.

On Sat, Jan 20, 2018 at 3:53 PM, Tutkowski, Mike 
wrote:

> So, your official position is that declaring a variable as constant is
> typically pointless because some future programmer can always change the
> variable to not be constant. :)
>
> In this case, to appease both parties (you and Wido), I’ll leave it final,
> but add a comment to explain why it’s final.
>
> It should end up being a moot point in 4.12 as I plan to change the
> replaceStorage method to create a shallow copy of the passed-in map and
> mutate it as need be. Then, we won’t even need this Boolean.
>
> > On Jan 20, 2018, at 9:58 AM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
> >
> > No setters help to make an object immutable, but in Java we have
> > reflection, and the only way to really avoid changing a property is using
> > the final modifier. However, even when using final, it is possible to do
> so
> > by manipulating the byte code of the class that describes the object and
> is
> > loaded to the JVM. This is what PowerMock does to deal with static and
> > final method/variable mocking.
> >
> > On Sat, Jan 20, 2018 at 2:40 PM, Tutkowski, Mike <
> mike.tutkow...@netapp.com>
> > wrote:
> >
> >> “For instance, when we have to design/create a library and we want to
> make
> >> sure an object is immutable.”
> >>
> >> According to your argument, though, you don’t need final here either:
> just
> >> make sure to never provide setters or change those values (and
> document).
> >>
> >>> On Jan 20, 2018, at 9:37 AM, Tutkowski, Mike <
> mike.tutkow...@netapp.com>
> >> wrote:
> >>>
> >>> Personally, I’m OK with it either way here. If @wido reads what you
> >> wrote and asks me to change it back to the way I wrote it initially, I’m
> >> happy to do so.
> >>>
> >>> I believe he sees the explicitly declared constant here not only as a
> >> protection against ourselves, but to prevent a future programmer from
> >> easily making a mistake. At least now, if this future programmer changes
> >> the value, the compile will fail and he/she will be forced to think
> through
> >> the repercussions of doing so.
> >>>
>  On Jan 20, 2018, at 9:30 AM, Rafael Weingärtner <
> >> rafaelweingart...@gmail.com> wrote:
> 
>  Never is a strong word. In any case, let it be if you believe it is
> >> going
>  to provide  benefits…
> 
>  I believe `final` modifier should be used in certain situation when it
> >> is
>  truly required. For instance, when we have to design/create a library
> >> and
>  we want to make sure an object is immutable. Then, we configure all of
> >> its
>  variables as final. Now, declaring a variable final in the middle of a
>  method to protect against ourselves…. It does not seem to bring much
>  benefit against future mistaken/accidental changes. It is always
> >> possible
>  for the hypothetical future programmer to remove the final and change
> >> the
>  variable. Perhaps a better documentation for the method explaining
> this
>  situations could bring more benefits. A single variable declared as
> >> final
>  does not give a hint for people on why it was made final.
> 
>  On Sat, Jan 20, 2018 at 2:08 PM, Tutkowski, Mike <
> >> mike.tutkow...@netapp.com>
>  wrote:
> 
> > Perhaps your argument against the final keyword is that it should
> >> never be
> > used? If so, you and @wido can debate that and let me know which way
> >> you’d
> > like this bit of code to end up.
> >
> >> On Jan 20, 2018, at 9:05 AM, Tutkowski, Mike <
> >> mike.tutkow...@netapp.com>
> > wrote:
> >>
> >> It’s pretty much the reason why the final variable exists in Java:
> to
> > make a variable a constant so no one accidentally changes it. @wido
> >> just
> > wanted the code to protect against the variable being
> changed...that’s
> >> all.
> >>
> >>> On Jan 20, 2018, at 8:25 AM, Rafael Weingärtner <
> > rafaelweingart...@gmail.com> wrote:
> >>>
> >>> Changed by a future programmer that may develop some changes in
> your
> > code?
> >>> Because, if you do not code any other assignment to that variable,
> it
> > will
> >>> never happen.
> >>>
> >>> On Sat, Ja

Re: [4.11] KVM Advanced Networking with SG Problem

[Rohit Yadav]

Wido - Were you able to reproduce and fix the issue? Thanks.



- Rohit






From: Wido den Hollander 
Sent: Friday, January 19, 2018 10:12:45 PM
To: dev@cloudstack.apache.org
Subject: Re: [4.11] KVM Advanced Networking with SG Problem



On 01/19/2018 02:03 PM, Özhan Rüzgar Karaman wrote:
> Hi Daan;
> Wido or others will write a fix, i am not a developer, i do not have a fix,
> i just only want to report it to make it official thats all :)
>

I'll look into this asap. The Python script should parse these rules
properly and then it should be fixed.

I hope to have a fix this weekend.

Wido

> Thanks
> Özhan
>
> On Fri, Jan 19, 2018 at 3:59 PM, Daan Hoogland 
> wrote:
>
>> This is not a PR but a ticket, Özhan. Do you plan to make a pull request on
>> github with your solution for it?
>>
>> On Fri, Jan 19, 2018 at 1:53 PM, Özhan Rüzgar Karaman <
>> oruzgarkara...@gmail.com> wrote:
>>
>>> Hi Daan;
>>> Wido is the previous PR's owner, he will check it. By the way i have
>>> created a PR for this problem which is below:
>>>
>>> https://issues.apache.org/jira/browse/CLOUDSTACK-10242
>>>
>>> I select its priority as blocker, if its wrong developers will update its
>>> priority.
>>>
>>> Thanks
>>> Özhan
>>>
>>>
>>>
>>> On Fri, Jan 19, 2018 at 3:25 PM, Daan Hoogland 
>>> wrote:
>>>
 Özhan, this is sure to break ipv6. can you make it use another
>> delimiter?

 On Fri, Jan 19, 2018 at 1:12 PM, Özhan Rüzgar Karaman <
 oruzgarkara...@gmail.com> wrote:

> Hi Rohit;
> This is a fresh install of 4.11 rc1 and we have only ipv4 setup on
>> our
 test
> environment no ipv6 addresses, our VR's are new 4.11 rc1 system vms.
>>> Our
> workaround is 4 lines of code to convert ";" character to ":" on
> security_group.py
> code to make it operational for ipv4 addresses but i am sure it will
 break
> Wido's "Add support for ipv6 address and subnets" PR. Workaround
>> works
 only
> for us because we have ipv4 only setup.
>
> If Wido could check parse_network_rules function on security_group.py
 then
> that could be great. After his check and possible code fix i like to
>>> make
> test again on our environment.
>
> @Rohit i will create a JIRA ticket to follow it easily by team.
>
> Thanks
> Özhan
>
> On Fri, Jan 19, 2018 at 2:51 PM, Rohit Yadav <
>>> rohit.ya...@shapeblue.com>
> wrote:
>
>> Hi Ozhan,
>>
>>
>> Thanks for sharing.
>>
>>
>> I traced the change to the following PR that changes the delimiter
>> character to ';' than ":" to support ipv6 addresses:
>>
>> https://github.com/apache/cloudstack/pull/2028/files
>>
>>
>> Can you share with the workaround, if applicable send a pull
>> request?
>>
>>
>> Were you still using old 4.9.3 VRs post upgrade, does killing old
>> 4.9
 VRs
>> help fix the issue? /cc Wido
>>
>>
>> - Rohit
>>
>> 
>>
>>
>>
>> 
>> From: Özhan Rüzgar Karaman 
>> Sent: Friday, January 19, 2018 3:38:19 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [4.11] KVM Advanced Networking with SG Problem
>>
>> Hi;
>> We solved the bug there and write a small workaround today, the
>>> problem
> is
>> generally from the Java code which calls security_group.py. On
>> 4.9.3
>> release it was using : character but from 4.11 release delimiter
 changed
> to
>> ; character but security_group.py expects : as delimeter so
>> security_group.py could not parse & send rules to the iptables.
>>
>> Afternoon i will create a JIRA ticket and if anyone could fix the
> delimiter
>> character or code in the Java code for 4.11 release that would be
>>> great
>> because without this code Security Groups are not operational for
>>> 4.11.
>>
>> Also @Rohit do we need to check test codes for Security Groups?
 Because i
>> do not understand how this bug passed our testing scenarios.
>>
>> Thanks
>> Özhan
>>
>>
>>
>>
>>
>>
>> On Fri, Jan 19, 2018 at 12:00 PM, Rohit Yadav <
 rohit.ya...@shapeblue.com
>>
>> wrote:
>>
>>> Can anyone help look into this issue, reproduce it and if it's a
> genuine
>>> bug help fix it?
>>>
>>> Any takers - Wido, Wei, Mike and others who may be using KVM+SG?
>>>
>>>
>>> - Rohit
>>>
>>> 
>>>
>>>
>>>
>>> 
>>> From: Özhan Rüzgar Karaman 
>>> Sent: Tuesday, January 16, 2018 9:53:59 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: [4.11] KVM Advanced Networking with SG Problem
>>>
>>> Hi;
>>> We made a test with 4.11 rc over Ubuntu16.04 KVM hosts and we
>>> noticed
>> that
>>> th

Re: [4.11] KVM Advanced Networking with SG Problem

[Wido den Hollander]

On 01/21/2018 11:23 AM, Rohit Yadav wrote:

Wido - Were you able to reproduce and fix the issue? Thanks.



Still working on it! This weekend I was short on time and wasn't able to 
fix it yet.


Today (Mon) and tomorrow (Tue) my time is limited as well. Trying to fix 
it asap.


Wido




- Rohit






From: Wido den Hollander 
Sent: Friday, January 19, 2018 10:12:45 PM
To: dev@cloudstack.apache.org
Subject: Re: [4.11] KVM Advanced Networking with SG Problem



On 01/19/2018 02:03 PM, Özhan Rüzgar Karaman wrote:

Hi Daan;
Wido or others will write a fix, i am not a developer, i do not have a fix,
i just only want to report it to make it official thats all :)



I'll look into this asap. The Python script should parse these rules
properly and then it should be fixed.

I hope to have a fix this weekend.

Wido


Thanks
Özhan

On Fri, Jan 19, 2018 at 3:59 PM, Daan Hoogland 
wrote:


This is not a PR but a ticket, Özhan. Do you plan to make a pull request on
github with your solution for it?

On Fri, Jan 19, 2018 at 1:53 PM, Özhan Rüzgar Karaman <
oruzgarkara...@gmail.com> wrote:


Hi Daan;
Wido is the previous PR's owner, he will check it. By the way i have
created a PR for this problem which is below:

https://issues.apache.org/jira/browse/CLOUDSTACK-10242

I select its priority as blocker, if its wrong developers will update its
priority.

Thanks
Özhan



On Fri, Jan 19, 2018 at 3:25 PM, Daan Hoogland 
wrote:


Özhan, this is sure to break ipv6. can you make it use another

delimiter?


On Fri, Jan 19, 2018 at 1:12 PM, Özhan Rüzgar Karaman <
oruzgarkara...@gmail.com> wrote:


Hi Rohit;
This is a fresh install of 4.11 rc1 and we have only ipv4 setup on

our

test

environment no ipv6 addresses, our VR's are new 4.11 rc1 system vms.

Our

workaround is 4 lines of code to convert ";" character to ":" on
security_group.py
code to make it operational for ipv4 addresses but i am sure it will

break

Wido's "Add support for ipv6 address and subnets" PR. Workaround

works

only

for us because we have ipv4 only setup.

If Wido could check parse_network_rules function on security_group.py

then

that could be great. After his check and possible code fix i like to

make

test again on our environment.

@Rohit i will create a JIRA ticket to follow it easily by team.

Thanks
Özhan

On Fri, Jan 19, 2018 at 2:51 PM, Rohit Yadav <

rohit.ya...@shapeblue.com>

wrote:


Hi Ozhan,


Thanks for sharing.


I traced the change to the following PR that changes the delimiter
character to ';' than ":" to support ipv6 addresses:

https://github.com/apache/cloudstack/pull/2028/files


Can you share with the workaround, if applicable send a pull

request?



Were you still using old 4.9.3 VRs post upgrade, does killing old

4.9

VRs

help fix the issue? /cc Wido


- Rohit






From: Özhan Rüzgar Karaman 
Sent: Friday, January 19, 2018 3:38:19 PM
To: dev@cloudstack.apache.org
Subject: Re: [4.11] KVM Advanced Networking with SG Problem

Hi;
We solved the bug there and write a small workaround today, the

problem

is

generally from the Java code which calls security_group.py. On

4.9.3

release it was using : character but from 4.11 release delimiter

changed

to

; character but security_group.py expects : as delimeter so
security_group.py could not parse & send rules to the iptables.

Afternoon i will create a JIRA ticket and if anyone could fix the

delimiter

character or code in the Java code for 4.11 release that would be

great

because without this code Security Groups are not operational for

4.11.


Also @Rohit do we need to check test codes for Security Groups?

Because i

do not understand how this bug passed our testing scenarios.

Thanks
Özhan






On Fri, Jan 19, 2018 at 12:00 PM, Rohit Yadav <

rohit.ya...@shapeblue.com


wrote:


Can anyone help look into this issue, reproduce it and if it's a

genuine

bug help fix it?

Any takers - Wido, Wei, Mike and others who may be using KVM+SG?


- Rohit






From: Özhan Rüzgar Karaman 
Sent: Tuesday, January 16, 2018 9:53:59 PM
To: dev@cloudstack.apache.org
Subject: [4.11] KVM Advanced Networking with SG Problem

Hi;
We made a test with 4.11 rc over Ubuntu16.04 KVM hosts and we

noticed

that

there is a problem on setting & applying security group changes

on

KVM

host.

All instances could ping vr and they could access internet but no

one

could

access to the instances.

I checked iptables rules and i noticed that iptables rules for vm

is

in

all

drop state for incoming packages while i gave access to all

ingress

and

egress tcp/udp traffic ports for that instances. Below are

iptables

output

for selected vm:

Chain i-2-6-VM (1 references)
target prot opt source   destination
DROP   all  --  anywhere anywhere

Chain i-2-6-VM-eg (1 references)
t

Re: [4.11] KVM Advanced Networking with SG Problem

[Wido den Hollander]

On 01/22/2018 07:35 AM, Wido den Hollander wrote:



On 01/21/2018 11:23 AM, Rohit Yadav wrote:

Wido - Were you able to reproduce and fix the issue? Thanks.



Still working on it! This weekend I was short on time and wasn't able to 
fix it yet.


Today (Mon) and tomorrow (Tue) my time is limited as well. Trying to fix 
it asap.


During my train ride this morning I wrote this patch: 
https://github.com/apache/cloudstack/pull/2418


@ Özhan, could you test this patch? It's just a matter of replacing 
security_group.py on your Hypervisor.


Thanks,

Wido



Wido




- Rohit






From: Wido den Hollander 
Sent: Friday, January 19, 2018 10:12:45 PM
To: dev@cloudstack.apache.org
Subject: Re: [4.11] KVM Advanced Networking with SG Problem



On 01/19/2018 02:03 PM, Özhan Rüzgar Karaman wrote:

Hi Daan;
Wido or others will write a fix, i am not a developer, i do not have 
a fix,

i just only want to report it to make it official thats all :)



I'll look into this asap. The Python script should parse these rules
properly and then it should be fixed.

I hope to have a fix this weekend.

Wido


Thanks
Özhan

On Fri, Jan 19, 2018 at 3:59 PM, Daan Hoogland 
wrote:

This is not a PR but a ticket, Özhan. Do you plan to make a pull 
request on

github with your solution for it?

On Fri, Jan 19, 2018 at 1:53 PM, Özhan Rüzgar Karaman <
oruzgarkara...@gmail.com> wrote:


Hi Daan;
Wido is the previous PR's owner, he will check it. By the way i have
created a PR for this problem which is below:

https://issues.apache.org/jira/browse/CLOUDSTACK-10242

I select its priority as blocker, if its wrong developers will 
update its

priority.

Thanks
Özhan



On Fri, Jan 19, 2018 at 3:25 PM, Daan Hoogland 


wrote:


Özhan, this is sure to break ipv6. can you make it use another

delimiter?


On Fri, Jan 19, 2018 at 1:12 PM, Özhan Rüzgar Karaman <
oruzgarkara...@gmail.com> wrote:


Hi Rohit;
This is a fresh install of 4.11 rc1 and we have only ipv4 setup on

our

test

environment no ipv6 addresses, our VR's are new 4.11 rc1 system vms.

Our

workaround is 4 lines of code to convert ";" character to ":" on
security_group.py
code to make it operational for ipv4 addresses but i am sure it will

break

Wido's "Add support for ipv6 address and subnets" PR. Workaround

works

only

for us because we have ipv4 only setup.

If Wido could check parse_network_rules function on 
security_group.py

then

that could be great. After his check and possible code fix i like to

make

test again on our environment.

@Rohit i will create a JIRA ticket to follow it easily by team.

Thanks
Özhan

On Fri, Jan 19, 2018 at 2:51 PM, Rohit Yadav <

rohit.ya...@shapeblue.com>

wrote:


Hi Ozhan,


Thanks for sharing.


I traced the change to the following PR that changes the delimiter
character to ';' than ":" to support ipv6 addresses:

https://github.com/apache/cloudstack/pull/2028/files


Can you share with the workaround, if applicable send a pull

request?



Were you still using old 4.9.3 VRs post upgrade, does killing old

4.9

VRs

help fix the issue? /cc Wido


- Rohit






From: Özhan Rüzgar Karaman 
Sent: Friday, January 19, 2018 3:38:19 PM
To: dev@cloudstack.apache.org
Subject: Re: [4.11] KVM Advanced Networking with SG Problem

Hi;
We solved the bug there and write a small workaround today, the

problem

is

generally from the Java code which calls security_group.py. On

4.9.3

release it was using : character but from 4.11 release delimiter

changed

to

; character but security_group.py expects : as delimeter so
security_group.py could not parse & send rules to the iptables.

Afternoon i will create a JIRA ticket and if anyone could fix the

delimiter

character or code in the Java code for 4.11 release that would be

great

because without this code Security Groups are not operational for

4.11.


Also @Rohit do we need to check test codes for Security Groups?

Because i

do not understand how this bug passed our testing scenarios.

Thanks
Özhan






On Fri, Jan 19, 2018 at 12:00 PM, Rohit Yadav <

rohit.ya...@shapeblue.com


wrote:


Can anyone help look into this issue, reproduce it and if it's a

genuine

bug help fix it?

Any takers - Wido, Wei, Mike and others who may be using KVM+SG?


- Rohit






From: Özhan Rüzgar Karaman 
Sent: Tuesday, January 16, 2018 9:53:59 PM
To: dev@cloudstack.apache.org
Subject: [4.11] KVM Advanced Networking with SG Problem

Hi;
We made a test with 4.11 rc over Ubuntu16.04 KVM hosts and we

noticed

that

there is a problem on setting & applying security group changes

on

KVM

host.

All instances could ping vr and they could access internet but no

one

could

access to the instances.

I checked iptables rules and i noticed that iptables rules for vm

is

in

all

drop state for incoming packages while i gave ac

Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)

[Boris Stoyanov]

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 upgrading from a version before dynamic roles,  does the 
> migration script take into account (or need to take into account) the 
> ‘missing’ quotaIsEnabled=15 parameter?
> 
> 
> 
> 
> paul.an...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 
> From: Rohit Yadav
> Sent: 19 January 2018 09:27
> To: users ; dev@cloudstack.apache.org; Paul 
> Angus 
> Subject: Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)
> 
> 
> Hi Bobby,
> 
> 
> 
> Agree, it's not user-friendly which is why admins should migrate to the 
> dynamic roles feature. But I'm not sure if this is a blocker and if an admin 
> wants to stick to the old static (commands.properties) way, they need to 
> manage changes themselves. We may add something to the release notes /cc 
> @Paul Angus.
> 
> 
> 
> - Rohit
> 
> 
> 
> Software Architect
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 
> 
> 
> 
> 
> 
> 
> 
> From: Boris Stoyanov 
> mailto:boris.stoya...@shapeblue.com>>
> Sent: Friday, January 19, 2018 2:51:32 PM
> To: users
> Cc: dev@cloudstack.apache.org
> Subject: Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)
> 
> Hi Rohit,
> 
> That doesn’t sound much user friendly what do you think? Can we look for a 
> way to automate this dependency in the upgrade process?
> 
> Bobby.
> 
> 
> boris.stoya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 
>> On 19 Jan 2018, at 10:50, Rohit Yadav 
>> mailto:rohit.ya...@shapeblue.com>> wrote:
>> 
>> Hi Bobby,
>> 
>> 
>> I checked the 4.5-4.11 upgrade environment, due to the nature of how static 
>> checker with commands.properties work, admins will be required to add/update 
>> new API/ACLs in the commands.properties file.
>> 
>> Adding the following to commands.properties file and restarting mgmt server 
>> fixes the issue:
>> 
>> quotaIsEnabled=15
>> 
>> 
>> Please continue testing, thanks.
>> 
>> 
>> - Rohit
>> 
>> 
>> 
>> 
>> 
>> 
>> From: Boris Stoyanov 
>> mailto:boris.stoya...@shapeblue.com>>
>> Sent: Wednesday, January 17, 2018 6:54:28 PM
>> To: us...@cloudstack.apache.org
>> Cc: dev@cloudstack.apache.org
>> Subject: Re: [VOTE] Apache Cloudstack 4.11.0.0 (LTS)
>> 
>> I think I’ve hit a blocker when upgrading to 4.11
>> 
>> Here’s the jira id: https://issues.apache.org/jira/browse/CLOUDSTACK-10236
>> 
>> I’ve upgraded from 4.5 to 4.11, then I’ve logged in with admin and got 
>> session expired immediately.
>> 
>> Regards,
>> Boris Stoyanov
>> 
>> 
>> boris.stoya...@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
>> 
>> 
>> 
>> On 17 Jan 2018, at 8:42, Tutkowski, Mike 
>> mailto:mike.tutkow...@netapp.com>>
>>  wrote:
>> 
>> Hi everyone,
>> 
>> For the past couple days, I have been running the KVM managed-storage 
>> regression-test suite against RC1.
>> 
>> With the exception of one issue (more on this below), all of these tests 
>> have passed.
>> 
>> Tomorrow I plan to start in on the VMware-related managed-storage tests.
>> 
>> Once I’ve completed running those, I expect to move on to the 
>> XenServer-related managed-storage tests.
>> 
>> I ran these XenServer and VMware tests just prior to RC1 being created, so I 
>> suspect all of those tests will come back successful.
>> 
>> Now, with regards to the one issue I found on KVM with managed storage:
>> 
>> It relates to a new feature whereby you can online migrate the storage of a 
>> VM from NFS or Ceph to managed storage.
>> 
>> During the code-review process, I made a change per a suggestion and it 
>>