CPU Sockets and Cores

[Michael Phillips]

All,
   The following pertains to cloudstack + vmware. Currently when using a multi 
CPU compute service offering, cloudstack creates the CPUs on the vm using all 
sockets. This can be an issue for operating systems that have physical CPU 
sockets limits. It can also be a license issue for certain software as well. An 
easy work around would be to let the admin define the socket to core ratio in 
the compute service offering. Are there in plans to implement such a feature in 
any upcoming cloudstack releases?

  

Re: [PROPOSAL] Move to github PR only during moratorium on commit

[Daan Hoogland]

At the moment it must be called 'hotfix/*' or 'bugfix/*'. we should
add 'feature/*' to that.

On Fri, Oct 24, 2014 at 11:11 PM, Mike Tutkowski
 wrote:
> Cool...so, it sounds like any branch we create in the repo will
> automatically have CI run against it post each commit.
>
> How do you know when CI has completed and what the results are?
>
> At that point, you could treat your own branch (as Daan says) as the
> "forward" branch. Once CI has been successful, you can merge your code to,
> say, 4.5 (or the RM can).
>
> We then need a protocol for when we merge to 4.5 from our own branch, but
> don't want to have those changes in master.
>
> If we do want those changes, of course we can just merge from 4.5 to master.
>
> On Fri, Oct 24, 2014 at 2:45 PM, Daan Hoogland 
> wrote:
>
>> We do run ci on branches!
>>
>> mobile dev with bilingual spelling checker used (read at your own risk)
>> Op 24 okt. 2014 20:38 schreef "Mike Tutkowski" <
>> mike.tutkow...@solidfire.com
>> >:
>>
>> > Right, we just need to make sure CI comes into play before the merge.
>> >
>> > Hence my earlier reply to what Daan mention:
>> >
>> > "My main concern was CI running before the code was checked into the
>> "real"
>> > branch from the staging branch."
>> >
>> > On Fri, Oct 24, 2014 at 12:28 PM, David Nalley  wrote:
>> >
>> > > On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland <
>> daan.hoogl...@gmail.com>
>> > > wrote:
>> > > > Mike, Why have everybody work on the same branch. people can work on
>> > > > their own branch and when they are done they can rebase on the tip
>> see
>> > > > ci success and then merge. The problem with forward branches is
>> > > > abandoned work or work that for some reason shouldn't go in 'this'
>> > > > release. it will remain there.
>> > > >
>> > >
>> > > CI really needs to happen before the merge occurs, IMO. Backing out
>> > > merges, in my experience, is incredibly painful. And typically this
>> > > means that someone else is going to have to clean up the mess after
>> > > someone merges.
>> > >
>> >
>> >
>> >
>> > --
>> > *Mike Tutkowski*
>> > *Senior CloudStack Developer, SolidFire Inc.*
>> > e: mike.tutkow...@solidfire.com
>> > o: 303.746.7302
>> > Advancing the way the world uses the cloud
>> > *™*
>> >
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*



-- 
Daan

Re: vm.password.length issue in 4.4.1-SNAPSHOT

[Ian Duffy]

>  I agree adding 3 characters is a bug and willing to fix it.

Me too.. I find it very worrying that the code base has tests that
cater for bugs to be valid input.
Really makes me wonder about the quality of the product.

Anyways... I did a grep of the codebase for usage of the method. Its not
used anywhere else... (Which does make me wonder why it existed in the
first place and if its functionality has been duplicated else where)

>  Any objections to setting the minimum to 8, the previous default?

No objections from me.

On 25 October 2014 01:41, Amogh Vasekar  wrote:

> Do note that the password generated here is considered temporary, as
> previously pointed out by Chiradeep in another thread.
>
> Thanks
> Amogh
>
> On 10/24/14 5:31 PM, "Nux!"  wrote:
>
> >Imho, considering the password is not very secure (it's missing symbols),
> >we should increase the length.
> >For my personal stuff I default to 15 chars.
> >
> >--
> >Sent from the Delta quadrant using Borg technology!
> >
> >Nux!
> >www.nux.ro
> >
> >- Original Message -
> >> From: "Amogh Vasekar" 
> >> To: dev@cloudstack.apache.org
> >> Cc: "laszlo hornyak" 
> >> Sent: Saturday, 25 October, 2014 00:37:07
> >> Subject: Re: vm.password.length issue in 4.4.1-SNAPSHOT
> >
> >> Hi Laszlo,
> >>
> >> Any comments on the below? I agree adding 3 characters is a bug and
> >> willing to fix it.
> >>
> >> In addition, Ian, I believe we should set a minimum allowed value for
> >>the
> >> config value vm.password.length. Any objections to setting the minimum
> >>to
> >> 8, the previous default?
> >>
> >> Thanks
> >> Amogh
> >>
> >> On 10/13/14 5:34 PM, "Ian Duffy"  wrote:
> >>
> >>>The only other usage of it is within
> >>>server/src/com/cloud/server/ConfigurationServerImpl.java
> >>>Its used for creating a Secondary storage vm copy password.
> >>>
> >>>I'm seeing absolutely no reason why we have 3 values going in no matter
> >>>what, I'm willing to say its a bug. I'm curious to why the tests are
> >>>written to deal with it though
> >>>
> >>>On 14 October 2014 00:26, Nux!  wrote:
> >>>
>  Well, it's a bit messy, but still better than the old password length.
>  Ideally this should get clarified/fixed, but for now I am happy with
> my
>  long+3 password! :)
> 
> 
>  Cheers,
>  Lucian
> 
>  --
>  Sent from the Delta quadrant using Borg technology!
> 
>  Nux!
>  www.nux.ro
> 
>  - Original Message -
>  > From: "Ian Duffy" 
>  > To: "CloudStack Dev" 
>  > Cc: "laszlo hornyak" 
>  > Sent: Monday, 13 October, 2014 19:54:53
>  > Subject: Re: vm.password.length issue in 4.4.1-SNAPSHOT
> 
>  > Hey Nux,
>  >
>  > So I passed this work off to a util class that was already present
> in
> the
>  > code base "PasswordGenerator"
>  >
>  >@Override
>  >public String generateRandomPassword() {
>  >Integer passwordLength =
>  > Integer.parseInt(_configDao.getValue("vm.password.length"));
>  >return
> PasswordGenerator.generateRandomPassword(passwordLength);
>  >}
>  >
>  > Not a clue why but the generateRandomPassword method creates a
> random
>  > 3-character string first then loops through to generate n random
>  characters.
>  >
>  >public static String generateRandomPassword(int num) {
>  >Random r = new SecureRandom();
>  >StringBuilder password = new StringBuilder();
>  >
>  >// Generate random 3-character string with a lowercase
> character,
>  >// uppercase character, and a digit
>  >
>  >
> 
> password.append(generateLowercaseChar(r)).append(generateUppercaseChar(
> r)
> ).append(generateDigit(r));
>  >
>  >// Generate a random n-character string with only lowercase
>  >// characters
>  >for (int i = 0; i < num; i++) {
>  >password.append(generateLowercaseChar(r));
>  >}
>  >
>  >return password.toString();
>  >}
>  >
>  > The unit tests seem to accommodate for this aswell:
>  >
>  >// actual length is requested length + 3
>  >
>  >
> Assert.assertTrue(PasswordGenerator.generateRandomPassword(0).length()
> ==
>  > 3);
>  >
>  >
> Assert.assertTrue(PasswordGenerator.generateRandomPassword(1).length()
> ==
>  > 4);
>  >
>  > I'm guessing there's some reasoning for this CCing Laszlo who
>  according
>  > to git log did some work on this class.
>  >
>  > Thanks,
>  >
>  > Ian
>  >
>  > On 13 October 2014 19:39, Nux!  wrote:
>  >
>  >> Hello,
>  >>
>  >> First of all "THANKS!" to whoever made this feature happen (Ian I
>  guess).
>  >> Now we can set more secure passwords generated for our instances.
>  >>
>  >> Second, the feature works, but

Re: vm.password.length issue in 4.4.1-SNAPSHOT

[Amogh Vasekar]

Do note that the password generated here is considered temporary, as
previously pointed out by Chiradeep in another thread.

Thanks
Amogh

On 10/24/14 5:31 PM, "Nux!"  wrote:

>Imho, considering the password is not very secure (it's missing symbols),
>we should increase the length.
>For my personal stuff I default to 15 chars.
>
>--
>Sent from the Delta quadrant using Borg technology!
>
>Nux!
>www.nux.ro
>
>- Original Message -
>> From: "Amogh Vasekar" 
>> To: dev@cloudstack.apache.org
>> Cc: "laszlo hornyak" 
>> Sent: Saturday, 25 October, 2014 00:37:07
>> Subject: Re: vm.password.length issue in 4.4.1-SNAPSHOT
>
>> Hi Laszlo,
>> 
>> Any comments on the below? I agree adding 3 characters is a bug and
>> willing to fix it.
>> 
>> In addition, Ian, I believe we should set a minimum allowed value for
>>the
>> config value vm.password.length. Any objections to setting the minimum
>>to
>> 8, the previous default?
>> 
>> Thanks
>> Amogh
>> 
>> On 10/13/14 5:34 PM, "Ian Duffy"  wrote:
>> 
>>>The only other usage of it is within
>>>server/src/com/cloud/server/ConfigurationServerImpl.java
>>>Its used for creating a Secondary storage vm copy password.
>>>
>>>I'm seeing absolutely no reason why we have 3 values going in no matter
>>>what, I'm willing to say its a bug. I'm curious to why the tests are
>>>written to deal with it though
>>>
>>>On 14 October 2014 00:26, Nux!  wrote:
>>>
 Well, it's a bit messy, but still better than the old password length.
 Ideally this should get clarified/fixed, but for now I am happy with
my
 long+3 password! :)


 Cheers,
 Lucian

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
 > From: "Ian Duffy" 
 > To: "CloudStack Dev" 
 > Cc: "laszlo hornyak" 
 > Sent: Monday, 13 October, 2014 19:54:53
 > Subject: Re: vm.password.length issue in 4.4.1-SNAPSHOT

 > Hey Nux,
 >
 > So I passed this work off to a util class that was already present
in
the
 > code base "PasswordGenerator"
 >
 >@Override
 >public String generateRandomPassword() {
 >Integer passwordLength =
 > Integer.parseInt(_configDao.getValue("vm.password.length"));
 >return
PasswordGenerator.generateRandomPassword(passwordLength);
 >}
 >
 > Not a clue why but the generateRandomPassword method creates a
random
 > 3-character string first then loops through to generate n random
 characters.
 >
 >public static String generateRandomPassword(int num) {
 >Random r = new SecureRandom();
 >StringBuilder password = new StringBuilder();
 >
 >// Generate random 3-character string with a lowercase
character,
 >// uppercase character, and a digit
 >
 >
 
password.append(generateLowercaseChar(r)).append(generateUppercaseChar(
r)
).append(generateDigit(r));
 >
 >// Generate a random n-character string with only lowercase
 >// characters
 >for (int i = 0; i < num; i++) {
 >password.append(generateLowercaseChar(r));
 >}
 >
 >return password.toString();
 >}
 >
 > The unit tests seem to accommodate for this aswell:
 >
 >// actual length is requested length + 3
 >
 > 
Assert.assertTrue(PasswordGenerator.generateRandomPassword(0).length()
==
 > 3);
 >
 > 
Assert.assertTrue(PasswordGenerator.generateRandomPassword(1).length()
==
 > 4);
 >
 > I'm guessing there's some reasoning for this CCing Laszlo who
 according
 > to git log did some work on this class.
 >
 > Thanks,
 >
 > Ian
 >
 > On 13 October 2014 19:39, Nux!  wrote:
 >
 >> Hello,
 >>
 >> First of all "THANKS!" to whoever made this feature happen (Ian I
 guess).
 >> Now we can set more secure passwords generated for our instances.
 >>
 >> Second, the feature works, but with a small glitch, the number
seems
to
 be
 >> affected by some sort of offset. I.e. if I set the password to be
15
 chars
 >> in length then the generated password will actually be 18 chars.
 >> In order to get a 15 chars long passwd I had to set
vm.password.length
 to
 >> 12. Bug or feature? :)
 >>
 >>
 >> Lucian
 >>
 >> --
 >> Sent from the Delta quadrant using Borg technology!
 >>
 >> Nux!
 >> www.nux.ro

Re: vm.password.length issue in 4.4.1-SNAPSHOT

[Nux!]

Imho, considering the password is not very secure (it's missing symbols), we 
should increase the length.
For my personal stuff I default to 15 chars.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Amogh Vasekar" 
> To: dev@cloudstack.apache.org
> Cc: "laszlo hornyak" 
> Sent: Saturday, 25 October, 2014 00:37:07
> Subject: Re: vm.password.length issue in 4.4.1-SNAPSHOT

> Hi Laszlo,
> 
> Any comments on the below? I agree adding 3 characters is a bug and
> willing to fix it.
> 
> In addition, Ian, I believe we should set a minimum allowed value for the
> config value vm.password.length. Any objections to setting the minimum to
> 8, the previous default?
> 
> Thanks
> Amogh
> 
> On 10/13/14 5:34 PM, "Ian Duffy"  wrote:
> 
>>The only other usage of it is within
>>server/src/com/cloud/server/ConfigurationServerImpl.java
>>Its used for creating a Secondary storage vm copy password.
>>
>>I'm seeing absolutely no reason why we have 3 values going in no matter
>>what, I'm willing to say its a bug. I'm curious to why the tests are
>>written to deal with it though
>>
>>On 14 October 2014 00:26, Nux!  wrote:
>>
>>> Well, it's a bit messy, but still better than the old password length.
>>> Ideally this should get clarified/fixed, but for now I am happy with my
>>> long+3 password! :)
>>>
>>>
>>> Cheers,
>>> Lucian
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>>
>>> - Original Message -
>>> > From: "Ian Duffy" 
>>> > To: "CloudStack Dev" 
>>> > Cc: "laszlo hornyak" 
>>> > Sent: Monday, 13 October, 2014 19:54:53
>>> > Subject: Re: vm.password.length issue in 4.4.1-SNAPSHOT
>>>
>>> > Hey Nux,
>>> >
>>> > So I passed this work off to a util class that was already present in
>>>the
>>> > code base "PasswordGenerator"
>>> >
>>> >@Override
>>> >public String generateRandomPassword() {
>>> >Integer passwordLength =
>>> > Integer.parseInt(_configDao.getValue("vm.password.length"));
>>> >return
>>>PasswordGenerator.generateRandomPassword(passwordLength);
>>> >}
>>> >
>>> > Not a clue why but the generateRandomPassword method creates a random
>>> > 3-character string first then loops through to generate n random
>>> characters.
>>> >
>>> >public static String generateRandomPassword(int num) {
>>> >Random r = new SecureRandom();
>>> >StringBuilder password = new StringBuilder();
>>> >
>>> >// Generate random 3-character string with a lowercase
>>>character,
>>> >// uppercase character, and a digit
>>> >
>>> >
>>> 
>>>password.append(generateLowercaseChar(r)).append(generateUppercaseChar(r)
>>>).append(generateDigit(r));
>>> >
>>> >// Generate a random n-character string with only lowercase
>>> >// characters
>>> >for (int i = 0; i < num; i++) {
>>> >password.append(generateLowercaseChar(r));
>>> >}
>>> >
>>> >return password.toString();
>>> >}
>>> >
>>> > The unit tests seem to accommodate for this aswell:
>>> >
>>> >// actual length is requested length + 3
>>> >
>>> > 
>>>Assert.assertTrue(PasswordGenerator.generateRandomPassword(0).length() ==
>>> > 3);
>>> >
>>> > 
>>>Assert.assertTrue(PasswordGenerator.generateRandomPassword(1).length() ==
>>> > 4);
>>> >
>>> > I'm guessing there's some reasoning for this CCing Laszlo who
>>> according
>>> > to git log did some work on this class.
>>> >
>>> > Thanks,
>>> >
>>> > Ian
>>> >
>>> > On 13 October 2014 19:39, Nux!  wrote:
>>> >
>>> >> Hello,
>>> >>
>>> >> First of all "THANKS!" to whoever made this feature happen (Ian I
>>> guess).
>>> >> Now we can set more secure passwords generated for our instances.
>>> >>
>>> >> Second, the feature works, but with a small glitch, the number seems
>>>to
>>> be
>>> >> affected by some sort of offset. I.e. if I set the password to be 15
>>> chars
>>> >> in length then the generated password will actually be 18 chars.
>>> >> In order to get a 15 chars long passwd I had to set
>>>vm.password.length
>>> to
>>> >> 12. Bug or feature? :)
>>> >>
>>> >>
>>> >> Lucian
>>> >>
>>> >> --
>>> >> Sent from the Delta quadrant using Borg technology!
>>> >>
>>> >> Nux!
>>> >> www.nux.ro

Re: vm.password.length issue in 4.4.1-SNAPSHOT

[Amogh Vasekar]

Hi Laszlo,

Any comments on the below? I agree adding 3 characters is a bug and
willing to fix it.

In addition, Ian, I believe we should set a minimum allowed value for the
config value vm.password.length. Any objections to setting the minimum to
8, the previous default?

Thanks
Amogh

On 10/13/14 5:34 PM, "Ian Duffy"  wrote:

>The only other usage of it is within
>server/src/com/cloud/server/ConfigurationServerImpl.java
>Its used for creating a Secondary storage vm copy password.
>
>I'm seeing absolutely no reason why we have 3 values going in no matter
>what, I'm willing to say its a bug. I'm curious to why the tests are
>written to deal with it though
>
>On 14 October 2014 00:26, Nux!  wrote:
>
>> Well, it's a bit messy, but still better than the old password length.
>> Ideally this should get clarified/fixed, but for now I am happy with my
>> long+3 password! :)
>>
>>
>> Cheers,
>> Lucian
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>> - Original Message -
>> > From: "Ian Duffy" 
>> > To: "CloudStack Dev" 
>> > Cc: "laszlo hornyak" 
>> > Sent: Monday, 13 October, 2014 19:54:53
>> > Subject: Re: vm.password.length issue in 4.4.1-SNAPSHOT
>>
>> > Hey Nux,
>> >
>> > So I passed this work off to a util class that was already present in
>>the
>> > code base "PasswordGenerator"
>> >
>> >@Override
>> >public String generateRandomPassword() {
>> >Integer passwordLength =
>> > Integer.parseInt(_configDao.getValue("vm.password.length"));
>> >return 
>>PasswordGenerator.generateRandomPassword(passwordLength);
>> >}
>> >
>> > Not a clue why but the generateRandomPassword method creates a random
>> > 3-character string first then loops through to generate n random
>> characters.
>> >
>> >public static String generateRandomPassword(int num) {
>> >Random r = new SecureRandom();
>> >StringBuilder password = new StringBuilder();
>> >
>> >// Generate random 3-character string with a lowercase
>>character,
>> >// uppercase character, and a digit
>> >
>> >
>> 
>>password.append(generateLowercaseChar(r)).append(generateUppercaseChar(r)
>>).append(generateDigit(r));
>> >
>> >// Generate a random n-character string with only lowercase
>> >// characters
>> >for (int i = 0; i < num; i++) {
>> >password.append(generateLowercaseChar(r));
>> >}
>> >
>> >return password.toString();
>> >}
>> >
>> > The unit tests seem to accommodate for this aswell:
>> >
>> >// actual length is requested length + 3
>> >
>> > 
>>Assert.assertTrue(PasswordGenerator.generateRandomPassword(0).length() ==
>> > 3);
>> >
>> > 
>>Assert.assertTrue(PasswordGenerator.generateRandomPassword(1).length() ==
>> > 4);
>> >
>> > I'm guessing there's some reasoning for this CCing Laszlo who
>> according
>> > to git log did some work on this class.
>> >
>> > Thanks,
>> >
>> > Ian
>> >
>> > On 13 October 2014 19:39, Nux!  wrote:
>> >
>> >> Hello,
>> >>
>> >> First of all "THANKS!" to whoever made this feature happen (Ian I
>> guess).
>> >> Now we can set more secure passwords generated for our instances.
>> >>
>> >> Second, the feature works, but with a small glitch, the number seems
>>to
>> be
>> >> affected by some sort of offset. I.e. if I set the password to be 15
>> chars
>> >> in length then the generated password will actually be 18 chars.
>> >> In order to get a 15 chars long passwd I had to set
>>vm.password.length
>> to
>> >> 12. Bug or feature? :)
>> >>
>> >>
>> >> Lucian
>> >>
>> >> --
>> >> Sent from the Delta quadrant using Borg technology!
>> >>
>> >> Nux!
>> >> www.nux.ro
>>

Re: Pulling Resource usage for domain or account

[Nitin Mehta]

I think listAccounts api also gives that info ? If this is not easy to
find please find an enhancement on JIRA. Thanks.

-Nitin 

On 24/10/14 11:51 AM, "Logan Barfield"  wrote:

>We have a cluster that is dedicated to a specific domain, and that domain
>has resource limits set.
>
>What would be the best way to display the currently utilized resources to
>the user of that domain?
>
>It's fairly easy with an API call to get the "Max" for each resource, but
>so far I've been unable to find a good way to grab the currently utilized
>resources (memory, primary storage, secondary storage) via the
>Domain-Admin
>or User APIs.
>
>I can do it via the Admin API, but even then it takes a few different
>calls
>to grab the data before cleaning it up and formatting it.

Re: [PROPOSAL] Move to github PR only during moratorium on commit

[Mike Tutkowski]

Cool...so, it sounds like any branch we create in the repo will
automatically have CI run against it post each commit.

How do you know when CI has completed and what the results are?

At that point, you could treat your own branch (as Daan says) as the
"forward" branch. Once CI has been successful, you can merge your code to,
say, 4.5 (or the RM can).

We then need a protocol for when we merge to 4.5 from our own branch, but
don't want to have those changes in master.

If we do want those changes, of course we can just merge from 4.5 to master.

On Fri, Oct 24, 2014 at 2:45 PM, Daan Hoogland 
wrote:

> We do run ci on branches!
>
> mobile dev with bilingual spelling checker used (read at your own risk)
> Op 24 okt. 2014 20:38 schreef "Mike Tutkowski" <
> mike.tutkow...@solidfire.com
> >:
>
> > Right, we just need to make sure CI comes into play before the merge.
> >
> > Hence my earlier reply to what Daan mention:
> >
> > "My main concern was CI running before the code was checked into the
> "real"
> > branch from the staging branch."
> >
> > On Fri, Oct 24, 2014 at 12:28 PM, David Nalley  wrote:
> >
> > > On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland <
> daan.hoogl...@gmail.com>
> > > wrote:
> > > > Mike, Why have everybody work on the same branch. people can work on
> > > > their own branch and when they are done they can rebase on the tip
> see
> > > > ci success and then merge. The problem with forward branches is
> > > > abandoned work or work that for some reason shouldn't go in 'this'
> > > > release. it will remain there.
> > > >
> > >
> > > CI really needs to happen before the merge occurs, IMO. Backing out
> > > merges, in my experience, is incredibly painful. And typically this
> > > means that someone else is going to have to clean up the mess after
> > > someone merges.
> > >
> >
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > *™*
> >
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
*™*

Re: [PROPOSAL] Move to github PR only during moratorium on commit

[Daan Hoogland]

We do run ci on branches!

mobile dev with bilingual spelling checker used (read at your own risk)
Op 24 okt. 2014 20:38 schreef "Mike Tutkowski" :

> Right, we just need to make sure CI comes into play before the merge.
>
> Hence my earlier reply to what Daan mention:
>
> "My main concern was CI running before the code was checked into the "real"
> branch from the staging branch."
>
> On Fri, Oct 24, 2014 at 12:28 PM, David Nalley  wrote:
>
> > On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland 
> > wrote:
> > > Mike, Why have everybody work on the same branch. people can work on
> > > their own branch and when they are done they can rebase on the tip see
> > > ci success and then merge. The problem with forward branches is
> > > abandoned work or work that for some reason shouldn't go in 'this'
> > > release. it will remain there.
> > >
> >
> > CI really needs to happen before the merge occurs, IMO. Backing out
> > merges, in my experience, is incredibly painful. And typically this
> > means that someone else is going to have to clean up the mess after
> > someone merges.
> >
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*
>

Re: [PROPOSAL] Move to github PR only during moratorium on commit

[Daan Hoogland]

mobile dev with bilingual spelling checker used (read at your own risk)
Op 24 okt. 2014 20:30 schreef "David Nalley" :
>
> On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland 
wrote:
> > Mike, Why have everybody work on the same branch. people can work on
> > their own branch and when they are done they can rebase on the tip see
> > ci success and then merge. The problem with forward branches is
> > abandoned work or work that for some reason shouldn't go in 'this'
> > release. it will remain there.
> >
>
> CI really needs to happen before the merge occurs, IMO.
Yes, that is exactly what i am saying
Backing out
> merges, in my experience, is incredibly painful. And typically this
> means that someone else is going to have to clean up the mess after
> someone merges.
and this is also what is wrong with the forward branches. It happened there
as well.

Pulling Resource usage for domain or account

[Logan Barfield]

We have a cluster that is dedicated to a specific domain, and that domain
has resource limits set.

What would be the best way to display the currently utilized resources to
the user of that domain?

It's fairly easy with an API call to get the "Max" for each resource, but
so far I've been unable to find a good way to grab the currently utilized
resources (memory, primary storage, secondary storage) via the Domain-Admin
or User APIs.

I can do it via the Admin API, but even then it takes a few different calls
to grab the data before cleaning it up and formatting it.

Jenkins build is back to normal : build-4.5 #43

[jenkins]

See 

Re: [PROPOSAL] Move to github PR only during moratorium on commit

[David Nalley]

On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland  wrote:
> Mike, Why have everybody work on the same branch. people can work on
> their own branch and when they are done they can rebase on the tip see
> ci success and then merge. The problem with forward branches is
> abandoned work or work that for some reason shouldn't go in 'this'
> release. it will remain there.
>

CI really needs to happen before the merge occurs, IMO. Backing out
merges, in my experience, is incredibly painful. And typically this
means that someone else is going to have to clean up the mess after
someone merges.

Re: [PROPOSAL] Move to github PR only during moratorium on commit

[Mike Tutkowski]

Right, we just need to make sure CI comes into play before the merge.

Hence my earlier reply to what Daan mention:

"My main concern was CI running before the code was checked into the "real"
branch from the staging branch."

On Fri, Oct 24, 2014 at 12:28 PM, David Nalley  wrote:

> On Fri, Oct 24, 2014 at 3:12 AM, Daan Hoogland 
> wrote:
> > Mike, Why have everybody work on the same branch. people can work on
> > their own branch and when they are done they can rebase on the tip see
> > ci success and then merge. The problem with forward branches is
> > abandoned work or work that for some reason shouldn't go in 'this'
> > release. it will remain there.
> >
>
> CI really needs to happen before the merge occurs, IMO. Backing out
> merges, in my experience, is incredibly painful. And typically this
> means that someone else is going to have to clean up the mess after
> someone merges.
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
*™*

RE: [HELP] cloudstack 4.4.0 src build failed

[Frank Zhang]

As you are building from source tarball, the simplest way to fix is to delete 
CertServiceTest.java

> -Original Message-
> From: Ian Duffy [mailto:i...@ianduffy.ie]
> Sent: Friday, October 24, 2014 9:54 AM
> To: CloudStack Dev
> Subject: Re: [HELP] cloudstack 4.4.0 src build failed
> 
> This looks like the certificate issue that has been mentioned in another 
> thread
> on the list.
> 
> On 24 October 2014 16:48, Nux!  wrote:
> 
> > Hello,
> >
> > Any reason you are not building 4.4.1? Perhaps it's fixed there.
> >
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro
> >
> > - Original Message -
> > > From: zengfh2...@aliyun.com
> > > To: "dev" 
> > > Sent: Friday, 24 October, 2014 15:13:19
> > > Subject: [HELP] cloudstack 4.4.0 src build failed
> >
> > > 您好：
> > > OS: CentOS6.3 x64
> > >cloudstack: apache-cloudstack-4.4.0-src.tar.bz2
> > >
> > >As building RPM，excute
> > cloudstack-4.4.0/packaging/centos63/package.sh ,the error
> > >as followed, please help me to resolve it, Thanks!
> > >
> > > Failed tests:
> > >
> > runUploadSslCertBadkeyAlgo(org.apache.cloudstack.network.lb.CertServic
> > eTest)
> > >
> > runUploadSslCertBadkeyPair(org.apache.cloudstack.network.lb.CertServic
> > eTest)
> > >
> > runUploadSslCertBadChain(org.apache.cloudstack.network.lb.CertServiceT
> > est)
> > >
> > runUploadSslCertNoRootCert(org.apache.cloudstack.network.lb.CertServic
> > eTest)
> > > runUploadSslCertNoChain(org.apache.cloudstack.network.lb.CertService
> > > Test)
> > >
> > > Tests in error:
> > >
> >
> runUploadSslCertWithCAChain(org.apache.cloudstack.network.lb.CertServiceTe
> st):
> > > Error parsing certificate data Certificate expired or not valid
> > >
> >
> runUploadSslCertSelfSignedNoPassword(org.apache.cloudstack.network.lb.Cert
> ServiceTest):
> > > Error parsing certificate data Certificate expired or not valid
> > >
> >
> runUploadSslCertSelfSignedWithPassword(org.apache.cloudstack.network.lb.Ce
> rtServiceTest):
> > > Error parsing certificate data Certificate expired or not valid
> > >
> > > Tests run: 139, Failures: 5, Errors: 3, Skipped: 1
> > >
> > >
> > > [INFO]
> > --
> > --
> > > [INFO] Reactor Summary:
> > > [INFO]
> > > [INFO] Apache CloudStack Developer Tools - Checkstyle Configuration
> > SUCCESS
> > > [8.201s]
> > > [INFO] Apache CloudStack . SUCCESS
> > [2.836s]
> > > [INFO] Apache CloudStack Maven Conventions Parent  SUCCESS
> > [1.335s]
> > > [INFO] Apache CloudStack Framework - Managed Context . SUCCESS
> > [5.058s]
> > > [INFO] Apache CloudStack Utils ... SUCCESS
> > [22.108s]
> > > [INFO] Apache CloudStack Framework ... SUCCESS
> > [0.090s]
> > > [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS
> > [13.717s]
> > > [INFO] Apache CloudStack Framework - Configuration ... SUCCESS
> > [7.190s]
> > > [INFO] Apache CloudStack API . SUCCESS
> > [24.591s]
> > > [INFO] Apache CloudStack Framework - REST  SUCCESS
> > [4.550s]
> > > [INFO] Apache CloudStack Framework - IPC . SUCCESS
> > [8.496s]
> > > [INFO] Apache CloudStack Cloud Engine  SUCCESS
> > [0.058s]
> > > [INFO] Apache CloudStack Cloud Engine API  SUCCESS
> > [6.813s]
> > > [INFO] Apache CloudStack Framework - Security  SUCCESS
> > [3.292s]
> > > [INFO] Apache CloudStack Core  SUCCESS
> > [17.587s]
> > > [INFO] Apache CloudStack Agents .. SUCCESS
> > [9.923s]
> > > [INFO] Apache CloudStack Framework - Clustering .. SUCCESS
> > [4.526s]
> > > [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS
> > [2.240s]
> > > [INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS
> > [22.376s]
> > > [INFO] Apache CloudStack Framework - Jobs  SUCCESS
> > [9.565s]
> > > [INFO] Apache CloudStack Cloud Engine Internal Components API
> > > SUCCESS
> > [5.471s]
> > > [INFO] Apache CloudStack Server .. FAILURE
> > [1:16.272s]
> > > [INFO] Apache CloudStack Usage Server  SKIPPED
> > > [INFO] Apache XenSource XAPI . SKIPPED
> > > [INFO] Apache CloudStack Cloud Engine Orchestration Component
> > > SKIPPED [INFO] Apache CloudStack Cloud Services ..
> > > SKIPPED [INFO] Apache CloudStack Secondary Storage ...
> > > SKIPPED [INFO] Apache CloudStack Secondary Storage Service ...
> > > SKIPPED [INFO] Apache CloudStack Engine Storage Component 
> > > SKIPPED [INFO] Apache CloudStack Engine Storage Volume Component .
> > > SKIPPED [INFO] Apache CloudStack Engine Storage Image Component ..
> > > SKIPPED [INFO] Apache CloudStack Engine Storage Data Motion
> > > Component SKIPPED [IN

Re: UI: where has "Acquire new IP" button disappeared?

[Nux!]

Hello,

This might sound stupid, but what is this "gridview" you are talking of?
This is what I am seeing http://imgur.com/9fl6ERD

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Gabor Apati-Nagy" 
> To: dev@cloudstack.apache.org
> Sent: Friday, 24 October, 2014 14:26:40
> Subject: RE: UI: where has "Acquire new IP" button disappeared?

> Hi Lucian,
> 
> The "View secondary IP" button should be displayed next to the IP Address in 
> the
> gridview. Clicking on that this page should display the "Acquire new secondary
> IP" button. I have tested this in master and we seem to have the same code in
> 4.4.
> Could you double check this? It could be confusing that the first button is 
> not
> in the heading, but is located in the grid.
> 
> Cheers,
> Gabor
> 
> 
> -Original Message-
> From: Nux! [mailto:n...@li.nux.ro]
> Sent: 24 October 2014 09:44
> To: dev@cloudstack.apache.org
> Subject: Re: UI: where has "Acquire new IP" button disappeared?
> 
> Opened https://issues.apache.org/jira/browse/CLOUDSTACK-7782 for this.
> 
> Anyone knows who we can bug for a fix?
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
>> From: "Nux!" 
>> To: dev@cloudstack.apache.org
>> Sent: Friday, 24 October, 2014 00:32:55
>> Subject: UI: where has "Acquire new IP" button disappeared?
> 
>> Hi,
>> 
>> Only now I notice that the option in the NIC tab of a VM
>> (Basic/Adv+SG) no longer has the "Acquire secondary" button, nor does it list
>> the Secondary IPs.
>> I can set and see the extra IPs in cloudmonkey though if I run:
>> 
>> add iptonic nicid=XXX
>> list nics nicid=XXX virtualmachineid=XXX
>> 
>> 
>> This is not OK ... alas I notice it too late. Promise to test more next 
>> release.
>> 
>> Any way I can get that back? I have people using the UI who rely on
>> this feature.
>> 
>> Lucian
>> 
>> --
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
> > www.nux.ro

Re: [HELP] cloudstack 4.4.0 src build failed

[Ian Duffy]

This looks like the certificate issue that has been mentioned in another
thread on the list.

On 24 October 2014 16:48, Nux!  wrote:

> Hello,
>
> Any reason you are not building 4.4.1? Perhaps it's fixed there.
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
> > From: zengfh2...@aliyun.com
> > To: "dev" 
> > Sent: Friday, 24 October, 2014 15:13:19
> > Subject: [HELP] cloudstack 4.4.0 src build failed
>
> > 您好：
> > OS: CentOS6.3 x64
> >cloudstack: apache-cloudstack-4.4.0-src.tar.bz2
> >
> >As building RPM，excute
> cloudstack-4.4.0/packaging/centos63/package.sh ,the error
> >as followed, please help me to resolve it, Thanks!
> >
> > Failed tests:
> >
> runUploadSslCertBadkeyAlgo(org.apache.cloudstack.network.lb.CertServiceTest)
> >
> runUploadSslCertBadkeyPair(org.apache.cloudstack.network.lb.CertServiceTest)
> >
> runUploadSslCertBadChain(org.apache.cloudstack.network.lb.CertServiceTest)
> >
> runUploadSslCertNoRootCert(org.apache.cloudstack.network.lb.CertServiceTest)
> > runUploadSslCertNoChain(org.apache.cloudstack.network.lb.CertServiceTest)
> >
> > Tests in error:
> >
> runUploadSslCertWithCAChain(org.apache.cloudstack.network.lb.CertServiceTest):
> > Error parsing certificate data Certificate expired or not valid
> >
> runUploadSslCertSelfSignedNoPassword(org.apache.cloudstack.network.lb.CertServiceTest):
> > Error parsing certificate data Certificate expired or not valid
> >
> runUploadSslCertSelfSignedWithPassword(org.apache.cloudstack.network.lb.CertServiceTest):
> > Error parsing certificate data Certificate expired or not valid
> >
> > Tests run: 139, Failures: 5, Errors: 3, Skipped: 1
> >
> >
> > [INFO]
> 
> > [INFO] Reactor Summary:
> > [INFO]
> > [INFO] Apache CloudStack Developer Tools - Checkstyle Configuration
> SUCCESS
> > [8.201s]
> > [INFO] Apache CloudStack . SUCCESS
> [2.836s]
> > [INFO] Apache CloudStack Maven Conventions Parent  SUCCESS
> [1.335s]
> > [INFO] Apache CloudStack Framework - Managed Context . SUCCESS
> [5.058s]
> > [INFO] Apache CloudStack Utils ... SUCCESS
> [22.108s]
> > [INFO] Apache CloudStack Framework ... SUCCESS
> [0.090s]
> > [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS
> [13.717s]
> > [INFO] Apache CloudStack Framework - Configuration ... SUCCESS
> [7.190s]
> > [INFO] Apache CloudStack API . SUCCESS
> [24.591s]
> > [INFO] Apache CloudStack Framework - REST  SUCCESS
> [4.550s]
> > [INFO] Apache CloudStack Framework - IPC . SUCCESS
> [8.496s]
> > [INFO] Apache CloudStack Cloud Engine  SUCCESS
> [0.058s]
> > [INFO] Apache CloudStack Cloud Engine API  SUCCESS
> [6.813s]
> > [INFO] Apache CloudStack Framework - Security  SUCCESS
> [3.292s]
> > [INFO] Apache CloudStack Core  SUCCESS
> [17.587s]
> > [INFO] Apache CloudStack Agents .. SUCCESS
> [9.923s]
> > [INFO] Apache CloudStack Framework - Clustering .. SUCCESS
> [4.526s]
> > [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS
> [2.240s]
> > [INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS
> [22.376s]
> > [INFO] Apache CloudStack Framework - Jobs  SUCCESS
> [9.565s]
> > [INFO] Apache CloudStack Cloud Engine Internal Components API SUCCESS
> [5.471s]
> > [INFO] Apache CloudStack Server .. FAILURE
> [1:16.272s]
> > [INFO] Apache CloudStack Usage Server  SKIPPED
> > [INFO] Apache XenSource XAPI . SKIPPED
> > [INFO] Apache CloudStack Cloud Engine Orchestration Component SKIPPED
> > [INFO] Apache CloudStack Cloud Services .. SKIPPED
> > [INFO] Apache CloudStack Secondary Storage ... SKIPPED
> > [INFO] Apache CloudStack Secondary Storage Service ... SKIPPED
> > [INFO] Apache CloudStack Engine Storage Component  SKIPPED
> > [INFO] Apache CloudStack Engine Storage Volume Component . SKIPPED
> > [INFO] Apache CloudStack Engine Storage Image Component .. SKIPPED
> > [INFO] Apache CloudStack Engine Storage Data Motion Component SKIPPED
> > [INFO] Apache CloudStack Engine Storage Cache Component .. SKIPPED
> > [INFO] Apache CloudStack Engine Storage Snapshot Component SKIPPED
> > [INFO] Apache CloudStack Cloud Engine API  SKIPPED
> > [INFO] Apache CloudStack Cloud Engine Service  SKIPPED
> > [INFO] Apache CloudStack Plugin POM .. SKIPPED
> > [INFO] Apache CloudStack Plugin - API Rate Limit . SKIPPED
> > [INFO] Apache CloudStack Plugin - API Discovery .. SKIPPED
> > [INFO] Apache CloudStack Plugin - ACL Static Role Based .. SKIPPED
> > [INFO] Apache 

RE: Urgent. Importing certificate to CS 4.3.1 using GUI

[Stephen Turner]

I'm still puzzled why it would have worked on my Firefox too. There must be 
some difference in configuration.

-- 
Stephen Turner


-Original Message-
From: Amogh Vasekar [mailto:amogh.vase...@citrix.com] 
Sent: 23 October 2014 16:18
To: dev@cloudstack.apache.org
Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI

Hi,

He certainly is :-)
Can you share the screenshot of firebug request and response so as to diagnose 
better?
Also, was the upload call made as admin or regular user?

Thanks,
Amogh

On 10/23/14 3:27 AM, "Suresh Sadhu"  wrote:

>Thanks France, We(France &myself) have diagnosed the problem and in 
>firefox after  uploading the certificate it shows "HTTP Error 501 Not 
>implemented" error in api response(firebug  output )and
>
>The request is not reaching the server  itself(CS management server and 
>api server logs not shown any API request details ..) so probably the 
>failure  is due to client side settings or  due to some other problem.
>
>We need to identify  reasons for "HTTP error 501 not implemented."
>http://www.checkupdown.com/status/E501.html
>
>Amogh/Nitin : can you please check in which cases this 501 not 
>implemented will occur.
>
>Regards
>Sadhu
>
> 
>
>
>
>
>
>-Original Message-
>From: France [mailto:mailingli...@isg.si]
>Sent: 23 October 2014 15:43
>To: dev@cloudstack.apache.org
>Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI
>
>Suresh is awesome. Hope Citrix knows that. :-) We diagnosed the issue 
>with ACS 4.3.1 and Firefox browser, and Suresh will update this thread 
>with details.
>
>Regards,
>F.
>
>
>On 15 Oct 2014, at 13:55, France  wrote:
>
>> Because i do not check this mailing list every day due to actual 
>>payed work, i have not seen your request.
>> I will contact you right now.
>> 
>> 
>> On 08 Oct 2014, at 20:10, Suresh Sadhu  wrote:
>> 
>>> Sure Nitin and as of now I didn't hear anything from France.
>>> 
>>> Regards
>>> sadhu
>>> 
>>> -Original Message-
>>> From: Nitin Mehta [mailto:nitin.me...@citrix.com]
>>> Sent: 08 October 2014 21:57
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI
>>> 
>>> Sadhu - Please do update the thread once you have some observation.
>>> Thanks
>>> 
>>> -Nitin
>>> 
>>> On 08/10/14 5:27 AM, "Suresh Sadhu"  wrote:
>>> 
 HI France,
 
 I can help  today .
 My personal email id is mailtosa...@gmail.com
 
 
 Regards
 sadhu
 
 -Original Message-
 From: Stephen Turner [mailto:stephen.tur...@citrix.com]
 Sent: 08 October 2014 17:43
 To: dev@cloudstack.apache.org
 Subject: RE: Urgent. Importing certificate to CS 4.3.1 using GUI
 
 France, I'm sorry, but I'm about to go away for three weeks, and 
 I'm not going to have time to work on this.
 
 Is there anyone else who could help France? Is anyone else seeing 
 the problem, because I couldn't reproduce it?
 
 --
 Stephen Turner
 
 
 
 -Original Message-
 From: France [mailto:mailingli...@isg.si]
 Sent: 08 October 2014 11:44
 To: dev@cloudstack.apache.org
 Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI
 
 Send me a private email and you can test it on my exact system with 
 all development options turned on as you wish.
 We will do it via remote screen sharing, like VNC, RDP, Teamviewer, ..
 
 Regards,
 F.
 
 On 26 Sep 2014, at 16:53, Stephen Turner 
 
 wrote:
 
> I'm afraid I couldn't reproduce this, even with your certificate 
> and private key. Everything I tried, I got "Update Certiciate 
> [sic] Succeeded".
> 
> Does anyone else have a convenient 4.3 and FF 32 that they can try 
> and repro this with?
> 
> France, if you open the developer tools in Firefox and do this 
> again, do you see any errors?
> 
> --
> Stephen Turner
> 
> 
> -Original Message-
> From: France [mailto:mailingli...@isg.si]
> Sent: 26 September 2014 13:44
> To: Stephen Turner
> Cc: dev@cloudstack.apache.org
> Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI
> 
> Issue has been created.
> I would assign it to you, but lack credentials?
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-7635
> 
> Regards,
> F.
> 
> On 26 Sep 2014, at 11:47, Stephen Turner 
> 
> wrote:
> 
>> Yes, I would like a bug report for this. Please assign it to me.
>> This bit of UI has been rewritten on master, but it should work 
>> the same in all browsers, so I'd like to investigate whether it's 
>> fixed on master, and also whether there are any other similar 
>> controls that aren't working in FF 32.
>> 
>> If you can attach a public key and other data that illustrates 
>> the problem, that would be great just to make sure that we can repro it.
>>

Re: commits on 4.5

[Mike Tutkowski]

Thanks, Leo

Yeah, being able to essentially "mark" a commit as NOT needing to be merged
(in fact, merging is wrong in this case) to a newer branch is key, I think,
to helping solve our branching issues.

On Fri, Oct 24, 2014 at 12:36 AM, Leo Simons 
wrote:

> Hey Mike,
>
> In git you accomplish these kinds of things with merge strategies. There’s
> a lot to choose from. What you’re describing sounds a bit like a variant on
> the “theirs” strategy. You can also do a recursive merge with a “theirs”
> conflict resolution choice, and there’s many other options. (see below)
>
> I don’t think it should be used though; there isn’t a tool problem here,
> it’s a communication problem and a priority problem causing a quality
> problem.
>
>
> cheers,
>
>
> Leo
>
> 
> 4 git merge --help
> ...
> MERGE STRATEGIES
>The merge mechanism (git merge and git pull commands) allows the
>backend merge strategies to be chosen with -s option. Some
> strategies
>can also take their own options, which can be passed by giving
>-X arguments to git merge and/or git pull.
> ...
>recursive
>This can only resolve two heads using a 3-way merge algorithm.
> When
>there is more than one common ancestor that can be used for
> 3-way
>merge, it creates a merged tree of the common ancestors and uses
>that as the reference tree for the 3-way merge. This has been
>reported to result in fewer merge conflicts without causing
>mismerges by tests done on actual merge commits taken from Linux
>2.6 kernel development history. Additionally this can detect and
>handle merges involving renames. This is the default merge
> strategy
>when pulling or merging one branch.
>
>The recursive strategy can take the following options:
>
>ours
>This option forces conflicting hunks to be auto-resolved
>cleanly by favoring our version. Changes from the other tree
>that do not conflict with our side are reflected to the
> merge
>result. For a binary file, the entire contents are taken
> from
>our side.
>
>This should not be confused with the ours merge strategy,
> which
>does not even look at what the other tree contains at all.
> It
>discards everything the other tree did, declaring our
> history
>contains all that happened in it.
>
>theirs
>This is the opposite of ours.
> ...
>octopus
>This resolves cases with more than two heads, but refuses to do
> a
>complex merge that needs manual resolution. It is primarily
> meant
>to be used for bundling topic branch heads together. This is the
>default merge strategy when pulling or merging more than one
>branch.
>
>ours
>This resolves any number of heads, but the resulting tree of the
>merge is always that of the current branch head, effectively
>ignoring all changes from all other branches. It is meant to be
>used to supersede old development history of side branches. Note
>that this is different from the -Xours option to the recursive
>merge strategy.
>
>subtree
>This is a modified recursive strategy. When merging trees A and
> B,
>if B corresponds to a subtree of A, B is first adjusted to match
>the tree structure of A, instead of reading the trees at the
> same
>level. This adjustment is also done to the common ancestor tree.
> ...
>
>
> On Oct 24, 2014, at 2:29 AM, Mike Tutkowski 
> wrote:
>
> > Maybe we need something like this in Git (maybe it's already there?):
> >
> >
> http://stackoverflow.com/questions/18074697/subversion-mark-as-merged-without-changing-anything
> >
> > The ability to record a commit has having been merged to another branch,
> > but nothing was really merged.
> >
> > Then when you checked code into 4.5 that shouldn't be in master, you
> simply
> > do a merge --record-only (in SVN terminology).
> >
> > On Thu, Oct 23, 2014 at 3:37 PM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> >> If we just did merges (instead of cherry picks) to 4.5, does Git allow
> us
> >> to ONLY merge that particular (merge) commit from 4.5 to master?
> >>
> >> In other words, I'd want to make sure we were only merging from 4.5 to
> >> master what we want to (and, as I mentioned earlier, not bring along
> >> commits to 4.5 that should not be in master).
> >>
> >> In SVN you could do a sort-of "empty" merge from branch x to a later
> >> branch (or set of branches), which basically told SVN that that commit
> was
> >> not supposed to be brought forward. Then when the next person came along
> >> and committed to branch x and merged forward, SVN would not take your
> >>

Re: [PROPOSAL] Move to github PR only during moratorium on commit

[Mike Tutkowski]

Yeah, Daan, the approach you describe sounds like a reasonable substitute
for what I have in that diagram.

My main concern was CI running before the code was checked into the "real"
branch from the staging branch.

On Fri, Oct 24, 2014 at 1:12 AM, Daan Hoogland 
wrote:

> Mike, Why have everybody work on the same branch. people can work on
> their own branch and when they are done they can rebase on the tip see
> ci success and then merge. The problem with forward branches is
> abandoned work or work that for some reason shouldn't go in 'this'
> release. it will remain there.
>
> On Fri, Oct 24, 2014 at 3:34 AM, Mike Tutkowski
>  wrote:
> > Are we talking about something like what I drew up here?:
> >
> > http://i.imgur.com/UgPtJGY.png
> >
> > In this scheme, the -forward branches are the ones you can directly
> commit
> > to while their peers without the -forward are the ones that code gets
> > merged to from its corresponding -forward branch.
> >
> > CI is performed on the -forward branches before any merging takes place.
> >
> > The "merge recorded" concept I put in the diagram refers to the situation
> > where you have a commit on a branch like 4.5, but you do NOT want it to
> > move forward to master.
> >
> > I don't know if Git has such a concept, but SVN calls this kind of a
> > "merge" merge recording. Merge recording essentially means you do not
> want
> > those changes brought forward to the specified branch (not now and not
> with
> > future merges other people or yourself may do).
> >
> >
> >
> > On Thu, Oct 23, 2014 at 5:30 PM, Animesh Chaturvedi <
> > animesh.chaturv...@citrix.com> wrote:
> >
> >>
> >>
> >> > -Original Message-
> >> > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> >> > Sent: Thursday, October 23, 2014 1:31 AM
> >> > To: dev
> >> > Subject: Re: [PROPOSAL] Move to github PR only during moratorium on
> >> > commit
> >> >
> >> > On Thu, Oct 23, 2014 at 10:22 AM, Rohit Yadav
> >> >  wrote:
> >> > > Hi,
> >> > >
> >> > >> On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi
> >> >  wrote:
> >> > ...
> >> > >> The approach for fixing issues in release branch first and master
> >> later is
> >> > not practical as we may miss out commits not made into master and
> future
> >> > release regressing without the fixes.
> >> > >
> >> > > By the same logic, if we fix by default on master only, the release
> >> branch
> >> > may miss out commits.
> >> >
> >> > I sttrongly disagree with Animesh here and think Rohit is overlooking
> a
> >> > simple fact. At the moment the branches are for 'stabalizing'.
> >> > Fixing on master first is in direct contradiction with that.
> >> >
> >> > We have not been stabalizing 4.4. it contains bug that have during the
> >> > release periods for 4.4.0 and 4.4.1 been fixed on master. That
> shouldn't
> >> > have been allowed to happen.
> >> [Animesh] Clearly we have disagreement. To avoid the issue that you
> >> mention David had created forward branch for 4.2 and I found it useful
> and
> >> continued with that approach in 4.3. With forward branch which are
> really
> >> staging it was a simple merge of forward back to release branch. The
> other
> >> approach of merging release branch into master work as well but in my
> >> opinion keeping master as the default branch (with protection of course
> )
> >> is simpler to understand and creates less confusion
> >>
> >>
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > *™*
>
>
>
> --
> Daan
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
*™*

Re: [HELP] cloudstack 4.4.0 src build failed

[Nux!]

Hello,

Any reason you are not building 4.4.1? Perhaps it's fixed there.

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: zengfh2...@aliyun.com
> To: "dev" 
> Sent: Friday, 24 October, 2014 15:13:19
> Subject: [HELP] cloudstack 4.4.0 src build failed

> 您好：
> OS: CentOS6.3 x64
>cloudstack: apache-cloudstack-4.4.0-src.tar.bz2
>
>As building RPM，excute cloudstack-4.4.0/packaging/centos63/package.sh 
> ,the error
>as followed, please help me to resolve it, Thanks!
> 
> Failed tests:
> runUploadSslCertBadkeyAlgo(org.apache.cloudstack.network.lb.CertServiceTest)
> runUploadSslCertBadkeyPair(org.apache.cloudstack.network.lb.CertServiceTest)
> runUploadSslCertBadChain(org.apache.cloudstack.network.lb.CertServiceTest)
> runUploadSslCertNoRootCert(org.apache.cloudstack.network.lb.CertServiceTest)
> runUploadSslCertNoChain(org.apache.cloudstack.network.lb.CertServiceTest)
> 
> Tests in error:
> runUploadSslCertWithCAChain(org.apache.cloudstack.network.lb.CertServiceTest):
> Error parsing certificate data Certificate expired or not valid
> runUploadSslCertSelfSignedNoPassword(org.apache.cloudstack.network.lb.CertServiceTest):
> Error parsing certificate data Certificate expired or not valid
> runUploadSslCertSelfSignedWithPassword(org.apache.cloudstack.network.lb.CertServiceTest):
> Error parsing certificate data Certificate expired or not valid
> 
> Tests run: 139, Failures: 5, Errors: 3, Skipped: 1
> 
> 
> [INFO] 
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Apache CloudStack Developer Tools - Checkstyle Configuration SUCCESS
> [8.201s]
> [INFO] Apache CloudStack . SUCCESS [2.836s]
> [INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [1.335s]
> [INFO] Apache CloudStack Framework - Managed Context . SUCCESS [5.058s]
> [INFO] Apache CloudStack Utils ... SUCCESS [22.108s]
> [INFO] Apache CloudStack Framework ... SUCCESS [0.090s]
> [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [13.717s]
> [INFO] Apache CloudStack Framework - Configuration ... SUCCESS [7.190s]
> [INFO] Apache CloudStack API . SUCCESS [24.591s]
> [INFO] Apache CloudStack Framework - REST  SUCCESS [4.550s]
> [INFO] Apache CloudStack Framework - IPC . SUCCESS [8.496s]
> [INFO] Apache CloudStack Cloud Engine  SUCCESS [0.058s]
> [INFO] Apache CloudStack Cloud Engine API  SUCCESS [6.813s]
> [INFO] Apache CloudStack Framework - Security  SUCCESS [3.292s]
> [INFO] Apache CloudStack Core  SUCCESS [17.587s]
> [INFO] Apache CloudStack Agents .. SUCCESS [9.923s]
> [INFO] Apache CloudStack Framework - Clustering .. SUCCESS [4.526s]
> [INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [2.240s]
> [INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [22.376s]
> [INFO] Apache CloudStack Framework - Jobs  SUCCESS [9.565s]
> [INFO] Apache CloudStack Cloud Engine Internal Components API SUCCESS [5.471s]
> [INFO] Apache CloudStack Server .. FAILURE [1:16.272s]
> [INFO] Apache CloudStack Usage Server  SKIPPED
> [INFO] Apache XenSource XAPI . SKIPPED
> [INFO] Apache CloudStack Cloud Engine Orchestration Component SKIPPED
> [INFO] Apache CloudStack Cloud Services .. SKIPPED
> [INFO] Apache CloudStack Secondary Storage ... SKIPPED
> [INFO] Apache CloudStack Secondary Storage Service ... SKIPPED
> [INFO] Apache CloudStack Engine Storage Component  SKIPPED
> [INFO] Apache CloudStack Engine Storage Volume Component . SKIPPED
> [INFO] Apache CloudStack Engine Storage Image Component .. SKIPPED
> [INFO] Apache CloudStack Engine Storage Data Motion Component SKIPPED
> [INFO] Apache CloudStack Engine Storage Cache Component .. SKIPPED
> [INFO] Apache CloudStack Engine Storage Snapshot Component SKIPPED
> [INFO] Apache CloudStack Cloud Engine API  SKIPPED
> [INFO] Apache CloudStack Cloud Engine Service  SKIPPED
> [INFO] Apache CloudStack Plugin POM .. SKIPPED
> [INFO] Apache CloudStack Plugin - API Rate Limit . SKIPPED
> [INFO] Apache CloudStack Plugin - API Discovery .. SKIPPED
> [INFO] Apache CloudStack Plugin - ACL Static Role Based .. SKIPPED
> [INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor SKIPPED
> [INFO] Apache CloudStack Plugin - Explicit Dedication Processor SKIPPED
> [INFO] Apache CloudStack Plugin - User Concentrated Pod Deployment Planner
> SKIPPED
> [INFO] Apache CloudStack Plugin - User Dispersing Deployment Planner SKIPPED
> [INFO] Apache CloudStack Plugin - Implicit De

[GitHub] cloudstack pull request: listDirectory method updated to use Objec...

[santhoshdaivajna]

GitHub user santhoshdaivajna opened a pull request:

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

listDirectory method updated to use ObjectListing.isTruncated().

Because buckets can contain a virtually unlimited number of keys, the
complete results of a list query can be extremely large. To manage large
result sets, Amazon S3 uses pagination to split them into multiple
responses.

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

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

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

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

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

This closes #25


commit 820d99344b1f3c07ee1d41fdeb1ec82a09acc292
Author: santhosh 
Date:   2014-10-24T15:45:29Z

listDirectory method updated to use ObjectListing.isTruncated().

Because buckets can contain a virtually unlimited number of keys, the
complete results of a list query can be extremely large. To manage large
result sets, Amazon S3 uses pagination to split them into multiple
responses.




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

Re: UI: where has "Acquire new IP" button disappeared?

[Nux!]

Hello,

This might sound stupid, but what is this "gridview" you are talking of?
This is what I am seeing http://imgur.com/9fl6ERD

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Gabor Apati-Nagy" 
> To: dev@cloudstack.apache.org
> Sent: Friday, 24 October, 2014 14:26:40
> Subject: RE: UI: where has "Acquire new IP" button disappeared?

> Hi Lucian,
> 
> The "View secondary IP" button should be displayed next to the IP Address in 
> the
> gridview. Clicking on that this page should display the "Acquire new secondary
> IP" button. I have tested this in master and we seem to have the same code in
> 4.4.
> Could you double check this? It could be confusing that the first button is 
> not
> in the heading, but is located in the grid.
> 
> Cheers,
> Gabor
> 
> 
> -Original Message-
> From: Nux! [mailto:n...@li.nux.ro]
> Sent: 24 October 2014 09:44
> To: dev@cloudstack.apache.org
> Subject: Re: UI: where has "Acquire new IP" button disappeared?
> 
> Opened https://issues.apache.org/jira/browse/CLOUDSTACK-7782 for this.
> 
> Anyone knows who we can bug for a fix?
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> - Original Message -
>> From: "Nux!" 
>> To: dev@cloudstack.apache.org
>> Sent: Friday, 24 October, 2014 00:32:55
>> Subject: UI: where has "Acquire new IP" button disappeared?
> 
>> Hi,
>> 
>> Only now I notice that the option in the NIC tab of a VM
>> (Basic/Adv+SG) no longer has the "Acquire secondary" button, nor does it list
>> the Secondary IPs.
>> I can set and see the extra IPs in cloudmonkey though if I run:
>> 
>> add iptonic nicid=XXX
>> list nics nicid=XXX virtualmachineid=XXX
>> 
>> 
>> This is not OK ... alas I notice it too late. Promise to test more next 
>> release.
>> 
>> Any way I can get that back? I have people using the UI who rely on
>> this feature.
>> 
>> Lucian
>> 
>> --
>> Sent from the Delta quadrant using Borg technology!
>> 
>> Nux!
> > www.nux.ro

[HELP] cloudstack 4.4.0 src build failed

[zengfh2...@aliyun.com]

您好：
 OS: CentOS6.3 x64
cloudstack: apache-cloudstack-4.4.0-src.tar.bz2

As building RPM，excute cloudstack-4.4.0/packaging/centos63/package.sh 
,the error as followed, please help me to resolve it, Thanks!

Failed tests: 
runUploadSslCertBadkeyAlgo(org.apache.cloudstack.network.lb.CertServiceTest) 
runUploadSslCertBadkeyPair(org.apache.cloudstack.network.lb.CertServiceTest) 
runUploadSslCertBadChain(org.apache.cloudstack.network.lb.CertServiceTest) 
runUploadSslCertNoRootCert(org.apache.cloudstack.network.lb.CertServiceTest) 
runUploadSslCertNoChain(org.apache.cloudstack.network.lb.CertServiceTest) 

Tests in error: 
runUploadSslCertWithCAChain(org.apache.cloudstack.network.lb.CertServiceTest): 
Error parsing certificate data Certificate expired or not valid 
runUploadSslCertSelfSignedNoPassword(org.apache.cloudstack.network.lb.CertServiceTest):
 Error parsing certificate data Certificate expired or not valid 
runUploadSslCertSelfSignedWithPassword(org.apache.cloudstack.network.lb.CertServiceTest):
 Error parsing certificate data Certificate expired or not valid 

Tests run: 139, Failures: 5, Errors: 3, Skipped: 1


[INFO]  
[INFO] Reactor Summary: 
[INFO] 
[INFO] Apache CloudStack Developer Tools - Checkstyle Configuration SUCCESS 
[8.201s] 
[INFO] Apache CloudStack . SUCCESS [2.836s] 
[INFO] Apache CloudStack Maven Conventions Parent  SUCCESS [1.335s] 
[INFO] Apache CloudStack Framework - Managed Context . SUCCESS [5.058s] 
[INFO] Apache CloudStack Utils ... SUCCESS [22.108s] 
[INFO] Apache CloudStack Framework ... SUCCESS [0.090s] 
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [13.717s] 
[INFO] Apache CloudStack Framework - Configuration ... SUCCESS [7.190s] 
[INFO] Apache CloudStack API . SUCCESS [24.591s] 
[INFO] Apache CloudStack Framework - REST  SUCCESS [4.550s] 
[INFO] Apache CloudStack Framework - IPC . SUCCESS [8.496s] 
[INFO] Apache CloudStack Cloud Engine  SUCCESS [0.058s] 
[INFO] Apache CloudStack Cloud Engine API  SUCCESS [6.813s] 
[INFO] Apache CloudStack Framework - Security  SUCCESS [3.292s] 
[INFO] Apache CloudStack Core  SUCCESS [17.587s] 
[INFO] Apache CloudStack Agents .. SUCCESS [9.923s] 
[INFO] Apache CloudStack Framework - Clustering .. SUCCESS [4.526s] 
[INFO] Apache CloudStack Framework - Event Notification .. SUCCESS [2.240s] 
[INFO] Apache CloudStack Cloud Engine Schema Component ... SUCCESS [22.376s] 
[INFO] Apache CloudStack Framework - Jobs  SUCCESS [9.565s] 
[INFO] Apache CloudStack Cloud Engine Internal Components API SUCCESS [5.471s] 
[INFO] Apache CloudStack Server .. FAILURE [1:16.272s] 
[INFO] Apache CloudStack Usage Server  SKIPPED 
[INFO] Apache XenSource XAPI . SKIPPED 
[INFO] Apache CloudStack Cloud Engine Orchestration Component SKIPPED 
[INFO] Apache CloudStack Cloud Services .. SKIPPED 
[INFO] Apache CloudStack Secondary Storage ... SKIPPED 
[INFO] Apache CloudStack Secondary Storage Service ... SKIPPED 
[INFO] Apache CloudStack Engine Storage Component  SKIPPED 
[INFO] Apache CloudStack Engine Storage Volume Component . SKIPPED 
[INFO] Apache CloudStack Engine Storage Image Component .. SKIPPED 
[INFO] Apache CloudStack Engine Storage Data Motion Component SKIPPED 
[INFO] Apache CloudStack Engine Storage Cache Component .. SKIPPED 
[INFO] Apache CloudStack Engine Storage Snapshot Component SKIPPED 
[INFO] Apache CloudStack Cloud Engine API  SKIPPED 
[INFO] Apache CloudStack Cloud Engine Service  SKIPPED 
[INFO] Apache CloudStack Plugin POM .. SKIPPED 
[INFO] Apache CloudStack Plugin - API Rate Limit . SKIPPED 
[INFO] Apache CloudStack Plugin - API Discovery .. SKIPPED 
[INFO] Apache CloudStack Plugin - ACL Static Role Based .. SKIPPED 
[INFO] Apache CloudStack Plugin - Host Anti-Affinity Processor SKIPPED 
[INFO] Apache CloudStack Plugin - Explicit Dedication Processor SKIPPED 
[INFO] Apache CloudStack Plugin - User Concentrated Pod Deployment Planner 
SKIPPED 
[INFO] Apache CloudStack Plugin - User Dispersing Deployment Planner SKIPPED 
[INFO] Apache CloudStack Plugin - Implicit Dedication Planner SKIPPED 
[INFO] Apache CloudStack Plugin - Skip Heurestics Planner SKIPPED 
[INFO] Apache CloudStack Plugin - Host Allocator Random .. SKIPPED 
[INFO] Apache CloudStack Plugin - Dedicated Resources  SKIPPED 
[INFO] Apache CloudStack Plugin - Hypervisor OracleVM  SKIPPED 
[INFO] Apache CloudStack Plugin - Open vSwitch ... SKIPPED 
[INFO] Apache CloudStack Plugin - Hypervisor 

RE: UI: where has "Acquire new IP" button disappeared?

[Gabor Apati-Nagy]

Hi Lucian,

The "View secondary IP" button should be displayed next to the IP Address in 
the gridview. Clicking on that this page should display the "Acquire new 
secondary IP" button. I have tested this in master and we seem to have the same 
code in 4.4.
Could you double check this? It could be confusing that the first button is not 
in the heading, but is located in the grid.

Cheers,
Gabor


-Original Message-
From: Nux! [mailto:n...@li.nux.ro] 
Sent: 24 October 2014 09:44
To: dev@cloudstack.apache.org
Subject: Re: UI: where has "Acquire new IP" button disappeared?

Opened https://issues.apache.org/jira/browse/CLOUDSTACK-7782 for this.

Anyone knows who we can bug for a fix?

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Nux!" 
> To: dev@cloudstack.apache.org
> Sent: Friday, 24 October, 2014 00:32:55
> Subject: UI: where has "Acquire new IP" button disappeared?

> Hi,
> 
> Only now I notice that the option in the NIC tab of a VM 
> (Basic/Adv+SG) no longer has the "Acquire secondary" button, nor does it list 
> the Secondary IPs.
> I can set and see the extra IPs in cloudmonkey though if I run:
> 
> add iptonic nicid=XXX
> list nics nicid=XXX virtualmachineid=XXX
> 
> 
> This is not OK ... alas I notice it too late. Promise to test more next 
> release.
> 
> Any way I can get that back? I have people using the UI who rely on 
> this feature.
> 
> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

Management server is stuck after upgrade to 4.4.1

[Thomas Schneider]

Hello,

I tried yo upgrade Cloudstack from 4.4.0 to 4.4.1, following the
instructions of the release note.
When I restarted the MS the update of the database worked as expected
but after the server is stuck.

Regards,

Partial log output:

2014-10-24 14:01:54,283 INFO  [c.c.u.d.T.Transaction] (main:null) Is
Data Base High Availiability enabled? Ans : false
2014-10-24 14:01:54,843 DEBUG [c.c.u.d.ConnectionConcierge] (main:null)
Registering a database connection for LockMaster1
2014-10-24 14:01:54,843 INFO  [c.c.u.d.Merovingian2] (main:null)
Cleaning up locks for 7012003873552
2014-10-24 14:01:54,853 INFO  [c.c.u.d.Merovingian2] (main:null)
Released 0 locks for 7012003873552
2014-10-24 14:01:54,895 INFO  [o.a.c.s.l.CloudStackExtendedLifeCycle]
(main:null) Running system integrity checker
com.cloud.upgrade.DatabaseUpgradeChecker@6345943f
2014-10-24 14:01:54,896 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null)
Grabbing lock to check for database upgrade.
2014-10-24 14:01:55,111 DEBUG [c.c.u.d.VersionDaoImpl] (main:null)
Checking to see if the database is at a version before it was the
version table is created
2014-10-24 14:01:55,140 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null)
DB version = 4.4.0 Code Version = 4.4.1
2014-10-24 14:01:55,142 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null)
Database upgrade must be performed from 4.4.0 to 4.4.1
2014-10-24 14:01:55,142 DEBUG [c.c.u.DatabaseUpgradeChecker] (main:null)
Running upgrade Upgrade440to441 to upgrade from 4.4.0-4.4.1 to 4.4.1
2014-10-24 14:01:55,149 DEBUG [c.c.u.s.Script] (main:null) Looking for
db/schema-440to441.sql in the classpath
2014-10-24 14:01:55,149 DEBUG [c.c.u.s.Script] (main:null) System
resource: file:/usr/share/cloudstack-management/setup/db/schema-440to441.sql
2014-10-24 14:01:55,149 DEBUG [c.c.u.s.Script] (main:null) Absolute path
=  /usr/share/cloudstack-management/setup/db/schema-440to441.sql
...
2014-10-24 14:01:55,293 DEBUG [c.c.u.d.ScriptRunner] (main:null) -- Fix
CLOUDSTACK-7624
2014-10-24 14:01:55,293 DEBUG [c.c.u.d.ScriptRunner] (main:null) ALTER
TABLE `cloud`.`configuration` MODIFY default_value varchar(8191), MODIFY
value varchar(8191)
2014-10-24 14:01:55,398 DEBUG [c.c.u.d.Upgrade440to441] (main:null)
Updating System Vm template IDs
2014-10-24 14:01:55,406 DEBUG [c.c.u.d.Upgrade440to441] (main:null)
Updating KVM System Vms
2014-10-24 14:01:55,410 DEBUG [c.c.u.d.Upgrade440to441] (main:null)
Updating XenServer System Vms
2014-10-24 14:01:55,414 DEBUG [c.c.u.d.Upgrade440to441] (main:null)
Updating VMware System Vms
2014-10-24 14:01:55,414 WARN  [c.c.u.d.Upgrade440to441] (main:null)
4.4.0 VMware SystemVm template not found. VMware hypervisor is not used,
so not failing upgrade
2014-10-24 14:01:55,415 DEBUG [c.c.u.d.Upgrade440to441] (main:null)
Updating Hyperv System Vms
2014-10-24 14:01:55,416 WARN  [c.c.u.d.Upgrade440to441] (main:null)
4.4.0 Hyperv SystemVm template not found. Hyperv hypervisor is not used,
so not failing upgrade
2014-10-24 14:01:55,416 DEBUG [c.c.u.d.Upgrade440to441] (main:null)
Updating LXC System Vms
2014-10-24 14:01:55,417 WARN  [c.c.u.d.Upgrade440to441] (main:null)
4.4.0 LXC SystemVm template not found. LXC hypervisor is not used, so
not failing upgrade
2014-10-24 14:01:55,417 DEBUG [c.c.u.d.Upgrade440to441] (main:null)
Updating System Vm Template IDs Complete
2014-10-24 14:01:55,525 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null)
Cleaning upgrades because all management server are now at the same version
2014-10-24 14:01:55,530 DEBUG [c.c.u.DatabaseUpgradeChecker] (main:null)
Upgrading to version 4.4.1...
2014-10-24 14:01:55,531 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null)
Cleanup upgrade Upgrade440to441 to upgrade from 4.4.0-4.4.1 to 4.4.1
2014-10-24 14:01:55,532 DEBUG [c.c.u.s.Script] (main:null) Looking for
db/schema-440to441-cleanup.sql in the classpath
2014-10-24 14:01:55,532 DEBUG [c.c.u.s.Script] (main:null) System
resource:
file:/usr/share/cloudstack-management/setup/db/schema-440to441-cleanup.sql
2014-10-24 14:01:55,532 DEBUG [c.c.u.s.Script] (main:null) Absolute path
=  /usr/share/cloudstack-management/setup/db/schema-440to441-cleanup.sql
2014-10-24 14:01:55,533 DEBUG [c.c.u.d.ScriptRunner] (main:null) --
Licensed to the Apache Software Foundation (ASF) under one
2014-10-24 14:01:55,533 DEBUG [c.c.u.d.ScriptRunner] (main:null) -- or
more contributor license agreements.  See the NOTICE file
2014-10-24 14:01:55,533 DEBUG [c.c.u.d.ScriptRunner] (main:null) --
distributed with this work for additional information
2014-10-24 14:01:55,533 DEBUG [c.c.u.d.ScriptRunner] (main:null) --
regarding copyright ownership.  The ASF licenses this file
2014-10-24 14:01:55,533 DEBUG [c.c.u.d.ScriptRunner] (main:null) -- to
you under the Apache License, Version 2.0 (the
2014-10-24 14:01:55,533 DEBUG [c.c.u.d.ScriptRunner] (main:null) --
"License"); you may not use this file except in compliance
2014-10-24 14:01:55,533 DEBUG [c.c.u.d.ScriptRunner] (main:null) -- with
the License.  You may obtain a copy of the Li

Re: (rolling) upgrade of redundant virtual router

[Daan Hoogland]

At first glance it seems that we need is to

- shutdown one side
- update the vo
- restart the one side
- shutdown the other side
- restart the other side

Somehow this seems to be too simple. the shutdown elements works in a
generic way while my use case only applies to the virtual router and
not to other providers. In fact the network may have a redundant
virtual router and some other providers for which redundant makes no
sense or that have their only redundancy mechs, right?

On Fri, Oct 24, 2014 at 10:43 AM, Daan Hoogland  wrote:
> H,
>
> I the present code a vr is updates as follows:
>
> // 1) Shutdown all the elements and cleanup all the rules.
> Don't allow to shutdown network in intermediate
> // states - Shutdown and Implementing
>
> // 2) Only after all the elements and rules are shutdown
> properly, update the network VO
> // get updated network
>
>// 3) Implement the elements and rules again
>
> // 4) if network has been upgraded from a non persistent ntwk
> offering to a persistent ntwk offering,
> // implement the network if its not already
>
> This means that for a redundant router vm both sides are brought down
> before upgrade of the db entries is done. This is not acceptable for
> mission critical environments such as our clients at Schuberg Philis
> have. I am to concoct a way around this and will have my sweet time at
> it. I am also willing to share this time with anyone that has thoughts
> and particularly concerns on the issue.
>
> To get to this point I extracted as much as I could from the
> updateNetwork method in NetworkServiceImpl. The results are in
> hotfix/CLOUDSTACK-7776. I plan to merge this before working on the
> actual fix but after I am convinced that I re-factored it enough and
> as much as possible. Please have a look if you dare to/enjoy it.
>
> --
> Daan



-- 
Daan

Fixing SystemVM builds

[Rohit Yadav]

Hi,

On jenkins.buildacloud.org, the last successful builds for systemvm template 
build jobs was 20-22 days ago. Can anyone give me either access to the infra so 
I can help debug and fix it, or people who have access help fix it? Thanks.

The common issue is that it takes a lot of time to copy the isos and it 
timeouts, or there is some server error.

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab

Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Infrastructure 
Support
CloudStack Bootcamp Training Courses

This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company 
registered by The Republic of South Africa and is traded under license from 
Shape Blue Ltd. ShapeBlue is a registered trademark.

(rolling) upgrade of redundant virtual router

[Daan Hoogland]

H,

I the present code a vr is updates as follows:

// 1) Shutdown all the elements and cleanup all the rules.
Don't allow to shutdown network in intermediate
// states - Shutdown and Implementing

// 2) Only after all the elements and rules are shutdown
properly, update the network VO
// get updated network

   // 3) Implement the elements and rules again

// 4) if network has been upgraded from a non persistent ntwk
offering to a persistent ntwk offering,
// implement the network if its not already

This means that for a redundant router vm both sides are brought down
before upgrade of the db entries is done. This is not acceptable for
mission critical environments such as our clients at Schuberg Philis
have. I am to concoct a way around this and will have my sweet time at
it. I am also willing to share this time with anyone that has thoughts
and particularly concerns on the issue.

To get to this point I extracted as much as I could from the
updateNetwork method in NetworkServiceImpl. The results are in
hotfix/CLOUDSTACK-7776. I plan to merge this before working on the
actual fix but after I am convinced that I re-factored it enough and
as much as possible. Please have a look if you dare to/enjoy it.

-- 
Daan

Re: UI: where has "Acquire new IP" button disappeared?

[Nux!]

Opened https://issues.apache.org/jira/browse/CLOUDSTACK-7782 for this.

Anyone knows who we can bug for a fix?

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Nux!" 
> To: dev@cloudstack.apache.org
> Sent: Friday, 24 October, 2014 00:32:55
> Subject: UI: where has "Acquire new IP" button disappeared?

> Hi,
> 
> Only now I notice that the option in the NIC tab of a VM (Basic/Adv+SG) no
> longer has the "Acquire secondary" button, nor does it list the Secondary IPs.
> I can set and see the extra IPs in cloudmonkey though if I run:
> 
> add iptonic nicid=XXX
> list nics nicid=XXX virtualmachineid=XXX
> 
> 
> This is not OK ... alas I notice it too late. Promise to test more next 
> release.
> 
> Any way I can get that back? I have people using the UI who rely on this
> feature.
> 
> Lucian
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

Re: 431 to 441, VR upgrade fails with VR config: execution failed: "/opt/cloud/bin/createipAlias.sh"

[Daan Hoogland]

thanks for walking the bleeding edge on this, Nux!

On Fri, Oct 24, 2014 at 10:32 AM, Nux!  wrote:
> Yep, https://issues.apache.org/jira/browse/CLOUDSTACK-7781
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
>> From: "Daan Hoogland" 
>> To: "dev" 
>> Sent: Friday, 24 October, 2014 08:03:59
>> Subject: Re: 431 to 441, VR upgrade fails with VR config: execution failed: 
>> "/opt/cloud/bin/createipAlias.sh"
>
>> Lucian, did you make a ticket for this? It seems a blocker bug to me!
>>
>> On Fri, Oct 24, 2014 at 1:28 AM, Nux!  wrote:
>>> Ok, so how I "solved" it:
>>>
>>> Followed the upgrade procedure to the letter, but before running
>>> cloudstack-sysvmadm to upgrade my sytemvms I have replaced the QCOW2 file in
>>> the secondary storage with a modified template in which I copied
>>> /opt/cloud/bin/createIpAlias.sh to /opt/cloud/bin/createipAlias.sh (and 
>>> made it
>>> immutable, just to make sure it doesn't go anywhere) ...
>>>
>>> After that I ran "nohup cloudstack-sysvmadm -d IPaddress -u cloud -p 
>>> password -a
>>> > sysvm.log 2>&1 &"
>>>
>>> Ugly, but it works. Thanks for helping me understand where the problem is
>>> exactly..
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>>
>>> - Original Message -
 From: "Daan Hoogland" 
 To: "dev" 
 Sent: Wednesday, 22 October, 2014 14:43:45
 Subject: Re: 431 to 441, VR upgrade fails with VR config: execution failed:
 "/opt/cloud/bin/createipAlias.sh"
>>>
 Jayapal, this was fixed but not in 4.4. why? and why does Lucian not
 hit it in 4.3 that contains the same error?

 On Wed, Oct 22, 2014 at 2:22 PM, Nux!  wrote:
> Ok, you lost me. So what do I need to modify to correct this?
>
> Would customising the sysvm template and symlinking
> /opt/cloud/bin/createIpAlias.sh to /opt/cloud/bin/createipAlias.sh solve 
> the
> issue?
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
>> From: "Jayapal Reddy Uradi" 
>> To: "" 
>> Sent: Wednesday, 22 October, 2014 13:18:05
>> Subject: Re: 431 to 441, VR upgrade fails with VR config: execution 
>> failed:
>> "/opt/cloud/bin/createipAlias.sh"
>
>> Hi Nux,
>>
>> The problem is not from the template.
>> The file in the systemvm.iso has correct file name.
>> VR config feature is referred it as incorrect.
>>
>> Thanks,
>> Jayapal
>> On 22-Oct-2014, at 5:18 PM, Nux!  wrote:
>>
>>> Daan,
>>>
>>> It may be old, but I don't see the problem with the 4.3.0 sysvm tmpl 
>>> (that I am
>>> still using, even with 4.3.1).
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>>
>>> - Original Message -
 From: "Daan Hoogland" 
 To: "dev" 
 Sent: Wednesday, 22 October, 2014 11:40:09
 Subject: Re: 431 to 441, VR upgrade fails with VR config: execution 
 failed:
 "/opt/cloud/bin/createipAlias.sh"
>>>
 Just checked,

 It is fixed in 4.5 but wasn't backported into 4.4. It is old code and
 the problem is in 4.3 as well.

 On Wed, Oct 22, 2014 at 9:39 AM, Nux!  wrote:
> Jayapal,
>
> Thanks, but why are we releasing a faulty systemvm template? Can't we 
> upload a
> new one without the typo?
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
>> From: "Jayapal Reddy Uradi" 
>> To: "" 
>> Sent: Wednesday, 22 October, 2014 05:52:14
>> Subject: Re: 431 to 441, VR upgrade fails with VR config: execution 
>> failed:
>> "/opt/cloud/bin/createipAlias.sh"
>
>> Hi Nux,
>>
>> There is spelling mistake 'i' instead of 'I' in the file name 
>> 'createipAlias.sh'
>>
>> Work around is in VR change createIpAlias.sh -> createipAlias.sh
>> Observe the MS log once the VR entered into Running state stop the 
>> MS so that VR
>> won't be destroyed.
>> Now go to VR and change the file name.
>>
>> This issue got fixed in 4.5 CLOUDSTACK-7246
>>
>> Thanks,
>> Jayapal
>> On 22-Oct-2014, at 6:03 AM, Nux!  wrote:
>>
>>> Hi,
>>>
>>> I almost upgraded from 4.3.1 to 4.4.1, everything went smoothly 
>>> except the VR
>>> upgrade (the other sysvms are fine). It will not upgrade, even if I 
>>> delete it
>>> and create another, same story:
>>>
>>> On the agent I see:
>>>
>>> 20

Re: 431 to 441, VR upgrade fails with VR config: execution failed: "/opt/cloud/bin/createipAlias.sh"

[Nux!]

Yep, https://issues.apache.org/jira/browse/CLOUDSTACK-7781

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Daan Hoogland" 
> To: "dev" 
> Sent: Friday, 24 October, 2014 08:03:59
> Subject: Re: 431 to 441, VR upgrade fails with VR config: execution failed: 
> "/opt/cloud/bin/createipAlias.sh"

> Lucian, did you make a ticket for this? It seems a blocker bug to me!
> 
> On Fri, Oct 24, 2014 at 1:28 AM, Nux!  wrote:
>> Ok, so how I "solved" it:
>>
>> Followed the upgrade procedure to the letter, but before running
>> cloudstack-sysvmadm to upgrade my sytemvms I have replaced the QCOW2 file in
>> the secondary storage with a modified template in which I copied
>> /opt/cloud/bin/createIpAlias.sh to /opt/cloud/bin/createipAlias.sh (and made 
>> it
>> immutable, just to make sure it doesn't go anywhere) ...
>>
>> After that I ran "nohup cloudstack-sysvmadm -d IPaddress -u cloud -p 
>> password -a
>> > sysvm.log 2>&1 &"
>>
>> Ugly, but it works. Thanks for helping me understand where the problem is
>> exactly..
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>> - Original Message -
>>> From: "Daan Hoogland" 
>>> To: "dev" 
>>> Sent: Wednesday, 22 October, 2014 14:43:45
>>> Subject: Re: 431 to 441, VR upgrade fails with VR config: execution failed:
>>> "/opt/cloud/bin/createipAlias.sh"
>>
>>> Jayapal, this was fixed but not in 4.4. why? and why does Lucian not
>>> hit it in 4.3 that contains the same error?
>>>
>>> On Wed, Oct 22, 2014 at 2:22 PM, Nux!  wrote:
 Ok, you lost me. So what do I need to modify to correct this?

 Would customising the sysvm template and symlinking
 /opt/cloud/bin/createIpAlias.sh to /opt/cloud/bin/createipAlias.sh solve 
 the
 issue?

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
> From: "Jayapal Reddy Uradi" 
> To: "" 
> Sent: Wednesday, 22 October, 2014 13:18:05
> Subject: Re: 431 to 441, VR upgrade fails with VR config: execution 
> failed:
> "/opt/cloud/bin/createipAlias.sh"

> Hi Nux,
>
> The problem is not from the template.
> The file in the systemvm.iso has correct file name.
> VR config feature is referred it as incorrect.
>
> Thanks,
> Jayapal
> On 22-Oct-2014, at 5:18 PM, Nux!  wrote:
>
>> Daan,
>>
>> It may be old, but I don't see the problem with the 4.3.0 sysvm tmpl 
>> (that I am
>> still using, even with 4.3.1).
>>
>> --
>> Sent from the Delta quadrant using Borg technology!
>>
>> Nux!
>> www.nux.ro
>>
>> - Original Message -
>>> From: "Daan Hoogland" 
>>> To: "dev" 
>>> Sent: Wednesday, 22 October, 2014 11:40:09
>>> Subject: Re: 431 to 441, VR upgrade fails with VR config: execution 
>>> failed:
>>> "/opt/cloud/bin/createipAlias.sh"
>>
>>> Just checked,
>>>
>>> It is fixed in 4.5 but wasn't backported into 4.4. It is old code and
>>> the problem is in 4.3 as well.
>>>
>>> On Wed, Oct 22, 2014 at 9:39 AM, Nux!  wrote:
 Jayapal,

 Thanks, but why are we releasing a faulty systemvm template? Can't we 
 upload a
 new one without the typo?

 Lucian

 --
 Sent from the Delta quadrant using Borg technology!

 Nux!
 www.nux.ro

 - Original Message -
> From: "Jayapal Reddy Uradi" 
> To: "" 
> Sent: Wednesday, 22 October, 2014 05:52:14
> Subject: Re: 431 to 441, VR upgrade fails with VR config: execution 
> failed:
> "/opt/cloud/bin/createipAlias.sh"

> Hi Nux,
>
> There is spelling mistake 'i' instead of 'I' in the file name 
> 'createipAlias.sh'
>
> Work around is in VR change createIpAlias.sh -> createipAlias.sh
> Observe the MS log once the VR entered into Running state stop the MS 
> so that VR
> won't be destroyed.
> Now go to VR and change the file name.
>
> This issue got fixed in 4.5 CLOUDSTACK-7246
>
> Thanks,
> Jayapal
> On 22-Oct-2014, at 6:03 AM, Nux!  wrote:
>
>> Hi,
>>
>> I almost upgraded from 4.3.1 to 4.4.1, everything went smoothly 
>> except the VR
>> upgrade (the other sysvms are fine). It will not upgrade, even if I 
>> delete it
>> and create another, same story:
>>
>> On the agent I see:
>>
>> 2014-10-22 01:17:17,857 DEBUG [kvm.resource.LibvirtComputingResource]
>> (agentRequest-Handler-5:null) Executing:
>> /usr/share/cloudstack-common/scripts/network/domr/router_proxy.sh 
>> vr_cfg.sh
>> 169.254.1.228 -c 
>> /va

Re: commits on 4.5

[Daan Hoogland]

On Fri, Oct 24, 2014 at 8:36 AM, Leo Simons  wrote:
> Hey Mike,
>
> In git you accomplish these kinds of things with merge strategies. There’s a 
> lot to choose from. What you’re describing sounds a bit like a variant on the 
> “theirs” strategy.
...
doh, will give it another spin. I used 'ours' instead or 'recursive -X
ours'. I think that is what we want except in Mikes usecase where we
would, knowing that there is only this commit to ignore, use 'ours'.


-- 
Daan

Re: [PROPOSAL] Move to github PR only during moratorium on commit

[Daan Hoogland]

Mike, Why have everybody work on the same branch. people can work on
their own branch and when they are done they can rebase on the tip see
ci success and then merge. The problem with forward branches is
abandoned work or work that for some reason shouldn't go in 'this'
release. it will remain there.

On Fri, Oct 24, 2014 at 3:34 AM, Mike Tutkowski
 wrote:
> Are we talking about something like what I drew up here?:
>
> http://i.imgur.com/UgPtJGY.png
>
> In this scheme, the -forward branches are the ones you can directly commit
> to while their peers without the -forward are the ones that code gets
> merged to from its corresponding -forward branch.
>
> CI is performed on the -forward branches before any merging takes place.
>
> The "merge recorded" concept I put in the diagram refers to the situation
> where you have a commit on a branch like 4.5, but you do NOT want it to
> move forward to master.
>
> I don't know if Git has such a concept, but SVN calls this kind of a
> "merge" merge recording. Merge recording essentially means you do not want
> those changes brought forward to the specified branch (not now and not with
> future merges other people or yourself may do).
>
>
>
> On Thu, Oct 23, 2014 at 5:30 PM, Animesh Chaturvedi <
> animesh.chaturv...@citrix.com> wrote:
>
>>
>>
>> > -Original Message-
>> > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
>> > Sent: Thursday, October 23, 2014 1:31 AM
>> > To: dev
>> > Subject: Re: [PROPOSAL] Move to github PR only during moratorium on
>> > commit
>> >
>> > On Thu, Oct 23, 2014 at 10:22 AM, Rohit Yadav
>> >  wrote:
>> > > Hi,
>> > >
>> > >> On 23-Oct-2014, at 11:47 am, Animesh Chaturvedi
>> >  wrote:
>> > ...
>> > >> The approach for fixing issues in release branch first and master
>> later is
>> > not practical as we may miss out commits not made into master and future
>> > release regressing without the fixes.
>> > >
>> > > By the same logic, if we fix by default on master only, the release
>> branch
>> > may miss out commits.
>> >
>> > I sttrongly disagree with Animesh here and think Rohit is overlooking a
>> > simple fact. At the moment the branches are for 'stabalizing'.
>> > Fixing on master first is in direct contradiction with that.
>> >
>> > We have not been stabalizing 4.4. it contains bug that have during the
>> > release periods for 4.4.0 and 4.4.1 been fixed on master. That shouldn't
>> > have been allowed to happen.
>> [Animesh] Clearly we have disagreement. To avoid the issue that you
>> mention David had created forward branch for 4.2 and I found it useful and
>> continued with that approach in 4.3. With forward branch which are really
>> staging it was a simple merge of forward back to release branch. The other
>> approach of merging release branch into master work as well but in my
>> opinion keeping master as the default branch (with protection of course )
>> is simpler to understand and creates less confusion
>>
>>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*



-- 
Daan

Re: [PROPOSAL] Move to github PR only during moratorium on commit

[Daan Hoogland]

On Fri, Oct 24, 2014 at 1:30 AM, Animesh Chaturvedi
 wrote:

>> I sttrongly disagree with Animesh here and think Rohit is overlooking a
>> simple fact. At the moment the branches are for 'stabalizing'.
>> Fixing on master first is in direct contradiction with that.
>>
>> We have not been stabalizing 4.4. it contains bug that have during the
>> release periods for 4.4.0 and 4.4.1 been fixed on master. That shouldn't
>> have been allowed to happen.
> [Animesh] Clearly we have disagreement. To avoid the issue that you mention 
> David had created forward branch for 4.2 and I found it useful and continued 
> with that approach in 4.3. With forward branch which are really staging it 
> was a simple merge of forward back to release branch. The other approach of 
> merging release branch into master work as well but in my opinion keeping 
> master as the default branch (with protection of course ) is simpler to 
> understand and creates less confusion
>

I abandoned that approach as cherry-picking started to give
complicated conflicts that I could not resolve. Also one particular
conflict, the one in the db upgrade script, kept coming back. This has
cost me a lot of time for work that was not there to begin with. Hence
my big aversion of the forward branches.


-- 
Daan

Re: 431 to 441, VR upgrade fails with VR config: execution failed: "/opt/cloud/bin/createipAlias.sh"

[Daan Hoogland]

Lucian, did you make a ticket for this? It seems a blocker bug to me!

On Fri, Oct 24, 2014 at 1:28 AM, Nux!  wrote:
> Ok, so how I "solved" it:
>
> Followed the upgrade procedure to the letter, but before running 
> cloudstack-sysvmadm to upgrade my sytemvms I have replaced the QCOW2 file in 
> the secondary storage with a modified template in which I copied 
> /opt/cloud/bin/createIpAlias.sh to /opt/cloud/bin/createipAlias.sh (and made 
> it immutable, just to make sure it doesn't go anywhere) ...
>
> After that I ran "nohup cloudstack-sysvmadm -d IPaddress -u cloud -p password 
> -a > sysvm.log 2>&1 &"
>
> Ugly, but it works. Thanks for helping me understand where the problem is 
> exactly..
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
>> From: "Daan Hoogland" 
>> To: "dev" 
>> Sent: Wednesday, 22 October, 2014 14:43:45
>> Subject: Re: 431 to 441, VR upgrade fails with VR config: execution failed: 
>> "/opt/cloud/bin/createipAlias.sh"
>
>> Jayapal, this was fixed but not in 4.4. why? and why does Lucian not
>> hit it in 4.3 that contains the same error?
>>
>> On Wed, Oct 22, 2014 at 2:22 PM, Nux!  wrote:
>>> Ok, you lost me. So what do I need to modify to correct this?
>>>
>>> Would customising the sysvm template and symlinking
>>> /opt/cloud/bin/createIpAlias.sh to /opt/cloud/bin/createipAlias.sh solve the
>>> issue?
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>>
>>> - Original Message -
 From: "Jayapal Reddy Uradi" 
 To: "" 
 Sent: Wednesday, 22 October, 2014 13:18:05
 Subject: Re: 431 to 441, VR upgrade fails with VR config: execution failed:
 "/opt/cloud/bin/createipAlias.sh"
>>>
 Hi Nux,

 The problem is not from the template.
 The file in the systemvm.iso has correct file name.
 VR config feature is referred it as incorrect.

 Thanks,
 Jayapal
 On 22-Oct-2014, at 5:18 PM, Nux!  wrote:

> Daan,
>
> It may be old, but I don't see the problem with the 4.3.0 sysvm tmpl 
> (that I am
> still using, even with 4.3.1).
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
>> From: "Daan Hoogland" 
>> To: "dev" 
>> Sent: Wednesday, 22 October, 2014 11:40:09
>> Subject: Re: 431 to 441, VR upgrade fails with VR config: execution 
>> failed:
>> "/opt/cloud/bin/createipAlias.sh"
>
>> Just checked,
>>
>> It is fixed in 4.5 but wasn't backported into 4.4. It is old code and
>> the problem is in 4.3 as well.
>>
>> On Wed, Oct 22, 2014 at 9:39 AM, Nux!  wrote:
>>> Jayapal,
>>>
>>> Thanks, but why are we releasing a faulty systemvm template? Can't we 
>>> upload a
>>> new one without the typo?
>>>
>>> Lucian
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>>
>>> - Original Message -
 From: "Jayapal Reddy Uradi" 
 To: "" 
 Sent: Wednesday, 22 October, 2014 05:52:14
 Subject: Re: 431 to 441, VR upgrade fails with VR config: execution 
 failed:
 "/opt/cloud/bin/createipAlias.sh"
>>>
 Hi Nux,

 There is spelling mistake 'i' instead of 'I' in the file name 
 'createipAlias.sh'

 Work around is in VR change createIpAlias.sh -> createipAlias.sh
 Observe the MS log once the VR entered into Running state stop the MS 
 so that VR
 won't be destroyed.
 Now go to VR and change the file name.

 This issue got fixed in 4.5 CLOUDSTACK-7246

 Thanks,
 Jayapal
 On 22-Oct-2014, at 6:03 AM, Nux!  wrote:

> Hi,
>
> I almost upgraded from 4.3.1 to 4.4.1, everything went smoothly 
> except the VR
> upgrade (the other sysvms are fine). It will not upgrade, even if I 
> delete it
> and create another, same story:
>
> On the agent I see:
>
> 2014-10-22 01:17:17,857 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-5:null) Executing:
> /usr/share/cloudstack-common/scripts/network/domr/router_proxy.sh 
> vr_cfg.sh
> 169.254.1.228 -c 
> /var/cache/cloud/VR-5109f323-dc37-4af2-b75d-41dd65acbf93.cfg
> 2014-10-22 01:17:17,934 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-5:null) Exit value is 1
> 2014-10-22 01:17:17,934 DEBUG [kvm.resource.LibvirtComputingResource]
> (agentRequest-Handler-5:null) VR config: execution failed:
> "/opt/cloud/bin/createipAlias.sh
> 289:10.13.208.78:255.255.255.248-224:10.187.71.194:255.255.255.192-", 
> check
> /var/log/cloud.log in VR f