Re: 4.9+ release

[Daan Hoogland]

maybe I should have answered here instead of the other thread :S

I am all with John on this. I can not judge the dates but the overall ideas
are spot on.

I now see the API weren't mentioned in this thread I think they should.

On Wed, Jun 15, 2016 at 1:53 AM, ilya  wrote:

> I agree and support John's comments below.
>
> Regards
> ilya
>
> On 6/14/16 2:44 PM, John Burwell wrote:
> > All,
> >
> > Completely agree with Daan.  Per semantic versioning, a major revision
> increase must introduce a backwards incompatible change in the public API,
> removal of one of more supported devices, reduction in the list of
> supported distributions.  I agree that when we require Java8+, drop Ubuntu
> 12.04 support, drop support for an old hypervisor version, etc,  we will
> need to increment the major revision to reflect the fact that the release
> is not backwards compatible.
> >
> > For 4.10 and LTS 4.9.0_1, I see it as critical that we support running
> on either Java7 or Java8.  In particular, producing an LTS release that
> only supports a JVM that has been unsupported for nearly 18 months would
> make it DOA in many shops.
> >
> > It seems like it would make sense to have a 5.0.0 release that removed
> support for a number of legacy components (e.g. Xen 6.0 possibly 6.2,
> Java7, CentOS 5, etc), as well as, internal improvements (e.g. simplified
> configuration).  The focus of this release would be to reduce the footprint
> of codebase, as well as, make a set of backwards incompatible changes that
> further decouples plugins from core.  We would then plan for a 6.0.0 in
> 4Q2017 to introduce further architectural changes and API revisions.  The
> advantage to this approach is that it breaks up the large refactorings and
> architectural design changes — allowing us to gain velocity by removing
> legacy components, reducing the risk of these changes, and providing user
> benefit earlier.  Based on the release plan I previously proposed we have
> the following releases remaining in 2016 and in early 2017:
> >
> > * 4.10 releasing on or about 28 August 2016
> > * 4.11 releasing on or about 23 October 2016
> > * 4.12 releasing on or about 18 December 2016
> > * 4.13 release on or about 5 February 2017
> >
> > 4.12 seems to be the sweet spot in the schedule to cut the 5.0.0 release
> described above.  It would give us sometime to plan and gain consensus
> around the changes in both the user and dev communities.  It would also
> allow the second LTS release to be based on 5.0.0 — allowing both release
> cycles to take advantage of the reduced support requirements and Java8
> language features. Based on this proposal, the releases above would change
> to the following:
> >
> > * 4.10 releasing on or about 28 August 2016
> > * 4.11 releasing on or about 23 October 2016
> > * 5.0.0 releasing on or about 18 December 2016
> > * 5.1.0 release on or about 5 February 2017
> >
> > I am in the process of moving my proposal into the wiki.  If this
> approach is acceptable, I will reflect it there, and open a thread to
> discuss 5.0.0.
> >
> > Thanks,
> > -John
> >
> >
> >>
> > john.burw...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> > @shapeblue
> >
> >
> > On Jun 14, 2016, at 2:02 PM, Paul Angus 
> wrote:
> >>
> >> +1 Daan.
> >>
> >> My recollection was that major version number changes were only to be
> triggered by breaks in backward compatibility (API).
> >>
> >>
> >> Kind regards,
> >>
> >> Paul Angus
> >>
> >> paul.an...@shapeblue.com
> >> www.shapeblue.com
> >> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> >> @shapeblue
> >>
> >>
> >>
> >> -Original Message-
> >> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> >> Sent: 14 June 2016 14:47
> >> To: dev 
> >> Cc: Rajani Karuturi 
> >> Subject: Re: 4.9+ release
> >>
> >> You know that would require more then one byte for our minor version,
> Will.
> >> I would be very pleased to go to 5.0 before that time.
> >>
> >> On Tue, Jun 14, 2016 at 3:43 PM, Will Stevens 
> wrote:
> >>
> >>> Daan is just trying to get us to version 4.256.  :P
> >>>
> >>> *Will STEVENS*
> >>> Lead Developer
> >>>
> >>> *CloudOps* *| *Cloud Solutions Experts
> >>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw
> >>> @CloudOps_
> >>>
> >>> On Tue, Jun 14, 2016 at 9:41 AM, Daan Hoogland
> >>> 
> >>> wrote:
> >>>
>  -1 to what Wido said. None of those points warant a major release
>  number upgrade. these should all be in 4.10, -.11, -12 etc.
> 
>  major incompatibilities like API refactor, dropping backend support
>  for this or that hyporvisor or DB refactor are the things that
>  warrant 5.0, IMNSHO
> 
>  On Tue, Jun 14, 2016 at 1:13 PM, Will Stevens
>  
>  wrote:
> 
> > +1. :)
> > On Jun 14, 2016 5:07 AM, "Wido den Hollander" 
> wrote:
> >
> >>
> >>> Op 14 juni 2016 om 10:55 schreef Rajani Karuturi <
> >>> raj...@apache.org
> > :
> >>>
> 

Re: .install and .postinstall files

[Wido den Hollander]

> Op 14 juni 2016 om 18:09 schreef Nicolás Vázquez :
> 
> 
> Thanks Rafael! My bad, it was '.postinst' extension instead of
> '.postinstall'
> 

These files are included the dpkg when building the .deb packages.

They are executed post-installation when installing the .deb on a system.

Widi

> 2016-06-14 12:37 GMT-03:00 Rafael Fonseca :
> 
> > Hey Nicolas,
> >
> > The .install file should be used by dpkg when the deb packages are built
> > with dpkg-buildpackage, i don't know about .postinstall extension, usually
> > you have to specify post-install scripts somewhere.. a grep -r on the code
> > base should expose if that postinstall file is called from deb packager or
> > something else.
> >
> > Anyone else reading this mail, yes, i'm still alive lol, just happened to
> > open my endless cloudstack mail folder lol :)
> >
> > On Tue, Jun 14, 2016 at 2:51 PM, Nicolás Vázquez 
> > wrote:
> >
> > > Hi all,
> > >
> > > A quick question: Where are 'debian/cloudstack-management.install' and
> > > 'debian/cloudstack-management.postinstall' files used? I see the first
> > one
> > > declares folders to be created but I don't know where is this file used.
> > >
> > > Thanks,
> > > Nicolas
> > >
> >

Re: [DISCUSS] 5.0.0 and 6.0.0

[Wido den Hollander]

You really like typing long e-mails! :)

> Op 15 juni 2016 om 2:39 schreef John Burwell :
> 
> 
> All,
> 
> We have been discussing whether or not the next release would introduce the 
> need to increment the major revision number from 4 to 5 (i.e. become 5.0.0).  
> While I think we are very close to the time to have a 5.0.0 release, I don’t 
> think the next release will introduce any backwards compatible changes that 
> necessitate.  However, Wido has brought two important questions — What are 
> our goals for a 5.0.0 release? When do we think we should target its release? 
>  I think we should address and gain consensus on these issues now rather than 
> allow circumstances to answer them for us.
> 
> Since I joined the community (back in the 4.1.0 days), 5.0.0 was a mythical, 
> someday release when CloudStack would have a perfect architecture, build 
> process, etc. -- a unicorn jumping a rainbow.  I realize that I have fallen 
> into the trap of seeing 5.0.0 as some endpoint of perfection rather than an 
> important milestone in the on-going improvement and evolution of the project. 
>  Thinking it about is the former rather than the later, I realize that we 
> have a legacy cruft that we need to discard in order to move forward and 
> architectural design improvements that we must implement to address emerging 
> infrastructure requirements.  I think we would be wise to separate these two 
> objectives into a 5.0.0 release (cruft removal/breaking refactorings) and 
> 6.0.0 (backwards incompatible architectural redesign).  Not only do I see 
> this approach as a risk mitigation, but also as a way to deliver improvements 
> to users and developers as quickly as possible.
> 
> For 5.0.0, my thought is that we would target the following high-level 
> objectives:
> 
> * Drop Java7 and adopt Java8 runtime and language features
> * Drop support for any hypervisor versions no longer supported by their 
> vendors or communities
> * Drop any plugins which are no longer maintained or for which the community 
> has no means to test
> * Drop support for any distributions no longer supported by their vendors or 
> communities

+1 to these points above.

> * Define an official support matrix for the project
> * Adopt a formal policy for sunsetting support of components based on the 
> end-of-life dates set by their vendors or communities
> * Refactoring/cleanup of various APIs
> * Embedded Jetty/uberjar/unified YAML file configuration
> 

Not completely sure about a official support matrix, but I get the point.

> While I am sure there are more clean up items, the focus of the release would 
> be to discard pieces that are in the way on further improvement.
> 
> 6.0.0 would be released within 9-12 months of 5.0.0 — giving the community 
> time to build atop 5.0.0 to redesign/improve the architecture of the system.
> 
> I would like to see 5.0.0 released by the end of 2016 or at the beginning of 
> 2017.  Based on the release plan I previously proposed, we would have the 
> following releases remaining in 2016 and in early 2017: 
> 
> * 4.10 releasing on or about 28 August 2016
> * 4.11 releasing on or about 23 October 2016
> * 4.12 releasing on or about 18 December 2016 
> * 4.13 release on or about 5 February 2017
> 
> 4.12 seems to be the sweet spot in the schedule to cut the 5.0.0 release 
> described above.  It would give us sometime to plan and gain consensus around 
> the changes in both the user and dev communities.  It would also allow the 
> second LTS release to be based on 5.0.0 — allowing both release cycles to 
> take advantage of the reduced support requirements and Java8 language 
> features. Based on this proposal, the releases above would change to the 
> following:
> 
> * 4.10 releasing on or about 28 August 2016
> * 4.11 releasing on or about 23 October 2016
> * 5.0.0 releasing on or about 18 December 2016 
> * 5.1.0 release on or about 5 February 2017
> 

My question is mainly who is going to support all versions and maintain them. 
Developers like to work on the newest stuff, so we get back to the LTS version. 
Person A fixes something in 5.0 and doesn't want/like to backport it to 4.X, 
what happens?

I'm all in favor of a 5.0 release, but we get back to the previously discussed 
topics around a LTS and the different views on that.

> 6.0.0 would be targeted for release in 4Q2017 — providing 9-12 months to 
> design and implement architectural improvements.
> 

I think that 6.0 is to close, 9 months is not a lot of time for us at the 
moment.

> Thoughts?  Other paths to 5.0.0 and beyond?
> -John
> john.burw...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
> 
>

Re: 4.9+ release

[Rajani Karuturi]

I like this discussion. But, my original question was not about what should
the next release number be?

i was checking if anyone working on anything big and hence want the next
release to be 5.0?

~Rajani




On Wed, Jun 15, 2016 at 12:29 PM, Daan Hoogland 
wrote:

> maybe I should have answered here instead of the other thread :S
>
> I am all with John on this. I can not judge the dates but the overall ideas
> are spot on.
>
> I now see the API weren't mentioned in this thread I think they should.
>
> On Wed, Jun 15, 2016 at 1:53 AM, ilya 
> wrote:
>
> > I agree and support John's comments below.
> >
> > Regards
> > ilya
> >
> > On 6/14/16 2:44 PM, John Burwell wrote:
> > > All,
> > >
> > > Completely agree with Daan.  Per semantic versioning, a major revision
> > increase must introduce a backwards incompatible change in the public
> API,
> > removal of one of more supported devices, reduction in the list of
> > supported distributions.  I agree that when we require Java8+, drop
> Ubuntu
> > 12.04 support, drop support for an old hypervisor version, etc,  we will
> > need to increment the major revision to reflect the fact that the release
> > is not backwards compatible.
> > >
> > > For 4.10 and LTS 4.9.0_1, I see it as critical that we support running
> > on either Java7 or Java8.  In particular, producing an LTS release that
> > only supports a JVM that has been unsupported for nearly 18 months would
> > make it DOA in many shops.
> > >
> > > It seems like it would make sense to have a 5.0.0 release that removed
> > support for a number of legacy components (e.g. Xen 6.0 possibly 6.2,
> > Java7, CentOS 5, etc), as well as, internal improvements (e.g. simplified
> > configuration).  The focus of this release would be to reduce the
> footprint
> > of codebase, as well as, make a set of backwards incompatible changes
> that
> > further decouples plugins from core.  We would then plan for a 6.0.0 in
> > 4Q2017 to introduce further architectural changes and API revisions.  The
> > advantage to this approach is that it breaks up the large refactorings
> and
> > architectural design changes — allowing us to gain velocity by removing
> > legacy components, reducing the risk of these changes, and providing user
> > benefit earlier.  Based on the release plan I previously proposed we have
> > the following releases remaining in 2016 and in early 2017:
> > >
> > > * 4.10 releasing on or about 28 August 2016
> > > * 4.11 releasing on or about 23 October 2016
> > > * 4.12 releasing on or about 18 December 2016
> > > * 4.13 release on or about 5 February 2017
> > >
> > > 4.12 seems to be the sweet spot in the schedule to cut the 5.0.0
> release
> > described above.  It would give us sometime to plan and gain consensus
> > around the changes in both the user and dev communities.  It would also
> > allow the second LTS release to be based on 5.0.0 — allowing both release
> > cycles to take advantage of the reduced support requirements and Java8
> > language features. Based on this proposal, the releases above would
> change
> > to the following:
> > >
> > > * 4.10 releasing on or about 28 August 2016
> > > * 4.11 releasing on or about 23 October 2016
> > > * 5.0.0 releasing on or about 18 December 2016
> > > * 5.1.0 release on or about 5 February 2017
> > >
> > > I am in the process of moving my proposal into the wiki.  If this
> > approach is acceptable, I will reflect it there, and open a thread to
> > discuss 5.0.0.
> > >
> > > Thanks,
> > > -John
> > >
> > >
> > >>
> > > john.burw...@shapeblue.com
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> > > @shapeblue
> > >
> > >
> > > On Jun 14, 2016, at 2:02 PM, Paul Angus 
> > wrote:
> > >>
> > >> +1 Daan.
> > >>
> > >> My recollection was that major version number changes were only to be
> > triggered by breaks in backward compatibility (API).
> > >>
> > >>
> > >> Kind regards,
> > >>
> > >> Paul Angus
> > >>
> > >> paul.an...@shapeblue.com
> > >> www.shapeblue.com
> > >> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > >> @shapeblue
> > >>
> > >>
> > >>
> > >> -Original Message-
> > >> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> > >> Sent: 14 June 2016 14:47
> > >> To: dev 
> > >> Cc: Rajani Karuturi 
> > >> Subject: Re: 4.9+ release
> > >>
> > >> You know that would require more then one byte for our minor version,
> > Will.
> > >> I would be very pleased to go to 5.0 before that time.
> > >>
> > >> On Tue, Jun 14, 2016 at 3:43 PM, Will Stevens 
> > wrote:
> > >>
> > >>> Daan is just trying to get us to version 4.256.  :P
> > >>>
> > >>> *Will STEVENS*
> > >>> Lead Developer
> > >>>
> > >>> *CloudOps* *| *Cloud Solutions Experts
> > >>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|*
> tw
> > >>> @CloudOps_
> > >>>
> > >>> On Tue, Jun 14, 2016 at 9:41 AM, Daan Hoogland
> > >>> 
> > >>> wrote:
> > >>>
> >  -1 to what Wido said. None of those p

Re: 4.9+ release

[ma...@exoscale.ch]

Hi,

From my CS starter point of view, I agree with John's comment. I would really 
like to see the next major version with a code & architecture clean-up, 
especially producing a code architecture in the direction of the Java9 Jigsaw 
modularity. It would be sad not to take the next specifications into account.
For the dates, it's good to produce periodically a new release for the 4.X but 
I don't see how putting one on the first 5.x version can be done before 
defining what will be it.

Marco

-- To introduce myself, I joined Exoscale a few months ago to work on CS code 
base to suit their needs.


> On 15 Jun 2016, at 11:31, Rajani Karuturi  wrote:
> 
> I like this discussion. But, my original question was not about what should
> the next release number be?
> 
> i was checking if anyone working on anything big and hence want the next
> release to be 5.0?
> 
> ~Rajani
> 
> 
> 
> 
> On Wed, Jun 15, 2016 at 12:29 PM, Daan Hoogland 
> wrote:
> 
>> maybe I should have answered here instead of the other thread :S
>> 
>> I am all with John on this. I can not judge the dates but the overall ideas
>> are spot on.
>> 
>> I now see the API weren't mentioned in this thread I think they should.
>> 
>> On Wed, Jun 15, 2016 at 1:53 AM, ilya 
>> wrote:
>> 
>>> I agree and support John's comments below.
>>> 
>>> Regards
>>> ilya
>>> 
>>> On 6/14/16 2:44 PM, John Burwell wrote:
 All,
 
 Completely agree with Daan.  Per semantic versioning, a major revision
>>> increase must introduce a backwards incompatible change in the public
>> API,
>>> removal of one of more supported devices, reduction in the list of
>>> supported distributions.  I agree that when we require Java8+, drop
>> Ubuntu
>>> 12.04 support, drop support for an old hypervisor version, etc,  we will
>>> need to increment the major revision to reflect the fact that the release
>>> is not backwards compatible.
 
 For 4.10 and LTS 4.9.0_1, I see it as critical that we support running
>>> on either Java7 or Java8.  In particular, producing an LTS release that
>>> only supports a JVM that has been unsupported for nearly 18 months would
>>> make it DOA in many shops.
 
 It seems like it would make sense to have a 5.0.0 release that removed
>>> support for a number of legacy components (e.g. Xen 6.0 possibly 6.2,
>>> Java7, CentOS 5, etc), as well as, internal improvements (e.g. simplified
>>> configuration).  The focus of this release would be to reduce the
>> footprint
>>> of codebase, as well as, make a set of backwards incompatible changes
>> that
>>> further decouples plugins from core.  We would then plan for a 6.0.0 in
>>> 4Q2017 to introduce further architectural changes and API revisions.  The
>>> advantage to this approach is that it breaks up the large refactorings
>> and
>>> architectural design changes — allowing us to gain velocity by removing
>>> legacy components, reducing the risk of these changes, and providing user
>>> benefit earlier.  Based on the release plan I previously proposed we have
>>> the following releases remaining in 2016 and in early 2017:
 
 * 4.10 releasing on or about 28 August 2016
 * 4.11 releasing on or about 23 October 2016
 * 4.12 releasing on or about 18 December 2016
 * 4.13 release on or about 5 February 2017
 
 4.12 seems to be the sweet spot in the schedule to cut the 5.0.0
>> release
>>> described above.  It would give us sometime to plan and gain consensus
>>> around the changes in both the user and dev communities.  It would also
>>> allow the second LTS release to be based on 5.0.0 — allowing both release
>>> cycles to take advantage of the reduced support requirements and Java8
>>> language features. Based on this proposal, the releases above would
>> change
>>> to the following:
 
 * 4.10 releasing on or about 28 August 2016
 * 4.11 releasing on or about 23 October 2016
 * 5.0.0 releasing on or about 18 December 2016
 * 5.1.0 release on or about 5 February 2017
 
 I am in the process of moving my proposal into the wiki.  If this
>>> approach is acceptable, I will reflect it there, and open a thread to
>>> discuss 5.0.0.
 
 Thanks,
 -John
 
 
> 
 john.burw...@shapeblue.com
 www.shapeblue.com
 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
 @shapeblue
 
 
 On Jun 14, 2016, at 2:02 PM, Paul Angus 
>>> wrote:
> 
> +1 Daan.
> 
> My recollection was that major version number changes were only to be
>>> triggered by breaks in backward compatibility (API).
> 
> 
> Kind regards,
> 
> Paul Angus
> 
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: 14 June 2016 14:47
> To: dev 
> Cc: Rajani Karutur

[GitHub] cloudstack issue #1581: CLOUDSTACK-9404 Fixed ordering of network ACL rules ...

[swill]

Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1581
  
I'm not sure what to make of this comment @kishankavala. Is that a 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 #1581: CLOUDSTACK-9404 Fixed ordering of network ACL rules ...

[kishankavala]

Github user kishankavala commented on the issue:

https://github.com/apache/cloudstack/pull/1581
  
@swill This is a regression caused by VR refactor. There could be more such 
issues. I would prefer a fix in the VR script. Current fix is more like 
reversing the order twice to make it correct. 






---
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 #1581: CLOUDSTACK-9404 Fixed ordering of network ACL rules ...

[swill]

Github user swill commented on the issue:

https://github.com/apache/cloudstack/pull/1581
  
@pdube can you review @kishankavala's comments.  I want to cut an RC soon, 
but we have other pending issues in the VR right now which @kiwiflyer, @dmabry 
and team are working on...


---
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 #1581: CLOUDSTACK-9404 Fixed ordering of network ACL rules ...

[leprechau]

Github user leprechau commented on the issue:

https://github.com/apache/cloudstack/pull/1581
  
Looking through the ```git blame``` for this section of code it appears the 
operator and the ordering of the list was the same as this patch prior to 2013 
when the operator was switched.


---
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 #1581: CLOUDSTACK-9404 Fixed ordering of network ACL rules ...

[pdube]

Github user pdube commented on the issue:

https://github.com/apache/cloudstack/pull/1581
  
@kishankavala I think that the ultimate fix will be in the VR. However, the 
inversion of the list is fixed with this patch, and does not require a VR 
update. This is a good enough fix for now, as the ordering inversion is a 
critical security bug, since the rule numbers you are giving are not being 
applied as expected.


---
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 #1581: CLOUDSTACK-9404 Fixed ordering of network ACL rules ...

[kishankavala]

Github user kishankavala commented on the issue:

https://github.com/apache/cloudstack/pull/1581
  
@leprechau ACL rule ordering was introduced in 2013 in ACS 4.2. Since 4.2 
release, the order was never changed.
Older commit your are referring to, was during development phase of 4.2.


---
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 #1581: CLOUDSTACK-9404 Fixed ordering of network ACL rules ...

[kishankavala]

Github user kishankavala commented on the issue:

https://github.com/apache/cloudstack/pull/1581
  
@pdube Current fix is good enough. I'm only concerned about more such 
issues in VR.
can you please create a tracking bug for VR fix and make a note that this 
is a regression?



---
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 #1581: CLOUDSTACK-9404 Fixed ordering of network ACL rules ...

[leprechau]

Github user leprechau commented on the issue:

https://github.com/apache/cloudstack/pull/1581
  
@kishankavala Understood, thank you for the explanation.  The long history 
of the project makes digging into some of these things difficult.


---
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 #1592: CLOUDSTACK-9416 : (ACS master GUI) Enabling S...

[prashanthvarma]

GitHub user prashanthvarma opened a pull request:

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

CLOUDSTACK-9416 : (ACS master GUI) Enabling Static NAT on an associated 
Public IP to one of the NICs (networks) of a multi-NIC VM fails due to a wrong 
(default) Guest VM IP being selected in the GUI



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

$ git pull https://github.com/prashanthvarma/cloudstack master

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

https://github.com/apache/cloudstack/pull/1592.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 #1592






---
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: CloudStack 4.8.0 with LXC - LibvirtException: unsupported configuration: System lacks NETNS support

[Syed Mushtaq]

Could this be related to the following bug?

https://bugzilla.redhat.com/show_bug.cgi?id=1083030



On Sat, Jun 11, 2016 at 1:29 AM, Cloud List  wrote:

> Dear all,
>
> Anyone implemented LXC on CloudStack before and can provide some advice?
> Documentation is a bit limited on this area. Other than below
> documentations, any other pointers anyone can provide?
>
>
> http://docs.cloudstack.apache.org/projects/cloudstack-installation/en/4.8/hypervisor/lxc.html
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/LXC+Template+creation
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/LXC+Support+in+Cloudstack
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/LXC+Enhancements
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
> -ip-
>
>
> On Fri, Jun 10, 2016 at 6:39 PM, Cloud List  wrote:
>
> > Dear all,
> >
> > We tried to setup an LXC cluster and add an LXC host into a test
> > CloudStack 4.8.0.1 environment. The cluster is created and the LXC host
> is
> > created successfully. We also tried to follow below documentation to
> create
> > an Ubuntu LXC template -- we are running Ubuntu 12.04.5 LTS.
> >
> >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/LXC+Template+creation
> >
> > ===
> > Install lxc: apt-get install lxc
> >
> > Create  a container with any name, in our case 'ubuntu':
> >
> > sudo lxc-create -t download -n ubuntu -- --dist ubuntu --release trusty
> > --arch amd64
> >
> > Creation of the LXC container will take a lot of time, it will be stored
> > here: /var/lib/lxc/ubuntu
> >
> > Next stop the container:
> > sudo lxc-stop -n ubuntu
> >
> > Next create a temp director, tar the rootfs and export the template:
> > mkdir -p /tmp/lxc-template
> > cd /tmp/lxc-template
> > sudo tar --numeric-owner -czf /tmp/lxc-template/template.tar.gz
> > /var/lib/lxc/ubuntu/rootfs/
> > ===
> >
> > As per suggestion from Rohit on another thread, I saved the template file
> > as .tar and register it to cloudstack with HVM disabled. I then tried to
> > create an LXC container instance using the template, but after a long
> > "Creating" process, the provisioning will fail with insufficient capacity
> > error.
> >
> > ===
> > 2016-06-10 18:24:45,468 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> > (API-Job-Executor-44:ctx-c8a4afdc job-232) (logid:523a0c37) Complete
> async
> > job-232, jobStatus: FAILED, resultCode: 530, result:
> > org.apache.cloudstack.api.response.ExceptionR
> > esponse/null/{"uuidList":[],"errorcode":530,"errortext":"Unable to start
> a
> > VM due to insufficient capacity"}
> > ===
> >
> > Further check on the LXC host's agent.log shows that the provisioning
> > failed due to libvirt exception, which says that the configuration is
> > unsupported because the system lacks NETNS support
> >
> > "LibvirtException: unsupported configuration: System lacks NETNS support"
> >
> > See excerpts of the logs below:
> >
> > ===
> > 2016-06-10 18:24:43,740 DEBUG
> > [resource.wrapper.LibvirtStartCommandWrapper]
> (agentRequest-Handler-1:null)
> > starting i-2-42-VM: 
> > i-2-42-VM
> > c29a74fb-e4bc-4aa2-bef4-3c8844de87df
> > Ubuntu 14.04 (64-bit)
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >>
> dir='/mnt/d7678837-9f9f-32ab-99f3-b508feb3595a/6d26a879-999f-4cba-bfcc-1d2d9e70af5c'/>
> >   
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 1048576
> > 
> > 
> > 
> > 1
> > 
> > exe
> > /sbin/init
> > 
> > 
> > 1000
> > 
> > restart
> > destroy
> > destroy
> > 
> >
> > 2016-06-10 18:24:43,743 WARN
> > [resource.wrapper.LibvirtStartCommandWrapper]
> (agentRequest-Handler-1:null)
> > LibvirtException
> > org.libvirt.LibvirtException: unsupported configuration: System lacks
> > NETNS support
> > at org.libvirt.ErrorHandler.processError(Unknown Source)
> > at org.libvirt.ErrorHandler.processError(Unknown Source)
> > at org.libvirt.Connect.domainCreateXML(Unknown Source)
> > at
> >
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.startVM(LibvirtComputingResource.java:1293)
> > at
> >
> com.cloud.hypervisor.kvm.resource.wrapper.LibvirtStartCommandWrapper.execute(LibvirtStartCommandWrapper.java:82)
> > at
> >
> com.cloud.hypervisor.kvm.resource.wrapper.LibvirtStartCommandWrapper.execute(LibvirtStartCommandWrapper.java:46)
> > at
> >
> com.cloud.hypervisor.kvm.resource.wrapper.LibvirtRequestWrapper.execute(LibvirtRequestWrapper.java:75)
> > at
> >
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.executeRequest(LibvirtComputingResource.java:1317)
> > at com.cloud.agent.Agent.processRequest(Agent.java:522)
> > at
> com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:830)
> > at com.cloud.utils.nio.Task.call(Task.java:83)
> > at com.cloud.utils.nio.Task.call(Task.java:29)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> > at
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPo

Re: .install and .postinstall files

[Nicolás Vázquez]

Thanks Wido!

2016-06-15 4:29 GMT-03:00 Wido den Hollander :

>
> > Op 14 juni 2016 om 18:09 schreef Nicolás Vázquez <
> nicovazque...@gmail.com>:
> >
> >
> > Thanks Rafael! My bad, it was '.postinst' extension instead of
> > '.postinstall'
> >
>
> These files are included the dpkg when building the .deb packages.
>
> They are executed post-installation when installing the .deb on a system.
>
> Widi
>
> > 2016-06-14 12:37 GMT-03:00 Rafael Fonseca :
> >
> > > Hey Nicolas,
> > >
> > > The .install file should be used by dpkg when the deb packages are
> built
> > > with dpkg-buildpackage, i don't know about .postinstall extension,
> usually
> > > you have to specify post-install scripts somewhere.. a grep -r on the
> code
> > > base should expose if that postinstall file is called from deb
> packager or
> > > something else.
> > >
> > > Anyone else reading this mail, yes, i'm still alive lol, just happened
> to
> > > open my endless cloudstack mail folder lol :)
> > >
> > > On Tue, Jun 14, 2016 at 2:51 PM, Nicolás Vázquez <
> nicovazque...@gmail.com>
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > A quick question: Where are 'debian/cloudstack-management.install'
> and
> > > > 'debian/cloudstack-management.postinstall' files used? I see the
> first
> > > one
> > > > declares folders to be created but I don't know where is this file
> used.
> > > >
> > > > Thanks,
> > > > Nicolas
> > > >
> > >
>

[GitHub] cloudstack pull request #1593: CLOUDSTACK-9417: Usage module refactoring

[nvazquez]

GitHub user nvazquez opened a pull request:

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

CLOUDSTACK-9417: Usage module refactoring

### Introduction
Usage sanity check file was not been updated on sanity check.

It is proposed:
* New usage folder `/var/cache/cloudstack/usage,` creation on 
`cloudstack-usage` package built.
* New sanity check file location in new folder `/var/cache/cloudstack/usage`
* Timestamp included in `usage.log` file
* Include `updateMaxId()` on sanity check as it wasn't being updated

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

$ git pull https://github.com/nvazquez/cloudstack bothvmmapandpr1584

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

https://github.com/apache/cloudstack/pull/1593.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 #1593


commit 388125d6a2454ee2bf79be62075a8e64c6496661
Author: nvazquez 
Date:   2016-06-15T20:22:11Z

CLOUDSTACK-9417: Add timestamp on usage.log file

commit 759889d344473d75dc1ff90e788c5c7e7106ec08
Author: nvazquez 
Date:   2016-06-15T20:23:03Z

CLOUDSTACK-9417: Usage module refactor




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

Release-Management Question about New API Plug-in

[Tutkowski, Mike]

Hi,


This is mainly a release-management question, but - of course - anyone who 
knows, please feel free to comment.


I have been developing a new API plug-in for a customer. The customer is using 
CloudStack 4.6.


I'd like to contribute the plug-in to our official repo, but I'm wondering if I 
can open a PR as far back as 4.6 (and, of course, I'd like to have this plug-in 
in all subsequent releases, as well).


Thoughts on this?


Thanks!

Mike

Re: Release-Management Question about New API Plug-in

[Daan Hoogland]

just do it. And as a committer make it on a branch in the apache repo, I'd
say. As a escrow to your customer ;)

On Thu, Jun 16, 2016 at 3:42 AM, Tutkowski, Mike 
wrote:

> Hi,
>
>
> This is mainly a release-management question, but - of course - anyone who
> knows, please feel free to comment.
>
>
> I have been developing a new API plug-in for a customer. The customer is
> using CloudStack 4.6.
>
>
> I'd like to contribute the plug-in to our official repo, but I'm wondering
> if I can open a PR as far back as 4.6 (and, of course, I'd like to have
> this plug-in in all subsequent releases, as well).
>
>
> Thoughts on this?
>
>
> Thanks!
>
> Mike
>



-- 
Daan

Re: Release-Management Question about New API Plug-in

[Rajani Karuturi]

"We will only fix bugs in this release branch, no back porting of new
features" -
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up

I would prefer a PR on master for 4.9+



~Rajani

On Thu, Jun 16, 2016 at 7:12 AM, Tutkowski, Mike 
wrote:

> Hi,
>
>
> This is mainly a release-management question, but - of course - anyone who
> knows, please feel free to comment.
>
>
> I have been developing a new API plug-in for a customer. The customer is
> using CloudStack 4.6.
>
>
> I'd like to contribute the plug-in to our official repo, but I'm wondering
> if I can open a PR as far back as 4.6 (and, of course, I'd like to have
> this plug-in in all subsequent releases, as well).
>
>
> Thoughts on this?
>
>
> Thanks!
>
> Mike
>

Re: Release-Management Question about New API Plug-in

[Tutkowski, Mike]

OK - I can always deliver the plug-in for 4.6 directly to my customers and 
first check it into the CloudStack repo maybe in 4.10 or later.

> On Jun 16, 2016, at 12:21 AM, Rajani Karuturi  wrote:
> 
> "We will only fix bugs in this release branch, no back porting of new
> features" -
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up
> 
> I would prefer a PR on master for 4.9+
> 
> 
> 
> ~Rajani
> 
> On Thu, Jun 16, 2016 at 7:12 AM, Tutkowski, Mike 
> wrote:
> 
>> Hi,
>> 
>> 
>> This is mainly a release-management question, but - of course - anyone who
>> knows, please feel free to comment.
>> 
>> 
>> I have been developing a new API plug-in for a customer. The customer is
>> using CloudStack 4.6.
>> 
>> 
>> I'd like to contribute the plug-in to our official repo, but I'm wondering
>> if I can open a PR as far back as 4.6 (and, of course, I'd like to have
>> this plug-in in all subsequent releases, as well).
>> 
>> 
>> Thoughts on this?
>> 
>> 
>> Thanks!
>> 
>> Mike
>>