[GitHub] cloudstack issue #1960: [4.11/Future] CLOUDSTACK-9782: Host HA and KVM HA pr...

[blueorangutan]

Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1960
  
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-600


---
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.
---

to value objects for one table

[Daan Hoogland]

Dear Devs,

I just came across a strange oder in the code that might have a background that 
some of you know about;

@Entity
@Table(name = "template_spool_ref")
public class VMTemplateStoragePoolVO implements VMTemplateStorageResourceAssoc, 
DataObjectInStore {…}

and

@Entity
@Table(name = "template_spool_ref")
public class TemplatePrimaryDataStoreVO implements 
StateObject {…)

seem to represent data from the same table. Both are pretty old. Is there a 
reason other than the implementation of different interfaces that these should 
both be maintained?

Regards,


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

two value objects for one table

[Daan Hoogland]

Subject spelling correct (

On 27/03/17 09:15, "Daan Hoogland"  wrote:

Dear Devs,

I just came across a strange oder in the code that might have a background 
that some of you know about;

@Entity
@Table(name = "template_spool_ref")
public class VMTemplateStoragePoolVO implements 
VMTemplateStorageResourceAssoc, DataObjectInStore {…}

and

@Entity
@Table(name = "template_spool_ref")
public class TemplatePrimaryDataStoreVO implements 
StateObject {…)

seem to represent data from the same table. Both are pretty old. Is there a 
reason other than the implementation of different interfaces that these should 
both be maintained?

Regards,


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




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

[GitHub] cloudstack issue #1960: [4.11/Future] CLOUDSTACK-9782: Host HA and KVM HA pr...

[borisstoyanov]

Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/1960
  
@blueorangutan test


---
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 #1960: [4.11/Future] CLOUDSTACK-9782: Host HA and KVM HA pr...

[blueorangutan]

Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1960
  
@borisstoyanov a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has 
been kicked to run smoke tests


---
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: two value objects for one table

[Wei ZHOU]

the files in engine/storage/src/org/apache/cloudstack/storage/volume/db are
not in use.
They can be removed.
The lines
in 
engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-core-daos-context.xml
also need to be removed.

-Wei


2017-03-27 9:23 GMT+02:00 Daan Hoogland :

> Subject spelling correct (
>
> On 27/03/17 09:15, "Daan Hoogland"  wrote:
>
> Dear Devs,
>
> I just came across a strange oder in the code that might have a
> background that some of you know about;
>
> @Entity
> @Table(name = "template_spool_ref")
> public class VMTemplateStoragePoolVO implements
> VMTemplateStorageResourceAssoc, DataObjectInStore {…}
>
> and
>
> @Entity
> @Table(name = "template_spool_ref")
> public class TemplatePrimaryDataStoreVO implements StateObject<
> ObjectInDataStoreStateMachine.State> {…)
>
> seem to represent data from the same table. Both are pretty old. Is
> there a reason other than the implementation of different interfaces that
> these should both be maintained?
>
> Regards,
>
>
> daan.hoogl...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>
>
>
> daan.hoogl...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>

[GitHub] cloudstack issue #2019: CLOUDSTACK-9851 travis CI build failure after merge ...

[yvsubhash]

Github user yvsubhash commented on the issue:

https://github.com/apache/cloudstack/pull/2019
  
LGTM for code changes


---
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: two value objects for one table

[Daan Hoogland]

Wei,

That means deleting the one that has been touched last, but you are right. It 
also leads me to a bunch of other classes that can be deleted (


On 27/03/17 10:19, "Wei ZHOU"  wrote:

the files in engine/storage/src/org/apache/cloudstack/storage/volume/db are
not in use.
They can be removed.
The lines
in 
engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-core-daos-context.xml
also need to be removed.

-Wei


2017-03-27 9:23 GMT+02:00 Daan Hoogland :

> Subject spelling correct (
>
> On 27/03/17 09:15, "Daan Hoogland"  wrote:
>
> Dear Devs,
>
> I just came across a strange oder in the code that might have a
> background that some of you know about;
>
> @Entity
> @Table(name = "template_spool_ref")
> public class VMTemplateStoragePoolVO implements
> VMTemplateStorageResourceAssoc, DataObjectInStore {…}
>
> and
>
> @Entity
> @Table(name = "template_spool_ref")
> public class TemplatePrimaryDataStoreVO implements StateObject<
> ObjectInDataStoreStateMachine.State> {…)
>
> seem to represent data from the same table. Both are pretty old. Is
> there a reason other than the implementation of different interfaces that
> these should both be maintained?
>
> Regards,
>
>
> daan.hoogl...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>
>
>
> daan.hoogl...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>



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

[GitHub] cloudstack issue #905: BUG-ID: CLOUDSTACK-8922: Unable to delete IP tag

[niteshsarda]

Github user niteshsarda commented on the issue:

https://github.com/apache/cloudstack/pull/905
  
I have tested this and **LGTM** for test.


---
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 #876: CLOUDSTACK-8865: Adding SR doesn't create Storage_poo...

[mrunalinikankariya]

Github user mrunalinikankariya commented on the issue:

https://github.com/apache/cloudstack/pull/876
  
LGTM on the code changes


---
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 #1734: CLOUDSTACK-9567 Difference in the api call outputs f...

[jayantpatil1234]

Github user jayantpatil1234 commented on the issue:

https://github.com/apache/cloudstack/pull/1734
  
I have tested this and **LGTM** for test. 


---
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.
---

S3 as Secondary Storage

[Will Stevens]

Hey All,
If anyone is using S3 as Secondary Storage in production (or even testing
at this point), please respond to this thread.

We have been using Swift in production for the last couple years and I
think we have worked out most of the kinks.  Not all of our fixes have been
pushed upstream yet because the Swift and S3 integrations are very
intertwined and we did not want to break the S3 implementation with our
Swift fixes.

We would like to get a sense of the stability of the S3 implementation to
see if it is also a good option as an object based secondary storage.

Thanks,

*Will Stevens*

[PROPOSAL] Storage Load Balancing

[Anshul Gangwar]

Hi All,

I would like to propose the storage load balancing feature. Please find the FS 
for the same at 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+Load+balancing.

Regards,
Anshul



DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the 
property of Accelerite, a Persistent Systems business. It is intended only for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient, you are not authorized to read, retain, copy, print, 
distribute or use this message. If you have received this communication in 
error, please notify the sender and delete all copies of this message. 
Accelerite, a Persistent Systems business does not accept any liability for 
virus infected mails.

[GitHub] cloudstack issue #1971: CLOUDSTACK-9726 Update state is not changed to UPDAT...

[bvbharatk]

Github user bvbharatk commented on the issue:

https://github.com/apache/cloudstack/pull/1971
  
@borisstoyanov 
ran test/integration/component/maint/test_redundant_router.py .

Test create network with non-default guest cidr with redundant routers ... 
=== TestName: test_createRvRNetwork | Status : SUCCESS ===
ok
Test create RvR supported network offering ... === TestName: 
test_createRvRNetworkOffering | Status : SUCCESS ===
ok
Test redundant router internals ... === TestName: 
test_redundantVR_internals | Status : SUCCESS ===
ok
Test stop master RVR ... === TestName: test_01_stopMasterRvR | Status : 
SUCCESS ===
ok
Test stop backup RVR ... === TestName: test_02_stopBackupRvR | Status : 
SUCCESS ===
ok
Test reboot master RVR ... === TestName: test_03_rebootMasterRvR | Status : 
SUCCESS ===
ok
Test reboot backup RVR ... === TestName: test_04_rebootBackupRvR | Status : 
SUCCESS ===
ok
Test stop backup RVR and start instance ... === TestName: 
test_05_stopBackupRvR_startInstance | Status : SUCCESS ===
ok
Test update network and check if VRs are updated in sequence ... === 
TestName: test_06_updateVRs_in_sequence | Status : SUCCESS ===
ok


---
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

[Rafael Weingärtner]

Sorry for the delay guys. I have been a little busy lately.

I will write down a wiki page detailing the code retirement steps. Then, I
will proceed and kick off the Midonet plugin retirement process.

On Mon, Mar 20, 2017 at 3:39 AM, Daan Hoogland 
wrote:

> Don’t worry Marty, non-committers/-coders will be heard here as well.
>
> Good point @swill I think we have enough wording to call this a policy
> now… As so far, no objections of any kind have been raised I also think it
> is now official unless someone now starts shouting. Here is a semi-formal
> definition of the procedure.
>
> Code that is not maintained and breaks the build will be phased out
> according to the following retirement procedure:
>
> 1. An 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; This
> will be in terms of “The firsts release after /mm/dd”
> 2. If no objection arises or no one volunteers to maintain the code, a
> Jira ticket to disable of the code is created.
> 3. A patch to disable the code in the build will be created.
> 4. The patch is applied and released with the next x.y.0 release.
> 5. A Jira ticket to execute the final removal of the code is created.
> 6. A patch for the definite removal of the code is created.
> 7. The patch will be applied 6 months after the x.y.0 release is announced
> and thus be release with x.(y+n).0 (n probably being 1 but could be higher)
>
>
> On 19/03/17 18:53, "Marty Godsey"  wrote:
>
> 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
> 

Re: [DISCUSS] Retirement of midonet plugin

[Erik Weber]

Personally I would be in favour of using releases rather than months
as time unit.
Our release schedule is very unpredictable, and it's hard to foresee
how many releases we've rolled out in 6 months.

Deprecate in the next (4.11?), remove a few releases later (4.13?).

-- 
Erik

On Sat, Mar 18, 2017 at 11:23 PM, 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

[GitHub] cloudstack issue #2019: CLOUDSTACK-9851 travis CI build failure after merge ...

[serg38]

Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/2019
  
LGTM


---
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 #1813: CLOUDSTACK-9604: Root disk resize support for VMware...

[serg38]

Github user serg38 commented on the issue:

https://github.com/apache/cloudstack/pull/1813
  
@cloudsadhu Thanks for the changes. LGTM on the code review. @borisstoyanov 
@rhtyd @DaanHoogland Can you kick off another round of test for vmware and Xen 
for 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: S3 as Secondary Storage

[Wido den Hollander]

> Op 27 maart 2017 om 14:09 schreef Will Stevens :
> 
> 
> Hey All,
> If anyone is using S3 as Secondary Storage in production (or even testing
> at this point), please respond to this thread.
> 

We are. Using Ceph's RADOS Gateway (Hammer, 0.94.11) as the gateway with 
CloudStack 4.5 (Yes... ;( ).

> We have been using Swift in production for the last couple years and I
> think we have worked out most of the kinks.  Not all of our fixes have been
> pushed upstream yet because the Swift and S3 integrations are very
> intertwined and we did not want to break the S3 implementation with our
> Swift fixes.
> 
> We would like to get a sense of the stability of the S3 implementation to
> see if it is also a good option as an object based secondary storage.
> 

It is, but our experiences are mainly with 4.5. It still uses a ancient version 
of the AWS S3 SDK and that causes most of our troubles.

In general we however see the ACS copies a lot of Objects to the S3 store and 
downloads them again afterwards. Not always the best thing. I wouldn't use 
Amazon S3 directly as that might cause a lot of data transfer.

Should be running 4.9 within 4 weeks, can report on it a lot better then.

Wido

> Thanks,
> 
> *Will Stevens*

[GitHub] cloudstack issue #1955: CLOUDSTACK-8239 Add VirtIO SCSI support for KVM host...

[wido]

Github user wido commented on the issue:

https://github.com/apache/cloudstack/pull/1955
  
Yes, we are indeed ready for a merge. Shall we do that?


---
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: S3 as Secondary Storage

[Will Stevens]

Thanks Wido.  Yes, we have the same 'outdated' SDK being used issue for
Swift as well.  It is embedded in the code and it is ancient.  I have not
had a chance to get in there and update to a recent library.

We upgraded our setup from 4.4 -> 4.7 and we are in the process of
validating 4.10 as our next release base.

We have also found the 'upload to object store, then download again right
away' to be slow and very inefficient.  We have considered reimplementing
that logic, but we have not gotten to it yet.

I will be interested to hear how things go with 4.9.

Thanks for the feedback Wido.  :)

*Will Stevens*



On Mon, Mar 27, 2017 at 10:08 AM, Wido den Hollander  wrote:

>
> > Op 27 maart 2017 om 14:09 schreef Will Stevens :
> >
> >
> > Hey All,
> > If anyone is using S3 as Secondary Storage in production (or even testing
> > at this point), please respond to this thread.
> >
>
> We are. Using Ceph's RADOS Gateway (Hammer, 0.94.11) as the gateway with
> CloudStack 4.5 (Yes... ;( ).
>
> > We have been using Swift in production for the last couple years and I
> > think we have worked out most of the kinks.  Not all of our fixes have
> been
> > pushed upstream yet because the Swift and S3 integrations are very
> > intertwined and we did not want to break the S3 implementation with our
> > Swift fixes.
> >
> > We would like to get a sense of the stability of the S3 implementation to
> > see if it is also a good option as an object based secondary storage.
> >
>
> It is, but our experiences are mainly with 4.5. It still uses a ancient
> version of the AWS S3 SDK and that causes most of our troubles.
>
> In general we however see the ACS copies a lot of Objects to the S3 store
> and downloads them again afterwards. Not always the best thing. I wouldn't
> use Amazon S3 directly as that might cause a lot of data transfer.
>
> Should be running 4.9 within 4 weeks, can report on it a lot better then.
>
> Wido
>
> > Thanks,
> >
> > *Will Stevens*
>

Re: [DISCUSS] Retirement of midonet plugin

[Daan Hoogland]

I am against that
Strain on the community is not in releases but in time. We already guarantee it 
is at least one minor

On 27/03/17 15:24, "Erik Weber"  wrote:

Personally I would be in favour of using releases rather than months
as time unit.
Our release schedule is very unpredictable, and it's hard to foresee
how many releases we've rolled out in 6 months.

Deprecate in the next (4.11?), remove a few releases later (4.13?).

-- 
Erik

On Sat, Mar 18, 2017 at 11:23 PM, 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 #1606: Allow CGN (RFC6598) to be used within a VPC

[rossor]

Github user rossor commented on the issue:

https://github.com/apache/cloudstack/pull/1606
  
Is it appropriate to add a comparatively complex integration test to cover 
a functional predicate whose cognitive load is so small?

I will expand the associated unit test to include boundary conditions 
testing of the CGN address range, and that would seem to me to be sufficient. 
Please advise.

@karuturi


---
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 we are planning to do something like "at least 6 months" because of
the irregularity of releases.  This gives us a date (from when the
announcement was release becomes available) till the PR to remove gets
merged.  That PR will then be included in the next release whenever it is.
So if the "time" is 6 months, it could actually be closer to 9 months
before it actually gets removes since the release may not be ready to be
cut at 6 months.

Does this make sense?  It gives us a way to have a date alert when a PR
should be merged rather than trying to track which releases each
decommissioned item is targeted for, which could mess up timing if there is
some long release cycles as well as short ones...

*Will STEVENS*
Lead Developer



On Mon, Mar 27, 2017 at 9:46 AM, Daan Hoogland 
wrote:

> I am against that
> Strain on the community is not in releases but in time. We already
> guarantee it is at least one minor
>
> On 27/03/17 15:24, "Erik Weber"  wrote:
>
> Personally I would be in favour of using releases rather than months
> as time unit.
> Our release schedule is very unpredictable, and it's hard to foresee
> how many releases we've rolled out in 6 months.
>
> Deprecate in the next (4.11?), remove a few releases later (4.13?).
>
> --
> Erik
>
> On Sat, Mar 18, 2017 at 11:23 PM, 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
> 

[GitHub] cloudstack issue #2019: CLOUDSTACK-9851 travis CI build failure after merge ...

[SudharmaJain]

Github user SudharmaJain commented on the issue:

https://github.com/apache/cloudstack/pull/2019
  
tag:mergeready


---
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 #1960: [4.11/Future] CLOUDSTACK-9782: Host HA and KVM HA pr...

[blueorangutan]

Github user blueorangutan commented on the issue:

https://github.com/apache/cloudstack/pull/1960
  
Trillian test result (tid-963)
Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
Total time taken: 34953 seconds
Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr1960-t963-kvm-centos7.zip
Intermitten failure detected: /marvin/tests/smoke/test_ha_kvm_agent.py
Intermitten failure detected: /marvin/tests/smoke/test_hostha_simulator.py
Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py
Intermitten failure detected: /marvin/tests/smoke/test_snapshots.py
Intermitten failure detected: /marvin/tests/smoke/test_templates.py
Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py
Test completed. 49 look ok, 3 have error(s)


Test | Result | Time (s) | Test File
--- | --- | --- | ---
test_02_redundant_VPC_default_routes | `Failure` | 874.51 | 
test_vpc_redundant.py
test_04_rvpc_privategw_static_routes | `Failure` | 330.43 | 
test_privategw_acl.py
test_02_list_snapshots_with_removed_data_store | `Error` | 0.04 | 
test_snapshots.py
test_ha_list_providers | `Error` | 0.02 | test_hostha_simulator.py
test_01_vpc_site2site_vpn | Success | 170.43 | test_vpc_vpn.py
test_01_vpc_remote_access_vpn | Success | 66.20 | test_vpc_vpn.py
test_01_redundant_vpc_site2site_vpn | Success | 260.69 | test_vpc_vpn.py
test_02_VPC_default_routes | Success | 277.21 | test_vpc_router_nics.py
test_01_VPC_nics_after_destroy | Success | 548.46 | test_vpc_router_nics.py
test_05_rvpc_multi_tiers | Success | 527.13 | test_vpc_redundant.py
test_04_rvpc_network_garbage_collector_nics | Success | 1330.72 | 
test_vpc_redundant.py
test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | 
Success | 559.52 | test_vpc_redundant.py
test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1286.51 | 
test_vpc_redundant.py
test_09_delete_detached_volume | Success | 157.14 | test_volumes.py
test_08_resize_volume | Success | 156.39 | test_volumes.py
test_07_resize_fail | Success | 156.44 | test_volumes.py
test_06_download_detached_volume | Success | 156.36 | test_volumes.py
test_05_detach_volume | Success | 155.84 | test_volumes.py
test_04_delete_attached_volume | Success | 151.22 | test_volumes.py
test_03_download_attached_volume | Success | 156.28 | test_volumes.py
test_02_attach_volume | Success | 124.18 | test_volumes.py
test_01_create_volume | Success | 711.49 | test_volumes.py
test_03_delete_vm_snapshots | Success | 275.19 | test_vm_snapshots.py
test_02_revert_vm_snapshots | Success | 100.65 | test_vm_snapshots.py
test_01_create_vm_snapshots | Success | 158.72 | test_vm_snapshots.py
test_deploy_vm_multiple | Success | 277.88 | test_vm_life_cycle.py
test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py
test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py
test_10_attachAndDetach_iso | Success | 31.69 | test_vm_life_cycle.py
test_09_expunge_vm | Success | 125.26 | test_vm_life_cycle.py
test_08_migrate_vm | Success | 30.92 | test_vm_life_cycle.py
test_07_restore_vm | Success | 0.13 | test_vm_life_cycle.py
test_06_destroy_vm | Success | 125.86 | test_vm_life_cycle.py
test_03_reboot_vm | Success | 125.85 | test_vm_life_cycle.py
test_02_start_vm | Success | 10.17 | test_vm_life_cycle.py
test_01_stop_vm | Success | 40.35 | test_vm_life_cycle.py
test_CreateTemplateWithDuplicateName | Success | 40.45 | test_templates.py
test_08_list_system_templates | Success | 0.04 | test_templates.py
test_07_list_public_templates | Success | 0.04 | test_templates.py
test_05_template_permissions | Success | 0.09 | test_templates.py
test_04_extract_template | Success | 5.31 | test_templates.py
test_03_delete_template | Success | 5.13 | test_templates.py
test_02_edit_template | Success | 90.14 | test_templates.py
test_01_create_template | Success | 25.34 | test_templates.py
test_10_destroy_cpvm | Success | 161.72 | test_ssvm.py
test_09_destroy_ssvm | Success | 163.91 | test_ssvm.py
test_08_reboot_cpvm | Success | 101.57 | test_ssvm.py
test_07_reboot_ssvm | Success | 133.59 | test_ssvm.py
test_06_stop_cpvm | Success | 131.74 | test_ssvm.py
test_05_stop_ssvm | Success | 133.64 | test_ssvm.py
test_04_cpvm_internals | Success | 1.18 | test_ssvm.py
test_03_ssvm_internals | Success | 3.41 | test_ssvm.py
test_02_list_cpvm_vm | Success | 0.13 | test_ssvm.py
test_01_list_sec_storage_vm | Success | 0.14 | test_ssvm.py
test_01_snapshot_root_disk | Success | 11.13 | test_snapshots.py
test_04_change_offering_small | Success | 239.66 | test_service_offerings.py
test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py
test_02_edit_service_offering | Success | 0.07

Re: [DISCUSS] Retirement of midonet plugin

[Rafael Weingärtner]

The process described by Will is what I was seeing/understating so far.
Thus, we do not need to be bound by a specific release, but rather by a
timeline. After the PR that includes the removal/disabling of the plugin
gets merged (will happen according to the timeline defined) the changes
will be in the next release (after the merge) and forward.

On Mon, Mar 27, 2017 at 12:03 PM, Will Stevens 
wrote:

> I think we are planning to do something like "at least 6 months" because of
> the irregularity of releases.  This gives us a date (from when the
> announcement was release becomes available) till the PR to remove gets
> merged.  That PR will then be included in the next release whenever it is.
> So if the "time" is 6 months, it could actually be closer to 9 months
> before it actually gets removes since the release may not be ready to be
> cut at 6 months.
>
> Does this make sense?  It gives us a way to have a date alert when a PR
> should be merged rather than trying to track which releases each
> decommissioned item is targeted for, which could mess up timing if there is
> some long release cycles as well as short ones...
>
> *Will STEVENS*
> Lead Developer
>
> 
>
> On Mon, Mar 27, 2017 at 9:46 AM, Daan Hoogland <
> daan.hoogl...@shapeblue.com>
> wrote:
>
> > I am against that
> > Strain on the community is not in releases but in time. We already
> > guarantee it is at least one minor
> >
> > On 27/03/17 15:24, "Erik Weber"  wrote:
> >
> > Personally I would be in favour of using releases rather than months
> > as time unit.
> > Our release schedule is very unpredictable, and it's hard to foresee
> > how many releases we've rolled out in 6 months.
> >
> > Deprecate in the next (4.11?), remove a few releases later (4.13?).
> >
> > --
> > Erik
> >
> > On Sat, Mar 18, 2017 at 11:23 PM, 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 maint

Re: [DISCUSS] Retirement of midonet plugin

[Erik Weber]

Sounds good :-)


Erik

man. 27. mar. 2017 kl. 18.03 skrev Will Stevens :

> I think we are planning to do something like "at least 6 months" because of
> the irregularity of releases.  This gives us a date (from when the
> announcement was release becomes available) till the PR to remove gets
> merged.  That PR will then be included in the next release whenever it is.
> So if the "time" is 6 months, it could actually be closer to 9 months
> before it actually gets removes since the release may not be ready to be
> cut at 6 months.
>
> Does this make sense?  It gives us a way to have a date alert when a PR
> should be merged rather than trying to track which releases each
> decommissioned item is targeted for, which could mess up timing if there is
> some long release cycles as well as short ones...
>
> *Will STEVENS*
> Lead Developer
>
> 
>
> On Mon, Mar 27, 2017 at 9:46 AM, Daan Hoogland <
> daan.hoogl...@shapeblue.com>
> wrote:
>
> > I am against that
> > Strain on the community is not in releases but in time. We already
> > guarantee it is at least one minor
> >
> > On 27/03/17 15:24, "Erik Weber"  wrote:
> >
> > Personally I would be in favour of using releases rather than months
> > as time unit.
> > Our release schedule is very unpredictable, and it's hard to foresee
> > how many releases we've rolled out in 6 months.
> >
> > Deprecate in the next (4.11?), remove a few releases later (4.13?).
> >
> > --
> > Erik
> >
> > On Sat, Mar 18, 2017 at 11:23 PM, 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
> > >> >
> >   

[GitHub] cloudstack issue #1889: CLOUDSTACK-9718: Revamp the dropdown showing lists o...

[rashmidixit]

Github user rashmidixit commented on the issue:

https://github.com/apache/cloudstack/pull/1889
  
@karuturi requesting you to merge these changes.


---
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 #1994: CLOUDSTACK-9827: Storage tags stored in multiple pla...

[karuturi]

Github user karuturi commented on the issue:

https://github.com/apache/cloudstack/pull/1994
  
Thank you all. I will merge #1961 and #1994 now


---
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 #1961: Fix for test_snapshots.py using nfs2 instead ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #1994: CLOUDSTACK-9827: Storage tags stored in multi...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 #2019: CLOUDSTACK-9851 travis CI build failure after merge ...

[koushik-das]

Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/2019
  
@SudharmaJain Although the PR fixes the tests but it is not correct. I 
looked at PR #1953 and the changes there are incorrect.

getMaxDataVolumes() returns only the data volume count by excluding the 
root and cd-rom device. That PR is again subtracting them which results in 
incorrect limit.


---
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 #1953: CLOUDSTACK-9794: Unable to attach more than 14 devic...

[koushik-das]

Github user koushik-das commented on the issue:

https://github.com/apache/cloudstack/pull/1953
  
@karuturi This PR is not correct and is resulting in travis CI failures. It 
needs to be properly fixed.


---
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 #1960: [4.11/Future] CLOUDSTACK-9782: Host HA and KVM HA pr...

[borisstoyanov]

Github user borisstoyanov commented on the issue:

https://github.com/apache/cloudstack/pull/1960
  
@rhtyd there seems to be a conflict for this merge, I'm currently running 
tests and will keep you posted


---
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 #1844: CLOUDSTACK-9668 : disksizeallocated of PrimaryStorag...

[jayakarteek]

Github user jayakarteek commented on the issue:

https://github.com/apache/cloudstack/pull/1844
  
Tested the scenario.
results are as below
select * from storage_pool;
# id, name, uuid, pool_type, port, data_center_id, pod_id, cluster_id, 
used_bytes, capacity_bytes, host_address, user_info, path, created, removed, 
update_time, status, storage_provider_name, scope, hypervisor, managed, 
capacity_iops
'11', 'pr_2', '80a753bb-6fad-3938-b657-ae62f6119804', 'NetworkFilesystem', 
'2049', '1', NULL, NULL, '4140196372480', '590228480', '10.147.28.7', NULL, 
'/export/home/jayakarteek/PR', '2017-03-28 05:54:28', NULL, NULL, 'Up', 
'DefaultPrimary', 'ZONE', 'VMware', '0', NULL

select * from  op_host_capacity;   **After attaching disk** 
id, host_id, data_center_id, pod_id, cluster_id, used_capacity, 
reserved_capacity, total_capacity, capacity_type, capacity_state, update_time, 
created
'11', '11', '1', NULL, NULL, '18253611008', '0', '1180456960', '3', 
'Enabled', '2017-03-28 05:57:58', '2017-03-28 05:57:58'
select * from  op_host_capacity;   **After detaching and deleting the disk**
# id, host_id, data_center_id, pod_id, cluster_id, used_capacity, 
reserved_capacity, total_capacity, capacity_type, capacity_state, update_time, 
created
'11', '11', '1', NULL, NULL, '0', '0', '1180456960', '3', 'Enabled', 
'2017-03-28 06:22:58', '2017-03-28 05:57:58'




---
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 #2019: CLOUDSTACK-9851 travis CI build failure after merge ...

[SudharmaJain]

Github user SudharmaJain commented on the issue:

https://github.com/apache/cloudstack/pull/2019
  
Thanks @koushik-das for reviewing this. So Let me close this and root 
volume detach should also be fixed as a part of PR #1953.


---
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.
---