Re: Which StringUtils to use?

[Daan Hoogland]

Ron, we could but that would only log during compile-time, not on runtime.
I am doing some analysis and commenting in Wido's ticket.

On Wed, Jan 10, 2018 at 9:23 PM, Ron Wheeler <rwhee...@artifact-software.com
> wrote:

> Is it possible to mark it as deprecated and have it log a warning when
> used?
>
> Ron
>
>
> On 10/01/2018 2:26 PM, Daan Hoogland wrote:
>
>> I think we could start with giving it an explicit non standard name like
>> CloudStackLocalStringUtils or something a little shorter. Making sure that
>> we prefer for these types of utils to be imported from other projects.
>>
>> On Wed, Jan 10, 2018 at 4:26 PM, Wido den Hollander <w...@widodh.nl>
>> wrote:
>>
>>
>>> On 01/10/2018 01:09 PM, Rafael Weingärtner wrote:
>>>
>>> Instead of creating a PR for that, we could do the bit by bit job
>>>> (hopefully one day we finish the job).
>>>> Every time we see a code using ACS's StringUtils, we check if it can be
>>>> replaced by Apache's one.
>>>>
>>>>
>>>> Yes, but that will slip from peoples attention and we will probably see
>>> cases where people still use the old one by accident.
>>>
>>> I've created a issue: https://issues.apache.org/jira
>>> /browse/CLOUDSTACK-10225
>>>
>>> I also started on some low hanging fruit as some methods in StringUtils
>>> are not used or are very easy to replace.
>>>
>>>
>>> Wido
>>>
>>> On Wed, Jan 10, 2018 at 10:01 AM, Wido den Hollander <w...@widodh.nl>
>>>
>>>> wrote:
>>>>
>>>>
>>>> On 01/10/2018 12:01 PM, Daan Hoogland wrote:
>>>>>
>>>>> I'd say remove as much functionality as we can from 'our' StringUtils
>>>>> and
>>>>>
>>>>>> phase them out asap.
>>>>>>
>>>>>>
>>>>>> Yes, but such a PR would be invasive and would be difficult to merge
>>>>>> and
>>>>>>
>>>>> also break a lot of other code.
>>>>>
>>>>> It's not easy since it will touch a lot, but I mean, a lot of files.
>>>>>
>>>>> Our StringUtils was a very good solution, but the Apache one is better
>>>>> I
>>>>> think.
>>>>>
>>>>> Wido
>>>>>
>>>>>
>>>>> On Wed, Jan 10, 2018 at 11:59 AM, Wido den Hollander <w...@widodh.nl>
>>>>>
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> We have com.cloud.utils.StringUtils which has a few nice functions,
>>>>>>> but
>>>>>>> throughout the code I also see org.apache.commons.lang.StringUtils
>>>>>>>
>>>>>>> They both provide about the same functionality, but which one do we
>>>>>>> prefer?
>>>>>>>
>>>>>>> I'd say org.apache.commons.lang.StringUtils as that allows us to
>>>>>>> remove
>>>>>>> our own StringUtils, but we could also have 'our' StringUtils simply
>>>>>>> be a
>>>>>>> wrapper around org.apache.commons.lang.StringUtils
>>>>>>>
>>>>>>> Opinions?
>>>>>>>
>>>>>>> Wido
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>


-- 
Daan

Re: Which StringUtils to use?

[Daan Hoogland]

I think we could start with giving it an explicit non standard name like
CloudStackLocalStringUtils or something a little shorter. Making sure that
we prefer for these types of utils to be imported from other projects.

On Wed, Jan 10, 2018 at 4:26 PM, Wido den Hollander <w...@widodh.nl> wrote:

>
>
> On 01/10/2018 01:09 PM, Rafael Weingärtner wrote:
>
>> Instead of creating a PR for that, we could do the bit by bit job
>> (hopefully one day we finish the job).
>> Every time we see a code using ACS's StringUtils, we check if it can be
>> replaced by Apache's one.
>>
>>
> Yes, but that will slip from peoples attention and we will probably see
> cases where people still use the old one by accident.
>
> I've created a issue: https://issues.apache.org/jira
> /browse/CLOUDSTACK-10225
>
> I also started on some low hanging fruit as some methods in StringUtils
> are not used or are very easy to replace.
>
>
> Wido
>
> On Wed, Jan 10, 2018 at 10:01 AM, Wido den Hollander <w...@widodh.nl>
>> wrote:
>>
>>
>>>
>>> On 01/10/2018 12:01 PM, Daan Hoogland wrote:
>>>
>>> I'd say remove as much functionality as we can from 'our' StringUtils and
>>>> phase them out asap.
>>>>
>>>>
>>>> Yes, but such a PR would be invasive and would be difficult to merge and
>>> also break a lot of other code.
>>>
>>> It's not easy since it will touch a lot, but I mean, a lot of files.
>>>
>>> Our StringUtils was a very good solution, but the Apache one is better I
>>> think.
>>>
>>> Wido
>>>
>>>
>>> On Wed, Jan 10, 2018 at 11:59 AM, Wido den Hollander <w...@widodh.nl>
>>>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>>>
>>>>> We have com.cloud.utils.StringUtils which has a few nice functions, but
>>>>> throughout the code I also see org.apache.commons.lang.StringUtils
>>>>>
>>>>> They both provide about the same functionality, but which one do we
>>>>> prefer?
>>>>>
>>>>> I'd say org.apache.commons.lang.StringUtils as that allows us to
>>>>> remove
>>>>> our own StringUtils, but we could also have 'our' StringUtils simply
>>>>> be a
>>>>> wrapper around org.apache.commons.lang.StringUtils
>>>>>
>>>>> Opinions?
>>>>>
>>>>> Wido
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>>


-- 
Daan

Re: [DISCUSS] Freezing master for 4.11

[Daan Hoogland]

I hope we understand each other correctly: No-one running an earlier
version then 4.11 should miss out on any functionality they are using now.

So if you use ipv6 and multiple cidrs now it must continue to work with no
loss of functionality. see my question below.

On Wed, Jan 10, 2018 at 7:06 PM, Ivan Kudryavtsev 
wrote:

> Daan, yes this sounds reasonable, I suppose who would like to fix, could
> do custom build for himself...
>
> But still it should be aknowledged somehow, if you use several cidrs for
> network, don't use v6, or don't upgrade to 4.11 because things will stop
> running well.
>
​Does this mean that several cidrs in ipv6 works in 4.9 and not in 4.11?


if yes; it is a blocker

if no; you might as well upgrade for other features as it doesn't work now
either.

-- 
Daan

Re: [DISCUSS] Freezing master for 4.11

[Daan Hoogland]

Ivan,
I was composing an answer but i think we agree:

Only if that functionality worked in the past. ipv6 support is still rather
new and must be considered experimental. I think we should fix it in a
maintenance release and not block the release for it. If it was working
before and broke, it should go in. To put it less mildly, I expect more
then ACS can deliver and we can't wait until all my wishes are implemented.


On Wed, Jan 10, 2018 at 6:58 PM, Ivan Kudryavtsev <kudryavtsev...@bw-sw.com>
wrote:

> Sorry, to clarify, I mean (if I correctly understand) that if someone has
> a network with several CIDRs in the basic zone and, lets say, 4.9.3
> upgraded to 4.11, which results that VMs stop getting DHCP announces for
> additional CIDRs from VR, it's a blocker thing...
>
> 2018-01-11 0:52 GMT+07:00 Ivan Kudryavtsev <kudryavtsev...@bw-sw.com>:
>
>> I suppose the bug, reported by Wido prevents adding additional CIDRs to
>> Network if IPv6 configured? If so, it's definitely a blocker thing because
>> everyone expects it's possible, because the function is implemented in ACS.
>>
>> 2018-01-11 0:41 GMT+07:00 Rohit Yadav <rohit.ya...@shapeblue.com>:
>>
>>> +1 what Dasn said.
>>>
>>> Wido - are you seeing (upgrade) failure, or something fails to work
>>> without this fix in basic zone?
>>> 
>>> From: Daan Hoogland <daan.hoogl...@gmail.com>
>>> Sent: Wednesday, January 10, 2018 10:50:22 PM
>>> To: dev
>>> Cc: Rohit Yadav
>>> Subject: Re: [DISCUSS] Freezing master for 4.11
>>>
>>> I think that we agreed in th3 past that a blocker is either something
>>> that prevents ACS to start or upgrade, or something that breaks prior
>>> functionality.
>>>
>>>
>>> rohit.ya...@shapeblue.com
>>> www.shapeblue.com
>>> 53 Chandos Place, Covent Garden, London  WC2N
>>> <https://maps.google.com/?q=53+Chandos+Place,+Covent+Garden,+London%C2%A0+WC2N=gmail=g>
>>> 4HSUK
>>> @shapeblue
>>>
>>>
>>>
>>> On Wed, Jan 10, 2018 at 6:13 PM, Wido den Hollander <w...@widodh.nl
>>> <mailto:w...@widodh.nl>> wrote:
>>>
>>>
>>> On 01/10/2018 05:47 PM, Rohit Yadav wrote:
>>> All,
>>>
>>>
>>> I want to thank all the reviewers, contributors and PR authors for their
>>> hard work, support and collaboration. We managed to review, test and merge
>>> more than 100 PRs towards the 4.11 milestone!
>>>
>>>
>>> Out of 11 open PRs on Monday, the list is down to 2 now which were
>>> recently added features:
>>>
>>> https://github.com/apache/cloudstack/milestone/3
>>>
>>>
>>> To keep up with the release schedule, I think it's time we should focus
>>> on stabilizing master, testing it, fix any regressions and blockers.
>>>
>>>
>>> I'll cut 4.11 branch on Monday (15th Jan) and start RC1 as per the
>>> schedule and master will be open for PRs with following merge criteria:
>>>
>>> - Blocker fixes, especially those blocking the release
>>>
>>> - Test failure and regression fixes
>>>
>>> - Release related fixes for example - upgrade blockers, database path,
>>> packaging and systemvmtemplate related etc.
>>>
>>>
>>> Thoughts, objections?
>>>
>>>
>>> Awesome!
>>>
>>> I'm looking for the definition for a blocker, I recently found this one:
>>> https://github.com/apache/cloudstack/pull/2396
>>>
>>> For us this is a big problem as we keep running into it, but probably
>>> nobody else. I don't want to promote my own PR as a blocker, but what is
>>> the definition?
>>>
>>> Because it's my own PR I didn't add the 4.11 milestone.
>>>
>>> Looking forward to 4.11!
>>>
>>>
>>> Wido
>>>
>>>
>>> - Rohit
>>>
>>> <https://cloudstack.apache.org>
>>>
>>>
>>>
>>> 
>>> From: Khosrow Moossavi <kmooss...@cloudops.com>> kmooss...@cloudops.com>>
>>> Sent: Monday, January 8, 2018 8:59:30 PM
>>> To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
>>> Subject: Re: [DISCUSS] Freezing master for 4.11
>>>
>>> +1 Daan and Rohit
>>>
>>> Khosrow Moossavi
>>>
>>> Cloud Infrastructure Developer
>>>
>>> t 514.447.3456
>>>

Re: [DISCUSS] Freezing master for 4.11

[Daan Hoogland]

I think that we agreed in th3 past that a blocker is either something that
prevents ACS to start or upgrade, or something that breaks prior
functionality.

On Wed, Jan 10, 2018 at 6:13 PM, Wido den Hollander <w...@widodh.nl> wrote:

>
>
> On 01/10/2018 05:47 PM, Rohit Yadav wrote:
>
>> All,
>>
>>
>> I want to thank all the reviewers, contributors and PR authors for their
>> hard work, support and collaboration. We managed to review, test and merge
>> more than 100 PRs towards the 4.11 milestone!
>>
>>
>> Out of 11 open PRs on Monday, the list is down to 2 now which were
>> recently added features:
>>
>> https://github.com/apache/cloudstack/milestone/3
>>
>>
>> To keep up with the release schedule, I think it's time we should focus
>> on stabilizing master, testing it, fix any regressions and blockers.
>>
>>
>> I'll cut 4.11 branch on Monday (15th Jan) and start RC1 as per the
>> schedule and master will be open for PRs with following merge criteria:
>>
>> - Blocker fixes, especially those blocking the release
>>
>> - Test failure and regression fixes
>>
>> - Release related fixes for example - upgrade blockers, database path,
>> packaging and systemvmtemplate related etc.
>>
>>
>> Thoughts, objections?
>>
>>
> Awesome!
>
> I'm looking for the definition for a blocker, I recently found this one:
> https://github.com/apache/cloudstack/pull/2396
>
> For us this is a big problem as we keep running into it, but probably
> nobody else. I don't want to promote my own PR as a blocker, but what is
> the definition?
>
> Because it's my own PR I didn't add the 4.11 milestone.
>
> Looking forward to 4.11!
>
>
> Wido
>
>
>> - Rohit
>>
>> <https://cloudstack.apache.org>
>>
>>
>>
>> 
>> From: Khosrow Moossavi <kmooss...@cloudops.com>
>> Sent: Monday, January 8, 2018 8:59:30 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [DISCUSS] Freezing master for 4.11
>>
>> +1 Daan and Rohit
>>
>> Khosrow Moossavi
>>
>> Cloud Infrastructure Developer
>>
>> t 514.447.3456
>>
>> <https://goo.gl/NYZ8KK>
>>
>>
>>
>> On Mon, Jan 8, 2018 at 7:58 AM, Boris Stoyanov <
>> boris.stoya...@shapeblue.com
>>
>>> wrote:
>>>
>>
>> Yes let’s do that.
>>>
>>>
>>> boris.stoya...@shapeblue.com
>>> www.shapeblue.com<http://www.shapeblue.com>
>>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>>> @shapeblue
>>>
>>>
>>>
>>>
>>> rohit.ya...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
>>
>>
>>> On 8 Jan 2018, at 14:41, Wido den Hollander <w...@widodh.nl> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On 01/08/2018 01:30 PM, Rohit Yadav wrote:
>>>>
>>>>> All,
>>>>> Thank you everyone for your feedback. Given we're in agreement with
>>>>>
>>>> Daan's proposal, I'll summarize and add strategy:
>>>
>>>> - We'll freeze the 4.11 milestone to only these 9 PRs:
>>>>>
>>>> https://github.com/apache/cloudstack/milestone/3
>>>
>>>> - In addition, only blocker, test fixes, and release/packaging related
>>>>>
>>>> fixes may be accepted in master now.
>>>
>>>> - If we don't hear from authors within a day, the PRs may be removed
>>>>>
>>>> from the milestone.
>>>
>>>> - We'll re-assess the list again by EOD, Wed 10 Jan 2018.
>>>>> Does this look agreeable? Thanks.
>>>>>
>>>>
>>>> Yes, it does! When the first RC comes out we should be able to run
>>>>
>>> tests, fix what's broken and focus in the release and 4.12 afterwards.
>>>
>>>>
>>>> Wido
>>>>
>>>> - Rohit
>>>>> <https://cloudstack.apache.org>
>>>>> 
>>>>> From: Daan Hoogland <daan.hoogl...@gmail.com>
>>>>> Sent: Monday, January 8, 2018 4:21:00 PM
>>>>> To: dev
>>>>> Subject: Re: [DISCUSS] Freezing master for 4.11
>>>>> slow display of arrogance in reacting this time ; yeeaahhh
>>>>> On Mon, Jan 8, 2018 at 11:22 AM, Voloshanenko Igor <
>&g

Re: Which StringUtils to use?

[Daan Hoogland]

I'd say remove as much functionality as we can from 'our' StringUtils and
phase them out asap.

On Wed, Jan 10, 2018 at 11:59 AM, Wido den Hollander  wrote:

> Hi,
>
> We have com.cloud.utils.StringUtils which has a few nice functions, but
> throughout the code I also see org.apache.commons.lang.StringUtils
>
> They both provide about the same functionality, but which one do we prefer?
>
> I'd say org.apache.commons.lang.StringUtils as that allows us to remove
> our own StringUtils, but we could also have 'our' StringUtils simply be a
> wrapper around org.apache.commons.lang.StringUtils
>
> Opinions?
>
> Wido
>



-- 
Daan

Re: cloudstack Wikipedia page

[Daan Hoogland]

just anonymously removed it, Giles

On Tue, Jan 9, 2018 at 11:21 AM, Giles Sirett 
wrote:

> Somebody has made an edit to the cloudstack wikipedia entry
>
> https://en.wikipedia.org/w/index.php?diff=819108440=815849996
>
> In essence, they have changed the start of the history section to give a
> history of the cloud.com domain name. I do not think that is either
> relevant or appropriate to the history of cloudstack itself
>
> Has anybody here got experience in editing on Wikipedia and able to
> object/change this edit ?
>
> I'm happy to take this task on, but have no experience in the process,
> policies, etc
>
>
> Kind regards
> Giles
>
>
> giles.sir...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>


-- 
Daan

Re: [DISCUSS] new way of github working

[Daan Hoogland]

Marc-Aurèle and Rafael, I mean both. I know we used to require the first, to 
create the release notes in a concise way and we used to ban the other because 
it leads to unnavigable revision trees. But now that squash and merge is a 
functionality of github one might argue that it doesn’t matter anymore. 
Personally, I am against squashing persé, in any case. I am not the law (other 
than during some triathlons) so we jointly might decide differently.

On 08/01/2018, 16:50, "Nicolas Vazquez" <nicolas.vazq...@shapeblue.com> wrote:

The same as Rafael described. If it is the second case I would prefer 
rebasing the target branch and push force instead of including merge commits in 
a PR

Obtener Outlook para Android<https://aka.ms/ghei36>


From: williamstev...@gmail.com <williamstev...@gmail.com> on behalf of Will 
Stevens <wstev...@cloudops.com>
Sent: Monday, January 8, 2018 11:34:42 AM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] new way of github working

Just a note Daan.  If a PR is merged with the `git pr ` tool in our
utilities folder, it will automatically include the merge commit.  Figured
I should mention that...

*Will Stevens*
CTO

<https://goo.gl/NYZ8KK>

On Mon, Jan 8, 2018 at 8:26 AM, Marc-Aurèle Brothier <ma...@exoscale.ch>
wrote:

> Same opinion as Rafael described.
>
> On Mon, Jan 8, 2018 at 11:30 AM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > I did not fully understand what you meant.
> >
> > Are you talking about the merge commit that can be created when a PR is
> > merged? Or, are you talking about a merge commit that is added to a PR
> when
> > a conflict is solved by its author(s)?
> >
> >
> > I do not have problems with the first type of merge commits. However, I
> > think we should not allow the second type to get into our code base.
> >
> > On Mon, Jan 8, 2018 at 7:45 AM, Daan Hoogland <daan.hoogl...@gmail.com>
> > wrote:
> >
> > > Devs,
> > >
> > > I see a lot of merge master to branch commits appearing on PRs. This 
is
> > > against prior (non-hard) agreements on how we work. It is getting to 
be
> > the
> > > daily practice so;
> > > How do we feel about
> > > 1. not using merge commits anymore?
> > > 2. merging back as a way of solving conflicts?
> > > and
> > > Do we need to make a policy of it or do we let it evolve, at the risk
> of
> > > having more hard to track feature/version matrices?
> > >
> > > --
> > > Daan
> > >
> >
> >
> >
> > --
> > Rafael Weingärtner
> >
>

nicolas.vazq...@shapeblue.com 
www.shapeblue.com
,   
@shapeblue
  
 




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

Re: [DISCUSS] Freezing master for 4.11

[Daan Hoogland]

slow display of arrogance in reacting this time ; yeeaahhh

On Mon, Jan 8, 2018 at 11:22 AM, Voloshanenko Igor <
igor.voloshane...@gmail.com> wrote:

> You again faster than me )))
>
> 2018-01-08 12:21 GMT+02:00 Voloshanenko Igor <igor.voloshane...@gmail.com
> >:
>
> > :D tnx )
> > Updated by my colleague already
> >
> > 2018-01-08 12:06 GMT+02:00 Daan Hoogland <daan.hoogl...@gmail.com>:
> >
> >> yeah, way ahead of you Igor ;) I asked a question about it
> >>
> >> On Mon, Jan 8, 2018 at 11:05 AM, Voloshanenko Igor <
> >> igor.voloshane...@gmail.com> wrote:
> >>
> >> > Updates posted to https://github.com/apache/cloudstack/pull/2389
> >> > Can you please review?
> >> >
> >> > 2018-01-08 11:57 GMT+02:00 Voloshanenko Igor <
> >> igor.voloshane...@gmail.com
> >> > >:
> >> >
> >> > > Sure. Got it.
> >> > >
> >> > > Will post update soon
> >> > >
> >> > > 2018-01-08 11:38 GMT+02:00 Daan Hoogland <daan.hoogl...@gmail.com>:
> >> > >
> >> > >> Igor, I remember your PR and think it is fine. It can also be
> argued
> >> > that
> >> > >> it needs to go in as a security feature. For an RM it is
> unthinkably
> >> > late,
> >> > >> but fortunately it is very small. I will however -1 it if it leads
> >> to a
> >> > >> plethora of last minute PRs to include.
> >> > >>
> >> > >> On Mon, Jan 8, 2018 at 10:33 AM, Voloshanenko Igor <
> >> > >> igor.voloshane...@gmail.com> wrote:
> >> > >>
> >> > >> > Guys, can we please include https://github.com/apache/clou
> >> > >> dstack/pull/2389
> >> > >> > into 4.11
> >> > >> > PR very small and updates will be published in next few hours.
> >> > >> >
> >> > >> > As we have this for a while in production for 4.8 branch.
> >> > >> >
> >> > >> > 2018-01-08 11:15 GMT+02:00 Boris Stoyanov <
> >> > boris.stoya...@shapeblue.com
> >> > >> >:
> >> > >> >
> >> > >> > > +1 Daan
> >> > >> > >
> >> > >> > >
> >> > >> > > boris.stoya...@shapeblue.com
> >> > >> > > www.shapeblue.com
> >> > >> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> >> > >> > > @shapeblue
> >> > >> > >
> >> > >> > >
> >> > >> > >
> >> > >> > > > On 8 Jan 2018, at 10:47, Daan Hoogland <
> >> daan.hoogl...@gmail.com>
> >> > >> > wrote:
> >> > >> > > >
> >> > >> > > > Rohit, Ivan,
> >> > >> > > >
> >> > >> > > > I think we can argue that the five open PRs on the milestone
> >> can
> >> > >> still
> >> > >> > go
> >> > >> > > > in as long as active work on them continues. I have not
> looked
> >> at
> >> > >> > Ivan's
> >> > >> > > > PRs yet but can see they were entered in december and he is
> >> > actively
> >> > >> > > > working on it so why not include those in the milestone. A
> >> bigger
> >> > >> > concern
> >> > >> > > > is that some of the remaining PRs in that milestone are
> >> > potentially
> >> > >> > > > conflicting. So we feature freeze now and work only to get
> the
> >> set
> >> > >> list
> >> > >> > > in
> >> > >> > > > (and blockers).
> >> > >> > > >
> >> > >> > > >
> >> > >> > > > On Mon, Jan 8, 2018 at 9:39 AM, Ivan Kudryavtsev <
> >> > >> > > kudryavtsev...@bw-sw.com>
> >> > >> > > > wrote:
> >> > >> > > >
> >> > >> > > >> Rohit, Devs,
> >> > >> > > >>
> >> > >> > > >> just consider adding:
> >> > >> > > >>
> >> > >> > > >> CLOUDSTACK-10188 / 

Re: [DISCUSS] Freezing master for 4.11

[Daan Hoogland]

yeah, way ahead of you Igor ;) I asked a question about it

On Mon, Jan 8, 2018 at 11:05 AM, Voloshanenko Igor <
igor.voloshane...@gmail.com> wrote:

> Updates posted to https://github.com/apache/cloudstack/pull/2389
> Can you please review?
>
> 2018-01-08 11:57 GMT+02:00 Voloshanenko Igor <igor.voloshane...@gmail.com
> >:
>
> > Sure. Got it.
> >
> > Will post update soon
> >
> > 2018-01-08 11:38 GMT+02:00 Daan Hoogland <daan.hoogl...@gmail.com>:
> >
> >> Igor, I remember your PR and think it is fine. It can also be argued
> that
> >> it needs to go in as a security feature. For an RM it is unthinkably
> late,
> >> but fortunately it is very small. I will however -1 it if it leads to a
> >> plethora of last minute PRs to include.
> >>
> >> On Mon, Jan 8, 2018 at 10:33 AM, Voloshanenko Igor <
> >> igor.voloshane...@gmail.com> wrote:
> >>
> >> > Guys, can we please include https://github.com/apache/clou
> >> dstack/pull/2389
> >> > into 4.11
> >> > PR very small and updates will be published in next few hours.
> >> >
> >> > As we have this for a while in production for 4.8 branch.
> >> >
> >> > 2018-01-08 11:15 GMT+02:00 Boris Stoyanov <
> boris.stoya...@shapeblue.com
> >> >:
> >> >
> >> > > +1 Daan
> >> > >
> >> > >
> >> > > boris.stoya...@shapeblue.com
> >> > > www.shapeblue.com
> >> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> >> > > @shapeblue
> >> > >
> >> > >
> >> > >
> >> > > > On 8 Jan 2018, at 10:47, Daan Hoogland <daan.hoogl...@gmail.com>
> >> > wrote:
> >> > > >
> >> > > > Rohit, Ivan,
> >> > > >
> >> > > > I think we can argue that the five open PRs on the milestone can
> >> still
> >> > go
> >> > > > in as long as active work on them continues. I have not looked at
> >> > Ivan's
> >> > > > PRs yet but can see they were entered in december and he is
> actively
> >> > > > working on it so why not include those in the milestone. A bigger
> >> > concern
> >> > > > is that some of the remaining PRs in that milestone are
> potentially
> >> > > > conflicting. So we feature freeze now and work only to get the set
> >> list
> >> > > in
> >> > > > (and blockers).
> >> > > >
> >> > > >
> >> > > > On Mon, Jan 8, 2018 at 9:39 AM, Ivan Kudryavtsev <
> >> > > kudryavtsev...@bw-sw.com>
> >> > > > wrote:
> >> > > >
> >> > > >> Rohit, Devs,
> >> > > >>
> >> > > >> just consider adding:
> >> > > >>
> >> > > >> CLOUDSTACK-10188 / https://github.com/apache/
> cloudstack/pull/2362
> >> > > [resouce
> >> > > >> accounting blocker bug]
> >> > > >> CLOUDSTACK-10170 / https://github.com/apache/
> cloudstack/pull/2350
> >> > > >> [security
> >> > > >> fix, enchancement]
> >> > > >>
> >> > > >> They are ready (we think so) for some time, but *no final review*
> >> yet.
> >> > > >>
> >> > > >>
> >> > > >> 2018-01-08 14:47 GMT+07:00 Rohit Yadav <
> rohit.ya...@shapeblue.com
> >> >:
> >> > > >>
> >> > > >>> All,
> >> > > >>>
> >> > > >>>
> >> > > >>> As per the previously shared schedule [1], by EOD today (8 Jan
> >> 2018)
> >> > we
> >> > > >>> would freeze master after which we'll only accept
> critical/blocker
> >> > > fixes,
> >> > > >>> stabilize master and start a voting thread on 4.11 RC1 (est. by
> 15
> >> > Jan
> >> > > >>> 2018).
> >> > > >>>
> >> > > >>>
> >> > > >>> I wanted to gather consensus if this is acceptable to everyone
> as
> >> > there
> >> > > >>> are still few outstanding feature PRs that I understand authors
> >> have
> >> > > >> worked
> >> > > >>> hard to get them in.
> >> > > >>>
> >> > > >>>
> >> > > >>> Please share your thoughts, comments.  If you're the author of
> >> such
> >> > an
> >> > > >>> existing PR, please work with us, address outstanding issues.
> >> > > >>>
> >> > > >>>
> >> > > >>> In case of no objections, it will be assumed that the plan is
> >> > > acceptable
> >> > > >>> to everyone. Thanks.
> >> > > >>>
> >> > > >>>
> >> > > >>> [1] http://markmail.org/message/mszlluye35acvn2j
> >> > > >>>
> >> > > >>>
> >> > > >>> - Rohit
> >> > > >>>
> >> > > >>> <https://cloudstack.apache.org>
> >> > > >>>
> >> > > >>>
> >> > > >>>
> >> > > >>> rohit.ya...@shapeblue.com
> >> > > >>> www.shapeblue.com
> >> > > >>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> >> > > >>> @shapeblue
> >> > > >>>
> >> > > >>>
> >> > > >>>
> >> > > >>>
> >> > > >>
> >> > > >>
> >> > > >> --
> >> > > >> With best regards, Ivan Kudryavtsev
> >> > > >> Bitworks Software, Ltd.
> >> > > >> Cell: +7-923-414-1515
> >> > > >> WWW: http://bitworks.software/ <http://bw-sw.com/>
> >> > > >>
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Daan
> >> > >
> >> > >
> >> >
> >>
> >>
> >>
> >> --
> >> Daan
> >>
> >
> >
>



-- 
Daan

[DISCUSS] new way of github working

[Daan Hoogland]

Devs,

I see a lot of merge master to branch commits appearing on PRs. This is
against prior (non-hard) agreements on how we work. It is getting to be the
daily practice so;
How do we feel about
1. not using merge commits anymore?
2. merging back as a way of solving conflicts?
and
Do we need to make a policy of it or do we let it evolve, at the risk of
having more hard to track feature/version matrices?

-- 
Daan

Re: [DISCUSS] Freezing master for 4.11

[Daan Hoogland]

Igor, I remember your PR and think it is fine. It can also be argued that
it needs to go in as a security feature. For an RM it is unthinkably late,
but fortunately it is very small. I will however -1 it if it leads to a
plethora of last minute PRs to include.

On Mon, Jan 8, 2018 at 10:33 AM, Voloshanenko Igor <
igor.voloshane...@gmail.com> wrote:

> Guys, can we please include https://github.com/apache/cloudstack/pull/2389
> into 4.11
> PR very small and updates will be published in next few hours.
>
> As we have this for a while in production for 4.8 branch.
>
> 2018-01-08 11:15 GMT+02:00 Boris Stoyanov <boris.stoya...@shapeblue.com>:
>
> > +1 Daan
> >
> >
> > boris.stoya...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> > > On 8 Jan 2018, at 10:47, Daan Hoogland <daan.hoogl...@gmail.com>
> wrote:
> > >
> > > Rohit, Ivan,
> > >
> > > I think we can argue that the five open PRs on the milestone can still
> go
> > > in as long as active work on them continues. I have not looked at
> Ivan's
> > > PRs yet but can see they were entered in december and he is actively
> > > working on it so why not include those in the milestone. A bigger
> concern
> > > is that some of the remaining PRs in that milestone are potentially
> > > conflicting. So we feature freeze now and work only to get the set list
> > in
> > > (and blockers).
> > >
> > >
> > > On Mon, Jan 8, 2018 at 9:39 AM, Ivan Kudryavtsev <
> > kudryavtsev...@bw-sw.com>
> > > wrote:
> > >
> > >> Rohit, Devs,
> > >>
> > >> just consider adding:
> > >>
> > >> CLOUDSTACK-10188 / https://github.com/apache/cloudstack/pull/2362
> > [resouce
> > >> accounting blocker bug]
> > >> CLOUDSTACK-10170 / https://github.com/apache/cloudstack/pull/2350
> > >> [security
> > >> fix, enchancement]
> > >>
> > >> They are ready (we think so) for some time, but *no final review* yet.
> > >>
> > >>
> > >> 2018-01-08 14:47 GMT+07:00 Rohit Yadav <rohit.ya...@shapeblue.com>:
> > >>
> > >>> All,
> > >>>
> > >>>
> > >>> As per the previously shared schedule [1], by EOD today (8 Jan 2018)
> we
> > >>> would freeze master after which we'll only accept critical/blocker
> > fixes,
> > >>> stabilize master and start a voting thread on 4.11 RC1 (est. by 15
> Jan
> > >>> 2018).
> > >>>
> > >>>
> > >>> I wanted to gather consensus if this is acceptable to everyone as
> there
> > >>> are still few outstanding feature PRs that I understand authors have
> > >> worked
> > >>> hard to get them in.
> > >>>
> > >>>
> > >>> Please share your thoughts, comments.  If you're the author of such
> an
> > >>> existing PR, please work with us, address outstanding issues.
> > >>>
> > >>>
> > >>> In case of no objections, it will be assumed that the plan is
> > acceptable
> > >>> to everyone. Thanks.
> > >>>
> > >>>
> > >>> [1] http://markmail.org/message/mszlluye35acvn2j
> > >>>
> > >>>
> > >>> - Rohit
> > >>>
> > >>> <https://cloudstack.apache.org>
> > >>>
> > >>>
> > >>>
> > >>> rohit.ya...@shapeblue.com
> > >>> www.shapeblue.com
> > >>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > >>> @shapeblue
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >>
> > >> --
> > >> With best regards, Ivan Kudryavtsev
> > >> Bitworks Software, Ltd.
> > >> Cell: +7-923-414-1515
> > >> WWW: http://bitworks.software/ <http://bw-sw.com/>
> > >>
> > >
> > >
> > >
> > > --
> > > Daan
> >
> >
>



-- 
Daan

Re: [DISCUSS] Freezing master for 4.11

[Daan Hoogland]

Rohit, Ivan,

I think we can argue that the five open PRs on the milestone can still go
in as long as active work on them continues. I have not looked at Ivan's
PRs yet but can see they were entered in december and he is actively
working on it so why not include those in the milestone. A bigger concern
is that some of the remaining PRs in that milestone are potentially
conflicting. So we feature freeze now and work only to get the set list in
(and blockers).


On Mon, Jan 8, 2018 at 9:39 AM, Ivan Kudryavtsev 
wrote:

> Rohit, Devs,
>
> just consider adding:
>
> CLOUDSTACK-10188 / https://github.com/apache/cloudstack/pull/2362 [resouce
> accounting blocker bug]
> CLOUDSTACK-10170 / https://github.com/apache/cloudstack/pull/2350
> [security
> fix, enchancement]
>
> They are ready (we think so) for some time, but *no final review* yet.
>
>
> 2018-01-08 14:47 GMT+07:00 Rohit Yadav :
>
> > All,
> >
> >
> > As per the previously shared schedule [1], by EOD today (8 Jan 2018) we
> > would freeze master after which we'll only accept critical/blocker fixes,
> > stabilize master and start a voting thread on 4.11 RC1 (est. by 15 Jan
> > 2018).
> >
> >
> > I wanted to gather consensus if this is acceptable to everyone as there
> > are still few outstanding feature PRs that I understand authors have
> worked
> > hard to get them in.
> >
> >
> > Please share your thoughts, comments.  If you're the author of such an
> > existing PR, please work with us, address outstanding issues.
> >
> >
> > In case of no objections, it will be assumed that the plan is acceptable
> > to everyone. Thanks.
> >
> >
> > [1] http://markmail.org/message/mszlluye35acvn2j
> >
> >
> > - Rohit
> >
> > 
> >
> >
> >
> > rohit.ya...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
>
>
> --
> With best regards, Ivan Kudryavtsev
> Bitworks Software, Ltd.
> Cell: +7-923-414-1515
> WWW: http://bitworks.software/ 
>



-- 
Daan

Re: test file sticking around

[Daan Hoogland]

thanks guys,
I did it in an @After-method anyway to make sure it still gets cleaned on
exceptions.
enjoy https://github.com/apache/cloudstack/pull/2384

On Wed, Jan 3, 2018 at 3:27 PM, Rohit Yadav <rohit.ya...@shapeblue.com>
wrote:

> +1 remove after test finishes.
>
>
>
> - Rohit
>
> <https://cloudstack.apache.org>
>
>
>
> ____
> From: Daan Hoogland <daan.hoogl...@gmail.com>
> Sent: Wednesday, January 3, 2018 7:17:04 PM
> To: dev
> Subject: test file sticking around
>
> devs,
>
> This has been bugging me but not enough to tackle: a file named
> 'services/secondary-storage/server/testfile' is created during the build
> and I think it is created in
> NfsSecondaryStorageResourceTest.testSwiftWriteMetadataFile(). I want to
> solve this with an @After method. Any reason not to? like it being used in
> more then just this test, or it should be destroyed in the test itself.
>
> ​regards,​
> --
> Daan
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>


-- 
Daan

test file sticking around

[Daan Hoogland]

devs,

This has been bugging me but not enough to tackle: a file named
'services/secondary-storage/server/testfile' is created during the build
and I think it is created in
NfsSecondaryStorageResourceTest.testSwiftWriteMetadataFile(). I want to
solve this with an @After method. Any reason not to? like it being used in
more then just this test, or it should be destroyed in the test itself.

​regards,​
-- 
Daan

Re: [VOTE] Clean up old and obsolete branches.

[Daan Hoogland]

0

On Tue, Jan 2, 2018 at 1:51 PM, Gabriel Beims Bräscher  wrote:

> +1
>
> 2018-01-02 9:46 GMT-02:00 Rafael Weingärtner  >:
>
> > Hope you guys had great holy days!
> >
> > Resuming the discussion we started last year in [1]. It is time to vote
> and
> > then to push (if the vote is successful) the protocol defined to our
> wiki.
> > Later we can start enforcing it.
> > I will summarize the protocol for branches in the official repository.
> >
> >1. We only maintain the master and major release branches. We
> currently
> >have a system of X.Y.Z.S. I define major release here as a release
> that
> >changes either ((X or Y) or (X and Y));
> >2. We will use tags for versioning. Therefore, all versions we release
> >are tagged accordingly, including minor and security releases;
> >3. When releasing the “SNAPSHOT” is removed and the branch of the
> >version is created (if the version is being cut from master). Rule (1)
> > one
> >is applied here; therefore, only major releases will receive branches.
> >Every release must have a tag according to the format X.Y.Z.S. After
> >releasing, we bump the POM of the version to next available SNAPSHOT;
> >4. If there's a need to fix an old version, we work on HEAD of
> >corresponding release branch. For instance, if we want to fix
> something
> > in
> >release 4.1.1.0, we will work on branch 4.1, which will have the POM
> > set to
> >4.1.2.0-SNAPSHOT;
> >5. People should avoid (it is not forbidden though) using the official
> >apache repository to store working branches. If we want to work
> > together on
> >some issues, we can set up a fork and give permission to interested
> > parties
> >(the official repository is restricted to committers). If one uses the
> >official repository, the branch used must be cleaned right after
> > merging;
> >6. Branches not following these rules will be removed if they have not
> >received attention (commits) for over 6 (six) months;
> >7. Before the removal of a branch in the official repository it is
> >mandatory to create a Jira ticket and send a notification email to
> >CloudStack’s dev mailing list. If there are no objections, the branch
> > can
> >be deleted seven (7) business days after the notification email is
> sent;
> >8. After the branch removal, the Jira ticket must be closed.
> >
> > Let’s go to the poll:
> > (+1) – I want to work using this protocol
> > (0) – Indifferent to me
> > (-1) – I prefer the way it is not, without any protocol/guidelines
> >
> >
> > [1]
> > http://mail-archives.apache.org/mod_mbox/cloudstack-dev/
> > 201711.mbox/%3CCAHGRR8ozDBX%3DJJewLz_cu-YP9vA3TEmesvxGArTDBPerAOj8Cw%
> > 40mail.gmail.com%3E
> >
> > --
> > Rafael Weingärtner
> >
>



-- 
Daan

Re: DZone article on software management

[Daan Hoogland]

thanks Ron,

Not planning any long train rides but this is worth one ;)

On Thu, Dec 28, 2017 at 11:26 AM, Ron Wheeler <
rwhee...@artifact-software.com> wrote:

> For those who are interested in process.
>
> This is an interesting summary of "Best Practices" for teamwork on
> software projects.
>
> https://dzone.com/storage/assets/7529578-rc-167-softwareconf
> igurationmanagementpatterns.pdf
>
> It describes practices that I believe are currently followed in the
> Cloudstack team.
>
> There is an good discussion about SCM and how to manage a stable
> development line with simple rules for managing private development
> branches.
>
> You may have to sign up for DZone to get this. It is free and I guess that
> you can drop out at any time.
> I understand that some will not want to bother but it is interesting
> reading and may have some sections that explicitly state policies that
> Cloudstack developers are following (or not).
>
> http://www.berczuk.com/ is the author's home page
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>


-- 
Daan

Re: Adding Spellchecker to code style validator

[Daan Hoogland]

like the idea Ivan, I hope it won't be enforced though, and just a help.
Coders are notorious for using spelling to distinguish between instances.

On Wed, Dec 20, 2017 at 1:36 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> +1
>
> On Wed, Dec 20, 2017 at 10:29 AM, Rohit Yadav 
> wrote:
>
> > Hi Ivan,
> >
> >
> > Thanks for the PR, I think that would be a good idea. We can introduce
> > such a checker/task in Travis's first job that currently does some sanity
> > checks (rat+build+unit tests etc).
> >
> >
> > - Rohit
> >
> > 
> > From: Ivan Kudryavtsev 
> > Sent: Tuesday, December 19, 2017 12:48:04 PM
> > To: dev
> > Subject: Adding Spellchecker to code style validator
> >
> > Hello, devs.
> >
> > How about adding spell checking to code style guide. ACS uses a lot of
> java
> > introspection including JSON generation, etc. so typos migrate to
> protocol
> > level. Working on CLOUDSTACK-10168 I found ipv4_adress inside python
> code /
> > dhcp related json, trying to improve "the camp" I moved to java code and
> > found ipv4Adress private var which is used in gson serializer resulting
> to
> > the protocol with bad keywords. Might it be spellchecker is able to fix
> it.
> >
> > The same thing is for logging messages, I usually looking for "address"
> not
> > for "adress" so It's really impossible to find relevant message if typos
> > exist.
> >
> > I'm not java guru to add spellchecker by myself and it's a project policy
> > thing, so might be it's a thing which worth adoption?
> >
> >
> > --
> > With best regards, Ivan Kudryavtsev
> > Bitworks Software, Ltd.
> > Cell: +7-923-414-1515
> > WWW: http://bitworks.software/ 
> >
> > rohit.ya...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
>
>
> --
> Rafael Weingärtner
>



-- 
Daan

Re: Clean up old and obsolete branches

[Daan Hoogland]

any workable procedure (including yours, Rafael) will do but let's be
extremely patient and lenient. I think we can start deleting a lot of old
branches (RC-branches and merged PRs to start with)

On Mon, Dec 18, 2017 at 2:23 PM, Marc-Aurèle Brothier <ma...@exoscale.ch>
wrote:

> +1 for me
>
> On the point 5, since you can have people working together on forks, I
> would simply state that no other branches except the official ones can be
> in the project repository, removing: "If one uses the official repository,
> the branch used must be cleaned right after merging;"
>
> On Mon, Dec 18, 2017 at 2:05 PM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > Guys, this is the moment to give your opinion here. Since nobody has
> > commented anything on the protocol. I will just add some more steps
> before
> > deletion.
> >
> >1. Only maintain the master and major release branches. We currently
> >have a system of X.Y.Z.S. I define major release here as a release
> that
> >changes either ((X or Y) or (X and Y));
> >2. We will use tags for versioning. Therefore, all versions we release
> >are tagged accordingly, including minor and security releases;
> >3. When releasing the “SNAPSHOT” is removed and the branch of the
> >version is created (if the version is being cut from master). Rule (1)
> > one
> >is applied here; therefore, only major releases will receive branches.
> >Every release must have a tag in the format X.Y.Z.S. After releasing,
> we
> >bump the pom of the version to next available SNAPSHOT;
> >4. If there's a need to fix an old version, we work on HEAD of
> >corresponding release branch;
> >5. People should avoid using the official apache repository to store
> >working branches. If we want to work together on some issues, we can
> > set up
> >a fork and give permission to interested parties (the official
> > repository
> >is restricted to committers). If one uses the official repository, the
> >branch used must be cleaned right after merging;
> >6. Branches not following these rules will be removed if they have not
> >received attention (commits) for over 6 (six) months;
> >7. Before the removal of a branch in the official repository it is
> >mandatory to create a Jira ticket and send a notification email to
> >CloudStack’s dev mailing list. If there are no objections, the branch
> > can
> >be deleted seven (7) business days after the notification email is
> sent;
> >8. After the branch removal, the Jira ticket must be closed.
> >
> >
> >  I will wait more two days. If we do not get comments here anymore, I
> will
> > call for a vote, and then if there are no objections I will write the
> > protocol on our Wiki. Afterwards, we can start removing branches
> (following
> > the defined protocol).
> >
> > On Thu, Dec 14, 2017 at 5:08 PM, Daan Hoogland <daan.hoogl...@gmail.com>
> > wrote:
> >
> > > sounds lime a lazy consensus vote; +1 from me
> > >
> > > On Thu, Dec 14, 2017 at 7:07 PM, Rafael Weingärtner <
> > > rafaelweingart...@gmail.com> wrote:
> > >
> > > > Guys,
> > > >
> > > > Khosrow has done a great job here, but we still need to move this
> > forward
> > > > and create a standard/guidelines on how to use the official repo.
> > Looking
> > > > at the list in [1] we can clearly see that things are messy.  This
> is a
> > > > minor discussion, but in my opinion, we should finish it.
> > > >
> > > > [1] https://issues.apache.org/jira/browse/CLOUDSTACK-10169
> > > >
> > > > I will propose the following regarding the use of the official
> > > repository.
> > > > I will be waiting for your feedback, and then proceed with a vote.
> > > >
> > > >1. Only maintain the master and major release branches. We
> currently
> > > >have a system of X.Y.Z.S. I define major release here as a release
> > > that
> > > >changes either ((X or Y) or (X and Y));
> > > >2. We will use tags for versioning. Therefore, all versions we
> > release
> > > >are tagged accordingly, including minor and security releases;
> > > >3. When releasing the “SNAPSHOT” is removed and the branch of the
> > > >version is created (if the version is being cut from master). Rule
> > (1)
> > > > one
> > > >is applied here; the

Re: [Discuss] Management cluster / Zookeeper holding locks

[Daan Hoogland]

Are you proposing to add zookeeper as an optional requirement, Marc-Aurèle?
or just curator? and what is the decision mech of including it or not?

On Mon, Dec 18, 2017 at 9:33 AM, Marc-Aurèle Brothier 
wrote:

> Hi everyone,
>
> I was wondering how many of you are running CloudStack with a cluster of
> management servers. I would think most of you, but it would be nice to hear
> everyone voices. And do you get hosts going over their capacity limits?
>
> We discovered that during the VM allocation, if you get a lot of parallel
> requests to create new VMs, most notably with large profiles, the capacity
> increase is done too far after the host capacity checks and results in
> hosts going over their capacity limits. To detail the steps: the deployment
> planner checks for cluster/host capacity and pick up one deployment plan
> (zone, cluster, host). The plan is stored in the database under a VMwork
> job and another thread picks that entry and starts the deployment,
> increasing the host capacity and sending the commands. Here there's a time
> gap between the host being picked up and the capacity increase for that
> host of a couple of seconds, which is well enough to go over the capacity
> on one or more hosts. A few VMwork job can be added in the DB queue
> targeting the same host before one gets picked up.
>
> To fix this issue, we're using Zookeeper to act as the multi JVM lock
> manager thanks to their curator library (
> https://curator.apache.org/curator-recipes/shared-lock.html). We also
> changed the time when the capacity is increased, which occurs now pretty
> much after the deployment plan is found and inside the zookeeper lock. This
> ensure we don't go over the capacity of any host, and it has been proven
> efficient since a month in our management server cluster.
>
> This adds another potential requirement which should be discuss before
> proposing a PR. Today the code works seamlessly without ZK too, to ensure
> it's not a hard requirement, for example in a lab.
>
> Comments?
>
> Kind regards,
> Marc-Aurèle
>



-- 
Daan

Re: Clean up old and obsolete branches

[Daan Hoogland]

sounds lime a lazy consensus vote; +1 from me

On Thu, Dec 14, 2017 at 7:07 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Guys,
>
> Khosrow has done a great job here, but we still need to move this forward
> and create a standard/guidelines on how to use the official repo. Looking
> at the list in [1] we can clearly see that things are messy.  This is a
> minor discussion, but in my opinion, we should finish it.
>
> [1] https://issues.apache.org/jira/browse/CLOUDSTACK-10169
>
> I will propose the following regarding the use of the official repository.
> I will be waiting for your feedback, and then proceed with a vote.
>
>1. Only maintain the master and major release branches. We currently
>have a system of X.Y.Z.S. I define major release here as a release that
>changes either ((X or Y) or (X and Y));
>2. We will use tags for versioning. Therefore, all versions we release
>are tagged accordingly, including minor and security releases;
>3. When releasing the “SNAPSHOT” is removed and the branch of the
>version is created (if the version is being cut from master). Rule (1)
> one
>is applied here; therefore, only major releases will receive branches.
>Every release must have a tag in the format X.Y.Z.S. After releasing, we
>bump the pom of the version to next available SNAPSHOT;
>4. If there's a need to fix an old version, we work on HEAD of
>corresponding release branch;
>5. People should avoid using the official apache repository to store
>working branches. If we want to work together on some issues, we can
> set up
>a fork and give permission to interested parties (the official
> repository
>is restricted to committers). If one uses the official repository, the
>branch used must be cleaned right after merging;
>6. Branches not following these rules will be removed if they have not
>received attention (commits) for over 6 (six) months.
>
> I think that is all. Do you guys have additions/removals/proposals so we
> can move this forward?
>
> On Mon, Dec 4, 2017 at 7:20 PM, Khosrow Moossavi 
> wrote:
>
> > I agree Erik. I updated the list in CLOUDSTACK-10169 with more
> information
> > (last updated, last commit, HEAD on master and PR status/number) to give
> us
> > more immediate visibility of the status of those branches. So any
> branches
> > can
> > be deleted if:
> >
> > - which its HEAD exists on master
> > - its PR was merged or closed (which surprisingly are not so many)
> > - it's old (last updated in 2015 or before?)
> >
> > and the rest of them can be deleted after more examination (if need be).
> >
> >
> > On Mon, Dec 4, 2017 at 6:37 AM, Rafael Weingärtner <
> > rafaelweingart...@gmail.com> wrote:
> >
> > > I thought someone might bring that up. The problem with using branches
> in
> > > the official repo is that only committers will be able to commit there.
> > So,
> > > we would restrict the group of people that might be able to participate
> > in
> > > this type of cooperation. I do not see the difficulty for a
> > > contributor/committer to give permissions for others in their own
> > > repository that is a fork from our official one. I have done that with
> > some
> > > friends before.
> > >
> > > Also, do not worry Erik; the idea is not to delete anything right away.
> > We
> > > are only bringing the topic for a broader discussion here.
> > >
> > > On Mon, Dec 4, 2017 at 8:58 AM, Erik Weber 
> wrote:
> > >
> > > > On Thu, Nov 30, 2017 at 9:05 PM, Khosrow Moossavi
> > > >  wrote:
> > > > > Hi Community
> > > > >
> > > > > I would like to start the discussion around deleting old and
> obsolete
> > > > > branches on github repository. This will help newcomers (including
> > > > myself)
> > > > > to keep track of which branches are important and which are not.
> And
> > > > since
> > > > > almost everyone's working on their own forks there is no need to
> keep
> > > > > feature/bugfix/hotfix branches around in the main official
> > repository.
> > > > >
> > > > > I've created an issue which contains full list of branches in
> > > > > GH/apache/cloudstack repo as of time of writing this email and the
> > > > > proposition of which one of them can be deleted.
> > > > >
> > > > > https://issues.apache.org/jira/browse/CLOUDSTACK-10169
> > > > >
> > > > > I would appreciate your questions, comments, suggestions.
> > > >
> > > > Do note that there might be branches with unmerged changes, I don't
> > > > think we should just automatically delete those without reflecting
> > > > over its content.
> > > > Although these branch might be stray now, there could be pieces there
> > > > that someone else could use at a later point.
> > > >
> > > > As for old feature/fix branches that has been merged, I'm +1 to
> > > > cleanup up those.
> > > >
> > > > --
> > > > Erik
> > > >
> > >
> > >
> > >
> > > --
> > > Rafael Weingärtner
> > >
> >
>
>
>
> --
> 

Re: Clean up old and obsolete branches

[Daan Hoogland]

also I think we can tolerate collective work on our repo. Not everything
has to go on forks.

On Fri, Dec 1, 2017 at 11:04 AM, Daan Hoogland <daan.hoogl...@gmail.com>
wrote:

> Rafael, I don't think that works. the versions in the pom.xml files are
> updated to non snapshot versions on per release mini branches. I like the
> principle but be carefull not to remove the GA branches.
>
> On Fri, Dec 1, 2017 at 10:41 AM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
>> Thanks for the initiative and the hard worki Khosrow!
>>
>> In my opinion, we should only maintain the master and major release
>> branches. Then, for minor versions, we can keep track of them using tags.
>> There is no need to have things such as GA-4.4.1, GA-4.4.2, and so forth.
>> Instead, we should keep only the branch 4.4, and the minor versions are
>> built on top of that branch (the branch would always have the top minor
>> version of the major version). The versioning is done using tags, and not
>> branches. Moreover, people should not use the official apache repository
>> to
>> store working branches. Working branches should be kept at the developer’s
>> personal repository on Github.
>>
>> To the initial list, I would also remove things such as GA-4.4.1,
>> GA-4.4.2,
>> and so on. As I said, we only need on branch per major release. The
>> versioning is executed through tags, and fixes on past releases should be
>> done in the branch of the release. Also, there are things like
>> “add_XS_71_72”, “cloudearlyinit”, “new-location”, and
>> “debian9-systemvmtemplate”; none of them should be there. They are working
>> branch from contributors/committers. These branches can be at their own
>> personal forks.
>>
>> On Fri, Dec 1, 2017 at 4:16 AM, Daan Hoogland <daan.hoogl...@gmail.com>
>> wrote:
>>
>> > thanks for that list Khosrow,  Also very usefull for cleaning people to
>> > clean their own fork.
>> > I think you can start with the lowest pom versions but I changed one
>> > because the referred ticket isn't closed. It's my own and I'll have a
>> look
>> > later today. For a lot of the branches the ticket aren't clear because
>> only
>> >  or CS- is in the titel. Only when
>> CLOUDSTACK-> > number> is in the titel you can see immediately that it is closed by the
>> > automatic strikethrough that happens. just a heads-up.
>> >
>> > +1
>> >
>> >
>> > On Fri, Dec 1, 2017 at 2:13 AM, Gabriel Beims Bräscher <
>> > gabrasc...@gmail.com
>> > > wrote:
>> >
>> > > Thanks for the initiative, Khosrow.
>> > >
>> > > +1 on removing obsolete branches.
>> > >
>> > > 2017-11-30 18:05 GMT-02:00 Khosrow Moossavi <kmooss...@cloudops.com>:
>> > >
>> > > > Hi Community
>> > > >
>> > > > I would like to start the discussion around deleting old and
>> obsolete
>> > > > branches on github repository. This will help newcomers (including
>> > > myself)
>> > > > to keep track of which branches are important and which are not. And
>> > > since
>> > > > almost everyone's working on their own forks there is no need to
>> keep
>> > > > feature/bugfix/hotfix branches around in the main official
>> repository.
>> > > >
>> > > > I've created an issue which contains full list of branches in
>> > > > GH/apache/cloudstack repo as of time of writing this email and the
>> > > > proposition of which one of them can be deleted.
>> > > >
>> > > > https://issues.apache.org/jira/browse/CLOUDSTACK-10169
>> > > >
>> > > > I would appreciate your questions, comments, suggestions.
>> > > >
>> > > > Thanks
>> > > >
>> > > > Khosrow Moossavi
>> > > >
>> > > > Cloud Infrastructure Developer
>> > > >
>> > > > CloudOps
>> > > >
>> > >
>> >
>> >
>> >
>> > --
>> > Daan
>> >
>>
>>
>>
>> --
>> Rafael Weingärtner
>>
>
>
>
> --
> Daan
>



-- 
Daan

Re: Clean up old and obsolete branches

[Daan Hoogland]

Rafael, I don't think that works. the versions in the pom.xml files are
updated to non snapshot versions on per release mini branches. I like the
principle but be carefull not to remove the GA branches.

On Fri, Dec 1, 2017 at 10:41 AM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Thanks for the initiative and the hard worki Khosrow!
>
> In my opinion, we should only maintain the master and major release
> branches. Then, for minor versions, we can keep track of them using tags.
> There is no need to have things such as GA-4.4.1, GA-4.4.2, and so forth.
> Instead, we should keep only the branch 4.4, and the minor versions are
> built on top of that branch (the branch would always have the top minor
> version of the major version). The versioning is done using tags, and not
> branches. Moreover, people should not use the official apache repository to
> store working branches. Working branches should be kept at the developer’s
> personal repository on Github.
>
> To the initial list, I would also remove things such as GA-4.4.1, GA-4.4.2,
> and so on. As I said, we only need on branch per major release. The
> versioning is executed through tags, and fixes on past releases should be
> done in the branch of the release. Also, there are things like
> “add_XS_71_72”, “cloudearlyinit”, “new-location”, and
> “debian9-systemvmtemplate”; none of them should be there. They are working
> branch from contributors/committers. These branches can be at their own
> personal forks.
>
> On Fri, Dec 1, 2017 at 4:16 AM, Daan Hoogland <daan.hoogl...@gmail.com>
> wrote:
>
> > thanks for that list Khosrow,  Also very usefull for cleaning people to
> > clean their own fork.
> > I think you can start with the lowest pom versions but I changed one
> > because the referred ticket isn't closed. It's my own and I'll have a
> look
> > later today. For a lot of the branches the ticket aren't clear because
> only
> >  or CS- is in the titel. Only when
> CLOUDSTACK- > number> is in the titel you can see immediately that it is closed by the
> > automatic strikethrough that happens. just a heads-up.
> >
> > +1
> >
> >
> > On Fri, Dec 1, 2017 at 2:13 AM, Gabriel Beims Bräscher <
> > gabrasc...@gmail.com
> > > wrote:
> >
> > > Thanks for the initiative, Khosrow.
> > >
> > > +1 on removing obsolete branches.
> > >
> > > 2017-11-30 18:05 GMT-02:00 Khosrow Moossavi <kmooss...@cloudops.com>:
> > >
> > > > Hi Community
> > > >
> > > > I would like to start the discussion around deleting old and obsolete
> > > > branches on github repository. This will help newcomers (including
> > > myself)
> > > > to keep track of which branches are important and which are not. And
> > > since
> > > > almost everyone's working on their own forks there is no need to keep
> > > > feature/bugfix/hotfix branches around in the main official
> repository.
> > > >
> > > > I've created an issue which contains full list of branches in
> > > > GH/apache/cloudstack repo as of time of writing this email and the
> > > > proposition of which one of them can be deleted.
> > > >
> > > > https://issues.apache.org/jira/browse/CLOUDSTACK-10169
> > > >
> > > > I would appreciate your questions, comments, suggestions.
> > > >
> > > > Thanks
> > > >
> > > > Khosrow Moossavi
> > > >
> > > > Cloud Infrastructure Developer
> > > >
> > > > CloudOps
> > > >
> > >
> >
> >
> >
> > --
> > Daan
> >
>
>
>
> --
> Rafael Weingärtner
>



-- 
Daan

Re: Clean up old and obsolete branches

[Daan Hoogland]

thanks for that list Khosrow,  Also very usefull for cleaning people to
clean their own fork.
I think you can start with the lowest pom versions but I changed one
because the referred ticket isn't closed. It's my own and I'll have a look
later today. For a lot of the branches the ticket aren't clear because only
 or CS- is in the titel. Only when CLOUDSTACK- is in the titel you can see immediately that it is closed by the
automatic strikethrough that happens. just a heads-up.

+1


On Fri, Dec 1, 2017 at 2:13 AM, Gabriel Beims Bräscher  wrote:

> Thanks for the initiative, Khosrow.
>
> +1 on removing obsolete branches.
>
> 2017-11-30 18:05 GMT-02:00 Khosrow Moossavi :
>
> > Hi Community
> >
> > I would like to start the discussion around deleting old and obsolete
> > branches on github repository. This will help newcomers (including
> myself)
> > to keep track of which branches are important and which are not. And
> since
> > almost everyone's working on their own forks there is no need to keep
> > feature/bugfix/hotfix branches around in the main official repository.
> >
> > I've created an issue which contains full list of branches in
> > GH/apache/cloudstack repo as of time of writing this email and the
> > proposition of which one of them can be deleted.
> >
> > https://issues.apache.org/jira/browse/CLOUDSTACK-10169
> >
> > I would appreciate your questions, comments, suggestions.
> >
> > Thanks
> >
> > Khosrow Moossavi
> >
> > Cloud Infrastructure Developer
> >
> > CloudOps
> >
>



-- 
Daan

Re: Hello

[Daan Hoogland]

nice to virtually meet you again, Ernie. have fun

On Thu, Nov 30, 2017 at 11:26 AM, Nux!  wrote:

> Welcome Ernie :>
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
> > From: "Rohit Yadav" 
> > To: "dev" 
> > Sent: Thursday, 30 November, 2017 09:47:17
> > Subject: Re: Hello
>
> > Welcome Ernie!
> >
> >
> > - Rohit
> >
> > 
> > From: Ernie Janse van Rensburg 
> > Sent: Thursday, November 30, 2017 2:08:57 PM
> > To: dev@cloudstack.apache.org
> > Subject: Hello
> >
> > Hi All
> >
> > I have recently joined Shape Blue as a software engineer and looking
> forward to
> > be part of the community.
> >
> > Regards
> >
> > Ernie Janse van Rensburg
> >
> > (Cape Town - South Africa)
> >
> > ernie.jvrensb...@shapeblue.com
> > www.shapeblue.com
> > ,
> > @shapeblue
> >
> >
> >
> >
> > rohit.ya...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
>



-- 
Daan

Re: CloudStack LTS EOL date?

[Daan Hoogland]

Ivan, don't do two sets of fixes. We will forwarfd merge from the 4.10
branch to master

On Thu, Nov 23, 2017 at 10:13 AM, Ivan Kudryavtsev  wrote:

> Hi, Paul.
>
> All my fixes to 4.10 are in pr:
> https://github.com/apache/cloudstack/pull/2320
>
> I think it should be organized somehow with PR per bug, just don't have
> enough time to do it with 4.10, but I sent all PRs for bugs found
> separately to master with jira tickets and all-in-one PR to 4.10.
>
> 23 нояб. 2017 г. 4:06 ПП пользователь "Paul Angus" <
> paul.an...@shapeblue.com>
> написал:
>
> > I'll add 'update the downloads page' to the wiki update...
> >
> > But for the rest of Ivan's issues, sounds like we need a 4.10.1 as well
> as
> > a 4.11
> >
> > Are there fixes in the master branch for the issues that you are seeing
> > Ivan (and are there bugs logged in Jira as blockers if not?)
> >
> >
> > Kind regards,
> >
> > Paul Angus
> >
> > paul.an...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
> > -Original Message-
> > From: Giles Sirett [mailto:giles.sir...@shapeblue.com]
> > Sent: 23 November 2017 09:01
> > To: dev@cloudstack.apache.org
> > Subject: RE: CloudStack LTS EOL date?
> >
> > I agree Ivan
> > http://cloudstack.apache.org/downloads.html makes no mention of LTS and
> > provides no guidance on benefits of different versions
> >
> > Kind regards
> > Giles
> >
> > giles.sir...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
> >
> >
> >
> >
> > -Original Message-
> > From: Ivan Kudryavtsev [mailto:kudryavtsev...@bw-sw.com]
> > Sent: 23 November 2017 01:45
> > To: dev@cloudstack.apache.org
> > Subject: Re: CloudStack LTS EOL date?
> >
> > Hi, all. Previous reply to wrong thread. Copy here.
> > According to Paul, everything looks ok, but I still feel the website
> > content is lacking of the information. My belief that index should
> clearly
> > state:
> >
> > Current LTS 4.9 | updated 2017.11.12 (4.9.3) | EOL=2018.X.Y Previous LTS
> > 4.X | updated 2017.04.01 (4.X.12) | EOL=2017.X.Y
> >
> > Current 4.10 | updated 2017.11.20 (4.10.1) | EOL=2018.05.Y
> >
> > The same is for download page. The reason is that some people don't need
> > new, they need very proven. Other need supported and third group needs
> > features.
> >
> > E.g. Right now we updated our proxmox nodes to latest stable and found
> > windows 8 is no longer works as expected. Previous stable - ok. We rolled
> > back. I mean that it could be a good way for a lot of users to see and
> > realize what options they have. Even now, we still have 4.3 in production
> > and happy.
> >
> > Right now, new person just downloads 4.10 and gets a lot of regressions
> > and unstable code. You might have seen last day e-mail threads. Even
> > templates created from snapshots are broken in 4.10 and it is
> > critical/blocker bug.
> > The user can meet the situation, that after a months when ssvm is
> reloaded
> > all users lost tons of templates.
> >
> > 22 нояб. 2017 г. 11:49 ПП пользователь "Will Stevens" <
> > wstev...@cloudops.com>
> > написал:
> >
> > Paul, I thought a 'big mouth' was a prerequisite for the RM position.
> > Isn't that the only reason I was the 4.9 RM?  :P
> >
> > *Will Stevens*
> > CTO
> >
> > 
> >
> > On Wed, Nov 22, 2017 at 11:39 AM, Paul Angus 
> > wrote:
> >
> > > HI All,
> > >
> > > The current LTS cycle is based on having an LTS release twice a year
> > > (at the time of design, ACS releases were coming out monthly).
> > >
> > > So, twice a year (nominally, January and July) we take the then
> > > current version of CloudStack, and declare that an LTS version, for
> > > which would we would then backport fixes for a period of up to 2
> > > years.  Thereby giving end users a version of CloudStack which would
> > > receive bug fixes for an extended period.
> > >
> > > This year however, the current version in January was the same as the
> > > current version in July, therefore 4.9 became the 'July' LTS as well
> > > as January LTS and therefore 4.9 will be supported until summer 2019
> > > (hence the 4.9.3 release)
> > >
> > > I and a number of my colleagues remain committed to continue to
> > > support 'LTS' releases in this fashion (there just wasn't anything
> > > really to 'announce' in July), which may be why people think that
> > > nothing is happening.
> > >
> > > With 2 LTS releases a year (6 months apart), 'next LTS +6 months'
> > > would only be 12 months from release.  Which I think is really too
> > > short a
> > period
> > > for the majority of enterprises.  Although we haven't written it this
> > > way, the current scheme gives a EOL of 'next LTS + 18 months'.
> > >
> > > So, I'm in favour of leaving things as they are.   The wiki page looks
> > > like it needs updating to be clearer (I'm happy to do that)
> > >
> > >
> > > But I DO 

Re: New committer: Gabriel Beims Bräscher

[Daan Hoogland]

welcome Gabriel, go get'm

On Thu, Nov 16, 2017 at 8:37 AM, Marc-Aurèle Brothier - Exoscale <
ma...@exoscale.ch> wrote:

> Welcome Gabriel & congrats!
>
> Marc-Aurèle
>
> On Wed, 2017-11-15 at 08:32 -0200, Rafael Weingärtner wrote:
> > The Project Management Committee (PMC) for Apache CloudStack has
> > invited
> > Gabriel Beims Bräscher to become committer and we are pleased to
> > announce
> > that he has accepted.
> >
> > Gabriel has shown commitment to Apache CloudStack community,
> > contributing
> > with PRs in a constant fashion. Moreover, he has also proved great
> > abilities to interact with the community quite often in our mailing
> > lists
> > and Slack channel trying to help people.
> >
> > Let´s congratulate and welcome Apache CloudStack’s newest committer.
> >
> > --
> > Rafael Weingärtner
>



-- 
Daan

Re: jetty simulator problem

[Daan Hoogland]

@Rohit, all of this is with -Dsimulator. It is probably due to one of my
many bad habits but I have this on fedora 26, macos 10.13 and macos 10.11

On Tue, Nov 14, 2017 at 5:49 PM, Rohit Yadav <rohit.ya...@shapeblue.com>
wrote:

> Daan,
>
> Try doing a mvn clean install build with - Dsimulator. See wiki on
> building for other parameters to consider or the Travis build/launch
> scripts,including prefering ipv4 stack.
>
> Our Travis build is green on current master, so likely an environment
> issue is causing these failures.
>
> PS. we recently upgraded master to spring 5.x however we have not caught
> any issues ib Travis or Trillian yet. Keep me posted if you still face the
> issues.
>
> Regards.
> 
> From: Rafael Weingärtner <rafaelweingart...@gmail.com>
> Sent: Tuesday, November 14, 2017 5:56:03 PM
> To: dev@cloudstack.apache.org
> Subject: Re: jetty simulator problem
>
> It works without removing annotation because they are not being processed
> (@component). That is why when you deleted the beans declaration in the XML
> Spring started complaining about those beans. So, if they are not being
> used, we can simply remove them.
>
> On Tue, Nov 14, 2017 at 10:09 AM, Daan Hoogland <daan.hoogl...@gmail.com>
> wrote:
>
> > On Tue, Nov 14, 2017 at 12:00 PM, Rafael Weingärtner <
> > rafaelweingart...@gmail.com> wrote:
> >
> > > That depends-on configuration is not needed when attributes are
> annotated
> > > with @inject or @Autowired, spring builds automatically de dependency
> > > hierarchy. Even though the removal of them did not seem to be
> necessary,
> > >
> > ​the other way around, it worked without removing the annotation, just
> > removing the depends-on attribute was enough.
> >
> > ​
> >
> > ​I haven't tried with the attribute and without the annotations.
> >
> > ​
> >
> > > their use is also not necessary. The issue seems to be related to
> > > application contexts building order. I am not sure how spring behaves
> > when
> > > it encounters the “depend-on” configuration and the bean have not yet
> > been
> > > created and this bean is in another XML file that has not yet been
> > > processed. When we moved to fat jar approach, was any version of the
> > > dependencies changed?
> > >
> > ​don't know, i haven't found any yet (looking at CLOUDSTACK-10012 tagged
> > commits)
> >
> > >
> > > On Tue, Nov 14, 2017 at 7:31 AM, Daan Hoogland <
> daan.hoogl...@gmail.com>
> > > wrote:
> > >
> > > > it actually already works with only the depends-on attributes in the
> > xml
> > > > removed but it all makes sense.
> > > >
> > > > On Tue, Nov 14, 2017 at 1:59 AM, Rafael Weingärtner <
> > > > rafaelweingart...@gmail.com> wrote:
> > > >
> > > > > I removed some spring configurations that were not making sense to
> > me.
> > > > > After that, everything started working. I committed these changes
> at
> > > > > https://github.com/rafaelweingartner/cloudstack/
> > tree/daanTestSimulator
> > > > >
> > > > > Could you test it? If it works I can open a PR.
> > > > >
> > > > > On Mon, Nov 13, 2017 at 5:33 PM, Daan Hoogland <
> > > daan.hoogl...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > trying with only the depends-on lines removed now
> > > > > >
> > > > > > On Mon, Nov 13, 2017 at 8:30 PM, Daan Hoogland <
> > > > daan.hoogl...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > from maven:
> > > > > > > mvn -pl client jetty:run -Dsimulator
> > > > > > >
> > > > > > > On Mon, Nov 13, 2017 at 8:16 PM, Rafael Weingärtner <
> > > > > > > rafaelweingart...@gmail.com> wrote:
> > > > > > >
> > > > > > >> The error changed! That is good... It is a misconfiguration
> with
> > > > > > >> dependencies between modules.
> > > > > > >> How are you running the simulator?
> > > > > > >>
> > > > > > >> On Mon, Nov 13, 2017 at 5:13 PM, Daan Hoogland <
> > > > > daan.hoogl...@gmail.com
> > > > > > >
> > > > > > >> wrote:
> > > > > > >>
> >

Re: jetty simulator problem

[Daan Hoogland]

On Tue, Nov 14, 2017 at 12:00 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> That depends-on configuration is not needed when attributes are annotated
> with @inject or @Autowired, spring builds automatically de dependency
> hierarchy. Even though the removal of them did not seem to be necessary,
>
​the other way around, it worked without removing the annotation, just
removing the depends-on attribute was enough.

​

​I haven't tried with the attribute and without the annotations.

​

> their use is also not necessary. The issue seems to be related to
> application contexts building order. I am not sure how spring behaves when
> it encounters the “depend-on” configuration and the bean have not yet been
> created and this bean is in another XML file that has not yet been
> processed. When we moved to fat jar approach, was any version of the
> dependencies changed?
>
​don't know, i haven't found any yet (looking at CLOUDSTACK-10012 tagged
commits)

>
> On Tue, Nov 14, 2017 at 7:31 AM, Daan Hoogland <daan.hoogl...@gmail.com>
> wrote:
>
> > it actually already works with only the depends-on attributes in the xml
> > removed but it all makes sense.
> >
> > On Tue, Nov 14, 2017 at 1:59 AM, Rafael Weingärtner <
> > rafaelweingart...@gmail.com> wrote:
> >
> > > I removed some spring configurations that were not making sense to me.
> > > After that, everything started working. I committed these changes at
> > > https://github.com/rafaelweingartner/cloudstack/tree/daanTestSimulator
> > >
> > > Could you test it? If it works I can open a PR.
> > >
> > > On Mon, Nov 13, 2017 at 5:33 PM, Daan Hoogland <
> daan.hoogl...@gmail.com>
> > > wrote:
> > >
> > > > trying with only the depends-on lines removed now
> > > >
> > > > On Mon, Nov 13, 2017 at 8:30 PM, Daan Hoogland <
> > daan.hoogl...@gmail.com>
> > > > wrote:
> > > >
> > > > > from maven:
> > > > > mvn -pl client jetty:run -Dsimulator
> > > > >
> > > > > On Mon, Nov 13, 2017 at 8:16 PM, Rafael Weingärtner <
> > > > > rafaelweingart...@gmail.com> wrote:
> > > > >
> > > > >> The error changed! That is good... It is a misconfiguration with
> > > > >> dependencies between modules.
> > > > >> How are you running the simulator?
> > > > >>
> > > > >> On Mon, Nov 13, 2017 at 5:13 PM, Daan Hoogland <
> > > daan.hoogl...@gmail.com
> > > > >
> > > > >> wrote:
> > > > >>
> > > > >> > didn't work:( trying with only some parts removed now
> > > > >> >
> > > > >> > Caused by: org.springframework.beans.factory.
> > > > >> > NoSuchBeanDefinitionException:
> > > > >> > No qualifying bean of type
> > > > >> > 'org.apache.cloudstack.engine.subsystem.api.storage.
> > > SnapshotService'
> > > > >> > available: expected at least 1 bean which qualifies as autowire
> > > > >> candidate.
> > > > >> > Dependency annotations: {@javax.inject.Inject()}
> > > > >> > at
> > > > >> > org.springframework.beans.factory.support.
> > > DefaultListableBeanFactory.
> > > > >> > raiseNoMatchingBeanFound
> > > > >> > (DefaultListableBeanFactory.java:1501)
> > > > >> >
> > > > >> > On Mon, Nov 13, 2017 at 7:27 PM, Rafael Weingärtner <
> > > > >> > rafaelweingart...@gmail.com> wrote:
> > > > >> >
> > > > >> > > These beans declarations do not make much sense. They are
> > declared
> > > > >> twice,
> > > > >> > > once in the XML (spring-engine-storage-
> > > snapshot-core-context.xml),
> > > > >> and
> > > > >> > the
> > > > >> > > second declaration is executed through the use of annotations
> > > > >> > (@Component)
> > > > >> > > in those classes. This exception is happening because there
> is a
> > > > >> > > configuration in the XML saying that one bean is depending on
> > the
> > > > >> other.
> > > > >> > > You can simply remove lines 30-40 from the XML file to fix
> this.
> > > > >> > >
> > > > >> > &g

Re: jetty simulator problem

[Daan Hoogland]

it actually already works with only the depends-on attributes in the xml
removed but it all makes sense.

On Tue, Nov 14, 2017 at 1:59 AM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> I removed some spring configurations that were not making sense to me.
> After that, everything started working. I committed these changes at
> https://github.com/rafaelweingartner/cloudstack/tree/daanTestSimulator
>
> Could you test it? If it works I can open a PR.
>
> On Mon, Nov 13, 2017 at 5:33 PM, Daan Hoogland <daan.hoogl...@gmail.com>
> wrote:
>
> > trying with only the depends-on lines removed now
> >
> > On Mon, Nov 13, 2017 at 8:30 PM, Daan Hoogland <daan.hoogl...@gmail.com>
> > wrote:
> >
> > > from maven:
> > > mvn -pl client jetty:run -Dsimulator
> > >
> > > On Mon, Nov 13, 2017 at 8:16 PM, Rafael Weingärtner <
> > > rafaelweingart...@gmail.com> wrote:
> > >
> > >> The error changed! That is good... It is a misconfiguration with
> > >> dependencies between modules.
> > >> How are you running the simulator?
> > >>
> > >> On Mon, Nov 13, 2017 at 5:13 PM, Daan Hoogland <
> daan.hoogl...@gmail.com
> > >
> > >> wrote:
> > >>
> > >> > didn't work:( trying with only some parts removed now
> > >> >
> > >> > Caused by: org.springframework.beans.factory.
> > >> > NoSuchBeanDefinitionException:
> > >> > No qualifying bean of type
> > >> > 'org.apache.cloudstack.engine.subsystem.api.storage.
> SnapshotService'
> > >> > available: expected at least 1 bean which qualifies as autowire
> > >> candidate.
> > >> > Dependency annotations: {@javax.inject.Inject()}
> > >> > at
> > >> > org.springframework.beans.factory.support.
> DefaultListableBeanFactory.
> > >> > raiseNoMatchingBeanFound
> > >> > (DefaultListableBeanFactory.java:1501)
> > >> >
> > >> > On Mon, Nov 13, 2017 at 7:27 PM, Rafael Weingärtner <
> > >> > rafaelweingart...@gmail.com> wrote:
> > >> >
> > >> > > These beans declarations do not make much sense. They are declared
> > >> twice,
> > >> > > once in the XML (spring-engine-storage-
> snapshot-core-context.xml),
> > >> and
> > >> > the
> > >> > > second declaration is executed through the use of annotations
> > >> > (@Component)
> > >> > > in those classes. This exception is happening because there is a
> > >> > > configuration in the XML saying that one bean is depending on the
> > >> other.
> > >> > > You can simply remove lines 30-40 from the XML file to fix this.
> > >> > >
> > >> > >
> > >> > >
> > >> > > Side note: Spring automatically build the chain of dependencies
> > >> between
> > >> > > beans to execute the dependency injection properly. The
> > configuration
> > >> > > "depends-on" you find in the XML "bean" element is to define an
> > exotic
> > >> > and
> > >> > > not obvious dependency.
> > >> > >
> > >> > >
> > >> > > On Mon, Nov 13, 2017 at 3:48 PM, Daan Hoogland <
> > >> daan.hoogl...@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > > > I'm looking at a problem, any one recognises this on master?
> > >> simulator
> > >> > > does
> > >> > > > not start cleanly.
> > >> > > >
> > >> > > > [WARNING] Failed startup of context
> o.e.j.m.p.JettyWebAppContext@
> > >> > > 51de5efa
> > >> > > > {/client,file:/Users/dahn/apache/cloudstack/client/
> > >> > > > target/classes/META-INF/webapp/,STARTING}{file:/Users/
> > >> > > > dahn/apache/cloudstack/client/target/classes/META-INF/webapp/}
> > >> > > > org.springframework.beans.factory.BeanCreationException: Error
> > >> > creating
> > >> > > > bean with name 'snapshotDataFactoryImpl' defined in URL
> > >> > > > [jar:file:/Users/dahn/.m2/repository/org/apache/
> > >> > cloudstack/cloud-engine-
> > >> > > > storage-snapshot/4.11.0.0-SNAPSHOT/cloud-engine-storage-
>

Re: jetty simulator problem

[Daan Hoogland]

trying with only the depends-on lines removed now

On Mon, Nov 13, 2017 at 8:30 PM, Daan Hoogland <daan.hoogl...@gmail.com>
wrote:

> from maven:
> mvn -pl client jetty:run -Dsimulator
>
> On Mon, Nov 13, 2017 at 8:16 PM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
>> The error changed! That is good... It is a misconfiguration with
>> dependencies between modules.
>> How are you running the simulator?
>>
>> On Mon, Nov 13, 2017 at 5:13 PM, Daan Hoogland <daan.hoogl...@gmail.com>
>> wrote:
>>
>> > didn't work:( trying with only some parts removed now
>> >
>> > Caused by: org.springframework.beans.factory.
>> > NoSuchBeanDefinitionException:
>> > No qualifying bean of type
>> > 'org.apache.cloudstack.engine.subsystem.api.storage.SnapshotService'
>> > available: expected at least 1 bean which qualifies as autowire
>> candidate.
>> > Dependency annotations: {@javax.inject.Inject()}
>> > at
>> > org.springframework.beans.factory.support.DefaultListableBeanFactory.
>> > raiseNoMatchingBeanFound
>> > (DefaultListableBeanFactory.java:1501)
>> >
>> > On Mon, Nov 13, 2017 at 7:27 PM, Rafael Weingärtner <
>> > rafaelweingart...@gmail.com> wrote:
>> >
>> > > These beans declarations do not make much sense. They are declared
>> twice,
>> > > once in the XML (spring-engine-storage-snapshot-core-context.xml),
>> and
>> > the
>> > > second declaration is executed through the use of annotations
>> > (@Component)
>> > > in those classes. This exception is happening because there is a
>> > > configuration in the XML saying that one bean is depending on the
>> other.
>> > > You can simply remove lines 30-40 from the XML file to fix this.
>> > >
>> > >
>> > >
>> > > Side note: Spring automatically build the chain of dependencies
>> between
>> > > beans to execute the dependency injection properly. The configuration
>> > > "depends-on" you find in the XML "bean" element is to define an exotic
>> > and
>> > > not obvious dependency.
>> > >
>> > >
>> > > On Mon, Nov 13, 2017 at 3:48 PM, Daan Hoogland <
>> daan.hoogl...@gmail.com>
>> > > wrote:
>> > >
>> > > > I'm looking at a problem, any one recognises this on master?
>> simulator
>> > > does
>> > > > not start cleanly.
>> > > >
>> > > > [WARNING] Failed startup of context o.e.j.m.p.JettyWebAppContext@
>> > > 51de5efa
>> > > > {/client,file:/Users/dahn/apache/cloudstack/client/
>> > > > target/classes/META-INF/webapp/,STARTING}{file:/Users/
>> > > > dahn/apache/cloudstack/client/target/classes/META-INF/webapp/}
>> > > > org.springframework.beans.factory.BeanCreationException: Error
>> > creating
>> > > > bean with name 'snapshotDataFactoryImpl' defined in URL
>> > > > [jar:file:/Users/dahn/.m2/repository/org/apache/
>> > cloudstack/cloud-engine-
>> > > > storage-snapshot/4.11.0.0-SNAPSHOT/cloud-engine-storage-
>> > > > snapshot-4.11.0.0-SNAPSHOT.jar!/META-INF/cloudstack/core/
>> > > > spring-engine-storage-snapshot-core-context.xml]:
>> > > > Circular depends-on relationship between 'snapshotDataFactoryImpl'
>> and
>> > > > 'volumeDataFactoryImpl'
>> > > > at
>> > > > org.springframework.beans.factory.support.
>> > AbstractBeanFactory.doGetBean
>> > > > (AbstractBeanFactory.java:300)
>> > > > at
>> > > > org.springframework.beans.factory.support.AbstractBeanFactor
>> y.getBean
>> > > > (AbstractBeanFactory.java:200)
>> > > > at
>> > > > org.springframework.beans.factory.support.
>> > AbstractBeanFactory.doGetBean
>> > > > (AbstractBeanFactory.java:304)
>> > > > at
>> > > > org.springframework.beans.factory.support.AbstractBeanFactor
>> y.getBean
>> > > > (AbstractBeanFactory.java:200)
>> > > > at
>> > > > org.springframework.beans.factory.support.DefaultListableBea
>> nFactory.
>> > > > preInstantiateSingletons
>> > > > (DefaultListableBeanFactory.java:756)
>> > > > at
>> > > > org.springframework.context.support.Abstrac

Re: jetty simulator problem

[Daan Hoogland]

from maven:
mvn -pl client jetty:run -Dsimulator

On Mon, Nov 13, 2017 at 8:16 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> The error changed! That is good... It is a misconfiguration with
> dependencies between modules.
> How are you running the simulator?
>
> On Mon, Nov 13, 2017 at 5:13 PM, Daan Hoogland <daan.hoogl...@gmail.com>
> wrote:
>
> > didn't work:( trying with only some parts removed now
> >
> > Caused by: org.springframework.beans.factory.
> > NoSuchBeanDefinitionException:
> > No qualifying bean of type
> > 'org.apache.cloudstack.engine.subsystem.api.storage.SnapshotService'
> > available: expected at least 1 bean which qualifies as autowire
> candidate.
> > Dependency annotations: {@javax.inject.Inject()}
> > at
> > org.springframework.beans.factory.support.DefaultListableBeanFactory.
> > raiseNoMatchingBeanFound
> > (DefaultListableBeanFactory.java:1501)
> >
> > On Mon, Nov 13, 2017 at 7:27 PM, Rafael Weingärtner <
> > rafaelweingart...@gmail.com> wrote:
> >
> > > These beans declarations do not make much sense. They are declared
> twice,
> > > once in the XML (spring-engine-storage-snapshot-core-context.xml), and
> > the
> > > second declaration is executed through the use of annotations
> > (@Component)
> > > in those classes. This exception is happening because there is a
> > > configuration in the XML saying that one bean is depending on the
> other.
> > > You can simply remove lines 30-40 from the XML file to fix this.
> > >
> > >
> > >
> > > Side note: Spring automatically build the chain of dependencies between
> > > beans to execute the dependency injection properly. The configuration
> > > "depends-on" you find in the XML "bean" element is to define an exotic
> > and
> > > not obvious dependency.
> > >
> > >
> > > On Mon, Nov 13, 2017 at 3:48 PM, Daan Hoogland <
> daan.hoogl...@gmail.com>
> > > wrote:
> > >
> > > > I'm looking at a problem, any one recognises this on master?
> simulator
> > > does
> > > > not start cleanly.
> > > >
> > > > [WARNING] Failed startup of context o.e.j.m.p.JettyWebAppContext@
> > > 51de5efa
> > > > {/client,file:/Users/dahn/apache/cloudstack/client/
> > > > target/classes/META-INF/webapp/,STARTING}{file:/Users/
> > > > dahn/apache/cloudstack/client/target/classes/META-INF/webapp/}
> > > > org.springframework.beans.factory.BeanCreationException: Error
> > creating
> > > > bean with name 'snapshotDataFactoryImpl' defined in URL
> > > > [jar:file:/Users/dahn/.m2/repository/org/apache/
> > cloudstack/cloud-engine-
> > > > storage-snapshot/4.11.0.0-SNAPSHOT/cloud-engine-storage-
> > > > snapshot-4.11.0.0-SNAPSHOT.jar!/META-INF/cloudstack/core/
> > > > spring-engine-storage-snapshot-core-context.xml]:
> > > > Circular depends-on relationship between 'snapshotDataFactoryImpl'
> and
> > > > 'volumeDataFactoryImpl'
> > > > at
> > > > org.springframework.beans.factory.support.
> > AbstractBeanFactory.doGetBean
> > > > (AbstractBeanFactory.java:300)
> > > > at
> > > > org.springframework.beans.factory.support.
> AbstractBeanFactory.getBean
> > > > (AbstractBeanFactory.java:200)
> > > > at
> > > > org.springframework.beans.factory.support.
> > AbstractBeanFactory.doGetBean
> > > > (AbstractBeanFactory.java:304)
> > > > at
> > > > org.springframework.beans.factory.support.
> AbstractBeanFactory.getBean
> > > > (AbstractBeanFactory.java:200)
> > > > at
> > > > org.springframework.beans.factory.support.
> DefaultListableBeanFactory.
> > > > preInstantiateSingletons
> > > > (DefaultListableBeanFactory.java:756)
> > > > at
> > > > org.springframework.context.support.AbstractApplicationContext.
> > > > finishBeanFactoryInitialization
> > > > (AbstractApplicationContext.java:868)
> > > > at
> > > > org.springframework.context.support.AbstractApplicationContext.
> refresh
> > > > (AbstractApplicationContext.java:549)
> > > > at
> > > > org.apache.cloudstack.spring.module.model.impl.
> > > DefaultModuleDefinitionSet.
> > > > loadContext
> > > > (DefaultModuleDefinitionSet.java:145)
> > > &

Re: jetty simulator problem

[Daan Hoogland]

didn't work:( trying with only some parts removed now

Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException:
No qualifying bean of type
'org.apache.cloudstack.engine.subsystem.api.storage.SnapshotService'
available: expected at least 1 bean which qualifies as autowire candidate.
Dependency annotations: {@javax.inject.Inject()}
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.raiseNoMatchingBeanFound
(DefaultListableBeanFactory.java:1501)

On Mon, Nov 13, 2017 at 7:27 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> These beans declarations do not make much sense. They are declared twice,
> once in the XML (spring-engine-storage-snapshot-core-context.xml), and the
> second declaration is executed through the use of annotations (@Component)
> in those classes. This exception is happening because there is a
> configuration in the XML saying that one bean is depending on the other.
> You can simply remove lines 30-40 from the XML file to fix this.
>
>
>
> Side note: Spring automatically build the chain of dependencies between
> beans to execute the dependency injection properly. The configuration
> "depends-on" you find in the XML "bean" element is to define an exotic and
> not obvious dependency.
>
>
> On Mon, Nov 13, 2017 at 3:48 PM, Daan Hoogland <daan.hoogl...@gmail.com>
> wrote:
>
> > I'm looking at a problem, any one recognises this on master? simulator
> does
> > not start cleanly.
> >
> > [WARNING] Failed startup of context o.e.j.m.p.JettyWebAppContext@
> 51de5efa
> > {/client,file:/Users/dahn/apache/cloudstack/client/
> > target/classes/META-INF/webapp/,STARTING}{file:/Users/
> > dahn/apache/cloudstack/client/target/classes/META-INF/webapp/}
> > org.springframework.beans.factory.BeanCreationException: Error creating
> > bean with name 'snapshotDataFactoryImpl' defined in URL
> > [jar:file:/Users/dahn/.m2/repository/org/apache/cloudstack/cloud-engine-
> > storage-snapshot/4.11.0.0-SNAPSHOT/cloud-engine-storage-
> > snapshot-4.11.0.0-SNAPSHOT.jar!/META-INF/cloudstack/core/
> > spring-engine-storage-snapshot-core-context.xml]:
> > Circular depends-on relationship between 'snapshotDataFactoryImpl' and
> > 'volumeDataFactoryImpl'
> > at
> > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean
> > (AbstractBeanFactory.java:300)
> > at
> > org.springframework.beans.factory.support.AbstractBeanFactory.getBean
> > (AbstractBeanFactory.java:200)
> > at
> > org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean
> > (AbstractBeanFactory.java:304)
> > at
> > org.springframework.beans.factory.support.AbstractBeanFactory.getBean
> > (AbstractBeanFactory.java:200)
> > at
> > org.springframework.beans.factory.support.DefaultListableBeanFactory.
> > preInstantiateSingletons
> > (DefaultListableBeanFactory.java:756)
> > at
> > org.springframework.context.support.AbstractApplicationContext.
> > finishBeanFactoryInitialization
> > (AbstractApplicationContext.java:868)
> > at
> > org.springframework.context.support.AbstractApplicationContext.refresh
> > (AbstractApplicationContext.java:549)
> > at
> > org.apache.cloudstack.spring.module.model.impl.
> DefaultModuleDefinitionSet.
> > loadContext
> > (DefaultModuleDefinitionSet.java:145)
> > at
> > org.apache.cloudstack.spring.module.model.impl.
> > DefaultModuleDefinitionSet$2.with
> > (DefaultModuleDefinitionSet.java:122)
> > at
> > org.apache.cloudstack.spring.module.model.impl.
> DefaultModuleDefinitionSet.
> > withModule
> > (DefaultModuleDefinitionSet.java:245)
> > at
> > org.apache.cloudstack.spring.module.model.impl.
> DefaultModuleDefinitionSet.
> > withModule
> > (DefaultModuleDefinitionSet.java:250)
> > at
> > org.apache.cloudstack.spring.module.model.impl.
> DefaultModuleDefinitionSet.
> > withModule
> > (DefaultModuleDefinitionSet.java:250)
> > at
> > org.apache.cloudstack.spring.module.model.impl.
> DefaultModuleDefinitionSet.
> > withModule
> > (DefaultModuleDefinitionSet.java:233)
> > at
> > org.apache.cloudstack.spring.module.model.impl.
> DefaultModuleDefinitionSet.
> > loadContexts
> > (DefaultModuleDefinitionSet.java:117)
> > at
> > org.apache.cloudstack.spring.module.model.impl.
> DefaultModuleDefinitionSet.
> > load
> > (DefaultModuleDefinitionSet.java:79)
> > at
> > org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactor

Re: POLL: ACL default egress policy rule in VPC

[Daan Hoogland]

3 of course ;)

On Mon, Nov 13, 2017 at 6:47 PM, Rene Moser  wrote:

> Hi Devs
>
> The last days I fought with the ACL egress rule behaviour and I would
> like to make a poll in which direction the fix should go.
>
> Short Version:
>
> We need to define a better default behaviour for acl default egress
> rule. I see 3 different options:
>
> 1. always add a default deny all egress rule.
>
> This would be super easy to do (should probably also the intermediate
> fix for 4.9, see https://github.com/apache/cloudstack/pull/2323)
>
>
> 2. add a deny all egress rule in case if have at least one egress allow
> rule.
>
> A bit intransparent to the user, but doable. This seems to be the
> behaviour how it was designed and should have been implemented.
>
>
> 3. use the default setting in the network offering "egressdefaultpolicy"
> to specify the default behavior.
>
> There is already a setting which specifies this behaviour but is not
> used in VPC. Why not use it?
>
> As a consequence when using this setting, the user should get more infos
> about the policy of the network offering while choosing it for the tier.
>
>
> Poll:
>
> 1. []
> 2. []
> 3. []
> 4. [] Other? What?
>
>
> Long Version:
>
> First, let's have a look of the issue:
>
> In version 4.5, creating a new acl with no egress (ACL_OUTBOUND) rule
> would result in a "accept egress all":
>
> -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
> NEW -j ACL_OUTBOUND_eth2
> -A ACL_OUTBOUND_eth2 -j ACCEPT
>
> When an egress (here deny 25 egress) rule (no mather if deny or allow)
> gets added the result is a "deny all" appended:
>
> -A PREROUTING -s 10.10.0.0/24 ! -d 10.10.0.1/32 -i eth2 -m state --state
> NEW -j ACL_OUTBOUND_eth2
> -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 25 -j DROP
> -A ACL_OUTBOUND_eth2 -j DROP
>
> This does not make any sense and is a bug IMHO.
>
>
> In 4.9 the behaviour is different:
>
> (note there is a bug in the ordering of egress rules which is fixed by
> https://github.com/apache/cloudstack/pull/2313)
>
> The default policy is kept accept egress all.
>
> -A PREROUTING -s 10.11.1.0/24 ! -d 10.11.1.1/32 -i eth2 -m state --state
> NEW -j ACL_OUTBOUND_eth2
> -A ACL_OUTBOUND_eth2 -d 224.0.0.18/32 -j ACCEPT
> -A ACL_OUTBOUND_eth2 -d 225.0.0.50/32 -j ACCEPT
> -A ACL_OUTBOUND_eth2 -p tcp -m tcp --dport 80 -j ACCEPT
>
>
> To me it looks like the wanted behavior was "egress all as default. If
> we have allow rules, append deny all". This would make sense but is
> quite instransparent.
>
> But let's poll
>
>
>


-- 
Daan

jetty simulator problem

[Daan Hoogland]

I'm looking at a problem, any one recognises this on master? simulator does
not start cleanly.

[WARNING] Failed startup of context o.e.j.m.p.JettyWebAppContext@51de5efa
{/client,file:/Users/dahn/apache/cloudstack/client/target/classes/META-INF/webapp/,STARTING}{file:/Users/dahn/apache/cloudstack/client/target/classes/META-INF/webapp/}
org.springframework.beans.factory.BeanCreationException: Error creating
bean with name 'snapshotDataFactoryImpl' defined in URL
[jar:file:/Users/dahn/.m2/repository/org/apache/cloudstack/cloud-engine-storage-snapshot/4.11.0.0-SNAPSHOT/cloud-engine-storage-snapshot-4.11.0.0-SNAPSHOT.jar!/META-INF/cloudstack/core/spring-engine-storage-snapshot-core-context.xml]:
Circular depends-on relationship between 'snapshotDataFactoryImpl' and
'volumeDataFactoryImpl'
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean
(AbstractBeanFactory.java:300)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean
(AbstractBeanFactory.java:200)
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean
(AbstractBeanFactory.java:304)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean
(AbstractBeanFactory.java:200)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons
(DefaultListableBeanFactory.java:756)
at
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization
(AbstractApplicationContext.java:868)
at
org.springframework.context.support.AbstractApplicationContext.refresh
(AbstractApplicationContext.java:549)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContext
(DefaultModuleDefinitionSet.java:145)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet$2.with
(DefaultModuleDefinitionSet.java:122)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule
(DefaultModuleDefinitionSet.java:245)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule
(DefaultModuleDefinitionSet.java:250)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule
(DefaultModuleDefinitionSet.java:250)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.withModule
(DefaultModuleDefinitionSet.java:233)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.loadContexts
(DefaultModuleDefinitionSet.java:117)
at
org.apache.cloudstack.spring.module.model.impl.DefaultModuleDefinitionSet.load
(DefaultModuleDefinitionSet.java:79)
at
org.apache.cloudstack.spring.module.factory.ModuleBasedContextFactory.loadModules
(ModuleBasedContextFactory.java:37)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.init
(CloudStackSpringContext.java:71)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.
(CloudStackSpringContext.java:58)
at
org.apache.cloudstack.spring.module.factory.CloudStackSpringContext.
(CloudStackSpringContext.java:62)
at
org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener.contextInitialized
(CloudStackContextLoaderListener.java:52)
at
org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized
(ContextHandler.java:800)
at
org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized
(ServletContextHandler.java:444)
at org.eclipse.jetty.server.handler.ContextHandler.startContext
(ContextHandler.java:791)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext
(ServletContextHandler.java:294)
at org.eclipse.jetty.webapp.WebAppContext.startWebapp
(WebAppContext.java:1349)
at org.eclipse.jetty.maven.plugin.JettyWebAppContext.startWebapp
(JettyWebAppContext.java:297)
at org.eclipse.jetty.webapp.WebAppContext.startContext
(WebAppContext.java:1342)
at org.eclipse.jetty.server.handler.ContextHandler.doStart
(ContextHandler.java:741)
at org.eclipse.jetty.webapp.WebAppContext.doStart
(WebAppContext.java:505)
at org.eclipse.jetty.maven.plugin.JettyWebAppContext.doStart
(JettyWebAppContext.java:366)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start
(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start
(ContainerLifeCycle.java:132)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart
(ContainerLifeCycle.java:114)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart
(AbstractHandler.java:61)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart
(ContextHandlerCollection.java:163)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start
(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start
(ContainerLifeCycle.java:132)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart
(ContainerLifeCycle.java:114)
at 

Re: Adoption Survey seems to be abandoned

[Daan Hoogland]

Hey Ivan, I am not very familiar to that survey. Is it mail based and where
did you sent it? If not can you do me a link? I don't think it is intended
to be ignored.

On Mon, Oct 30, 2017 at 4:51 AM, Ivan Kudryavtsev 
wrote:

> Hi, DevTeam.
>
> May be dev@ is wrong list, sorry in advance.
>
> It seems that adopters list is abandoned. I mean that I filled it about 3+
> month ago and don't see our org in list of adopters (might be it was just
> ignored, but worth to mention anyway). I don't know either it's intended or
> not, just wanted to note that.
>
> Have a great day.
>



-- 
Daan

Re: Upgrade Cloudstack 4.5 to 4.9 - Unable to upgrade the database

[Daan Hoogland]

sorry Cristian, I wasn't clear. Can you add a jira ticket at
issues.apache.org/jira?

@devs I have heard this before but am not sure if it was exactly the same.
Anybody else? Was this fixed in 4.10 or master yet?
tl;dr setting password doesn't work for Cristian due to the firewall on the
VR.

On Fri, Oct 13, 2017 at 1:44 PM, Ciobanu Cristian <cristian.c@istream.today>
wrote:

> Daan,
>
> Can I track this issue somewhere?
>
>
> Thank you!
> Cristian
>
> -----Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Thursday, October 12, 2017 9:46 AM
> To: us...@cloudstack.apache.org
> Subject: Re: Upgrade Cloudstack 4.5 to 4.9 - Unable to upgrade the database
>
> Cristian,
>
> I am cross-posting this to dev@coudstack.a.o, sorry for the noise. I have
> heard this before but am not sure if it was exactly the same. It sounds
> like a bug to me. Can you enter one in jira?
> Anybody else? Was this fixed in 4.10 or master yet?
>
> On Wed, Oct 11, 2017 at 11:23 PM, Ciobanu Cristian
> <cristian.c@istream.today
> > wrote:
>
> > Hello,
> >
> >  After I continued the investigation I found that router is not
> > allowing the VM to fetch the password (port 8080) not sure what is
> > wrong with this version but in order to fix I have added this rule "-A
> > INPUT -p tcp -m tcp --dport 8080 -j ACCEPT"  on virtual router..
> >
> >   Any idea how to fix this, permanent?  In case reinstall the router
> > for sure I will have to do this again.
> >
> >
> > Thank you.
> > Cristian
> >
> > -Original Message-
> > From: Ciobanu Cristian [mailto:cristian.c@istream.today]
> > Sent: Wednesday, October 11, 2017 9:45 PM
> > To: 'us...@cloudstack.apache.org' <us...@cloudstack.apache.org>
> > Subject: RE: Upgrade Cloudstack 4.5 to 4.9 - Unable to upgrade the
> > database
> >
> > I was able to update the virtual router only after I have restarted
> > the iptables-persistend form virtual router side, not sure what is
> > wrong with this router version but I don't get the right status if I
> > don't restart the iptables from virtual router, I have did multiple
> tests :
> >
> > Example :
> >  -  Reboot router
> > - getting this error : job-3247/job-3248, cmd: CheckSshCommand)
> > (logid:6b3de9fa) Trying to
> > > connect to 149.56.xxx.xx  ( I see this error in management log )
> > - restart iptables from router side
> > - works
> >
> >   In case I destroy/restart the router I have to repeat the same
> > thing, restart iptables...
> >
> >   I also tested a new deploy with a template used before on this
> > setup, looks like the password set for new deploy is not working...
> >
> >
> > Any idea why I have those issue?
> >
> > Upgraded from 4.5.2 to 4.9.3 ( shapeblue packages )
> >
> >
> > Regards,
> > Cristian
> >
> >
> > -Original Message-
> > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> > Sent: Wednesday, October 11, 2017 6:10 PM
> > To: us...@cloudstack.apache.org
> > Subject: Re: Upgrade Cloudstack 4.5 to 4.9 - Unable to upgrade the
> > database
> >
> > that is a tricky one. You can destroy the vm from VmWare and set the
> > state to stopped in the DB. It should then start a new one.
> > check if r-4-VM/ROOT-4-01.vmdk has gone from the datastore.
> >
> > the cause is probably some synchronisation issue. We've seen and
> > solved it before but are yet to find the root cause.
> >
> >
> > On Wed, Oct 11, 2017 at 4:23 PM, Ciobanu Cristian
> > <cristian.c@istream.today
> > >
> > wrote:
> >
> > > Hello,
> > >
> > >Was my mistake, forgot to add the system template from cloudstack
> > > interface before starting the upgrade, now I have other issue, looks
> > > like after I have enabled one of the zone and click on upgrade
> > > virtual router I still see the state "starting" if I check the
> > > router from vSphere side is up.
> > >
> > >
> > >   This is what is see :
> > >
> > > tting
> > > catalina.out:INFO  [c.c.h.v.r.VmwareResource]
> > > (DirectAgent-381:ctx-5f16ff50 ns53.ip-149-56-xx.net,
> > > job-3247/job-3248, cmd: StartCommand) (logid:6b3de9fa) Chose disk
> > > controller for vol ROOT -> osdefault, based on root disk controller
> > > settings at global configuration setting.
> > > catalina.out:INFO  [c.c.h.v.m.DatastoreMO]
> > > (DirectAgent-381:ctx-5f16ff50 ns53

Re: Can't create Basic Zone with master

[Daan Hoogland]

Mike, i created https://github.com/apache/cloudstack/pull/2296 after
investigation. haven't tested it yet.

On Fri, Oct 13, 2017 at 9:29 AM, Daan Hoogland <daan.hoogl...@gmail.com>
wrote:

> Mike, absolutely right and I would usually just say "okay revert" but in
> this case I want to look to fix forward. This commit is an attempt to make
> network types more pluggable. So let me see if I can find a solution. I had
> trusted on the smoke tests to pick this up.
>
> On Thu, Oct 12, 2017 at 10:50 PM, Tutkowski, Mike <
> mike.tutkow...@netapp.com> wrote:
>
>> It looks like this commit broke support for Basic Zones:
>>
>> a06530d (Daan: Can you look into this?)
>>
>> 4.10
>>
>> @Override
>> protected boolean canHandle(NetworkOffering offering, DataCenter dc) {
>> // this guru handles system Direct pod based network
>> if (dc.getNetworkType() == NetworkType.Basic &&
>> isMyTrafficType(offering.getTrafficType())) {
>> return true;
>> } else {
>> s_logger.trace("We only take care of Guest Direct Pod based
>> networks");
>> return false;
>> }
>> }
>>
>> master
>>
>> @Override
>> protected boolean canHandle(NetworkOffering offering, DataCenter dc,
>> PhysicalNetwork physnet) {
>> // this guru handles system Direct pod based network
>> if (dc.getNetworkType() == NetworkType.Basic &&
>> isMyTrafficType(offering.getTrafficType()) &&
>> isMyIsolationMethod(physnet)) {
>> return true;
>> } else {
>> s_logger.trace("We only take care of Guest Direct Pod based
>> networks");
>> return false;
>> }
>> }
>>
>> isMyIsolationMethod(physnet) fails (new to master):
>>
>> protected boolean isMyIsolationMethod(PhysicalNetwork
>> physicalNetwork) {
>> for (IsolationMethod m : _isolationMethods) {
>> if (physicalNetwork.getIsolationM
>> ethods().contains(m.toString())) {
>> return true;
>> }
>> }
>> return false;
>> }
>>
>> _isolationMethods = new IsolationMethod[] { new IsolationMethod("VLAN") };
>>
>> _isolationMethods is only of size = 1 and m.toString() returns “VLAN”
>> whereas physicalNetwork.getIsolationMethods() is of size = 0. This
>> method returns false and none of the network gurus can support the creation
>> of a Basic Zone.
>>
>> On 10/12/17, 7:03 AM, "Tutkowski, Mike" <mike.tutkow...@netapp.com>
>> wrote:
>>
>> Yes, I can debug it more. I’m in the middle of some other task at the
>> moment, so I might not be able to get to it until later this evening. In
>> the meanwhile, I figured I’d send out the previous e-mail in case it might
>> sound like something one of our networking devs recognize. :) Thanks!
>>
>> On Oct 12, 2017, at 12:18 AM, Rohit Yadav <rohit.ya...@shapeblue.com
>> <mailto:rohit.ya...@shapeblue.com>> wrote:
>>
>> Hi Mike,
>>
>>
>> I think you can repeat the process with 4.10 and compare with master
>> as to which NetworkGuru is supposed to design and return you a network,
>> then you can do some git log tracing to find what was changed and why the
>> respective network guru is not returning a network. It could be
>> environment/config issue or change/regression in code.
>>
>>
>> For local/nfs storage, and all three hypervisor no major regression
>> was seen in last trillian smoke test runs.
>>
>>
>> - Rohit
>>
>> 
>> From: Tutkowski, Mike <mike.tutkow...@netapp.com> mike.tutkow...@netapp.com>>
>> Sent: Thursday, October 12, 2017 1:17:50 AM
>> To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>
>> Subject: Re: Can't create Basic Zone with master
>>
>> Hi Rohit,
>>
>> I walked through the debugger with this and now have more info:
>>
>> The following network gurus are leveraged to create networks
>> successfully:
>>
>> PublicNetworkGuru
>> PodBasedNetworkGuru
>> ControlNetworkGuru
>> StorageNetworkGuru
>>
>> Once the zone-creation wizard reaches the “Enabling Security Group
>> provider” part, NetworkOrchestrator.setupNetwork is again invoked and
>> this time throws an exception.
>>
>> It walks through all of its network gurus and none of them returns a
>> pointe

Re: Can't create Basic Zone with master

[Daan Hoogland]

Mike, absolutely right and I would usually just say "okay revert" but in
this case I want to look to fix forward. This commit is an attempt to make
network types more pluggable. So let me see if I can find a solution. I had
trusted on the smoke tests to pick this up.

On Thu, Oct 12, 2017 at 10:50 PM, Tutkowski, Mike  wrote:

> It looks like this commit broke support for Basic Zones:
>
> a06530d (Daan: Can you look into this?)
>
> 4.10
>
> @Override
> protected boolean canHandle(NetworkOffering offering, DataCenter dc) {
> // this guru handles system Direct pod based network
> if (dc.getNetworkType() == NetworkType.Basic &&
> isMyTrafficType(offering.getTrafficType())) {
> return true;
> } else {
> s_logger.trace("We only take care of Guest Direct Pod based
> networks");
> return false;
> }
> }
>
> master
>
> @Override
> protected boolean canHandle(NetworkOffering offering, DataCenter dc,
> PhysicalNetwork physnet) {
> // this guru handles system Direct pod based network
> if (dc.getNetworkType() == NetworkType.Basic &&
> isMyTrafficType(offering.getTrafficType()) &&
> isMyIsolationMethod(physnet)) {
> return true;
> } else {
> s_logger.trace("We only take care of Guest Direct Pod based
> networks");
> return false;
> }
> }
>
> isMyIsolationMethod(physnet) fails (new to master):
>
> protected boolean isMyIsolationMethod(PhysicalNetwork
> physicalNetwork) {
> for (IsolationMethod m : _isolationMethods) {
> if (physicalNetwork.getIsolationMethods().contains(m.toString()))
> {
> return true;
> }
> }
> return false;
> }
>
> _isolationMethods = new IsolationMethod[] { new IsolationMethod("VLAN") };
>
> _isolationMethods is only of size = 1 and m.toString() returns “VLAN”
> whereas physicalNetwork.getIsolationMethods() is of size = 0. This method
> returns false and none of the network gurus can support the creation of a
> Basic Zone.
>
> On 10/12/17, 7:03 AM, "Tutkowski, Mike"  wrote:
>
> Yes, I can debug it more. I’m in the middle of some other task at the
> moment, so I might not be able to get to it until later this evening. In
> the meanwhile, I figured I’d send out the previous e-mail in case it might
> sound like something one of our networking devs recognize. :) Thanks!
>
> On Oct 12, 2017, at 12:18 AM, Rohit Yadav  mailto:rohit.ya...@shapeblue.com>> wrote:
>
> Hi Mike,
>
>
> I think you can repeat the process with 4.10 and compare with master
> as to which NetworkGuru is supposed to design and return you a network,
> then you can do some git log tracing to find what was changed and why the
> respective network guru is not returning a network. It could be
> environment/config issue or change/regression in code.
>
>
> For local/nfs storage, and all three hypervisor no major regression
> was seen in last trillian smoke test runs.
>
>
> - Rohit
>
> 
> From: Tutkowski, Mike >
> Sent: Thursday, October 12, 2017 1:17:50 AM
> To: dev@cloudstack.apache.org
> Subject: Re: Can't create Basic Zone with master
>
> Hi Rohit,
>
> I walked through the debugger with this and now have more info:
>
> The following network gurus are leveraged to create networks
> successfully:
>
> PublicNetworkGuru
> PodBasedNetworkGuru
> ControlNetworkGuru
> StorageNetworkGuru
>
> Once the zone-creation wizard reaches the “Enabling Security Group
> provider” part, NetworkOrchestrator.setupNetwork is again invoked and
> this time throws an exception.
>
> It walks through all of its network gurus and none of them returns a
> pointer to a Network object.
>
>for (final NetworkGuru guru : networkGurus) {
>final Network network = guru.design(offering, plan,
> predefined, owner);
>if (network == null) {
>continue;
>}
>
> Since no Network object was returned, the list of Network objects is
> empty and an exception is thrown.
>
> Thanks,
> Mike
>
> On 10/11/17, 1:44 AM, "Rohit Yadav" > wrote:
>
>Mike,
>
>
>Can you re-deploy a fresh environment and see what's failing,
> stepping through the workflow. The specific line it's throwing exception is
> caused when there are no network (network size is 0) setup:
>
>
>https://github.com/apache/cloudstack/blob/master/engine/
> orchestration/src/org/apache/cloudstack/engine/orchestration/
> NetworkOrchestrator.java#L715
>
>
>- Rohit
>
>
>From: Tutkowski, Mike >
>Sent: 

Re: release manager 4.11?

[Daan Hoogland]

Imran,

first please read [1] and [2]. There are bound to be ommisions in it. You
can come back with questions anytime.

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
[2]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Management



On Tue, Oct 10, 2017 at 9:43 AM, Imran Ahmed <im...@eaxiom.net> wrote:

> Hi Daan,
> I would be happy for contributing my part. Please guide me about the
> procedures.
> Regards,
>
> Imran
>
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Tuesday, October 10, 2017 12:10 PM
> To: dev; us...@cloudstack.apache.org
> Subject: release manager 4.11?
>
> users and devs,
>
> Sorry for the cross post.
>
> Is there any devops guru that wishes to take on the 4.11 release, with
> assistence of course?
>
> --
> Daan
>
>


-- 
Daan

release manager 4.11?

[Daan Hoogland]

users and devs,

Sorry for the cross post.

Is there any devops guru that wishes to take on the 4.11 release, with
assistence of course?

-- 
Daan

Re: [ANNOUNCE] Syed Mushtaq Ahmed has joined the PMC

[Daan Hoogland]

Good going and clear trail Syed

On Mon, Oct 9, 2017 at 2:06 PM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Congratulation Syed, and thanks for the hard work you have put into ACS so
> far.
>
> On Mon, Oct 9, 2017 at 8:59 AM, Rohit Yadav 
> wrote:
>
> > Congratulations Syed!
> >
> >
> > - Rohit
> >
> > 
> > From: Paul Angus 
> > Sent: Monday, October 9, 2017 4:56:51 PM
> > To: dev@cloudstack.apache.org; us...@cloudstack.apache.org
> > Subject: [ANNOUNCE] Syed Mushtaq Ahmed has joined the PMC
> >
> > Fellow CloudStackers,
> >
> > It gives me great pleasure to say that Syed has be invited to join the
> PMC
> > and has gracefully accepted.
> > Please joining me in congratulating Syed!
> >
> >
> > Kind regards,
> >
> > Paul Angus
> >
> >
> > paul.an...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
> > rohit.ya...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> >
>
>
> --
> Rafael Weingärtner
>



-- 
Daan

Re: Checkstyle / code style / reformatting

[Daan Hoogland]

I am a fan of convention and think everyone should have some. Strict
enforcing of non-functionals, I'm not to big on. I see what you want to
achieve here but am reluctant not to -1 any strictness. If we do it with a
post-commit-hook (or if such a thing exists a post-merge-hook) we will
allow for code to be altered after being approved, won't we?

On Fri, Sep 29, 2017 at 9:44 AM, Marc-Aurèle Brothier 
wrote:

> Hi everyone,
>
> Would you think it's worth tightening the checkstyle rules and run a
> reformatting pass on the code base to align everything slowly? I know it
> will hide changes using the blame functionality, and would force people to
> edit some PR. Is the trade-off worth it for you?
>
> The idea would be to add one by one those extra checkstyle rules, and do
> the code change/reformat accordingly each time with one rule in one PR. A
> new rule should first be accepted by the community before starting on the
> PR to do the changes (otherwise it might be a lot of wasted time). When
> merged, a new rule can be added.
>
> The code style that bothers me most right now for example is blocks without
> braces, so my first proposal would be:
>
> 
> 
> 
>
> I have a lot more to add, but as said, one at a time ;-)
>
> The list of rules: http://checkstyle.sourceforge.net/checks.html
> The current rules:
> https://github.com/apache/cloudstack/blob/master/tools/
> checkstyle/src/main/resources/cloud-style.xml
>
> What do you think?
>
> Marc-Aurèle
>



-- 
Daan

Re: Clean up of unused constants

[Daan Hoogland]

+1 Sigert, be my guest. We will run integration tests on your changes anyway, 
so low risk ;)

On 2017/09/26 15:55, "Rafael Weingärtner"  wrote:

IMO, if something is not used or if something does not work, it has to 
be removed or fixed.

I am +1 for the removal of unused constants. Did you check if the value 
of these unused constants were being used somewhere? I mean, using the 
value without referencing the constant.


On 9/26/2017 9:55 AM, Sigert GOEMINNE wrote:
> Hi all,
>
> Am I allowed to remove all unused constants in ApiConstants.java?
>
> Kind regards,
>
> *Sigert Goeminne*
> Software Development Engineer
>

-- 
Rafael Weingärtner




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

log4j(2)

[Daan Hoogland]

People,

I am trying to up log4j to log4j2: 
https://issues.apache.org/jira/browse/CLOUDSTACK-10089
A discussion earlier led to the question if we should use sl4j, but my answer 
is no, because ACS uses to advanced features at some places and log4j-2 leaves 
you the choice to install a proxy for sl4j.
I wouldn’t mind continuing the discussion in the ticket, so please leave 
comments there.

Regards,

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

Re: New committers: Nathan Johnson and Marc-Aurèle Brothier

[Daan Hoogland]

congrats guys, go get'm

On Fri, Sep 22, 2017 at 8:18 PM, Milamber  wrote:

>
> Congrats Nathan & Marc-Aurèle!
>
> On 22/09/2017 17:31, Rafael Weingärtner wrote:
>
>> The Project Management Committee (PMC) for Apache CloudStack has invited
>> Nathan Johnson and Marc-Aurèle Brothier to become committers and we are
>> pleased to announce that they have accepted.
>>
>> They have shown commitment to Apache CloudStack community, contributing
>> with PRs in a constant fashion. Moreover, they have proved great abilities
>> to interact with the community quite often in our mailing lists and Slack
>> channel trying to help people.
>>
>> Let´s congratulate and welcome Apache CloudStack’s two newest committers.
>>
>> --
>> Rafael Weingärtner
>>
>>
>


-- 
Daan

Re: one question network survey

[Daan Hoogland]

H Imran,
I am not sure I can get from your reply whether you configured anything for 
those vxlans inside cloudstack. It sounds like your just trunking upstream.
If I am wrong (not uncommon), you are probably talking about the guestnetwork 
as it ties your hosts together, right?

My question is mainly to what did you configure in cloudstack to use vxlans in 
your cloud.

Thanks,

On 2017/08/28 11:29, "Imran Ahmed" <im...@eaxiom.net> wrote:

Hi Daan,

I use a separate trunk  (OVS or non OVS bonded with LACP ) connected to 
multiple switches (which are already configured into a switch stack). There can 
be multiple case scenarios but I am mentioning the most generic one .

Hope that answers your question if I have correctly understood your 
question.


Regards,



-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@shapeblue.com] 
Sent: Monday, August 28, 2017 12:20 PM
To: dev@cloudstack.apache.org; us...@cloudstack.apache.org
Subject: one question network survey

Devs and users,

Can you all please tell me how you are using VxLan in your cloudstack 
environments?

The reason behind this is that I am planning some refactoring in the 
networkgurus and I don’t want to break any running installations on upgrade. If 
you are not using vxlan but know of people that might not react, using it, 
please point me to them.

Thanks,

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
  
 

one question network survey

[Daan Hoogland]

Devs and users,

Can you all please tell me how you are using VxLan in your cloudstack 
environments?

The reason behind this is that I am planning some refactoring in the 
networkgurus and I don’t want to break any running installations on upgrade. If 
you are not using vxlan but know of people that might not react, using it, 
please point me to them.

Thanks,

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

user_ip question

[Daan Hoogland]

devs,

there is a field is_system in the user_ip_address. I see no instance
of it that is not 0 in my envs. I am looking to implement some ip
reservation for systemVMs. it seems this field is applicable or even
intended for this purpose.

Anyone that has some advice on this?

tnx
-- 
Daan

Re: [README][Quarterly Call] - CloudStack Development, Blockers and Community Efforts

[Daan Hoogland]

Looking forward to this but I will only be available the first half hour for 
this.

On 19/07/2017, 20:58, "ilya"  wrote:

Hi Devs and Users

Hope this message finds you well,

As mentioned earlier, we would like to start with quarterly calls to
discuss the direction of cloudstack project.

I propose to split the 90 minute call into 3 topics:

1) Development efforts - 60 minutes
Upcoming Features you are working on developing (to avoid
collision andmaintain the roadmap).
  Depending on number of topics we need to discuss - time for
each topic will be set accordingly.
  If you would like to particiapate - please respond to this
thread and adhere to sample format below:  











   

2) Release Blockers - 20 minutes
  If you would like to participate - please respond to this
thread and adhere to sample format below:  






3) Community Efforts - 10+ minutes





The proposed date and time  - Thursday August 17th 9AM PT.

Minutes will be taken and posted on dev list. Due to number of things we
need to discuss - we have to keep the call very structured, each topic -
timed and very high level.
If there are issues and or suggestions, we will note it down in few
sentences, identify interested parties and have them do a "post"
discussion on the mailing list.

Looking forward to your comments,

Regards,
ilya




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

Re: 4.10.0.0 release announcement draft

[Daan Hoogland]

How about using one of the older announcements as draft, Rajani? That is how I 
did it in the past.

On 19/07/2017, 08:11, "Rajani Karuturi"  wrote:

api changes and fixed issues are available at
https://github.com/apache/cloudstack-docs-rn/pull/30

Pierre-Luc is helping on upgrade docs.

Can someone help on release announcement draft please?

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/


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

Re: @ACL annotation

[Daan Hoogland]

yes, see ParamProcessWorker for the handling

On Tue, Jul 18, 2017 at 12:48 PM, Pavan Kumar Aravapalli
 wrote:
> Hi,
>
>  I found some of the api parameters annotated with @ACL in source code.  
> Is this feature enabled ? In ACS , if so provide me some information on how 
> it implemented and works.
>
>
> ~Regards
>   Pavan
>
> 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.



-- 
Daan

Re: Cloudstack dev Noob start :-)

[Daan Hoogland]

Sorry Oliver, I don't think we use such a tag. Good suggestion though. For now, 
look at findbugs and such tools for things you could re-factor.

On 12/07/17 13:42, "Olivier Lamy" <ol...@apache.org> wrote:

Hi
Yes I dropped all databases.
But I was trying to create manually by myself all the databases and initial
schemas manually..
Well finally reading the thread "Developer Guide - Current Setup Guide"
helped me and I found what I missed to do :-) (sorry for the noise)

As a starter I'd like to know if you have any issue flagged as
"starter/noob" level? (just some easy issue I could have a look to discover
the code)
Thanks!

Cheers
Olivier


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

On 11 July 2017 at 00:56, Daan Hoogland <daan.hoogl...@gmail.com> wrote:

> Oliver, I am pretty sure you where having a mysql version error at
> first. This one is new to me. Did you fully remove mysql and the cloud
> database and then install mariadb? Maybe you can drop all tables and
> run the mvn command for installing a db instead of the create db
> script. just for checking
>
> On Mon, Jul 10, 2017 at 9:39 AM, Olivier Lamy <ol...@apache.org> wrote:
> > Hi
> > Looks more to be a permission issue
> > Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException:
> ALTER
> > command denied to user 'cloud'@'localhost' for table 'account'
> >
> > When running create-database script I get this warning.
> >
> > sql> GRANT ALL ON cloud.* to cloud@`%` identified by 'cloud'
> > [2017-07-07 09:47:56] [HY000][1287] Using GRANT statement to modify
> > existing user's properties other than privileges is deprecated and will
> be
> > removed in future release. Use ALTER USER statement for this operation.
> >
> > Anyway I changed to MariaBD and made some progress :-)  but still an
> error.
> >
> > My steps:
> >
> > * running the following scripts to create databases: 
create-database.sql,
> > create-database-premium.sql, create-database-simulator.sql.
> >
> > * running the following scripts to create base schemas:
> create-schema.sql,
> > create-schema-premium.sql, create-schema-simulator.sql
> >
> > * start the ui with mvn -pl :cloud-client-ui jetty:run
> >
> > But now it fail with (stack trace truncated but full available here:
> > https://gist.github.com/olamy/b13e5f831b933829dd2ced7ddb5dc59b
> >
> > INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) (logid:) Cleanup 
upgrade
> > Upgrade441to442 to upgrade from 4.4.1-4.4.2 to 4.4.2
> >
> > ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:) Error executing: ALTER
> > TABLE `cloud`.`guest_os_hypervisor` ADD FOREIGN KEY (`guest_os_id`)
> > REFERENCES `cloud`.`guest_os`(`id`)
> >
> > ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:)
> > com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViol
> ationException:
> > Cannot add or update a child row: a foreign key constraint fails
> > (`cloud`.`#sql-882f_27`, CONSTRAINT `#sql-882f_27_ibfk_1` FOREIGN KEY
> > (`guest_os_id`) REFERENCES `guest_os` (`id`))
> >
> > ERROR [c.c.u.DatabaseUpgradeChecker] (main:null) (logid:) Unable to
> execute
> > upgrade script:
> > /Users/olamy/dev/sources/open-sources/cloudstack/cloudstack/
> client/target/utilities/scripts/db/db/schema-442to450.sql
> >
> > com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViol
> ationException:
> > Cannot add or update a child row: a foreign key constraint fails
> > (`cloud`.`#sql-882f_27`, CONSTRAINT `#sql-882f_27_ibfk_1` FOREIGN KEY
> > (`guest_os_id`) REFERENCES `guest_os` (`id`))
> >
> > ERROR [c.c.u.DatabaseUpgradeChecker] (main:null) (logid:) Unable to
> upgrade
> > the database
> >
> > com.cloud.utils.exception.CloudRuntimeException: Unable to execute
> upgrade
> > script:
> > /Users/olamy/dev/sources/open-sources/cloudstack/cloudstack/
> client/target/utilities/scripts/db/db/schema-442to450.sql
> >
> > Not sure what to do here :-(
> >
> > On 6 July 2017 at 19:22, Wido den Hollander <w...@widodh.nl> wrote:
> >
> >>
> >> > Op 6 juli 2017 om 9:02 schreef Olivier Lamy <ol...@apache.org>:
> >

Re: Usage Server in Docker Simulator

[Daan Hoogland]

John,



too bad but that indeed means it isn’t running. You can double check with



# service cloudstack-usage status

cloudstack-usage is stopped



and if need be



# service cloudstack-usage start

Starting CloudStack Usage Monitor cloudstack-usage [  OK  ]



I am not running the container usually so I am not sure if it uses systemctl 
for controlling services instead. Just running it in hindsight should™n’t hurt 
your use case.



On 12/07/17 00:24, "John McDonnell"  wrote:



Hi,



I asked this back in April on the Users mailing list and the response

I got was that the usage server should be on by default in the docker

container.  I got sidetracked by other things and am coming back to

this issue.



Is it meant to be running by default? or is there something needed to

do to turn it on in the container?  (wasn't sure if this is a defect,

so thought I'd ask here.)





I use the container as a development tool(to avoid using a real life

system) to test the API out and usage collection is a major part of

what I use the API for.





Steps to reproduce:



(Have docker installed)

$ docker pull cloudstack/simulator

$ docker run --name cloudstack -d -p 8080:8080 cloudstack/simulator

$ docker exec -ti cloudstack python \

/root/tools/marvin/marvin/deployDataCenter.py -i 
/root/setup/dev/advanced.cfg



After a while login to the UI: localhost:8080/client (admin:password)



And usually, after a while, there will be a General Alert saying there

is no Usage Server running.  Even before this message, if I add an

instance, and attempt to collection usage with the API, I don't get

anything back.



Any help?



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

Re: Usage Server in Docker Simulator

[Daan Hoogland]

Ok, then it isn’t installed but that it can. 
# yum install cloudstack-usageit makes sense to look at the docker definition 
and do it there

On 12/07/17 09:07, "John McDonnell"  wrote:

Hi,

Any idea how to start it when running in the Docker simulator?

Obviously the service talked about here[1] isn’t available in the 
container, so I can’t just 'service cloudstack-usage restart’.


[1]: 
https://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.8/usage.html#configuring-the-usage-server
 



John


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

> On 12 Jul 2017, at 06:33, Erik Weber  wrote:
> 
> Are you running the usage server?
> 
> It is a different service and run independently of the mgmt server
> 
> -- 
> Erik
> 
> ons. 12. jul. 2017 kl. 00.25 skrev John McDonnell 
> :
> 
>> Hi,
>> 
>> I asked this back in April on the Users mailing list and the response
>> I got was that the usage server should be on by default in the docker
>> container.  I got sidetracked by other things and am coming back to
>> this issue.
>> 
>> Is it meant to be running by default? or is there something needed to
>> do to turn it on in the container?  (wasn't sure if this is a defect,
>> so thought I'd ask here.)
>> 
>> 
>> I use the container as a development tool(to avoid using a real life
>> system) to test the API out and usage collection is a major part of
>> what I use the API for.
>> 
>> 
>> Steps to reproduce:
>> 
>> (Have docker installed)
>> $ docker pull cloudstack/simulator
>> $ docker run --name cloudstack -d -p 8080:8080 cloudstack/simulator
>> $ docker exec -ti cloudstack python \
>> /root/tools/marvin/marvin/deployDataCenter.py -i
>> /root/setup/dev/advanced.cfg
>> 
>> After a while login to the UI: localhost:8080/client (admin:password)
>> 
>> And usually, after a while, there will be a General Alert saying there
>> is no Usage Server running.  Even before this message, if I add an
>> instance, and attempt to collection usage with the API, I don't get
>> anything back.
>> 
>> Any help?
>> 

Re: Usage Server in Docker Simulator

[Daan Hoogland]

maybe a double post due to mail issues:

Ok, then it isn’t installed but that it can.
# yum install cloudstack-usage
assuming centos as base. It makes sense to look at the docker
definition and do it there

On Wed, Jul 12, 2017 at 9:07 AM, John McDonnell
 wrote:
> Hi,
>
> Any idea how to start it when running in the Docker simulator?
>
> Obviously the service talked about here[1] isn’t available in the container, 
> so I can’t just 'service cloudstack-usage restart’.
>
>
> [1]: 
> https://docs.cloudstack.apache.org/projects/cloudstack-administration/en/4.8/usage.html#configuring-the-usage-server
>  
> 
>
>
> John
>
>> On 12 Jul 2017, at 06:33, Erik Weber  wrote:
>>
>> Are you running the usage server?
>>
>> It is a different service and run independently of the mgmt server
>>
>> --
>> Erik
>>
>> ons. 12. jul. 2017 kl. 00.25 skrev John McDonnell >> :
>>
>>> Hi,
>>>
>>> I asked this back in April on the Users mailing list and the response
>>> I got was that the usage server should be on by default in the docker
>>> container.  I got sidetracked by other things and am coming back to
>>> this issue.
>>>
>>> Is it meant to be running by default? or is there something needed to
>>> do to turn it on in the container?  (wasn't sure if this is a defect,
>>> so thought I'd ask here.)
>>>
>>>
>>> I use the container as a development tool(to avoid using a real life
>>> system) to test the API out and usage collection is a major part of
>>> what I use the API for.
>>>
>>>
>>> Steps to reproduce:
>>>
>>> (Have docker installed)
>>> $ docker pull cloudstack/simulator
>>> $ docker run --name cloudstack -d -p 8080:8080 cloudstack/simulator
>>> $ docker exec -ti cloudstack python \
>>> /root/tools/marvin/marvin/deployDataCenter.py -i
>>> /root/setup/dev/advanced.cfg
>>>
>>> After a while login to the UI: localhost:8080/client (admin:password)
>>>
>>> And usually, after a while, there will be a General Alert saying there
>>> is no Usage Server running.  Even before this message, if I add an
>>> instance, and attempt to collection usage with the API, I don't get
>>> anything back.
>>>
>>> Any help?
>>>
>



-- 
Daan

Re: [4.10] repos

[Daan Hoogland]

https://builds.cloudstack.org/view/release/job/build-systemvm is configured to 
push the systemvm for a version taken from a parameter

On 12/07/17 08:45, "Rajani Karuturi"  wrote:

AFAIK, there is no job that automatically pushes templates. I
manually copied the templates from build
https://builds.cloudstack.org/view/master/job/build-master-systemvm/272/
to http://download.cloudstack.org/systemvm/4.10/

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On July 12, 2017 at 5:36 AM, Pierre-Luc Dion
(pdion...@apache.org) wrote:

Hi,

I've created new jenkins jobs [1] to create package for our
release, The
jobs pushed rpm's but for systemvm, look like there is a wget
job somewhere
that download systemvm template from jenkins from build of
master branch,
I've created a set of systemvm templates that I would like to
published on
download.cloudstack.org but they are most likely going to be
overwritten,
could we disable that job ?

[1] https://builds.cloudstack.org/view/release/

PL


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

Re: next major release

[Daan Hoogland]

Thanks Rajani,
I created the upgrade paths and am no test compiling. Expect a PR in the next 
hour (I added the new path to every version not just past 4.0)

On 12/07/17 08:41, "Rajani Karuturi"  wrote:

I made the pom changes on master to 4.11.0.0-SNAPSHOT

4.10 branch is created

master and 4.10 can now accept changes once the upgrade paths are
in place.

Release notes and release announcement are the pending items now.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On July 12, 2017 at 1:23 AM, Wido den Hollander (w...@widodh.nl)
wrote:

I would say 4.11

5.0 should have major changes (like mentioned), API changes or
other big things. It should have 'killer features'. New GUI, New
API, etc. That kind of things.

Wido

Op 10 juli 2017 om 7:09 schreef Rajani Karuturi
:

should it be 4.11.0.0 or 5.0.0.0?

~Rajani
http://cloudplatform.accelerite.com/


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

Re: [4.10] repos

[Daan Hoogland]

Monsieur,

The job should be altered to go into 4.11. lemme look.

On 12/07/17 02:06, "Pierre-Luc Dion"  wrote:

Hi,

I've created new jenkins jobs [1] to create package for our release, The
jobs pushed rpm's but for systemvm, look like there is a wget job somewhere
that download systemvm template from jenkins from build of master branch,
I've created a set of systemvm templates that I would like to published on
download.cloudstack.org but they are most likely going to be overwritten,
could we disable that job ?

[1] https://builds.cloudstack.org/view/release/

PL



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

Re: [DISCUSS] upgrade to 4.11

[Daan Hoogland]

of which the heart is full, the mouth spilled ... (free from ancient
dutch saying ;)

On Tue, Jul 11, 2017 at 3:56 PM, Will Stevens <wstev...@cloudops.com> wrote:
> Oh ok.  DB upgrade, not a new skeleton for the upgrade path between version
> (hypervisors, etc...).
>
> My bad.  :)
>
> *Will Stevens*
> CTO
>
> <https://goo.gl/NYZ8KK>
>
> On Tue, Jul 11, 2017 at 9:41 AM, Daan Hoogland <daan.hoogl...@shapeblue.com>
> wrote:
>
>> No I am creating the upgrade code for the next version.
>> (schema-41000to41100 and upgrade java class)
>>
>> On 11/07/17 15:29, "williamstev...@gmail.com on behalf of Will Stevens" <
>> williamstev...@gmail.com on behalf of wstev...@cloudops.com> wrote:
>>
>> Not sure I have an answer for that.  Are you creating a PR to this set
>> of
>> documentation or where are you working?
>> https://github.com/apache/cloudstack-docs-rn/tree/
>> master/source/upgrade
>>
>> *Will Stevens*
>> CTO
>>
>> <https://goo.gl/NYZ8KK>
>>
>> On Tue, Jul 11, 2017 at 9:15 AM, Daan Hoogland <
>> daan.hoogl...@shapeblue.com>
>> wrote:
>>
>> > Devs,
>> >
>> > I am busy creating the skeleton upgrade code for our next version
>> (working
>> > name 4.11). Are we still supporting all direct upgrades from 2.x
>> onward or
>> > should we only assume upgrade paths from 4.y onwards?
>> >
>> > Tnx,
>> >
>> > 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

Re: [DISCUSS] upgrade to 4.11

[Daan Hoogland]

No I am creating the upgrade code for the next version. (schema-41000to41100 
and upgrade java class)

On 11/07/17 15:29, "williamstev...@gmail.com on behalf of Will Stevens" 
<williamstev...@gmail.com on behalf of wstev...@cloudops.com> wrote:

Not sure I have an answer for that.  Are you creating a PR to this set of
documentation or where are you working?
https://github.com/apache/cloudstack-docs-rn/tree/master/source/upgrade

*Will Stevens*
CTO

<https://goo.gl/NYZ8KK>

On Tue, Jul 11, 2017 at 9:15 AM, Daan Hoogland <daan.hoogl...@shapeblue.com>
wrote:

> Devs,
>
> I am busy creating the skeleton upgrade code for our next version (working
> name 4.11). Are we still supporting all direct upgrades from 2.x onward or
> should we only assume upgrade paths from 4.y onwards?
>
> Tnx,
>
> 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
  
 

[DISCUSS] upgrade to 4.11

[Daan Hoogland]

Devs,

I am busy creating the skeleton upgrade code for our next version (working name 
4.11). Are we still supporting all direct upgrades from 2.x onward or should we 
only assume upgrade paths from 4.y onwards?

Tnx,

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

Re: Developer Guide - Current Setup Guide?

[Daan Hoogland]

We have always given non committers access to the wiki if we knew them
on list. In fact when I (first) joined our group there was no
restriction on the wiki at all.

On Mon, Jul 10, 2017 at 6:57 PM, Will Stevens <williamstev...@gmail.com> wrote:
> This is what he means:
> https://www.apache.org/dev/new-committers-guide.html#cla
>
> I don't know that it is required for wiki access, but someone probably does
> understand those details.
>
>
> On Jul 10, 2017 12:44 PM, "Alex Hitchins" <a...@alexhitchins.com> wrote:
>
> Sorry, CLA?
>
> Is this the licence? I don't believe I do have one personally. I believe I
> may have an account for the wiki still, will see if I can resurrect it.
>
> Happy to amend the wiki, it is just the process of finding what is out of
> date by trial and error.
>
> The PR I have open, that should be very separate from the wiki though, no?
>
>> On 10 Jul 2017, at 16:10, Ron Wheeler <rwhee...@artifact-software.com>
> wrote:
>>
>> Alex,
>> Do you have a CLA on file with Apache.
>> You should have one to contribute to the wiki.
>>
>> Ron
>>
>>> On 10/07/2017 10:42 AM, Daan Hoogland wrote:
>>> create your account on cwiki and we can give you access
>>>
>>>> On Sun, Jul 9, 2017 at 12:10 AM, Alex Hitchins <a...@alexhitchins.com>
> wrote:
>>>> Please let me know if there is anything I can do to help with this.
>>>>
>>>> I have an open PR on the repo readme.md, minor documentation change but
> somehow is breaking the build. My guess is it's something unrelated on
> master.
>>>>
>>>>> On 8 Jul 2017, at 22:37, Will Stevens <williamstev...@gmail.com> wrote:
>>>>>
>>>>> We need to amend. As of 4.10 we are on jdk 8.
>>>>>
>>>>> I will have to review it and see what needs to be done to bring it up
> to
>>>>> date.
>>>>>
>>>>> On Jul 8, 2017 4:46 PM, "Alex Hitchins" <a...@alexhitchins.com> wrote:
>>>>>
>>>>> Asking as I want to be sure I'm getting myself setup correctly.
>>>>>
>>>>> I appreciate setup guides may not necessitate lots of amendments
> however 4
>>>>> years seemed a long time to go with nothing. Are we still on JDK 6 for
>>>>> example?
>>>>>
>>>>> More than happy to amend Confluence with updates as I come across them.
>>>>>
>>>>>
>>>>> Alexander Hitchins
>>>>> 
>>>>> E: a...@alexhitchins.com
>>>>> W: alexhitchins.com
>>>>> M: 07788 423 969
>>>>> T: 01892 523 587
>>>>>
>>>>> -Original Message-
>>>>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>>>>> Sent: 07 July 2017 21:08
>>>>> To: dev <dev@cloudstack.apache.org>
>>>>> Subject: Re: Developer Guide - Current Setup Guide?
>>>>>
>>>>> Why do you ask, Alex? Is something not working?
>>>>>
>>>>> Biligual auto correct use.  Read at your own risico
>>>>>
>>>>>> On 7 Jul 2017 9:54 pm, "Alex Hitchins" <a...@alexhitchins.com> wrote:
>>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>>
>>>>>>
>>>>>> I note this was last amended 2013, is there a better/more recent
>>>>>> resource for the aspiring CloudStack developer?
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/
>>>>>> Setting+up+CloudStack
>>>>>> +Development+Environment+on+Linux
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Alexander Hitchins
>>>>>>
>>>>>> 
>>>>>>
>>>>>> E: a...@alexhitchins.com
>>>>>>
>>>>>> W: alexhitchins.com
>>>>>>
>>>>>> M: 07788 423 969
>>>>>>
>>>>>> T: 01892 523 587
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwhee...@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>



-- 
Daan

Re: Developer Guide - Current Setup Guide?

[Daan Hoogland]

Why do you say that Ron? You need one to become a committer. for the
wiki we need to recognise you as a contributor. I think you need no
more.

On Mon, Jul 10, 2017 at 5:10 PM, Ron Wheeler
<rwhee...@artifact-software.com> wrote:
> Alex,
> Do you have a CLA on file with Apache.
> You should have one to contribute to the wiki.
>
> Ron
>
> On 10/07/2017 10:42 AM, Daan Hoogland wrote:
>>
>> create your account on cwiki and we can give you access
>>
>> On Sun, Jul 9, 2017 at 12:10 AM, Alex Hitchins <a...@alexhitchins.com>
>> wrote:
>>>
>>> Please let me know if there is anything I can do to help with this.
>>>
>>> I have an open PR on the repo readme.md, minor documentation change but
>>> somehow is breaking the build. My guess is it's something unrelated on
>>> master.
>>>
>>>> On 8 Jul 2017, at 22:37, Will Stevens <williamstev...@gmail.com> wrote:
>>>>
>>>> We need to amend. As of 4.10 we are on jdk 8.
>>>>
>>>> I will have to review it and see what needs to be done to bring it up to
>>>> date.
>>>>
>>>> On Jul 8, 2017 4:46 PM, "Alex Hitchins" <a...@alexhitchins.com> wrote:
>>>>
>>>> Asking as I want to be sure I'm getting myself setup correctly.
>>>>
>>>> I appreciate setup guides may not necessitate lots of amendments however
>>>> 4
>>>> years seemed a long time to go with nothing. Are we still on JDK 6 for
>>>> example?
>>>>
>>>> More than happy to amend Confluence with updates as I come across them.
>>>>
>>>>
>>>> Alexander Hitchins
>>>> 
>>>> E: a...@alexhitchins.com
>>>> W: alexhitchins.com
>>>> M: 07788 423 969
>>>> T: 01892 523 587
>>>>
>>>> -Original Message-
>>>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>>>> Sent: 07 July 2017 21:08
>>>> To: dev <dev@cloudstack.apache.org>
>>>> Subject: Re: Developer Guide - Current Setup Guide?
>>>>
>>>> Why do you ask, Alex? Is something not working?
>>>>
>>>> Biligual auto correct use.  Read at your own risico
>>>>
>>>>> On 7 Jul 2017 9:54 pm, "Alex Hitchins" <a...@alexhitchins.com> wrote:
>>>>>
>>>>> Hello all,
>>>>>
>>>>>
>>>>>
>>>>> I note this was last amended 2013, is there a better/more recent
>>>>> resource for the aspiring CloudStack developer?
>>>>>
>>>>>
>>>>>
>>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/
>>>>> Setting+up+CloudStack
>>>>> +Development+Environment+on+Linux
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Alexander Hitchins
>>>>>
>>>>> 
>>>>>
>>>>> E: a...@alexhitchins.com
>>>>>
>>>>> W: alexhitchins.com
>>>>>
>>>>> M: 07788 423 969
>>>>>
>>>>> T: 01892 523 587
>>>>>
>>>>>
>>>>>
>>>>>
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>



-- 
Daan

Re: Cloudstack dev Noob start :-)

[Daan Hoogland]

Oliver, I am pretty sure you where having a mysql version error at
first. This one is new to me. Did you fully remove mysql and the cloud
database and then install mariadb? Maybe you can drop all tables and
run the mvn command for installing a db instead of the create db
script. just for checking

On Mon, Jul 10, 2017 at 9:39 AM, Olivier Lamy  wrote:
> Hi
> Looks more to be a permission issue
> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: ALTER
> command denied to user 'cloud'@'localhost' for table 'account'
>
> When running create-database script I get this warning.
>
> sql> GRANT ALL ON cloud.* to cloud@`%` identified by 'cloud'
> [2017-07-07 09:47:56] [HY000][1287] Using GRANT statement to modify
> existing user's properties other than privileges is deprecated and will be
> removed in future release. Use ALTER USER statement for this operation.
>
> Anyway I changed to MariaBD and made some progress :-)  but still an error.
>
> My steps:
>
> * running the following scripts to create databases: create-database.sql,
> create-database-premium.sql, create-database-simulator.sql.
>
> * running the following scripts to create base schemas: create-schema.sql,
> create-schema-premium.sql, create-schema-simulator.sql
>
> * start the ui with mvn -pl :cloud-client-ui jetty:run
>
> But now it fail with (stack trace truncated but full available here:
> https://gist.github.com/olamy/b13e5f831b933829dd2ced7ddb5dc59b
>
> INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) (logid:) Cleanup upgrade
> Upgrade441to442 to upgrade from 4.4.1-4.4.2 to 4.4.2
>
> ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:) Error executing: ALTER
> TABLE `cloud`.`guest_os_hypervisor` ADD FOREIGN KEY (`guest_os_id`)
> REFERENCES `cloud`.`guest_os`(`id`)
>
> ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:)
> com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException:
> Cannot add or update a child row: a foreign key constraint fails
> (`cloud`.`#sql-882f_27`, CONSTRAINT `#sql-882f_27_ibfk_1` FOREIGN KEY
> (`guest_os_id`) REFERENCES `guest_os` (`id`))
>
> ERROR [c.c.u.DatabaseUpgradeChecker] (main:null) (logid:) Unable to execute
> upgrade script:
> /Users/olamy/dev/sources/open-sources/cloudstack/cloudstack/client/target/utilities/scripts/db/db/schema-442to450.sql
>
> com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException:
> Cannot add or update a child row: a foreign key constraint fails
> (`cloud`.`#sql-882f_27`, CONSTRAINT `#sql-882f_27_ibfk_1` FOREIGN KEY
> (`guest_os_id`) REFERENCES `guest_os` (`id`))
>
> ERROR [c.c.u.DatabaseUpgradeChecker] (main:null) (logid:) Unable to upgrade
> the database
>
> com.cloud.utils.exception.CloudRuntimeException: Unable to execute upgrade
> script:
> /Users/olamy/dev/sources/open-sources/cloudstack/cloudstack/client/target/utilities/scripts/db/db/schema-442to450.sql
>
> Not sure what to do here :-(
>
> On 6 July 2017 at 19:22, Wido den Hollander  wrote:
>
>>
>> > Op 6 juli 2017 om 9:02 schreef Olivier Lamy :
>> >
>> >
>> > Hi,
>> > Long time I didn't participate here.
>> > I'd like to do some hacking.
>> > I'm not clear on the process for noob :-)
>> > I ran sql scripts:
>> > * create-database.sql
>> > * create-schema.sql
>> >
>> > Then I start with mvn -pl :cloud-client-ui jetty:run
>> > But I got the this error (see stacktrace below)
>> > I use osx, mysql 5.7.18_1 installed with brew
>> >
>> > Thanks a lot for your help
>> >
>> > Caused by: com.cloud.utils.exception.CloudRuntimeException: Unable to
>> > upgrade the database
>> >
>> > at
>> > com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpg
>> radeChecker.java:438)
>> >
>> > at
>> > com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgra
>> deChecker.java:509)
>> >
>> > at
>> > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLif
>> eCycle.checkIntegrity(CloudStackExtendedLifeCycle.java:65)
>> >
>> > at
>> > org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLif
>> eCycle.start(CloudStackExtendedLifeCycle.java:55)
>> >
>> > at
>> > org.springframework.context.support.DefaultLifecycleProcesso
>> r.doStart(DefaultLifecycleProcessor.java:173)
>> >
>> > ... 70 more
>> >
>> > Caused by: com.cloud.utils.exception.CloudRuntimeException: Unable to
>> > execute upgrade script:
>> > /Users/olamy/dev/sources/open-sources/cloudstack/cloudstack/
>> client/target/utilities/scripts/db/db/schema-410to420.sql
>> >
>> > at
>> > com.cloud.upgrade.DatabaseUpgradeChecker.runScript(DatabaseU
>> pgradeChecker.java:331)
>> >
>> > at
>> > com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpg
>> radeChecker.java:425)
>> >
>> > ... 74 more
>> >
>> > Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException:
>> ALTER
>> > command denied to user 'cloud'@'localhost' for table 'account'
>> >
>>
>> I see a access denied. Could you check the access credentials of the user
>> in MySQL?
>>
>> Wido
>>
>> > at 

Re: Developer Guide - Current Setup Guide?

[Daan Hoogland]

create your account on cwiki and we can give you access

On Sun, Jul 9, 2017 at 12:10 AM, Alex Hitchins <a...@alexhitchins.com> wrote:
> Please let me know if there is anything I can do to help with this.
>
> I have an open PR on the repo readme.md, minor documentation change but 
> somehow is breaking the build. My guess is it's something unrelated on master.
>
>> On 8 Jul 2017, at 22:37, Will Stevens <williamstev...@gmail.com> wrote:
>>
>> We need to amend. As of 4.10 we are on jdk 8.
>>
>> I will have to review it and see what needs to be done to bring it up to
>> date.
>>
>> On Jul 8, 2017 4:46 PM, "Alex Hitchins" <a...@alexhitchins.com> wrote:
>>
>> Asking as I want to be sure I'm getting myself setup correctly.
>>
>> I appreciate setup guides may not necessitate lots of amendments however 4
>> years seemed a long time to go with nothing. Are we still on JDK 6 for
>> example?
>>
>> More than happy to amend Confluence with updates as I come across them.
>>
>>
>> Alexander Hitchins
>> 
>> E: a...@alexhitchins.com
>> W: alexhitchins.com
>> M: 07788 423 969
>> T: 01892 523 587
>>
>> -Original Message-
>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> Sent: 07 July 2017 21:08
>> To: dev <dev@cloudstack.apache.org>
>> Subject: Re: Developer Guide - Current Setup Guide?
>>
>> Why do you ask, Alex? Is something not working?
>>
>> Biligual auto correct use.  Read at your own risico
>>
>>> On 7 Jul 2017 9:54 pm, "Alex Hitchins" <a...@alexhitchins.com> wrote:
>>>
>>> Hello all,
>>>
>>>
>>>
>>> I note this was last amended 2013, is there a better/more recent
>>> resource for the aspiring CloudStack developer?
>>>
>>>
>>>
>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/
>>> Setting+up+CloudStack
>>> +Development+Environment+on+Linux
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Alexander Hitchins
>>>
>>> 
>>>
>>> E: a...@alexhitchins.com
>>>
>>> W: alexhitchins.com
>>>
>>> M: 07788 423 969
>>>
>>> T: 01892 523 587
>>>
>>>
>>>
>>>
>



-- 
Daan

Re: Developer Guide - Current Setup Guide?

[Daan Hoogland]

Why do you ask, Alex? Is something not working?

Biligual auto correct use.  Read at your own risico

On 7 Jul 2017 9:54 pm, "Alex Hitchins"  wrote:

> Hello all,
>
>
>
> I note this was last amended 2013, is there a better/more recent resource
> for the aspiring CloudStack developer?
>
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/
> Setting+up+CloudStack
> +Development+Environment+on+Linux
>
>
>
>
>
>
>
>
>
> Alexander Hitchins
>
> 
>
> E: a...@alexhitchins.com
>
> W: alexhitchins.com
>
> M: 07788 423 969
>
> T: 01892 523 587
>
>
>
>

Re: [VOTE] Apache CloudStack 4.10.0.0 RC7

[Daan Hoogland]

we need another binding vote and I know Boris way of working. I don't
have time to test myself but given Boris vote I
+1 (binding)

On Thu, Jul 6, 2017 at 9:52 AM, Boris Stoyanov
 wrote:
> +1
>
> I’ve did upgrade testing with VMWare 5.5u3, advanced zone running on CentOS 
> 6.8 from:
> 4.5 -> 4.10 rc7
> 4.6 -> 4.10 rc7
> 4.9 -> 4.10 rc7
>
> All went smooth VRs got updated to the latests version and was able to add 
> new VMs to them.
>
> Thanks,
> Boris Stoyanov
>
>
> boris.stoya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>> On Jul 5, 2017, at 4:30 PM, Kris Sterckx  
>> wrote:
>>
>> +1 from Nuage !
>>
>> Thanks
>>
>> Kris
>>
>> On 5 July 2017 at 15:11, Wido den Hollander  wrote:
>>
>>> +1 (binding)
>>>
>>> - Tested building DEB packages
>>> - Tested deployment with Basic Networking on Ubuntu 16.04
>>> - Tested IPv6 integration in Basic Networking
>>>
 Op 3 juli 2017 om 6:52 schreef Rajani Karuturi :


 Hi All,

 I've created 4.10.0.0 release with the following artifacts up for a vote:

 Git Branch and Commit SH:
 https://github.com/apache/cloudstack/commit/
>>> 9d2893d44a3c3a4829be0964cc991272c1d13e4d
 Commit:9d2893d44a3c3a4829be0964cc991272c1d13e4d
 Branch: https://github.com/apache/cloudstack/tree/4.10.0.0-
>>> RC20170703T1006

 Source release (checksums and signatures are available at the same
 location):
 https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/

 SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC7/

 PRs merged since RC4: #2150 and #2089
 PRs merged since RC5: revert of #2084
 PRs merged since RC6: #2162

 PGP release keys (signed using CBB44821):
 https://dist.apache.org/repos/dist/release/cloudstack/KEYS

 Vote will be open for 72 hours.

 For sanity in tallying the vote, can PMC members please be sure to
>>> indicate
 "(binding)" with their vote?

 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)

 Thanks,
 ~Rajani
 http://cloudplatform.accelerite.com/
>>>
>



-- 
Daan

Re: Cloudstack dev Noob start :-)

[Daan Hoogland]

Btw, I use mariadb 10.2.6 installed with brew 

On 06/07/2017, 09:27, "Daan Hoogland" <daan.hoogl...@shapeblue.com> wrote:

H Oliver, your mysql seems to new for cloudstack ;) and welcome back

On 06/07/2017, 09:02, "Olivier Lamy" <ol...@apache.org> wrote:

Hi,
Long time I didn't participate here.
I'd like to do some hacking.
I'm not clear on the process for noob :-)
I ran sql scripts:
* create-database.sql
* create-schema.sql

Then I start with mvn -pl :cloud-client-ui jetty:run
But I got the this error (see stacktrace below)
I use osx, mysql 5.7.18_1 installed with brew

Thanks a lot for your help

Caused by: com.cloud.utils.exception.CloudRuntimeException: Unable to
upgrade the database

at

com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:438)

at

com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:509)

at

org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.checkIntegrity(CloudStackExtendedLifeCycle.java:65)

at

org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:55)

at

org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:173)

... 70 more

Caused by: com.cloud.utils.exception.CloudRuntimeException: Unable to
execute upgrade script:

/Users/olamy/dev/sources/open-sources/cloudstack/cloudstack/client/target/utilities/scripts/db/db/schema-410to420.sql

at

com.cloud.upgrade.DatabaseUpgradeChecker.runScript(DatabaseUpgradeChecker.java:331)

at

com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:425)

... 74 more

Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: 
ALTER
command denied to user 'cloud'@'localhost' for table 'account'

at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:185)

at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:87)

at

com.cloud.upgrade.DatabaseUpgradeChecker.runScript(DatabaseUpgradeChecker.java:322)
Cheers
-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy



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
  
 

Re: Cloudstack dev Noob start :-)

[Daan Hoogland]

H Oliver, your mysql seems to new for cloudstack ;) and welcome back

On 06/07/2017, 09:02, "Olivier Lamy"  wrote:

Hi,
Long time I didn't participate here.
I'd like to do some hacking.
I'm not clear on the process for noob :-)
I ran sql scripts:
* create-database.sql
* create-schema.sql

Then I start with mvn -pl :cloud-client-ui jetty:run
But I got the this error (see stacktrace below)
I use osx, mysql 5.7.18_1 installed with brew

Thanks a lot for your help

Caused by: com.cloud.utils.exception.CloudRuntimeException: Unable to
upgrade the database

at

com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:438)

at

com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:509)

at

org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.checkIntegrity(CloudStackExtendedLifeCycle.java:65)

at

org.apache.cloudstack.spring.lifecycle.CloudStackExtendedLifeCycle.start(CloudStackExtendedLifeCycle.java:55)

at

org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:173)

... 70 more

Caused by: com.cloud.utils.exception.CloudRuntimeException: Unable to
execute upgrade script:

/Users/olamy/dev/sources/open-sources/cloudstack/cloudstack/client/target/utilities/scripts/db/db/schema-410to420.sql

at

com.cloud.upgrade.DatabaseUpgradeChecker.runScript(DatabaseUpgradeChecker.java:331)

at

com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:425)

... 74 more

Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: ALTER
command denied to user 'cloud'@'localhost' for table 'account'

at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:185)

at com.cloud.utils.db.ScriptRunner.runScript(ScriptRunner.java:87)

at

com.cloud.upgrade.DatabaseUpgradeChecker.runScript(DatabaseUpgradeChecker.java:322)
Cheers
-- 
Olivier Lamy
http://twitter.com/olamy | http://linkedin.com/in/olamy



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

Solved: Silent failure of deploydb on developer machine

[Daan Hoogland]

For the interested: This is the behaviour on macos 10.12 with mysql
5.6. Downgrading mysql solves the problem

On Mon, Jul 3, 2017 at 5:14 PM, Daan Hoogland
<daan.hoogl...@shapeblue.com> wrote:
> Has anybody outthere seen a
> mvn – P developer –pl developer –Ddeploydb
> report success without executing any sql commands?
> No create schema is not even executed.
>
> daan.hoogl...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>



-- 
Daan

Silent failure of deploydb on developer machine

[Daan Hoogland]

Has anybody outthere seen a
mvn – P developer –pl developer –Ddeploydb
report success without executing any sql commands?
No create schema is not even executed.

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

Re: JIRA - PLEASE READ

[Daan Hoogland]

On Thu, Jun 29, 2017 at 11:06 AM, Paul Angus  wrote:
> + Release notes will be impossible to create without a proper Jira history.
> And no one will know what has gone into CloudStack.


No they are not mr Grumpy. they should be base on the code anyway,
hence on git, not jira. I do not appose to the use of Jira but it is
not required for good coding practices and as we are not and will not
function as a corporation, jira is an extra for those that grave for
it. not a requirement.

-- 
Daan

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Daan Hoogland]

shapeblue.com
>> www.shapeblue.com ( http://www.shapeblue.com )
>> 53 Chandos Place, Covent Garden, London WC2N 4HSUK
>> @shapeblue
>>
>> -Original Message-
>> From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com]
>> Sent: 27 June 2017 01:25
>> To: dev@cloudstack.apache.org
>> Cc: Wido den Hollander <w...@widodh.nl>
>> Subject: Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3
>>
>> I tend to agree with you here, Daan. I know the downside we’ve
>> discussed
>> in the past is that overall community participation in the RC
>> process has
>> dropped off when such a new branch is created (since the
>> community as a
>> whole tends to focus more on the new branch rather than on
>> testing the RC
>> and releasing it).
>>
>> I believe we should do the following: As we approach the first
>> RC, we need
>> to limit the number of PRs going into the branch (in order to
>> stabilize
>> it). If we had a super duper array of automated regression tests
>> that ran
>> against the code, then we might be able to avoid this, but our
>> automated
>> test suite is not extensive enough for us to do so.
>>
>> As we approach the first RC, only blockers and trivial (ex. text
>> changes)
>> PRs should be permitted in. Once we cut the first RC, create a
>> new branch
>> for ongoing dev work. In between RCs, we can only allow in code
>> related to
>> blocker PRs (or trivial text changes, as discussed before).
>>
>> What do people think?
>>
>> On 6/13/17, 4:56 AM, "Daan Hoogland" <daan.hoogl...@gmail.com>
>> wrote:
>>
>> this is why i say we should branch on first RC, fix in release
>> branch
>> only and merge forward
>>
>> On Tue, Jun 13, 2017 at 12:41 PM, Will Stevens <
>> williamstev...@gmail.com> wrote:
>>
>> I know it is hard to justify not merging PRs that seem ready but
>> are
>>
>> not
>>
>> blockers in an RC, but it is a vicious circle which ultimately
>>
>> results in a
>>
>> longer RC process.
>>
>> It is something i struggled with as a release manager as well.
>>
>> On Jun 13, 2017 1:56 AM, "Rajani Karuturi" <raj...@apache.org>
>>
>> wrote:
>>
>> Thanks Mike,
>>
>> Will hold off next RC until we hear an update from you.
>>
>> Regarding merging non-blockers, unfortunately, its a side-effect
>> of taking more than three months in the RC phase :(
>>
>> Thanks,
>>
>> ~ Rajani
>>
>> http://cloudplatform.accelerite.com/
>>
>> On June 13, 2017 at 10:10 AM, Tutkowski, Mike
>> (mike.tutkow...@netapp.com) wrote:
>>
>> Hi everyone,
>>
>> I had a little time this evening and re-ran some VMware-related
>> tests around managed storage. I noticed a problem that I’d like
>> to investigate before we spin up the next RC. Let’s hold off on
>> the next RC until I can find out more (I should know more within
>> 24 hours).
>>
>> Thanks!
>> Mike
>>
>> On 6/12/17, 2:40 AM, "Wido den Hollander" <w...@widodh.nl>
>> wrote:
>>
>> Op 10 juni 2017 om 21:18 schreef "Tutkowski, Mike"
>>
>> <mike.tutkow...@netapp.com>:
>>
>> Hi,
>>
>> I opened a PR against the most recent RC:
>>
>> https://github.com/apache/cloudstack/pull/2141
>>
>> I ran all managed-storage regression tests against it and they
>>
>> pass (as noted in detail in the PR).
>>
>> If someone wants to take this code and create a new RC from
>>
>> it, I’m +1 on the new RC as long as this is the only commit
>> addedto it since the current RC.
>>
>> Thanks Mike!
>>
>> If this PR is good we should probably merge it asap and go for
>> RC5.
>>
>> 4.10 should really be released by now.
>>
>> Wido
>>
>> Thanks!
>> Mike
>>
>> On 6/9/17, 7:43 PM, "Tutkowski, Mike"
>>
>> <mike.tutkow...@netapp.com> wrote:
>>
>> Hi everyone,
>>
>> I found a critical issue that was introduced into this RC
>>
>> since the most recent RC, so I am -1 on this RC.
>>
>> The fix for this ticket breaks the support for storing volume
>>
>> snapshots on primary storage (which is a feature managed
>> storagecan support):
>>
>> https://issues.apache.org/jira/browse/CLOUDSTACK-9685
>>
>> Here is the SHA: 336df84f1787de962a67d0a34551f9027303040e
>>
>> At a high level, 

Re: [VOTE] Apache CloudStack 4.10.0.0 RC5

[Daan Hoogland]

It was an optimization that got merged and if someone is hindered we should 
back out and proceed, I’d say. 

On 21/06/17 16:00, "Wido den Hollander"  wrote:


> Op 20 juni 2017 om 21:35 schreef Kris Sterckx 
:
> 
> 
> I am sorry, I need to vote -1

:(

Anybody else have an idea on how to proceed? We keep having issues popping 
up with 4.10

This should be fixable right for 4.10?

We have so many work piling up for 4.11 right now, we should really get 
that going.

Wido

> 
> 
> https://github.com/apache/cloudstack/pull/2084  is causing password reset
> issues for us (Nuage) (i know in native tests pass though...).
> 
> We are trying to provide a fix but the following modified VR script is
> having severe issues :
> 
> 
https://github.com/apache/cloudstack/blob/master/systemvm/patches/debian/config/opt/cloud/bin/configure.py
>  :
> 
> - import of  CsPassword  is missing
> 
> - line 910 : this invocation of the constructor is invalid  (ctor is  def
> __init__(self, dbag)  )
> 
> Also i believe for SDN provided networks there is something overlooked as
> we don't see the ip tables set for the VR to respond to password reset
> requests.  We believe the script is not setting iptables_change = True in
> case of networks for which the VR is not in the dataplane.
> 
> 
> I suggest this PR is backed out for now it this is not an urgent add to 
the
> 4.10 release, or we spend time at fixing it.
> 
> We definitely want to help in making that happen.
> 
> 
> Thanks,
> 
> Kris
> 
> -- Nuage Networks
> 

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

> On 20 June 2017 at 07:45, Rajani Karuturi  wrote:
> 
> > Hi All,
> >
> > I've created 4.10.0.0 release with the following artifacts up for a 
vote:
> >
> > Git Branch and Commit SH:
> > 
https://github.com/apache/cloudstack/commit/058e34224c0555396c043c6473ac07
> > ab3e8424cd
> > Commit:058e34224c0555396c043c6473ac07ab3e8424cd
> > Branch: 
https://github.com/apache/cloudstack/tree/4.10.0.0-RC20170620T1023
> >
> > Source release (checksums and signatures are available at the same
> > location):
> > https://dist.apache.org/repos/dist/dev/cloudstack/4.10.0.0/
> >
> > SystemVm Templates: http://download.cloudstack.org/systemvm/4.10/RC5/
> >
> > New PRs merged since RC4: #2150 and #2089
> >
> > PGP release keys (signed using CBB44821):
> > https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> >
> > Vote will be open for 72 hours.
> >
> > For sanity in tallying the vote, can PMC members please be sure to 
indicate
> > "(binding)" with their vote?
> >
> > [ ] +1  approve
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >
> >
> > Thanks,
> > ~Rajani
> > http://cloudplatform.accelerite.com/
> >

Re: [VOTE] Apache Cloudstack 4.10.0.0 RC3

[Daan Hoogland]

this is why i say we should branch on first RC, fix in release branch
only and merge forward

On Tue, Jun 13, 2017 at 12:41 PM, Will Stevens  wrote:
> I know it is hard to justify not merging PRs that seem ready but are not
> blockers in an RC, but it is a vicious circle which ultimately results in a
> longer RC process.
>
> It is something i struggled with as a release manager as well.
>
> On Jun 13, 2017 1:56 AM, "Rajani Karuturi"  wrote:
>
> Thanks Mike,
>
> Will hold off next RC until we hear an update from you.
>
> Regarding merging non-blockers, unfortunately, its a side-effect
> of taking more than three months in the RC phase :(
>
> Thanks,
>
> ~ Rajani
>
> http://cloudplatform.accelerite.com/
>
> On June 13, 2017 at 10:10 AM, Tutkowski, Mike
> (mike.tutkow...@netapp.com) wrote:
>
> Hi everyone,
>
> I had a little time this evening and re-ran some VMware-related
> tests around managed storage. I noticed a problem that I’d like
> to investigate before we spin up the next RC. Let’s hold off on
> the next RC until I can find out more (I should know more within
> 24 hours).
>
> Thanks!
> Mike
>
> On 6/12/17, 2:40 AM, "Wido den Hollander" 
> wrote:
>
>> Op 10 juni 2017 om 21:18 schreef "Tutkowski, Mike"
> :
>>
>>
>> Hi,
>>
>> I opened a PR against the most recent RC:
> https://github.com/apache/cloudstack/pull/2141
>>
>> I ran all managed-storage regression tests against it and they
> pass (as noted in detail in the PR).
>>
>> If someone wants to take this code and create a new RC from
> it, I’m +1 on the new RC as long as this is the only commit added
> to it since the current RC.
>
> Thanks Mike!
>
> If this PR is good we should probably merge it asap and go for
> RC5.
>
> 4.10 should really be released by now.
>
> Wido
>
>>
>> Thanks!
>> Mike
>>
>> On 6/9/17, 7:43 PM, "Tutkowski, Mike"
>  wrote:
>>
>> Hi everyone,
>>
>> I found a critical issue that was introduced into this RC
> since the most recent RC, so I am -1 on this RC.
>>
>> The fix for this ticket breaks the support for storing volume
> snapshots on primary storage (which is a feature managed storage
> can support):
>>
>> https://issues.apache.org/jira/browse/CLOUDSTACK-9685
>>
>> Here is the SHA: 336df84f1787de962a67d0a34551f9027303040e
>>
>> At a high level, what it does is remove a row from the
> cloud.snapshot_store_ref table when a volume is deleted that has
> one or more volume snapshots.
>>
>> This is fine for non-managed (traditional) storage; however,
> managed storage can store volume snapshots on primary storage, so
> removing this row breaks that functionality.
>>
>> I can fix the problem that this commit introduced by looking
> at the primary storage that supports the volume snapshot and
> checking the following: 1) Is this managed storage? 2) If yes, is
> the snapshot in question stored on that primary storage?
>>
>> The problem is I will be out of the office for a couple weeks
> and will not be able to address this until I return.
>>
>> We could revert the commit, but I still will not have time to
> run the managed-storage regression test suite until I return.
>>
>> On a side note, it looks like this commit was introduced since
> the most recent RC. I would argue that it was not a blocker and
> should not have been placed into the new RC. We (as a community)
> tend to have a lot of code go in between RCs and that just
> increases the chances of introducing critical issues and thus
> delaying the release. We’ve gotten better at this over the years,
> but we should focus more on only allowing the entry of new code
> into a follow-on RC that is critical (or so trivial as to not at
> all be likely to introduce any problems…like fixing an error
> message).
>>
>> Thanks for your efforts on this, everyone!
>> Mike
>>
>> On 6/9/17, 8:52 AM, "Tutkowski, Mike"
>  wrote:
>>
>> Hi Rajani,
>>
>> I will see if I can get all of my managed-storage testing
> (both automated and manual) done today. If not, we’ll need to see
> if someone else can complete it before we OK this RC as I won’t
> be back in the office for a couple weeks. I’ll report back later
> today.
>>
>> Thanks,
>> Mike
>>
>> On 6/9/17, 2:34 AM, "Rajani Karuturi" 
> wrote:
>>
>> Yup. thats right. I dont know how it happened but, it created
>> from the previous RC commit. The script is supposed to do a
> git
>> pull. I didn't notice any failures. Not sure what went wrong.
>>
>> Thanks for finding it mike. I am creating RC4 now and
> cancelling
>> this.
>>
>> ~ Rajani
>>
>> http://cloudplatform.accelerite.com/
>>
>> On June 9, 2017 at 12:07 PM, Tutkowski, Mike
>> (mike.tutkow...@netapp.com) wrote:
>>
>> Hi Rajani,
>>
>> I don’t see the following PR in this RC:
>>
>> https://github.com/apache/cloudstack/pull/2098
>>
>> I ran all of my managed-storage regression tests. They all
>> passed with the exception of the one that 

Re: [DISCUSS] API versioning

[Daan Hoogland]

The wiki page exists for changes to be introduced at 5.0. It has been there for 
more than a year so it needs tlc.
As for the API I sugest to start with a v2Beta api that we then migrate to v2 
once we feel it can be maintained for a while without breaking backwards 
compatibility. (and move to ACS 5.0 at that point)
Alternatively we can just upgrade quickly (v2, v3, v4, …)

In short +1 for Rene’s idea but with caveats.

On 05/06/2017, 17:57, "Syed Ahmed"  wrote:

+1 for the API versioning. If you could create a wiki page Rene, we can
start documenting the changes.

Thanks,
-Syed

On Mon, Jun 5, 2017 at 10:14 AM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> This might be a good excuse for an ACS 5.0! Maybe with some other 
additions
> such as the support for OASIS CAMP or TOSCA?
>
> It would be interesting to have a ROADMAP with these desires/wishes.
>
> On Mon, Jun 5, 2017 at 8:52 AM, Simon Weller 
> wrote:
>
> >
> > +1. Echoing what Rohit pointed out, we have a lot of cleanup to do :-) 
It
> > certainly makes it a lot easier though when you're not breaking
> > compatibility with existing code.
> >
> > 
> > From: Rohit Yadav 
> > Sent: Monday, June 5, 2017 4:04 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] API versioning
> >
> > +1 Good idea, though bear in mind there are 500+ APIs with no
> > modern-RESTful-standardization, a lot of work.
> >
> >
> > Regards.
> >
> > 
> > From: Nitin Kumar Maharana 
> > Sent: 05 June 2017 12:37:24
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] API versioning
> >
> > This looks good. +1
> >
> > rohit.ya...@shapeblue.com
> > www.shapeblue.com
> > [http://shapeblue.com/wp-content/uploads/2014/03/sungardonline1.jpg]<
> > http://www.shapeblue.com/>
> >
> > Shapeblue - The CloudStack Company
> > www.shapeblue.com
> > The city of Prague was the venue for the spring meeting of the 
Cloudstack
> > European user group. There was
> >
> >
> >
> > 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
  
 

> On 04-Jun-2017, at 2:34 PM, Rene Moser  wrote:
> > >
> > > Hi
> > >
> > > I recently developed ansible modules for the ACL API and ... found 
this
> > > has a really inconsistent API naming. E.g.
> > >
> > > createNetworkACL <<-- this creates an ACL rule
> > > createNetworkACLList <<-- this create the ACL
> > >
> > > updateNetworkACLItem <<-- this updates an ACL rule
> > > updateNetworkACLList <<-- this updates the ACL
> > >
> > > My first thoughs was, someone has to fix this, like
> > >
> > > createNetworkAclRule <<-- this create the ACL rule
> > > createNetworkAcl <<-- this creates an ACL
> > >
> > > updateNetworkAclRule <<-- this updates the ACL rule
> > > updateNetworkAcl <<-- this updates an ACL
> > >
> > > But how without breaking the API for backwards compatibility? I know a
> > > few other places where the API has inconsistent namings. Fixing the 
API
> > > but in a controlled way? What about by adding a version to the API?
> > >
> > > I would like to introduce a API versioning to cloudstack: The current
> > > API would be frozen into verison v1. The new API will have v2. The
> > > versioned API has the URL scheme:
> > >
> > > /client/api/
> > >
> > > The current API would be /client/api/v1 and the /client/api would be 
an
> > > alias for v1. This ensures backwards compatibility.
> > >
> > > This would allow us to deprecate and change APIs.
> > >
> > > Any thoughts?
> > >
> > >
> > >
> >
> >
> >
> >
> > 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.
> >
>
>
>
> --
> Rafael Weingärtner
>

Re: Miami CCC '17 Roundtable/Hackathon Summary

[Daan Hoogland]

At the moment I am looking at CAMP, used by Apache Brooklyn, to see if it makes 
sense to embed a Brooklyn engine in ACS. There is an extension to Brooklyn for 
TOSCA for comparison but I’d like to keep it as simple as possible and hence 
use CAMP. (as you know Rafael ;)

On 29/05/2017, 23:17, "Rafael Weingärtner"  wrote:

On this idea of Rene to easily provide ways for vendors to integrate
solutions; if we had an endpoint that receives a blueprint for VM(s)
described in some language (let’s say TOSCA) we might be able to achieve
that without needing to add tons of code to ACS. Appliances could be
described in this language and would be easily introduced into ACS
(pluggable appliances?); then there is the matter of creating customization
endpoints for the deployed appliance, so administrators can configure it.
We also would need to improve further the internals of ACS to provide
better extension points for anyone that wants to extend/enhance its core
features.

I also agree with everything discussed so far that even if we modularize
the VR, we need to do so in a transparent way for the
operators/administrators that are already used to the ACS way of doing
cloud.

On Mon, May 29, 2017 at 8:46 AM, Rene Moser  wrote:

> Hi
>
> On 05/23/2017 02:16 PM, Simon Weller wrote:
>
> > We floated some ideas related to short term VR fixes in order to make it
> more modular, as well as API driven, rather than the currently SSH JSON
> injections.
>
> Speaking about endless possibilities... ;)
>
> I support the initiative (+1) to make the routing more API driven and
> modular, the issue I see with a "too hard backed" appliance is the
> integration into the existing environment.
>
> One big benefit of the VR is that we can relatively easy customize it.
>
> I had some thoughts about how to integrate a standardized "custom
> configuration" mechanism to the VR.
>
> I like the idea to have a "user data" or "cloud init" for the VR on the
> network offerings level. This would allow any virtual appliance "vendor"
> to implement a simple interface (e.g. static yaml/json data) which
> allows the "cloudstack admin" to customize the virtual appliance in the
> network offerings API.
>
> E.g. for our VR, the "cloud init" interface would allow
>
> * to install and configure custom monitoring solution
> * configure the automated update mechanism
> * add web hooks to trigger what so ever
> * install and run cfgmgmt like puppet/ansible-pull
> * etc.
>
> So for any virtual appliance the interfaces would be the same but the
> config option would differ based on features they provide.
>
> Regards
> René
>



-- 
Rafael Weingärtner



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

Re: Miami CCC '17 Roundtable/Hackathon Summary

[Daan Hoogland]

ntric 
Usability.
>  
>  If I rambled a little here I apologize, its 11:30pm and sometimes I 
get ahead of myself (especially when I write something like this at this hour) 
when writing about something I am passionate about and I am passionate about 
getting more exposure and adoption of ACS.
>  
>  Thank you for listening guys.. Sorry for the ramble.
>  
>  Regards,
>  Marty Godsey
>  Principal Engineer
>  nSource Solutions, LLC
>  
>  -Original Message-
>  From: Rafael Weingärtner [mailto:rafaelweingart...@gmail.com]
>  Sent: Tuesday, May 23, 2017 11:18 AM
>  To: dev@cloudstack.apache.org
>  Subject: Re: Miami CCC '17 Roundtable/Hackathon Summary
>  
>  I missed the roundtable and hackathon, my bad guys :(
>  
>  I liked the ideas that you (all) put forward. The VR is interesting 
and a nice feature to have, but it causes some pain to maintain in our 
development cycles. The idea to split the current VR into NFV is great; this 
can make things more pluggable and take ACS to NFV (officially). We could 
develop a framework in ACS (an API method?) that creates a system VM called NFV 
where people (vendors, enthusiast, users and others) can then extend and add 
their functions/systems there. The problem is the work required to design and 
develop such thing.
>  
>  I use Daan`s words here, this is a community effort and not a single 
company or individual. What do you guys think? We could start creating a 
roadmap of when we want this feature (milestones for delivering piece by piece 
of the complete feature), then the draft of a proposal, and later define the 
implementation job, so people of the community can embrace it.
>  
>  On Tue, May 23, 2017 at 10:18 AM, Daan Hoogland 
<daan.hoogl...@shapeblue.com
>  > wrote:
>  
>  > Great thanks Simon,
>  >
>  > Just want to play bingo a bit; dividing the VR into VNFs (virtual
>  > network
>  > functions) was mentioned. This pertains to the mention of making 
the
>  > VR more modular ;)
>  >
>  > Hopefully everybody is inspired by this because no one company or
>  > person is going to make this happen.
>  >
>  > Dahn
>  >
>  > On 23/05/17 14:16, "Simon Weller" <swel...@ena.com.INVALID> wrote:
>  >
>  > Hi everyone,
>  >
>  >
>  > During the CCC last week in Miami, we held a 
roundtable/hackathon
>  > to discuss some of the major areas the community would like to 
focus
>  > more attention.
>  >
>  >
>  > The discussions were passionate and were mainly focused around
>  > networking and our current use of our home-spun Virtual Router.
>  >
>  >
>  > For most of the us, the VR has become a challenging beast, 
mainly
>  > due to how difficult it is to end-to-end test for new releases.
>  >
>  > Quite often PRs are pushed that fix an issue on one feature 
set,
>  > but break another unintentionally. This has a great deal to do with
>  > how inter-mingled all the features are currently.
>  >
>  >
>  > We floated some ideas related to short term VR fixes in order 
to
>  > make it more modular, as well as API driven, rather than the 
currently
>  > SSH JSON injections.
>  >
>  > A number of possible alternatives were also brought up to see 
what
>  > VR feature coverage could be handled by other virtual appliances
>  > currently out on the market.
>  >
>  >
>  > These included (but not limited to):
>  >
>  >
>  > VyOS (current PR out there for integration via a plugin – 
thanks
>  > Matthew!)
>  >
>  > Microtek (Commerical)
>  >
>  > Openswitch/Flexswitch
>  >
>  > Cloud Router
>  >
>  >
>  > The second major topic of the day was related to how we want to
>  > integrate networking moving forward.
>  >
>  >
>  > A fair number of individuals felt that we shouldn't be 
focusing so
>  > much on integrating network functions, but relying on other network

Re: Miami CCC '17 Roundtable/Hackathon Summary

[Daan Hoogland]

Great thanks Simon,

Just want to play bingo a bit; dividing the VR into VNFs (virtual network 
functions) was mentioned. This pertains to the mention of making the VR more 
modular ;)

Hopefully everybody is inspired by this because no one company or person is 
going to make this happen.

Dahn

On 23/05/17 14:16, "Simon Weller"  wrote:

Hi everyone,


During the CCC last week in Miami, we held a roundtable/hackathon to 
discuss some of the major areas the community would like to focus more 
attention.


The discussions were passionate and were mainly focused around networking 
and our current use of our home-spun Virtual Router.


For most of the us, the VR has become a challenging beast, mainly due to 
how difficult it is to end-to-end test for new releases.

Quite often PRs are pushed that fix an issue on one feature set, but break 
another unintentionally. This has a great deal to do with how inter-mingled all 
the features are currently.


We floated some ideas related to short term VR fixes in order to make it 
more modular, as well as API driven, rather than the currently SSH JSON 
injections.

A number of possible alternatives were also brought up to see what VR 
feature coverage could be handled by other virtual appliances currently out on 
the market.


These included (but not limited to):


VyOS (current PR out there for integration via a plugin – thanks Matthew!)

Microtek (Commerical)

Openswitch/Flexswitch

Cloud Router


The second major topic of the day was related to how we want to integrate 
networking moving forward.


A fair number of individuals felt that we shouldn't be focusing so much on 
integrating network functions, but relying on other network orchestrators to 
hand this.

It was also noted that what draws a lot of people to ACS is the fact we 
have a VR and do provide these functions out of the box.


We discussed how we could standardize the network sub system to use some 
sort of queuing bus to make it easier for others projects to integrate their 
solutions.

The current plugin implementation is fairly complex and often other 
projects (or commercial entities) put it into the too hard basket, until 
someone either does it themselves or is willing to pay for the development.

Most also felt it was important to maintain a default network function that 
works out of the box so that the complexity of a full orchestrator could be 
avoided if not needed.


I'm sure I've missed some key points, so hopefully this starts a discussion 
with the entire community of where we focused next.


Thanks to all those that participated on Tuesday afternoon.


- Si




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

Re: GSoC'17

[Daan Hoogland]

On Mon, May 22, 2017 at 4:37 PM, sachin patil  wrote:
>
>> > >> According to the link you told me to enter in acs.list in source.d
>> > >> folder. Cloudstack-agent 4.9.2 is installed.  I build CS management
>> from
>> > >> code 4.10.0.0 snapshot.


You better have a look at this. Does the agent and the ms both support
(the same version of) that setup host params command? something might
have changed between 4.9.2 and 4.10 snapshot.

-- 
Daan

Re: GSoC'17

[Daan Hoogland]

Sachin, this seems more a code version issue to me than an environment issue. 
SetHostParamsCommand is not recognised as a command. Could you try this on 4.9 
branch and see if you have the same issue?

You also might want to look at the versions of gson. And if there is a jar for 
that preinstalled on the hosts or mgmt server.


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

On 21/05/17 11:46, "sachin patil"  wrote:

My setup environment
ubunut 16.04 LTS
KVM host
NFS / mysql servers

On Sun, May 21, 2017 at 3:13 PM, sachin patil 
wrote:

> Hello all,
>
>   I am a student from NITW recently selected for gsoc '17. I
> am tyring to a get a new development environment setup.
>
>
> I follwed this guide to get my setup done https://cwiki.apache.org/
> confluence/display/CLOUDSTACK/Setting+up+CloudStack+Developm
> ent+Environment+on+Linux
>
> But I am facing some error in my cloudstack agent
> agent.log files is attached below for reference.
>
> My host is forever in a connecting state and that doesn't change even
> after restarting management server or agent.
>
>
>
> how can i solve this issue?
>
> Thank you.
>
> Regards,
> Sachin Patil
>

Re: Extend CloudStack for a new hypervisor

[Daan Hoogland]

John, I never implemented one but I am about to investigate the ovm3 one to see 
if I can maintain it for a customer. I know the guy that wrote it and he says 
it’s fairly simple given the constraint of a hypervisor plugin, so I’d have a 
look at that one if I where you.

Important thing to consider is the agent concept, most hypervisors have 
directly attached agents, i.e. running in the management server. You might not 
want that and have a look at KVM as well (hyperv as alternative but that one is 
the odd man out)

This btw sounds like a strategic direction, but indeed not for cloudstack.

Hope to hear a lot about your progress ;)

On 19/05/2017, 13:36, "Erik Weber"  wrote:
I can already hear the slogan in my head "CloudStack - making
OpenStack great again" :-p

On Fri, May 19, 2017 at 12:57 PM, John Smith  wrote:
> Ok...so bear with me on this one.
>
> "Hypervisor" was a little white lie.  What I actually want to do is
> implement OpenStack as a backend for CloudStack (yo dawg, I hear you like
> cloud in your clouds, etc).  I know I can use KVM and OVS as backends for
> CloudStack natively but, as I said, this is for a project with some very
> specific needs...
>
> As OpenStack is completely API driven, I see no issues with the basics of
> communication between CS and OS.
>
> This would, of course, bypass the OS concept of Linux network namespaces
> for routing and I would implement the CS routing VM as a VM (just like in
> VMware or Xen) connected between an OS tenant network and an OS external
> network.  CS volumes would be OS volumes.  Secondary storage would be a VM
> running NFS.
>
> In principle, I see that the CS concepts of compute, network and storage
> could be implemented on OS.  I was hoping that I could basically write a
> "driver" that would do the necessary actions against OS based on standard
> calls to a CS class/method/whatever, based on some assumption that the
> underlying hypervisor in CS was at least some sort of pluggable
> architecture.
>
> Yes, this may sound a little crazy, and I did say this was probably not
> something strategic to the CloudStack direction, but for me it actually
> fits a funny shaped hole I've discovered and I'm interested in at least
> understanding how such a thing could be done.
>
> Thanks,
>
> John.
>
>
>
> On Fri, May 19, 2017 at 12:06 AM, Simon Weller 
> wrote:
>
>> Which hypervisor are you wanting to implement?
>>
>> Simon Weller/615-312-6068
>>
>> -Original Message-
>> From: John Smith [john.smith@gmail.com]
>> Received: Thursday, 18 May 2017, 5:29PM
>> To: dev@cloudstack.apache.org [dev@cloudstack.apache.org]
>> Subject: Extend CloudStack for a new hypervisor
>>
>> Greetings!
>>
>> I have a need to extend CloudStack to support an additional hypervisor.
>> This is not something I consider strategic for CloudStack itself, but I
>> have a project with a very specific need.
>>
>> I have a development background but am not an active developer right now
>> ... so looking forward to getting back in the saddle!  I've never 
developed
>> against the CloudStack tree before.
>>
>> I can't find any docs on how one would introduce support for a new
>> hypervisor (eg. what classes, methods, etc, need to be implemented,
>> extended, etc) and checking the source tree I can't easily see if there 
is
>> a base to build from.  I would appreciate any pointers about where to 
start
>> looking to save me going through the entire tree from scratch.
>>
>> The standard CloudStack concepts should be easy enough (ha!) to map 1:1 
to
>> this additional hypervisor (including primary & secondary storage, 
router &
>> secondary storage VMs, the networking concepts, etc) so I'm hoping that I
>> can simply implement it like a VMware or Xen backend ...
>>
>> Thanks in advance!
>>
>> John.
>>



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

Re: [Proposal] MaaS Integration for Baremetal Provisioning in Cloudstack

[Daan Hoogland]

Good initiative, looks nice.

On 11/05/17 16:53, "Syed Ahmed"  wrote:

Hi All,

I want to propose a new plugin in Cloudstack to enable Baremetal
provisioning using MaaS by Canonical. This will enable a lot of interesting
features some of which are

1. Advanced networking support within the same network as VMs
2. Support for multiple networks/VPC
3. Support for bonding in case of switch failure
4. Support for disk erase when destroying a baremetal VM
5. Windows support is provided by MaaS/Canonical

The FS can be found at [1]. Please let me know what you guys think. I'm
eager for your feedback. I will open the PR in a day or two for this.

[1]:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/MaaS+Integration+for+Baremetal+Provisioning+in+Cloudstack

Thanks,
-Syed



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

Re: [PROPOSAL] branch on first RC and open up master for features

[Daan Hoogland]

As far as I remember only 4.4 and the commercial 3.x series were releases that 
way.

On 09/05/17 08:25, "Erik Weber" <terbol...@gmail.com> wrote:

On Mon, May 8, 2017 at 10:40 AM, Daan Hoogland
<daan.hoogl...@shapeblue.com> wrote:
> LS,
>
> In a lot of occasions, we have seen new features that are waiting for 
releases with blocker bugs and while these bugs certainly must be solved, users 
that are not hindered by those bugs directly are stopped by them. Therefore, I 
propose we will fork on the first RC branches for future releases, so that 
development is not stopped for it. If the release process takes too long and to 
nice features get merged in between we can always decide to re-branch before 
releasing.


I might be misunderstanding, but isn't your proposal more or less how
we used to do releases back in the day?

-- 
Erik



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

Re: [PROPOSAL] branch on first RC and open up master for features

[Daan Hoogland]

But these two points of attention are not mutually exclusive, are they?

On 08/05/17 12:50, "Rajani Karuturi" <raj...@apache.org> wrote:

I disagree. The release process is taking long because we dont
have enough people working on the release. Sometimes, even the
blockers don't get enough attention. There is no point in adding
features on already broken/blocked master which is not
releasable. "un-freezing" master for new features shouldn't be
the goal in my opinion. We should move towards faster
releases/release cycles.

Thanks,

~ Rajani

http://cloudplatform.accelerite.com/

On May 8, 2017 at 2:11 PM, Daan Hoogland
(daan.hoogl...@shapeblue.com) wrote:

LS,

In a lot of occasions, we have seen new features that are
waiting for releases with blocker bugs and while these bugs
certainly must be solved, users that are not hindered by those
bugs directly are stopped by them. Therefore, I propose we will
fork on the first RC branches for future releases, so that
development is not stopped for it. If the release process takes
too long and to nice features get merged in between we can always
decide to re-branch before releasing.

Thoughts..?
Daan

daan.hoogl...@shapeblue.com
www.shapeblue.com ( http://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
  
 

[PROPOSAL] branch on first RC and open up master for features

[Daan Hoogland]

LS,

In a lot of occasions, we have seen new features that are waiting for releases 
with blocker bugs and while these bugs certainly must be solved, users that are 
not hindered by those bugs directly are stopped by them. Therefore, I propose 
we will fork on the first RC branches for future releases, so that development 
is not stopped for it. If the release process takes too long and to nice 
features get merged in between we can always decide to re-branch before 
releasing.

Thoughts..?
Daan

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

Re: Very slow Virtual Router provisioning with 4.9.2.0

[Daan Hoogland]

As far as I can tell there was a missing license header and no license issue at 
all. On the other hand, both didn’t pass Jenkins or travis and I did not 
analyse the code fully enough so I could do with intensive review. Both having 
failed and their warranty at merge.

https://github.com/apache/cloudstack/pull/2083
https://github.com/apache/cloudstack/pull/2084

On 04/05/17 13:33, "Wido den Hollander" <w...@widodh.nl> wrote:

Here we go: https://github.com/apache/cloudstack/pull/2077

That works really well for us. 70% less DHCP entries in our VR in Basic 
Networking since only the entries for that POD are send to the VR.

Wido

> Op 4 mei 2017 om 12:12 schreef Wido den Hollander <w...@widodh.nl>:
> > Op 4 mei 2017 om 11:11 schreef Wei ZHOU <ustcweiz...@gmail.com>:
> > > 2017-05-04 10:48 GMT+02:00 Wido den Hollander <w...@widodh.nl>:
> > > > Op 3 mei 2017 om 14:49 schreef Daan Hoogland 
<daan.hoogl...@gmail.com>:
 
> > > > Happy to pick this up, Remi. I'm travelling now but will look at 
both on
> > > > Friday.
> > > > On 3 May 2017 2:25 pm, "Remi Bergsma" <rberg...@schubergphilis.com>
> > > > > On 03/05/2017, 13:44, "Rohit Yadav" <rohit.ya...@shapeblue.com> wrote:
> > > > > From: Remi Bergsma <rberg...@schubergphilis.com>
> > > > > Sent: 03 May 2017 16:58:18
> > > > > To: dev@cloudstack.apache.org
> > > > > Subject: Re: Very slow Virtual Router provisioning with 
4.9.2.0
> > > > >
> > > > > Hi,
> > > > >
> > > > > The patches I talked about:
> > > > >
> > > > > 1) Iptables speed improvement
> > > > > https://github.com/apache/cloudstack/pull/1482
> > > > > Was reverted due to a licensing issue.
> > > > >
> > > > > 2) Passwd speed improvement
> > > > > https://github.com/MissionCriticalCloudOldRepos/
> > > cosmic-core/pull/138
> > > > >
> > > > > By now, these are rather old patches so they need some work 
before
> > > > > they apply to CloudStack again.
> > > > >
 


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

Re: GSoC'17

[Daan Hoogland]

Have fun Sachin,

May you come up with the most flexible, extensible, pluggable, configurable 
addition to our project ever ;)


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

On 05/05/17 17:49, "sachin patil"  wrote:

Hello all,

   I have been selected for GSoC'17 and would be working on
CloudStack-9778 (
 Adding a new NoVNC console ).

The aim of this feature is to make it possible to connect to VM consoles
using  VNC client called NoVNC in browsers.

NoVNC console is better than our current customized console. Additional
features that NoVNC provides over the current customized console include a
copy/paste functionality, scrollback. NoVNC uses websockets that provides a
more reliable and secure connections.

My proposal can be found here

https://docs.google.com/document/d/1IqJiZ_sJZktAoPjdQePoinBNZzPboR1jCkUXBpqanjo/edit

I have been selected for this project with my mentors Rohit Yadav and Syed
Ahmed.

Would like to know about your thoughts/ideas on this project.

Regards,
Sachin Patil

Re: Very slow Virtual Router provisioning with 4.9.2.0

[Daan Hoogland]

Happy to pick this up, Remi. I'm travelling now but will look at both on
Friday.

Biligual auto correct use.  Read at your own risico

On 3 May 2017 2:25 pm, "Remi Bergsma"  wrote:

> Always happy to share, but I won’t have time to work on porting this to
> CloudStack any time soon.
>
> Regards, Remi
>
>
> On 03/05/2017, 13:44, "Rohit Yadav"  wrote:
>
> Hi Remi, thanks for sharing. We would love to have those changes (for
> 4.9+), looking forward to your pull requests.
>
>
> Regards.
>
> 
> From: Remi Bergsma 
> Sent: 03 May 2017 16:58:18
> To: dev@cloudstack.apache.org
> Subject: Re: Very slow Virtual Router provisioning with 4.9.2.0
>
> Hi,
>
> The patches I talked about:
>
> 1) Iptables speed improvement
> https://github.com/apache/cloudstack/pull/1482
> Was reverted due to a licensing issue.
>
> 2) Passwd speed improvement
> https://github.com/MissionCriticalCloudOldRepos/cosmic-core/pull/138
>
> By now, these are rather old patches so they need some work before
> they apply to CloudStack again.
>
> Regards, Remi
>
>
>
> On 03/05/2017, 12:49, "Jeff Hair"  wrote:
>
> Hi Remi,
>
> Do you have a link to the PR that was reverted? And also possibly
> the code
> that makes the password updating more efficient?
>
> Jeff
>
> On Wed, May 3, 2017 at 10:36 AM, Remi Bergsma <
> rberg...@schubergphilis.com>
> wrote:
>
> > Hi Wido,
> >
> > When we had similar issues last year, we found that for example
> comparing
> > the iptables rules one-by-one is 1000x slower than simply
> loading them all
> > at once. Boris rewrote this part in our Cosmic fork, may be
> worth looking
> > into this again. The PR to CloudStack was merged, but reverted
> later, can't
> > remember why. We run it in production ever since. Also feeding
> passwords to
> > the passwd server is very inefficient (it operates like a
> snowball and gets
> > slower once you have more VMs). That we also fixed in Cosmic,
> not sure if
> > that patch made it upstream. Wrote it about a year ago already.
> >
> > We tested applying 10K iptables rules in just a couple of
> seconds. 1000
> > VMs takes a few minutes to deploy.
> >
> > Generally speaking I'd suggest looking at the logs to find what
> takes long
> > or is executed a lot of times. Iptables and passwd are two to
> look at.
> >
> > If you want I can lookup the patches. Not handy on my phone now
> ;-)
> >
> > Regards, Remi
> > 
> > From: Wido den Hollander 
> > Sent: Tuesday, May 2, 2017 7:57:08 PM
> > To: dev@cloudstack.apache.org
> > Subject: Very slow Virtual Router provisioning with 4.9.2.0
> >
> > Hi,
> >
> > Last night I upgraded a CloudStack 4.5.2 setup to 4.9.2.0. All
> went well,
> > but the VR provisioning is terribly slow which causes all kinds
> of problems.
> >
> > The vr_cfg.sh and update_config.py scripts start to run. Restart
> dnsmasq,
> > add metadata, etc.
> >
> > But for just 1800 hosts this can take up to 2 hours and that
> causes
> > timeouts in the management server and other problems.
> >
> > 2 hours is just very, very slow. So I am starting to wonder if
> something
> > is wrong here.
> >
> > Did anybody else see this?
> >
> > Running Basic Networking with CloudStack 4.9.2.0
> >
> > Wido
> >
>
>
>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>
>
>

Re: Github messages on dev list

[Daan Hoogland]

Sorry to poop the party late but I am really opposed to commits@clo… To me this 
one is only for commits on potential release branches not for all the work in 
progress. I’d rather see either a separate list or people subscribing 
themselves to PRs on github.

I do agree the dev@ is polluted and could do without. On the other hand 
technical decisions tend to move to github and so a mirror on dev@ makes sense.

Hate me!

On 30/04/17 20:09, "Wido den Hollander"  wrote:


> Op 28 april 2017 om 10:24 schreef Rene Moser :
> 
> 
> Hi Wido
> 
> There have been messages from github in the past (you probably had a
> filter?). I already wrote I don't like it and suggested to use
> comm...@cloudstack.apache.org for automated and bot messages.
> 
> But a few devs insisted they like to keep them here that filtering would
> be an option (for all others). So I created a filter (although I still
> thing my suggestion would be the cleaner solution). The filter is not
> matching anymore, I also have to adjust it.
> 
> I am still +1 for moving them to commits@ and whoever needs them can
> subscribe to this list. Opt-In.
> 

Yes, let me ask for that at infra. The commits list seems like the right 
place for this.

I rather don't filter any messages since it might scare people away from 
the dev list when they get so many messages.

Wido

> René
> 
> On 04/28/2017 08:28 AM, Wido den Hollander wrote:
> > Hi,
> > 
> > See: https://issues.apache.org/jira/browse/INFRA-13929
> > 
> > We are now getting all these messages from Github on 
dev@cloudstack.apache.org
> > 
> > We didn't have this before. Do we want this?
> > 
> > Personally I find it very annoying that my inbox now gets so many 
messages from Github.
> > 
> > Anybody else feeling that way?
> > 
> > Wido
> >



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

Re: :[VOTE] Apache Cloudstack 4.10.0.0

[Daan Hoogland]

I rebased that last one. I don’t think this is still a blocker.

On 19/04/17 12:39, "Rajani Karuturi"  wrote:

CLOUDSTACK-9408 - remove runtime references to
http://download.cloud.com

Thanks,

~Rajani



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

Re: [Github/Gitbox] Setting up your committer account

[Daan Hoogland]

Paul if we put effort in automation we should do so using the review 
functionality of github, where you can approve a PR

On 16/04/17 09:45, "Paul Angus"  wrote:

That’s in progress...
It would be cool if we could parse comments for LGTM and OK to Merge so 
that we can have them as status labels.

Otherwise a manual process of updating a status would still be great. 



Kind regards,

Paul Angus

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


-Original Message-
From: Wido den Hollander [mailto:w...@widodh.nl] 
Sent: 15 April 2017 11:30
To: dev@cloudstack.apache.org
Subject: [Github/Gitbox] Setting up your committer account

Hi,

Since yesterday we are using the Gitbox [0] services from ASF to have 
Github our 'primary' source of code.

This means that we can now label PRs, merge them, close them, all on Github.

If you are a committer you have to be added to the 'cloudstack committers' 
team on Github and this is done automatically [1] once every X hours.

You however need to make sure that your Apache Profile/ID [2] has the right 
information and that you have 2FA [3] enabled on your Github account.

The steps you need to take:

- Make sure you are a CloudStack committer
- Make sure you have a Github account
- Enable 2FA [3] on your Github account
- Update your Apache profile [2] and add your Github username

Now, after a few hours the sync between ASF and Github should be completed 
and you are added to the right team on Github.

If that doesn't work you might need to visit the Gitbox setup page [4] to 
link your Apache account to Github.

Since we moved to Gitbox the URL of our Git repositories also changed, for 
example:

- https://gitbox.apache.org/repos/asf/cloudstack.git

If you want RO you can also sync from Github:

- https://github.com/apache/cloudstack.git


Once you are in the right group on Github you should be able to label PRs, 
close them, merge them and move.

I have already created [5] a bunch of labels. If we all try to label the 
PRs it will be much easier for people to filter PRs and review them.

Questions? Ask!

Wido

[0]: https://gitbox.apache.org/
[1]: https://issues.apache.org/jira/browse/INFRA-13885
[2]: https://id.apache.org/
[3]: https://help.github.com/articles/about-two-factor-authentication/
[4]: https://gitbox.apache.org/setup/
[5]: https://github.com/apache/cloudstack/labels



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

Re: [DISCUSS][PROPOSAL] CA authority plugin definition

[Daan Hoogland]

Simon, I can think of use cases for that and it is an interesting topic. I can 
also see it as being implemented in a CA-plugin. I do not think it should be in 
the base of this framework though. That would complicate cloudstack for simple 
users to much I think. On the other hand, it would have more use cases then 
just for CA-plugins (fantasy running now)

On 14/04/17 16:57, "Simon Weller" <swel...@ena.com> wrote:

Daan,


What about integrating some like Vault (https://github.com/hashicorp/vault)?


- Si

____
From: Daan Hoogland <daan.hoogl...@shapeblue.com>
Sent: Friday, April 14, 2017 5:46 AM
To: dev@cloudstack.apache.org
Subject: [DISCUSS][PROPOSAL] CA authority plugin definition

Devs,

Following a discussion with a client they came up with the idea to create a 
pluggable CA-framework. A plugin would serve components in cloudstack that so 
require (management servers, agents, load balancers, SVMs, etc.) with 
certificates answering certificate requests and validating certificates on 
request.

A default plugin can be written that serves according to its own self 
signed root certificate and have its own revocation list to be managed by the 
admin. Other plugin could forward by mail or web requests to external parties.

A CA-plugin will have to

-  Setup, for the default this means creating its certificate, for 
others it might mean install an intermediate certificate or configure a mail, 
or website address.

-  Accept and answer certificate requests

oFor client certificates

oFor server certificates

-  Accept revocation requests

-  Validate a connection request according to origin and 
certificate and . What extra data is is defined by the plugin and 
can be credentials or field-definitions referring the x509 entries or for 
instance port numbers allowed… this is basically free to the implementer.

A next step will have to be integrating the request calls with installs on 
targets but I think as is this feature merits itself as it could be used with 
out of band configuration management tools as well.

Any thoughts, remarks and critiques are welcome,

daan.hoogl...@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
Shapeblue - The CloudStack Company<http://www.shapeblue.com/>
www.shapeblue.com
Background Cloudstack relies on a fixed download site when it fetches the 
built-in guest VM templates. That download site has historically



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
  
 

[DISCUSS][PROPOSAL] CA authority plugin definition

[Daan Hoogland]

Devs,

Following a discussion with a client they came up with the idea to create a 
pluggable CA-framework. A plugin would serve components in cloudstack that so 
require (management servers, agents, load balancers, SVMs, etc.) with 
certificates answering certificate requests and validating certificates on 
request.

A default plugin can be written that serves according to its own self signed 
root certificate and have its own revocation list to be managed by the admin. 
Other plugin could forward by mail or web requests to external parties.

A CA-plugin will have to

-  Setup, for the default this means creating its certificate, for 
others it might mean install an intermediate certificate or configure a mail, 
or website address.

-  Accept and answer certificate requests

oFor client certificates

oFor server certificates

-  Accept revocation requests

-  Validate a connection request according to origin and certificate 
and . What extra data is is defined by the plugin and can be 
credentials or field-definitions referring the x509 entries or for instance 
port numbers allowed… this is basically free to the implementer.

A next step will have to be integrating the request calls with installs on 
targets but I think as is this feature merits itself as it could be used with 
out of band configuration management tools as well.

Any thoughts, remarks and critiques are welcome,

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

Re: [VOTE] Apache Cloudstack should join the gitbox experiment.

[Daan Hoogland]

Thanks Wido

On 13/04/17 11:06, "Wido den Hollander" <w...@widodh.nl> wrote:

Hi All,

As there were no objections from committers nor PMC members I went ahead 
and filed a ticket with Infra: https://issues.apache.org/jira/browse/INFRA-13885

Waiting for their response and will update if I have more information 
regarding this move.

Wido

> Op 10 april 2017 om 18:22 schreef Daan Hoogland <daan.hoogl...@gmail.com>:
> 
> 
> In the Apache foundation an experiment has been going on to host
> mirrors of Apache project on github with more write access then just
> to the mirror-bot. For those projects committers can merge on github
> and put labels on PRs.
> 
> I move to have the project added to the gitbox experiment
> please cast your votes
> 
> +1 CloudStack should be added to the gitbox experiment
> +-0 I don't care
> -1 CloudStack shouldn't be added to the gitbox experiment and give your 
reasons
> 
> thanks,
> -- 
> Daan



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

Re: growing #threads problem

[Daan Hoogland]

I found the bug that let me to encounter this behaviour. I’ll keep an eye on 
this after I fixed it (simple stupid NPE). I don’t think it is a big problem as 
the DirectAgentCronJobs are maximised to 500 by default. Still strange that it 
keeps growing in a rather silent environment though.

On 11/04/17 13:11, "Daan Hoogland" <daan.hoogl...@shapeblue.com> wrote:

Nproc == -1 , both soft and hard so unless this is inherited from VMs in 
nested environments this can’t be the problem

Also no strange unexpected exceptions found, only failed connections to 
hosts during startup and environment configuration.

On 11/04/17 12:01, "Koushik Das" <koushik@accelerite.com> wrote:

Check the MS logs to see if there are OOM exceptions due to threads not 
available. If that’s the case then you may have to adjust nproc limits in 
/etc/security/limits.conf.


    On 11/04/17, 1:11 PM, "Daan Hoogland" <daan.hoogl...@shapeblue.com> 
wrote:

My next step is to rebase my change to 4.9 and see if that works. 
But that is a stab in the dark I must admit.
    
On 11/04/17 09:30, "Daan Hoogland" <daan.hoogl...@shapeblue.com> 
wrote:

Devs,

While I am creating a runnable tob e scheduled I ran into a 
problem. My scheduledJob nevers gets called and looking at the process the 
number of threads of type “DirectAgent-*” and “DirectAgentCronJob-*” keep 
growing. My job is scanning for templates in the primary storage and references 
to it in the database, so it seems to be unrelated. This is a 4.10 vmware based 
nested environment. Has anyone seen such a behaviour? I am still looking but I 
hope I won’t be reporting a blocker for 4.10 on this….

Any clue is welcome at this point,

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
  
 






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.



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
  
 

Re: growing #threads problem

[Daan Hoogland]

Nproc == -1 , both soft and hard so unless this is inherited from VMs in nested 
environments this can’t be the problem

Also no strange unexpected exceptions found, only failed connections to hosts 
during startup and environment configuration.

On 11/04/17 12:01, "Koushik Das" <koushik@accelerite.com> wrote:

Check the MS logs to see if there are OOM exceptions due to threads not 
available. If that’s the case then you may have to adjust nproc limits in 
/etc/security/limits.conf.


On 11/04/17, 1:11 PM, "Daan Hoogland" <daan.hoogl...@shapeblue.com> wrote:

My next step is to rebase my change to 4.9 and see if that works. But 
that is a stab in the dark I must admit.
    
    On 11/04/17 09:30, "Daan Hoogland" <daan.hoogl...@shapeblue.com> wrote:

Devs,

While I am creating a runnable tob e scheduled I ran into a 
problem. My scheduledJob nevers gets called and looking at the process the 
number of threads of type “DirectAgent-*” and “DirectAgentCronJob-*” keep 
growing. My job is scanning for templates in the primary storage and references 
to it in the database, so it seems to be unrelated. This is a 4.10 vmware based 
nested environment. Has anyone seen such a behaviour? I am still looking but I 
hope I won’t be reporting a blocker for 4.10 on this….

Any clue is welcome at this point,

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
  
 






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.



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

Re: growing #threads problem

[Daan Hoogland]

My next step is to rebase my change to 4.9 and see if that works. But that is a 
stab in the dark I must admit.

On 11/04/17 09:30, "Daan Hoogland" <daan.hoogl...@shapeblue.com> wrote:

Devs,

While I am creating a runnable tob e scheduled I ran into a problem. My 
scheduledJob nevers gets called and looking at the process the number of 
threads of type “DirectAgent-*” and “DirectAgentCronJob-*” keep growing. My job 
is scanning for templates in the primary storage and references to it in the 
database, so it seems to be unrelated. This is a 4.10 vmware based nested 
environment. Has anyone seen such a behaviour? I am still looking but I hope I 
won’t be reporting a blocker for 4.10 on this….

Any clue is welcome at this point,

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
  
 

growing #threads problem

[Daan Hoogland]

Devs,

While I am creating a runnable tob e scheduled I ran into a problem. My 
scheduledJob nevers gets called and looking at the process the number of 
threads of type “DirectAgent-*” and “DirectAgentCronJob-*” keep growing. My job 
is scanning for templates in the primary storage and references to it in the 
database, so it seems to be unrelated. This is a 4.10 vmware based nested 
environment. Has anyone seen such a behaviour? I am still looking but I hope I 
won’t be reporting a blocker for 4.10 on this….

Any clue is welcome at this point,

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