[GitHub] cloudstack pull request #1853: CLOUDSTACK-9696: Fixed Virtual Router deploym...

[anshul1886]

GitHub user anshul1886 reopened a pull request:

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

CLOUDSTACK-9696: Fixed Virtual Router deployment failing if there are…

… no shared resources available

and has access to resources through parent domain heirarachy

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/anshul1886/cloudstack-1 CLOUDSTACK-9696

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cloudstack/pull/1853.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #1853


commit 0024dfc62266cc52380b7977860f667414d36e42
Author: Anshul Gangwar 
Date:   2016-12-22T06:17:03Z

CLOUDSTACK-9696: Fixed Virtual Router deployment failing if there are no 
shared resources available
and has access to resources through parent domain heirarachy




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack pull request #1853: CLOUDSTACK-9696: Fixed Virtual Router deploym...

[anshul1886]

Github user anshul1886 closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack issue #1853: CLOUDSTACK-9696: Fixed Virtual Router deployment fai...

[koushik-das]

Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/1853
  
Code change LGTM.
@anshul1886 Please make sure Travis is green.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack issue #1582: CLOUDSTACK-9408 for the move away from download.clou...

[karuturi]

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1582
  
@borisstoyanov Can you run @blueorangutan tests on this please?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack issue #1582: CLOUDSTACK-9408 for the move away from download.clou...

[karuturi]

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1582
  
I see that its already using download.cloudstack.org. Its merge ready. Will 
merge once I do some tests. Thanks @DaanHoogland 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Welcoming Wido as the new ACS VP

[Ian Rae]

Great to hear Wido, congrats and see you in Miami!

On Sun, Mar 19, 2017 at 1:45 PM Wido den Hollander  wrote:

> Thank you Will and all!
>
> I'll be present at CCC in Miami this year for a 'official' initiation as
> VP of the CloudStack project :)
>
> Wido
>
> > Op 16 maart 2017 om 18:00 schreef Will Stevens :
> >
> >
> > Hello Everyone,
> > It has been a pleasure working with you as the ACS VP over the past year.
> > I would like to say Thank You to everyone who has supported me in this
> role
> > and have supported the project as a whole.
> >
> > It is my pleasure to announce that Wido den Hollander has been voted in
> to
> > replace me as the Apache Cloudstack VP in our annual VP rotation.  Wido
> has
> > a long history with the project and we are happy welcome him into this
> new
> > role.
> >
> > Be sure to join us at CCC in Miami [1] so we can initiate him correctly
> > over many beers.  :)
> >
> > Cheers,
> >
> > *Will Stevens*
> >
> > ​[1] http://us.cloudstackcollab.org/​
>
-- 
Ian Rae
CEO | PDG
c: 514.944.4008

CloudOps | Cloud Infrastructure and Networking Solutions
www.cloudops.com | 420 rue Guy | Montreal | Canada | H3J 1S6

RE: [DISCUSS] Retirement of midonet plugin

[Marty Godsey]

I know that I am not a committer (I am a systems, networking guy, I don’t 
"code") but I agree with Will. Giving the community at large some time to yell 
if they are using is good.

Regards,
Marty Godsey
Principal Engineer
nSource Solutions, LLC

-Original Message-
From: Will Stevens [mailto:williamstev...@gmail.com] 
Sent: Sunday, March 19, 2017 7:39 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Retirement of midonet plugin

I think there needs to be at least 6 months between the disable code being 
released and the delete PR being merged. I feel like the clock has to start 
only when the disable code is generally available in a stable release (not when 
it is merged).

On Mar 19, 2017 6:47 AM, "Daan Hoogland" 
wrote:

> You are spot on. We can add a due date for the final removal I think.
> Let’s not add a target version, I’d say.
>
> On 18/03/17 23:23, "Rafael Weingärtner" 
> wrote:
>
> Sorry the delay guys, I have been swapped these last days.
>
> In summary, everybody that spoke is in favor of the plugin retirement.
> I am
> assuming that people who did not present their opinion agree with 
> the ones
> presented here.
>
> The process to retire this plugin would be the following:
>
>1. Announce in our mailing lists the road map of retirement, a 
> data for
>the final removal should be defined and presented in this road map;
>2. Create a Jira ticket to execute the plugin disabling (is this
>expression right?!), and of course, a PR to disable the build 
> until final
>deletion;
>3. Create a Jira ticket to execute the final removal of the plugin.
> The
>removal should only happen when the defined date comes by;
>4. Wait patiently while time goes by….
>5. When the time comes, create the PR and execute the plugin 
> removal.
>
>
> What date would you guys prefer to execute the plugin removal? 3, 
> 6, or 12
> months from now?
> What do you think of this process? Am I missing something else?
>
>
>
> On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair 
> wrote:
>
> > Complete removal of the plugin was my solution to the problem of 
> the jar
> > file's dependencies. If it's not used or maintained, then it 
> should be
> > removed, in my opinion. Disabling it in the build is a good 
> first step.
> >
> > *Jeff Hair*
> > Technical Lead and Software Developer
> >
> > Tel: (+354) 415 0200
> > j...@greenqloud.com
> > www.greenqloud.com
> >
> > On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav < 
> rohit.ya...@shapeblue.com>
> > wrote:
> >
> > > +1 as others have noted
> > >
> > >
> > > Disable the plugin from the default build for next few releases and
> > > eventually deprecate/remove the plugin from the codebase. The 
> roadmap can
> > > look something like:
> > >
> > > - Announce on the MLs that we're planning to do this, send a 
> PR and get
> > it
> > > accepted
> > >
> > > - During the release process RM should make this information 
> available to
> > > everyone (including voting thread, would be nice to have a 
> shortlog of
> > > major changes in the voting email?)
> > >
> > > - In the release notes and release announcement, note that 
> midonet is no
> > > longer included in the default build and is planned to be 
> deprecated
> > >
> > > - By end of the year, if we've no communication received 
> deprecate and
> > > remove the plugin with an announcement
> > >
> > >
> > > I think this should be done with Midonet and any other plugins 
> that are
> > > causing issues and are no longer maintained by anyway.
> > >
> > >
> > > Regards.
> > >
> > > 
> > > From: Sergey Levitskiy 
> > > Sent: 15 March 2017 07:00:51
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: [DISCUSS] Retirement of midonet plugin
> > >
> > > I am for:
> > >  (i) disable the build for the plugin for the next 2 major release
> > > followed by
> > > (ii)  remove everything in ACS 4.12 if no one express regrets 
> by then
> > >
> > >
> > >
> > >
> > > rohit.ya...@shapeblue.com
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > @shapeblue
> > >
> > >
> > >
> > >
> >
>
>
>
> --
> Rafael Weingärtner
>
>
>
> daan.hoogl...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
>
>
>
>

Re: Welcoming Wido as the new ACS VP

[Wido den Hollander]

Thank you Will and all!

I'll be present at CCC in Miami this year for a 'official' initiation as VP of 
the CloudStack project :)

Wido 

> Op 16 maart 2017 om 18:00 schreef Will Stevens :
> 
> 
> Hello Everyone,
> It has been a pleasure working with you as the ACS VP over the past year.
> I would like to say Thank You to everyone who has supported me in this role
> and have supported the project as a whole.
> 
> It is my pleasure to announce that Wido den Hollander has been voted in to
> replace me as the Apache Cloudstack VP in our annual VP rotation.  Wido has
> a long history with the project and we are happy welcome him into this new
> role.
> 
> Be sure to join us at CCC in Miami [1] so we can initiate him correctly
> over many beers.  :)
> 
> Cheers,
> 
> *Will Stevens*
> 
> ​[1] http://us.cloudstackcollab.org/​

[GitHub] cloudstack issue #1994: CLOUDSTACK-9827: Storage tags stored in multiple pla...

[karuturi]

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1994
  
Thanks @nvazquez Waiting for LGTMs


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] cloudstack issue #1582: CLOUDSTACK-9408 for the move away from download.clou...

[karuturi]

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1582
  
I want this to be updated to use download.cloudstack.org instead of 
cloudstack.apt-get.eu. 
I will send a PR with URL changes to this PR.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] Retirement of midonet plugin

[Will Stevens]

I think there needs to be at least 6 months between the disable code being
released and the delete PR being merged. I feel like the clock has to start
only when the disable code is generally available in a stable release (not
when it is merged).

On Mar 19, 2017 6:47 AM, "Daan Hoogland" 
wrote:

> You are spot on. We can add a due date for the final removal I think.
> Let’s not add a target version, I’d say.
>
> On 18/03/17 23:23, "Rafael Weingärtner" 
> wrote:
>
> Sorry the delay guys, I have been swapped these last days.
>
> In summary, everybody that spoke is in favor of the plugin retirement.
> I am
> assuming that people who did not present their opinion agree with the
> ones
> presented here.
>
> The process to retire this plugin would be the following:
>
>1. Announce in our mailing lists the road map of retirement, a data
> for
>the final removal should be defined and presented in this road map;
>2. Create a Jira ticket to execute the plugin disabling (is this
>expression right?!), and of course, a PR to disable the build until
> final
>deletion;
>3. Create a Jira ticket to execute the final removal of the plugin.
> The
>removal should only happen when the defined date comes by;
>4. Wait patiently while time goes by….
>5. When the time comes, create the PR and execute the plugin
> removal.
>
>
> What date would you guys prefer to execute the plugin removal? 3, 6,
> or 12
> months from now?
> What do you think of this process? Am I missing something else?
>
>
>
> On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair 
> wrote:
>
> > Complete removal of the plugin was my solution to the problem of the
> jar
> > file's dependencies. If it's not used or maintained, then it should
> be
> > removed, in my opinion. Disabling it in the build is a good first
> step.
> >
> > *Jeff Hair*
> > Technical Lead and Software Developer
> >
> > Tel: (+354) 415 0200
> > j...@greenqloud.com
> > www.greenqloud.com
> >
> > On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav <
> rohit.ya...@shapeblue.com>
> > wrote:
> >
> > > +1 as others have noted
> > >
> > >
> > > Disable the plugin from the default build for next few releases and
> > > eventually deprecate/remove the plugin from the codebase. The
> roadmap can
> > > look something like:
> > >
> > > - Announce on the MLs that we're planning to do this, send a PR
> and get
> > it
> > > accepted
> > >
> > > - During the release process RM should make this information
> available to
> > > everyone (including voting thread, would be nice to have a
> shortlog of
> > > major changes in the voting email?)
> > >
> > > - In the release notes and release announcement, note that midonet
> is no
> > > longer included in the default build and is planned to be
> deprecated
> > >
> > > - By end of the year, if we've no communication received deprecate
> and
> > > remove the plugin with an announcement
> > >
> > >
> > > I think this should be done with Midonet and any other plugins
> that are
> > > causing issues and are no longer maintained by anyway.
> > >
> > >
> > > Regards.
> > >
> > > 
> > > From: Sergey Levitskiy 
> > > Sent: 15 March 2017 07:00:51
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: [DISCUSS] Retirement of midonet plugin
> > >
> > > I am for:
> > >  (i) disable the build for the plugin for the next 2 major release
> > > followed by
> > > (ii)  remove everything in ACS 4.12 if no one express regrets by
> then
> > >
> > >
> > >
> > >
> > > rohit.ya...@shapeblue.com
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > @shapeblue
> > >
> > >
> > >
> > >
> >
>
>
>
> --
> Rafael Weingärtner
>
>
>
> daan.hoogl...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>

Re: [DISCUSS] Retirement of midonet plugin

[Will Stevens]

And I forgot to mention that I an +1 on this process...

On Mar 19, 2017 7:39 AM, "Will Stevens"  wrote:

> I think there needs to be at least 6 months between the disable code being
> released and the delete PR being merged. I feel like the clock has to start
> only when the disable code is generally available in a stable release (not
> when it is merged).
>
> On Mar 19, 2017 6:47 AM, "Daan Hoogland" 
> wrote:
>
>> You are spot on. We can add a due date for the final removal I think.
>> Let’s not add a target version, I’d say.
>>
>> On 18/03/17 23:23, "Rafael Weingärtner" 
>> wrote:
>>
>> Sorry the delay guys, I have been swapped these last days.
>>
>> In summary, everybody that spoke is in favor of the plugin
>> retirement. I am
>> assuming that people who did not present their opinion agree with the
>> ones
>> presented here.
>>
>> The process to retire this plugin would be the following:
>>
>>1. Announce in our mailing lists the road map of retirement, a
>> data for
>>the final removal should be defined and presented in this road map;
>>2. Create a Jira ticket to execute the plugin disabling (is this
>>expression right?!), and of course, a PR to disable the build
>> until final
>>deletion;
>>3. Create a Jira ticket to execute the final removal of the
>> plugin. The
>>removal should only happen when the defined date comes by;
>>4. Wait patiently while time goes by….
>>5. When the time comes, create the PR and execute the plugin
>> removal.
>>
>>
>> What date would you guys prefer to execute the plugin removal? 3, 6,
>> or 12
>> months from now?
>> What do you think of this process? Am I missing something else?
>>
>>
>>
>> On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair 
>> wrote:
>>
>> > Complete removal of the plugin was my solution to the problem of
>> the jar
>> > file's dependencies. If it's not used or maintained, then it should
>> be
>> > removed, in my opinion. Disabling it in the build is a good first
>> step.
>> >
>> > *Jeff Hair*
>> > Technical Lead and Software Developer
>> >
>> > Tel: (+354) 415 0200
>> > j...@greenqloud.com
>> > www.greenqloud.com
>> >
>> > On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav <
>> rohit.ya...@shapeblue.com>
>> > wrote:
>> >
>> > > +1 as others have noted
>> > >
>> > >
>> > > Disable the plugin from the default build for next few releases
>> and
>> > > eventually deprecate/remove the plugin from the codebase. The
>> roadmap can
>> > > look something like:
>> > >
>> > > - Announce on the MLs that we're planning to do this, send a PR
>> and get
>> > it
>> > > accepted
>> > >
>> > > - During the release process RM should make this information
>> available to
>> > > everyone (including voting thread, would be nice to have a
>> shortlog of
>> > > major changes in the voting email?)
>> > >
>> > > - In the release notes and release announcement, note that
>> midonet is no
>> > > longer included in the default build and is planned to be
>> deprecated
>> > >
>> > > - By end of the year, if we've no communication received
>> deprecate and
>> > > remove the plugin with an announcement
>> > >
>> > >
>> > > I think this should be done with Midonet and any other plugins
>> that are
>> > > causing issues and are no longer maintained by anyway.
>> > >
>> > >
>> > > Regards.
>> > >
>> > > 
>> > > From: Sergey Levitskiy 
>> > > Sent: 15 March 2017 07:00:51
>> > > To: dev@cloudstack.apache.org
>> > > Subject: Re: [DISCUSS] Retirement of midonet plugin
>> > >
>> > > I am for:
>> > >  (i) disable the build for the plugin for the next 2 major release
>> > > followed by
>> > > (ii)  remove everything in ACS 4.12 if no one express regrets by
>> then
>> > >
>> > >
>> > >
>> > >
>> > > rohit.ya...@shapeblue.com
>> > > www.shapeblue.com
>> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> > > @shapeblue
>> > >
>> > >
>> > >
>> > >
>> >
>>
>>
>>
>> --
>> Rafael Weingärtner
>>
>>
>>
>> daan.hoogl...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
>>
>>
>>
>>

Re: [DISCUSS] Retirement of midonet plugin

[Daan Hoogland]

You are spot on. We can add a due date for the final removal I think. Let’s not 
add a target version, I’d say.

On 18/03/17 23:23, "Rafael Weingärtner"  wrote:

Sorry the delay guys, I have been swapped these last days.

In summary, everybody that spoke is in favor of the plugin retirement. I am
assuming that people who did not present their opinion agree with the ones
presented here.

The process to retire this plugin would be the following:

   1. Announce in our mailing lists the road map of retirement, a data for
   the final removal should be defined and presented in this road map;
   2. Create a Jira ticket to execute the plugin disabling (is this
   expression right?!), and of course, a PR to disable the build until final
   deletion;
   3. Create a Jira ticket to execute the final removal of the plugin. The
   removal should only happen when the defined date comes by;
   4. Wait patiently while time goes by….
   5. When the time comes, create the PR and execute the plugin removal.


What date would you guys prefer to execute the plugin removal? 3, 6, or 12
months from now?
What do you think of this process? Am I missing something else?



On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair  wrote:

> Complete removal of the plugin was my solution to the problem of the jar
> file's dependencies. If it's not used or maintained, then it should be
> removed, in my opinion. Disabling it in the build is a good first step.
>
> *Jeff Hair*
> Technical Lead and Software Developer
>
> Tel: (+354) 415 0200
> j...@greenqloud.com
> www.greenqloud.com
>
> On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav 
> wrote:
>
> > +1 as others have noted
> >
> >
> > Disable the plugin from the default build for next few releases and
> > eventually deprecate/remove the plugin from the codebase. The roadmap 
can
> > look something like:
> >
> > - Announce on the MLs that we're planning to do this, send a PR and get
> it
> > accepted
> >
> > - During the release process RM should make this information available 
to
> > everyone (including voting thread, would be nice to have a shortlog of
> > major changes in the voting email?)
> >
> > - In the release notes and release announcement, note that midonet is no
> > longer included in the default build and is planned to be deprecated
> >
> > - By end of the year, if we've no communication received deprecate and
> > remove the plugin with an announcement
> >
> >
> > I think this should be done with Midonet and any other plugins that are
> > causing issues and are no longer maintained by anyway.
> >
> >
> > Regards.
> >
> > 
> > From: Sergey Levitskiy 
> > Sent: 15 March 2017 07:00:51
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] Retirement of midonet plugin
> >
> > I am for:
> >  (i) disable the build for the plugin for the next 2 major release
> > followed by
> > (ii)  remove everything in ACS 4.12 if no one express regrets by then
> >
> >
> >
> >
> > rohit.ya...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
>



-- 
Rafael Weingärtner



daan.hoogl...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

[GitHub] cloudstack issue #1908: CLOUDSTACK-9317: Fixed disable static nat on leaving...

[cloudmonger]

Github user cloudmonger commented on the issue:

https://github.com/apache/cloudstack/pull/1908
  
### ACS CI BVT Run
 **Sumarry:**
 Build Number 3
 Hypervisor xenserver
 NetworkType Advanced
 Passed=623
 Failed=290
 Skipped=58

_Link to logs Folder (search by build_no):_ 
https://www.dropbox.com/sh/yj3wnzbceo9uef2/AAB6u-Iap-xztdm6jHX9SjPja?dl=0


**Failed tests:**
* test_dhcp_dns_offload.py

 * ContextSuite context=TestDeployVMs>:setup Failed

* test_affinity_groups_projects.py

 * test_01_deploy_vm_anti_affinity_group Failed

 * test_02_deploy_vm_anti_affinity_group_fail_on_not_enough_hosts Failed

 * test_01_list_aff_grps_for_vm Failed

 * test_02_list_multiple_aff_grps_for_vm Failed

 * test_01_update_aff_grp_by_ids Failed

* test_ps_domain_limits.py

 * test_04_create_template_snapshot Failed

* test_ss_domain_limits.py

 * test_04_create_template_delete_account Failed

 * test_04_create_template_delete_account Failing since 2 runs

 * test_01_multiple_domains_secondary_storage_limits Failed

 * test_01_multiple_domains_secondary_storage_limits Failing since 2 runs

 * test_02_multiple_domains_secondary_storage_counts Failed

* test_deploy_vm_userdata_multi_nic.py

 * test_deployvm_multinic Failed

* test_vpn_service.py

 * test_01_VPN_service Failed

* test_organization_states.py

 * ContextSuite context=TestOrganizationStates>:setup Failed

* test_escalations_snapshots.py

 * ContextSuite context=TestSnapshots>:setup Failed

* test_dynamic_compute_offering.py

 * test_max_account_memory_scale_VM_1_ADMIN_ACCOUNT Failed

 * test_max_account_memory_scale_VM_2_USER_ACCOUNT Failed

 * test_deploy_VM_with_affinity_group_1_ADMIN_ACCOUNT Failed

 * test_deploy_VM_with_affinity_group_2_USER_ACCOUNT Failed

 * ContextSuite context=TestDynamicServiceOffering>:setup Failed

 * test_change_so_running_vm_dynamic_to_dynamic_1_ADMIN_ACCOUNT Failed

 * test_change_so_running_vm_dynamic_to_dynamic_2_USER_ACCOUNT Failed

 * test_change_so_running_vm_dynamic_to_static_1_ADMIN_ACCOUNT Failed

 * test_change_so_running_vm_dynamic_to_static_2_USER_ACCOUNT Failed

 * test_change_so_running_vm_static_to_dynamic_1_ADMIN_ACCOUNT Failed

 * test_change_so_running_vm_static_to_dynamic_2_USER_ACCOUNT Failed

 * test_change_so_running_vm_static_to_static_1_ADMIN_ACCOUNT Failed

 * test_change_so_running_vm_static_to_static_2_USER_ACCOUNT Failed

 * test_change_so_stopped_vm_dynamic_to_dynamic_1_ADMIN_ACCOUNT Failed

 * test_change_so_stopped_vm_dynamic_to_dynamic_2_USER_ACCOUNT Failed

 * test_change_so_stopped_vm_dynamic_to_static_1_ADMIN_ACCOUNT Failed

 * test_change_so_stopped_vm_dynamic_to_static_2_USER_ACCOUNT Failed

 * test_change_so_stopped_vm_static_to_dynamic_1_ADMIN_ACCOUNT Failed

 * test_change_so_stopped_vm_static_to_dynamic_2_USER_ACCOUNT Failed

 * test_change_so_stopped_vm_static_to_static_1_ADMIN_ACCOUNT Failed

* test_ps_resource_limits_volume.py

 * test_attach_volume_exceeding_primary_limits Failed

* test_vpc.py

 * test_07_restart_network_vm_running Failed

 * test_08_delete_vpc Failed

 * test_11_deploy_vm_wo_network_netdomain Failed

 * test_13_deploy_vm_with_vpc_netdomain Failed

 * test_14_deploy_vm_1 Failed

 * test_15_deploy_vm_2 Failed

 * test_16_deploy_vm_for_user_by_admin Failed

 * test_21_deploy_vm_with_gateway_ip Failed

 * test_22_vpn_customer_gw_with_hostname Failed

* test_non_contiguous_vlan.py

 * test_01_add_non_contiguous_ranges Failed

* test_project_usage.py

 * ContextSuite context=TestLBRuleUsage>:setup Failed

 * ContextSuite context=TestNatRuleUsage>:setup Failed

 * ContextSuite context=TestPublicIPUsage>:setup Failed

 * ContextSuite context=TestSnapshotUsage>:setup Failed

 * ContextSuite context=TestVmUsage>:setup Failed

 * ContextSuite context=TestVolumeUsage>:setup Failed

 * ContextSuite context=TestVpnUsage>:setup Failed

* test_ps_max_limits.py

 * test_01_deploy_vm_domain_limit_reached Failed

 * test_02_deploy_vm_account_limit_reached Failed

 * test_03_deploy_vm_project_limit_reached Failed

* test_project_resources.py

 * test_07_associate_public_ip Failed

* test_vpc_network_staticnatrule.py

 * test_01_VPC_StaticNatRuleCreateStoppedState Failed

 * test_03_VPC_StopCreateMultipleStaticNatRuleStopppedState Failed

 * test_04_VPC_CreateMultipleStaticNatRule Failed

 *