Re: [ANNOUNCE] New PMC Member: Pierre-Luc Dion

[Rajani Karuturi]

Congratulations Pierre-Luc!!

~Rajani

On Wed, Oct 1, 2014 at 11:24 PM, Pierre-Luc Dion  wrote:

> Thanks guys!
>
>
> PL
>
> On Wed, Oct 1, 2014 at 1:36 PM, Nux!  wrote:
>
> > Congrats, Pierre-Luc! :)
> >
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro
> >
> > - Original Message -
> > > From: "Chip Childers" 
> > > To: dev@cloudstack.apache.org
> > > Sent: Tuesday, 30 September, 2014 14:50:40
> > > Subject: [ANNOUNCE] New PMC Member: Pierre-Luc Dion
> >
> > > The Project Management Committee (PMC) for Apache CloudStack has asked
> > > Pierre-Luc Dion to join the PMC and we are pleased to announce that he
> > > has accepted.
> > >
> > > Join me in congratulating Pierre-Luc!
> > >
> > > -chip
> > > On behalf of the Apache CloudStack PMC
> >
>

Re: [ANNOUNCE] New PMC Member: Ian Duffy

[Rajani Karuturi]

Congratulations Ian!!

~Rajani

On Wed, Oct 1, 2014 at 11:05 PM, Nux!  wrote:

> Congrats, Ian, good job! :)
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>
> - Original Message -
> > From: "Chip Childers" 
> > To: dev@cloudstack.apache.org
> > Sent: Tuesday, 30 September, 2014 14:50:42
> > Subject: [ANNOUNCE] New PMC Member: Ian Duffy
>
> > The Project Management Committee (PMC) for Apache CloudStack has asked
> > Ian Duffy to join the PMC and we are pleased to announce that he has
> > accepted.
> >
> > Join me in congratulating Ian!
> >
> > -chip
> > On behalf of the Apache CloudStack PMC
>

Re: Can't launch VMs

[Daan Hoogland]

I am not sure Carlos, but I think it was due to a fix of some other network
related issue in 4.3.1. I thought we wrote an update/fix for it. So I am
looking at how your env missed out.

On Sun, Oct 5, 2014 at 1:10 AM, Carlos Reátegui  wrote:

> Sure, but I am not sure if the problem happened when I upgraded to 4.3.0
> or 4.3.1.  When (what version) did the broadcast_uri in the network table
> require an entry for Guest networks and not able to be null?
>
>
> On Oct 4, 2014, at 4:15 AM, Daan Hoogland  wrote:
>
> Carlos, I think you found a bug in our upgrade scripts. Can you describe
> the scenario in a ticket?
>
> On Sat, Oct 4, 2014 at 1:48 AM, Carlos Reátegui 
> wrote:
>
>> Hmm.  I just checked another deployment I did with 4.4.0 using the same
>> zone type and network offering and it has the broadcast_uri set to
>> vlan://untagged.
>>
>> I also checked previous backups from older versions (4.10 and 4.2.1) and
>> in all of those the broadcast_uri was blank.  I am wondering if this is a
>> bug in the upgrade scripts.
>>
>> I updated network 204 and set the broadcast_uri and now I am able to
>> start new instances.
>>
>> thank you for your help!
>>
>> I am including my nics table just in case you spot something else out of
>> the ordinary.
>>
>> mysql> select id, instance_id, network_id, netmask, gateway, ip4_address,
>> broadcast_uri, mode, state, strategy from nics where network_id=204 order
>> by ip4_address;
>>
>> +-+-++---+-+---+-+--+--+-+
>> | id  | instance_id | network_id | netmask   | gateway |
>> ip4_address   | broadcast_uri   | mode | state| strategy|
>>
>> +-+-++---+-+---+-+--+--+-+
>> |  60 |  52 |204 | NULL  | NULL| NULL
>>  | NULL| Dhcp | Deallocating | Start   |
>> |  64 |  53 |204 | NULL  | NULL| NULL
>>  | NULL| Dhcp | Deallocating | Start   |
>> |  68 |  54 |204 | NULL  | NULL| NULL
>>  | NULL| Dhcp | Deallocating | Start   |
>> |  72 |  55 |204 | NULL  | NULL| NULL
>>  | NULL| Dhcp | Deallocating | Start   |
>> |  76 |  56 |204 | NULL  | NULL| NULL
>>  | NULL| Dhcp | Deallocating | Start   |
>> |  30 |  21 |204 | 255.255.255.0 | 172.30.45.1 |
>> 172.30.45.100 | vlan://untagged | Dhcp | Deallocating | Start   |
>> |  32 |  23 |204 | 255.255.255.0 | 172.30.45.1 |
>> 172.30.45.100 | vlan://untagged | Dhcp | Deallocating | Start   |
>> |  43 |  34 |204 | 255.255.255.0 | 172.30.45.1 |
>> 172.30.45.100 | vlan://untagged | Dhcp | Deallocating | Start   |
>> |  47 |  38 |204 | 255.255.255.0 | 172.30.45.1 |
>> 172.30.45.100 | vlan://untagged | Dhcp | Reserved | Start   |
>> |   1 |   1 |204 | 255.255.255.0 | 172.30.45.1 |
>> 172.30.45.101 | vlan://untagged | Dhcp | Deallocating | Start   |
>> |  13 |   5 |204 | 255.255.255.0 | 172.30.45.1 |
>> 172.30.45.101 | vlan://untagged | Dhcp | Deallocating | Start   |
>> |  87 |  59 |204 | 255.255.255.0 | 172.30.45.1 |
>> 172.30.45.101 | vlan://untagged | Dhcp | Deallocating | Start   |
>> | 116 |NULL |204 | NULL  | 172.30.45.1 |
>> 172.30.45.101 | NULL| NULL | Reserved | PlaceHolder |
>> | 120 |  91 |204 | 255.255.255.0 | 172.30.45.1 |
>> 172.30.45.101 | vlan://untagged | Dhcp | Reserved | Start   |
>> |  23 |  14 |204 | 255.255.255.0 | 172.30.45.1 |
>> 172.30.45.102 | vlan://untagged | Dhcp | Reserved | Start   |
>> |  21 |  12 |204 | 255.255.255.0 | 172.30.45.1 |
>> 172.30.45.103 | vlan://untagged | Dhcp | Deallocating | Start   |
>> | 109 |  81 |204 | 255.255.255.0 | 172.30.45.1 |
>> 172.30.45.103 | vlan://untagged | Dhcp | Deallocating | Start   |
>> |   4 |   2 |204 | 255.255.255.0 | 172.30.45.1 |
>> 172.30.45.104 | vlan://untagged | Dhcp | Deallocating | Start   |
>> |  84 |  58 |204 | 255.255.255.0 | 172.30.45.1 |
>> 172.30.45.104 | vlan://untagged | Dhcp | Deallocating | Start   |
>> |  89 |  60 |204 | 255.255.255.0 | 172.30.45.1 |
>> 172.30.45.104 | vlan://untagged | Dhcp | Deallocating | Start   |
>> | 117 |  90 |204 | 255.255.255.0 | 172.30.45.1 |
>> 172.30.45.104 | vlan://untagged | Dhcp | Reserved | Start   |
>> |  19 |  10 |204 | 255.255.255.0 | 172.30.45.1 |
>> 172.30.45.105 | vlan://untagged | Dhcp | Reserved | Start   |
>> |  34 |  25 |204 | 255.255.255.0 | 172.

[VOTE][ACS44]Apache CloudStack 4.4.1 RC 1 in branch 4.4-RC20141006T1046

[Daan Hoogland]

Hi All,

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

Git Branch and Commit SH:
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20141006T1046
Commit: 3d8c09dd146241fedda2f0167dcd60fdf66b0b1d

List of changes:
http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/

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

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

Vote will be open for 72 hours.

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

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

-- 
Daan

Review Request 26356: [RHEL7] management server failed to start once machine is rebooted

[Damodar Reddy Talakanti]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26356/
---

Review request for cloudstack and Rayees Namathponnan.


Bugs: CLOUDSTACK-7671
https://issues.apache.org/jira/browse/CLOUDSTACK-7671


Repository: cloudstack-git


Description
---

After you install management server on rhel 7 and start the server. Now try to 
reboot the machine and start management server then it will fail to start as 
pid file is not able to create as cloud user.


Diffs
-

  packaging/centos63/cloud.spec 7306d1f 
  packaging/centos63/default/macros.spec f3c937c 
  packaging/centos63/rhel7/cloudstack-management.conf PRE-CREATION 
  packaging/centos63/rhel7/macros.spec 4b71092 

Diff: https://reviews.apache.org/r/26356/diff/


Testing
---

Tested on RHEL-7 and RHEL 6.2 servers.

Installed and re booted the machines..


Thanks,

Damodar Reddy Talakanti

Re: Review Request 26356: [RHEL7] management server failed to start once machine is rebooted

[Damodar Reddy Talakanti]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26356/
---

(Updated Oct. 6, 2014, 9:45 a.m.)


Review request for cloudstack, Kishan Kavala and Rayees Namathponnan.


Changes
---

Adding Kishan


Bugs: CLOUDSTACK-7671
https://issues.apache.org/jira/browse/CLOUDSTACK-7671


Repository: cloudstack-git


Description
---

After you install management server on rhel 7 and start the server. Now try to 
reboot the machine and start management server then it will fail to start as 
pid file is not able to create as cloud user.


Diffs
-

  packaging/centos63/cloud.spec 7306d1f 
  packaging/centos63/default/macros.spec f3c937c 
  packaging/centos63/rhel7/cloudstack-management.conf PRE-CREATION 
  packaging/centos63/rhel7/macros.spec 4b71092 

Diff: https://reviews.apache.org/r/26356/diff/


Testing
---

Tested on RHEL-7 and RHEL 6.2 servers.

Installed and re booted the machines..


Thanks,

Damodar Reddy Talakanti

Re: [VOTE][ACS44]Apache CloudStack 4.4.1 RC 2 in branch 4.4-RC20141006T1046

[Daan Hoogland]

changing subject due to a c&p bug, thanks Geoff

On Mon, Oct 6, 2014 at 10:56 AM, Daan Hoogland 
wrote:

> Hi All,
>
> I've created a 4.4.1 release, with the following artifacts up for a vote:
>
> Git Branch and Commit SH:
>
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20141006T1046
> Commit: 3d8c09dd146241fedda2f0167dcd60fdf66b0b1d
>
> List of changes:
>
> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/
>
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.4.1/
>
> PGP release keys (signed using 4096R/AA4736F3):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> Vote will be open for 72 hours.
>
> For sanity in tallying the vote, can PMC members please be sure to
> indicate "(binding)" with their vote?
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> --
> Daan
>



-- 
Daan

Re: Review Request 25885: CLOUDSTACK-7594: Adding automation test cases for Stopped VM test path

[suresh sadhu]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/25885/#review55486
---


def test_03_pt_deploy_vm_with_startvm_false(self):

in test03,why are we checking for routervm stop state when we are deploying vm 
in stopped state.

- suresh sadhu


On Oct. 1, 2014, 9:18 a.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25885/
> ---
> 
> (Updated Oct. 1, 2014, 9:18 a.m.)
> 
> 
> Review request for cloudstack, suresh sadhu and SrikanteswaraRao Talluri.
> 
> 
> Bugs: CLOUDSTACK-7594
> https://issues.apache.org/jira/browse/CLOUDSTACK-7594
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Automation test cases for Stopped VM test path.
> 
> 
> Diffs
> -
> 
>   test/integration/testpaths/testpath_stopped_vm.py PRE-CREATION 
>   tools/marvin/marvin/lib/base.py d623386 
> 
> Diff: https://reviews.apache.org/r/25885/diff/
> 
> 
> Testing
> ---
> 
> Yes.
> 
> Advanced zone:
> Positive test for stopped VM test path - T1 ... === TestName: 
> test_01_pt_deploy_vm_without_startvm | Status : SUCCESS ===
> ok
> Positive test for stopped VM test path - T1 variant ... === TestName: 
> test_02_pt_deploy_vm_with_startvm_true | Status : SUCCESS ===
> ok
> Positive test for stopped VM test path - T2 ... === TestName: 
> test_03_pt_deploy_vm_with_startvm_false | Status : SUCCESS ===
> ok
> Positive test for stopped VM test path - T3 and variant, T9 ... === TestName: 
> test_04_pt_startvm_false_attach_disk | Status : SUCCESS ===
> ok
> Positive test for stopped VM test path - T4 ... === TestName: 
> test_05_pt_startvm_false_attach_disk_change_SO | Status : SUCCESS ===
> ok
> Positive test for stopped VM test path - T5 ... === TestName: 
> test_06_pt_startvm_false_attach_iso | Status : SUCCESS ===
> ok
> Positive test for stopped VM test path - T5 variant ... === TestName: 
> test_07_pt_startvm_false_attach_iso_running_vm | Status : SUCCESS ===
> ok
> Positive test for stopped VM test path - T10 ... === TestName: 
> test_08_pt_startvm_false_password_enabled_template | Status : SUCCESS ===
> ok
> Positive test for stopped VM test path - T11 ... === TestName: 
> test_09_pt_destroy_stopped_vm | Status : SUCCESS ===
> ok
> Positive test for stopped VM test path - T12 ... === TestName: 
> test_10_max_account_limit | Status : SUCCESS ===
> ok
> 
> 
> Basic zone:
> 
> Positive test for stopped VM test path - T1 ... === TestName: 
> test_01_pt_deploy_vm_without_startvm | Status : SUCCESS ===
> ok
> Positive test for stopped VM test path - T1 variant ... === TestName: 
> test_02_pt_deploy_vm_with_startvm_true | Status : SUCCESS ===
> ok
> Positive test for stopped VM test path - T2 ... === TestName: 
> test_03_pt_deploy_vm_with_startvm_false | Status : SUCCESS ===
> ok
> Positive test for stopped VM test path - T3 and variant, T9 ... === TestName: 
> test_04_pt_startvm_false_attach_disk | Status : SUCCESS ===
> ok
> Positive test for stopped VM test path - T4 ... === TestName: 
> test_05_pt_startvm_false_attach_disk_change_SO | Status : SUCCESS ===
> ok
> Positive test for stopped VM test path - T5 ... === TestName: 
> test_06_pt_startvm_false_attach_iso | Status : SUCCESS ===
> ok
> Positive test for stopped VM test path - T5 variant ... === TestName: 
> test_07_pt_startvm_false_attach_iso_running_vm | Status : SUCCESS ===
> ok
> Positive test for stopped VM test path - T10 ... === TestName: 
> test_08_pt_startvm_false_password_enabled_template | Status : SUCCESS ===
> ok
> Positive test for stopped VM test path - T11 ... === TestName: 
> test_09_pt_destroy_stopped_vm | Status : SUCCESS ===
> ok
> Positive test for stopped VM test path - T12 ... === TestName: 
> test_10_max_account_limit | Status : SUCCESS ===
> ok
> 
> --
> Ran 10 tests in 2792.968s
> 
> OK
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

[MASTER-SNMP Alerts] - Trying to test Master, but building is failing

[Wilder Rodrigues]

Hi all,

Just clone master and tried to build the simulator in order to start testing. 
Unfortunately, did not pass SNMP Alerts module:


---

 T E S T S

---

Running org.apache.cloudstack.alert.snmp.SnmpEnhancedPatternLayoutTest

Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.293 sec

Running org.apache.cloudstack.alert.snmp.SnmpTrapAppenderTest

log4j:ERROR  Error in crearting snmp object, sbpltk1zffh04: sbpltk1zffh04: 
nodename nor servname provided, or not known

log4j:ERROR  Invalid format for the IP Addresses or Ports parameter

log4j:ERROR  size of ip addresses , communities, and ports list doesn't match, 
setting all to null

log4j:ERROR  size of ip addresses , communities, and ports list doesn't match, 
setting all to null

log4j:ERROR  Invalid format for the IP Addresses or Ports parameter

Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.058 sec <<< 
FAILURE!


Results :


Failed tests:   
appendTest(org.apache.cloudstack.alert.snmp.SnmpTrapAppenderTest):  error 
snmpHelper list size not as expected  expected:<0> but was:<2>


Tests run: 9, Failures: 1, Errors: 0, Skipped: 0

Is there anyone looking into this already?

Cheers,
Wilder

Re: [VOTE][ACS44]Apache CloudStack 4.4.1 RC 1 in branch 4.4-RC20141006T1046

[Mike Tutkowski]

+1 (binding)

On Monday, October 6, 2014, Daan Hoogland  wrote:

> Hi All,
>
> I've created a 4.4.1 release, with the following artifacts up for a vote:
>
> Git Branch and Commit SH:
>
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20141006T1046
> Commit: 3d8c09dd146241fedda2f0167dcd60fdf66b0b1d
>
> List of changes:
>
> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/
>
> Source release (checksums and signatures are available at the same
> location):
> https://dist.apache.org/repos/dist/dev/cloudstack/4.4.1/
>
> PGP release keys (signed using 4096R/AA4736F3):
> https://dist.apache.org/repos/dist/release/cloudstack/KEYS
>
> Vote will be open for 72 hours.
>
> For sanity in tallying the vote, can PMC members please be sure to
> indicate "(binding)" with their vote?
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> --
> 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
*™*

Review Request 26361: CLOUDSTACK-7660: Enhance system vm template to support baremetal

[Harikrishna Patnala]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26361/
---

Review request for cloudstack and Frank Zhang.


Bugs: CLOUDSTACK-7660
https://issues.apache.org/jira/browse/CLOUDSTACK-7660


Repository: cloudstack-git


Description
---

CLOUDSTACK-7660: Enhance system vm template to support baremetal
Installed Package flask and merged the disk partition


Please review the merging part of disk partitions.


Diffs
-

  systemvm/patches/debian/buildsystemvm.sh 7f6188a 
  tools/appliance/definitions/systemvmtemplate/preseed.cfg 0d2f70b 

Diff: https://reviews.apache.org/r/26361/diff/


Testing
---


Thanks,

Harikrishna Patnala

Re: Review Request 26361: CLOUDSTACK-7660: Enhance system vm template to support baremetal

[Harikrishna Patnala]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26361/
---

(Updated Oct. 6, 2014, 2:06 p.m.)


Review request for cloudstack, Frank Zhang and Sateesh Chodapuneedi.


Bugs: CLOUDSTACK-7660
https://issues.apache.org/jira/browse/CLOUDSTACK-7660


Repository: cloudstack-git


Description
---

CLOUDSTACK-7660: Enhance system vm template to support baremetal
Installed Package flask and merged the disk partition


Please review the merging part of disk partitions.


Diffs
-

  systemvm/patches/debian/buildsystemvm.sh 7f6188a 
  tools/appliance/definitions/systemvmtemplate/preseed.cfg 0d2f70b 

Diff: https://reviews.apache.org/r/26361/diff/


Testing
---


Thanks,

Harikrishna Patnala

Review Request 26364: CLOUDSTACK-7673 Handle multiple gateways in test_ssvm.py

[Alex Brett]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26364/
---

Review request for cloudstack and SrikanteswaraRao Talluri.


Bugs: CLOUDSTACK-7673
https://issues.apache.org/jira/browse/CLOUDSTACK-7673


Repository: cloudstack-git


Description
---

In some situations (e.g. EIP) listVlanRanges can return multiple entries,
however the checks in test_ssvm.py were only ever looking at the first result,
therefore these tests could incorrectly fail.

Modify the check to look at all returned gateways for a match


Diffs
-

  test/integration/smoke/test_ssvm.py 5713569 

Diff: https://reviews.apache.org/r/26364/diff/


Testing
---

Verified the tests pass in a normal scenario


Thanks,

Alex Brett

Re: Review Request 25772: new nfs storage adapter for kvm hypervisor plugin to support managed storage.[CLOUDSTACK-7576].

[Marcus Sorensen]

> On Oct. 6, 2014, 4:50 a.m., Marcus Sorensen wrote:
> > It looks pretty straightforward, doesn't look like it will break anything, 
> > and sounds like it works, so I'm ok with it.  It looks like this performs a 
> > "1 qcow2 vol per nfs mount" type storage?
> 
> Mike Tutkowski wrote:
> Hey Marcus,
> 
> If you're OK with this, do you have time to check it in to Git?
> 
> Thanks!
> Mike
> 
> punith s wrote:
> hi marcus,
> 
> yes it's a 1:1 mapping between a qcow2 vol per nfs dataset
> 
> thanks

I'm not sure I know how to properly check this into git. I've been following 
the mailing list just closely enough to know that there's been some changes 
proposed to how we check things in, and that master is perhaps frozen right now.


- Marcus


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/25772/#review55480
---


On Oct. 6, 2014, 4:22 a.m., punith s wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/25772/
> ---
> 
> (Updated Oct. 6, 2014, 4:22 a.m.)
> 
> 
> Review request for cloudstack, Mike Tutkowski and Marcus Sorensen.
> 
> 
> Bugs: CLOUDSTACK-7576
> https://issues.apache.org/jira/browse/CLOUDSTACK-7576
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> this adapter provides one to one mapping between the SAN volume to a VM's 
> disk, so that it can guarantee the QoS for the performance sensitive 
> applications residing on the disk.
> this adapter is based on nfs protocol.
> 
> features being supported:
> * attach volume
> * detach volume
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/agent/api/to/DiskTO.java afab856 
>   api/src/com/cloud/storage/Storage.java 4d267eb 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStoragePoolManager.java
>  f44bb03 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStoragePool.java
>  1a756cb 
>   
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/ManagedNfsStorageAdaptor.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/25772/diff/
> 
> 
> Testing
> ---
> 
> system testing done
> 
> 
> File Attachments
> 
> 
> architecture
>   
> https://reviews.apache.org/media/uploaded/files/2014/09/18/86449aef-17f3-49fb-b087-be74fade231a__ACS_cloudbyte_integration_with_KVM_for_guaranteeing_QoS_at_VM_level.__.jpg
> 
> 
> Thanks,
> 
> punith s
> 
>

Checking in to 4.5

[Mike Tutkowski]

Hi David,

So, I know we're a ways past code freeze, but we seem to have been
(rightly) focusing more of our dev effort as a community on 4.3.1 and 4.4.1
lately.

It seems that check-ins have gone into master in the recent past and that
you felt they should not be reverted.

That being the case, Marcus and I have completed a review of the following
and were wondering if it would be OK to put it in master?

https://reviews.apache.org/r/25772/

Thanks!

-- 
*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: Shellshock

[Leo Simons]

On Oct 3, 2014, at 4:03 PM, Alex Brett  wrote:
> On 03 October 2014 13:52, Adrian Lewis [adr...@alsiconsulting.co.uk] wrote:
>> The only solution I can think of is to 'apt-get update bash' on every
>> system VM but clearly these get fired up dynamically. Is it possible to
>> boot the template, make modifications and then use as a replacement system
>> VM? Are there processes that happen on boot that only happen once and
>> therefore need resetting to recreate the template?
> 
> This isn't a quick fix, so not suitable for this specific issue, but 
> something I've wondered for a while is rather than keep having to build new 
> system VM templates for every small change, would we be better integrating a 
> tool such as Puppet / Chef, so we can bring a system VM 'up to date' when it 
> boots, as long as it's the right 'base'.
> 
> What I'm thinking here (using Puppet terminology as that's what I'm familiar 
> with, but could be any similar mechanism or even just a simple script) is 
> when the system VM loads up, it connects to the management server and 
> retrieves a manifest, which it then applies. That manifest would specify:
> - Packages to update (including if necessary any apt/yum repo information)
> - Config files to put in place
> - Anything else required like starting any services etc
> 
> While it would slightly delay the boot process, it would ensure that on e.g. 
> upgrade, you don't have to immediately replace your system VM template unless 
> a substantial change (e.g. base system VM distro / partition layout) has been 
> made. You could still bring in an updated template to speed things up, but it 
> would be far less urgent to do so...
> 
> Any thoughts on this anybody?

We've had the same thoughts and investigated it in some detail, 
78f21166c10f291fca395c6ab8d67b7137e0ea86 is about the last point before we 
abandoned that approach.

https://github.com/schubergphilis/cloudstack/blob/78f21166c10f291fca395c6ab8d67b7137e0ea86/systemvm/patches/debian/config/opt/cloud/bin/merge.py
https://github.com/schubergphilis/cloudstack/tree/78f21166c10f291fca395c6ab8d67b7137e0ea86/tools/vagrant/systemvm

the idea was that all systemvm configuration would take the shape of chef data 
bags passed along from the management server, that would then be used to 
configure chef cookbooks that would be executed using chef-solo.

We abandoned this approach because running chef-solo took too long and used too 
many resources; I think a similar argument would hold against ‘puppet apply’. 
The systemvm when deployed as a router is a network device and I guess in 
general that having heavy processes running periodically on active network 
devices is a bit scary.

So now the "persistent config" part of our redundant vpc router branch is still 
using the configuration management model of converging to a desired state, but 
written using a less fancy but more efficient and predictable custom python 
script.

https://github.com/schubergphilis/cloudstack/blob/feature/systemvm-persistent-config/systemvm/patches/debian/config/opt/cloud/bin/configure.py

Having said all that, I agree with Logan that

On Oct 3, 2014, at 5:30 PM, Logan Barfield  wrote:
> In the long term I think the better option would be to allow
> the templates to be patched more easily (i.e. make changes and save the
> template).

Right now we resort to custom template builds a times, as well as various bits 
of cloudmonkey or marvin scripting to find and iterate over system vms and do 
things to them (like apply bash patches). It’s possible to do this stuff but it 
isn’t easy, and it would definitely be good to have a well-beaten path for 
operators to wander down.

I’m not sure having the management server assume responsibility over some of 
the systemvm patching would be good: it could get into conflict with operators 
wanting to do their own / slightly different patching. It’d have to be an 
appropriately ‘open’ design which then brings with it its own set of security 
considerations.


cheers,


Leo

Re: Shellshock

[Logan Barfield]

I would suggest that having some sort of built in functionality tied to the
management server would be a good thing, but don't make it overbearing.  If
operators have their own patch methodolgies right now that's fine, and they
should be able to continue to use them.  For smaller shops or operations
teams with limited development experience an 'official' patch method would
be great.

I know we've run into quite a few bugs and operations problems that
required us to update the code and re-compile CloudStack, or implement some
sort of hack, or wait until the next release.  These options shouldn't be
the norm; in other words operations teams (not development, not devops,
actual sysadmins) shoulnd't need to wait on the developers to apply fixes
or changes.


Thank You,

Logan Barfield
Tranquil Hosting

On Mon, Oct 6, 2014 at 1:03 PM, Leo Simons 
wrote:

> On Oct 3, 2014, at 4:03 PM, Alex Brett  wrote:
> > On 03 October 2014 13:52, Adrian Lewis [adr...@alsiconsulting.co.uk]
> wrote:
> >> The only solution I can think of is to 'apt-get update bash' on every
> >> system VM but clearly these get fired up dynamically. Is it possible to
> >> boot the template, make modifications and then use as a replacement
> system
> >> VM? Are there processes that happen on boot that only happen once and
> >> therefore need resetting to recreate the template?
> >
> > This isn't a quick fix, so not suitable for this specific issue, but
> something I've wondered for a while is rather than keep having to build new
> system VM templates for every small change, would we be better integrating
> a tool such as Puppet / Chef, so we can bring a system VM 'up to date' when
> it boots, as long as it's the right 'base'.
> >
> > What I'm thinking here (using Puppet terminology as that's what I'm
> familiar with, but could be any similar mechanism or even just a simple
> script) is when the system VM loads up, it connects to the management
> server and retrieves a manifest, which it then applies. That manifest would
> specify:
> > - Packages to update (including if necessary any apt/yum repo
> information)
> > - Config files to put in place
> > - Anything else required like starting any services etc
> >
> > While it would slightly delay the boot process, it would ensure that on
> e.g. upgrade, you don't have to immediately replace your system VM template
> unless a substantial change (e.g. base system VM distro / partition layout)
> has been made. You could still bring in an updated template to speed things
> up, but it would be far less urgent to do so...
> >
> > Any thoughts on this anybody?
>
> We've had the same thoughts and investigated it in some detail,
> 78f21166c10f291fca395c6ab8d67b7137e0ea86 is about the last point before we
> abandoned that approach.
>
>
> https://github.com/schubergphilis/cloudstack/blob/78f21166c10f291fca395c6ab8d67b7137e0ea86/systemvm/patches/debian/config/opt/cloud/bin/merge.py
>
> https://github.com/schubergphilis/cloudstack/tree/78f21166c10f291fca395c6ab8d67b7137e0ea86/tools/vagrant/systemvm
>
> the idea was that all systemvm configuration would take the shape of chef
> data bags passed along from the management server, that would then be used
> to configure chef cookbooks that would be executed using chef-solo.
>
> We abandoned this approach because running chef-solo took too long and
> used too many resources; I think a similar argument would hold against
> ‘puppet apply’. The systemvm when deployed as a router is a network device
> and I guess in general that having heavy processes running periodically on
> active network devices is a bit scary.
>
> So now the "persistent config" part of our redundant vpc router branch is
> still using the configuration management model of converging to a desired
> state, but written using a less fancy but more efficient and predictable
> custom python script.
>
>
> https://github.com/schubergphilis/cloudstack/blob/feature/systemvm-persistent-config/systemvm/patches/debian/config/opt/cloud/bin/configure.py
>
> Having said all that, I agree with Logan that
>
> On Oct 3, 2014, at 5:30 PM, Logan Barfield 
> wrote:
> > In the long term I think the better option would be to allow
> > the templates to be patched more easily (i.e. make changes and save the
> > template).
>
> Right now we resort to custom template builds a times, as well as various
> bits of cloudmonkey or marvin scripting to find and iterate over system vms
> and do things to them (like apply bash patches). It’s possible to do this
> stuff but it isn’t easy, and it would definitely be good to have a
> well-beaten path for operators to wander down.
>
> I’m not sure having the management server assume responsibility over some
> of the systemvm patching would be good: it could get into conflict with
> operators wanting to do their own / slightly different patching. It’d have
> to be an appropriately ‘open’ design which then brings with it its own set
> of security considerations.
>
>
> cheers,
>
>
> Leo
>
>

Re: [VOTE][ACS44]Apache CloudStack 4.4.1 RC 1 in branch 4.4-RC20141006T1046

[Marcus]

Is it just me, or does this branch/commit not exist?

On Mon, Oct 6, 2014 at 7:42 AM, Mike Tutkowski  wrote:

> +1 (binding)
>
> On Monday, October 6, 2014, Daan Hoogland  wrote:
>
> > Hi All,
> >
> > I've created a 4.4.1 release, with the following artifacts up for a vote:
> >
> > Git Branch and Commit SH:
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20141006T1046
> > Commit: 3d8c09dd146241fedda2f0167dcd60fdf66b0b1d
> >
> > List of changes:
> >
> >
> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/
> >
> > Source release (checksums and signatures are available at the same
> > location):
> > https://dist.apache.org/repos/dist/dev/cloudstack/4.4.1/
> >
> > PGP release keys (signed using 4096R/AA4736F3):
> > https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> >
> > Vote will be open for 72 hours.
> >
> > For sanity in tallying the vote, can PMC members please be sure to
> > indicate "(binding)" with their vote?
> >
> > [ ] +1  approve
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >
> > --
> > 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: Can't launch VMs

[Carlos Reátegui]

Let me know if you require more detail:

https://issues.apache.org/jira/browse/CLOUDSTACK-7674



On Oct 6, 2014, at 1:53 AM, Daan Hoogland  wrote:

> I am not sure Carlos, but I think it was due to a fix of some other network 
> related issue in 4.3.1. I thought we wrote an update/fix for it. So I am 
> looking at how your env missed out.
> 
> On Sun, Oct 5, 2014 at 1:10 AM, Carlos Reátegui  wrote:
> Sure, but I am not sure if the problem happened when I upgraded to 4.3.0 or 
> 4.3.1.  When (what version) did the broadcast_uri in the network table 
> require an entry for Guest networks and not able to be null?
> 
> 
> On Oct 4, 2014, at 4:15 AM, Daan Hoogland  wrote:
> 
>> Carlos, I think you found a bug in our upgrade scripts. Can you describe the 
>> scenario in a ticket?
>> 
>> On Sat, Oct 4, 2014 at 1:48 AM, Carlos Reátegui  wrote:
>> Hmm.  I just checked another deployment I did with 4.4.0 using the same zone 
>> type and network offering and it has the broadcast_uri set to 
>> vlan://untagged.
>> 
>> I also checked previous backups from older versions (4.10 and 4.2.1) and in 
>> all of those the broadcast_uri was blank.  I am wondering if this is a bug 
>> in the upgrade scripts. 
>> 
>> I updated network 204 and set the broadcast_uri and now I am able to start 
>> new instances.
>> 
>> thank you for your help!
>> 
>> I am including my nics table just in case you spot something else out of the 
>> ordinary.
>> 
>> mysql> select id, instance_id, network_id, netmask, gateway, ip4_address, 
>> broadcast_uri, mode, state, strategy from nics where network_id=204 order by 
>> ip4_address;
>> +-+-++---+-+---+-+--+--+-+
>> | id  | instance_id | network_id | netmask   | gateway | ip4_address 
>>   | broadcast_uri   | mode | state| strategy|
>> +-+-++---+-+---+-+--+--+-+
>> |  60 |  52 |204 | NULL  | NULL| NULL
>>   | NULL| Dhcp | Deallocating | Start   |
>> |  64 |  53 |204 | NULL  | NULL| NULL
>>   | NULL| Dhcp | Deallocating | Start   |
>> |  68 |  54 |204 | NULL  | NULL| NULL
>>   | NULL| Dhcp | Deallocating | Start   |
>> |  72 |  55 |204 | NULL  | NULL| NULL
>>   | NULL| Dhcp | Deallocating | Start   |
>> |  76 |  56 |204 | NULL  | NULL| NULL
>>   | NULL| Dhcp | Deallocating | Start   |
>> |  30 |  21 |204 | 255.255.255.0 | 172.30.45.1 | 
>> 172.30.45.100 | vlan://untagged | Dhcp | Deallocating | Start   |
>> |  32 |  23 |204 | 255.255.255.0 | 172.30.45.1 | 
>> 172.30.45.100 | vlan://untagged | Dhcp | Deallocating | Start   |
>> |  43 |  34 |204 | 255.255.255.0 | 172.30.45.1 | 
>> 172.30.45.100 | vlan://untagged | Dhcp | Deallocating | Start   |
>> |  47 |  38 |204 | 255.255.255.0 | 172.30.45.1 | 
>> 172.30.45.100 | vlan://untagged | Dhcp | Reserved | Start   |
>> |   1 |   1 |204 | 255.255.255.0 | 172.30.45.1 | 
>> 172.30.45.101 | vlan://untagged | Dhcp | Deallocating | Start   |
>> |  13 |   5 |204 | 255.255.255.0 | 172.30.45.1 | 
>> 172.30.45.101 | vlan://untagged | Dhcp | Deallocating | Start   |
>> |  87 |  59 |204 | 255.255.255.0 | 172.30.45.1 | 
>> 172.30.45.101 | vlan://untagged | Dhcp | Deallocating | Start   |
>> | 116 |NULL |204 | NULL  | 172.30.45.1 | 
>> 172.30.45.101 | NULL| NULL | Reserved | PlaceHolder |
>> | 120 |  91 |204 | 255.255.255.0 | 172.30.45.1 | 
>> 172.30.45.101 | vlan://untagged | Dhcp | Reserved | Start   |
>> |  23 |  14 |204 | 255.255.255.0 | 172.30.45.1 | 
>> 172.30.45.102 | vlan://untagged | Dhcp | Reserved | Start   |
>> |  21 |  12 |204 | 255.255.255.0 | 172.30.45.1 | 
>> 172.30.45.103 | vlan://untagged | Dhcp | Deallocating | Start   |
>> | 109 |  81 |204 | 255.255.255.0 | 172.30.45.1 | 
>> 172.30.45.103 | vlan://untagged | Dhcp | Deallocating | Start   |
>> |   4 |   2 |204 | 255.255.255.0 | 172.30.45.1 | 
>> 172.30.45.104 | vlan://untagged | Dhcp | Deallocating | Start   |
>> |  84 |  58 |204 | 255.255.255.0 | 172.30.45.1 | 
>> 172.30.45.104 | vlan://untagged | Dhcp | Deallocating | Start   |
>> |  89 |  60 |204 | 255.255.255.0 | 172.30.45.1 | 
>> 172.30.45.104 | vlan://untagged | Dhcp | Deallocating | Start   |
>> | 117 |  90 |204 | 255.255.255.0 | 172.30.45.1 | 
>> 172.30.45.104 | vlan://untagged | Dhcp | Reserved   

Re: [VOTE][ACS44]Apache CloudStack 4.4.1 RC 1 in branch 4.4-RC20141006T1046

[Mike Tutkowski]

I grabbed the most recent for 4.4.1.

Let me see if I can find 3d8c09dd146241fedda2f0167dcd60fdf66b0b1d
specifically.

On Mon, Oct 6, 2014 at 11:59 AM, Marcus  wrote:

> Is it just me, or does this branch/commit not exist?
>
> On Mon, Oct 6, 2014 at 7:42 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com
> > wrote:
>
> > +1 (binding)
> >
> > On Monday, October 6, 2014, Daan Hoogland 
> wrote:
> >
> > > Hi All,
> > >
> > > I've created a 4.4.1 release, with the following artifacts up for a
> vote:
> > >
> > > Git Branch and Commit SH:
> > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20141006T1046
> > > Commit: 3d8c09dd146241fedda2f0167dcd60fdf66b0b1d
> > >
> > > List of changes:
> > >
> > >
> >
> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/
> > >
> > > Source release (checksums and signatures are available at the same
> > > location):
> > > https://dist.apache.org/repos/dist/dev/cloudstack/4.4.1/
> > >
> > > PGP release keys (signed using 4096R/AA4736F3):
> > > https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> > >
> > > Vote will be open for 72 hours.
> > >
> > > For sanity in tallying the vote, can PMC members please be sure to
> > > indicate "(binding)" with their vote?
> > >
> > > [ ] +1  approve
> > > [ ] +0  no opinion
> > > [ ] -1  disapprove (and reason why)
> > >
> > > --
> > > 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
> > *™*
> >
>



-- 
*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: [VOTE][ACS44]Apache CloudStack 4.4.1 RC 1 in branch 4.4-RC20141006T1046

[Marcus]

I'm seeing the last change as Oct 3rd here...

https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=summary

On Mon, Oct 6, 2014 at 12:05 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> I grabbed the most recent for 4.4.1.
>
> Let me see if I can find 3d8c09dd146241fedda2f0167dcd60fdf66b0b1d
> specifically.
>
> On Mon, Oct 6, 2014 at 11:59 AM, Marcus  wrote:
>
> > Is it just me, or does this branch/commit not exist?
> >
> > On Mon, Oct 6, 2014 at 7:42 AM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com
> > > wrote:
> >
> > > +1 (binding)
> > >
> > > On Monday, October 6, 2014, Daan Hoogland 
> > wrote:
> > >
> > > > Hi All,
> > > >
> > > > I've created a 4.4.1 release, with the following artifacts up for a
> > vote:
> > > >
> > > > Git Branch and Commit SH:
> > > >
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20141006T1046
> > > > Commit: 3d8c09dd146241fedda2f0167dcd60fdf66b0b1d
> > > >
> > > > List of changes:
> > > >
> > > >
> > >
> >
> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/
> > > >
> > > > Source release (checksums and signatures are available at the same
> > > > location):
> > > > https://dist.apache.org/repos/dist/dev/cloudstack/4.4.1/
> > > >
> > > > PGP release keys (signed using 4096R/AA4736F3):
> > > > https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> > > >
> > > > Vote will be open for 72 hours.
> > > >
> > > > For sanity in tallying the vote, can PMC members please be sure to
> > > > indicate "(binding)" with their vote?
> > > >
> > > > [ ] +1  approve
> > > > [ ] +0  no opinion
> > > > [ ] -1  disapprove (and reason why)
> > > >
> > > > --
> > > > 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
> > > *™*
> > >
> >
>
>
>
> --
> *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: [VOTE][ACS44]Apache CloudStack 4.4.1 RC 1 in branch 4.4-RC20141006T1046

[Mike Tutkowski]

I see it:

  *SHA:*

3d8c09dd146241fedda2f0167dcd60fdf66b0b1d

*Author:*

Daan Hoogland 

*Date:*

Mon Oct 06 2014 02:46:12 GMT-0600 (MDT)

*Subject:*

*Updating pom.xml version numbers for release 4.4.1*

*Refs:*

upstream/4.4-RC20141006T1046

*Parent:*

63fbd16dd11388bd93cdbec4ea7fe6de37aa7fc5

On Mon, Oct 6, 2014 at 12:06 PM, Marcus  wrote:

> I'm seeing the last change as Oct 3rd here...
>
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=summary
>
> On Mon, Oct 6, 2014 at 12:05 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > I grabbed the most recent for 4.4.1.
> >
> > Let me see if I can find 3d8c09dd146241fedda2f0167dcd60fdf66b0b1d
> > specifically.
> >
> > On Mon, Oct 6, 2014 at 11:59 AM, Marcus  wrote:
> >
> > > Is it just me, or does this branch/commit not exist?
> > >
> > > On Mon, Oct 6, 2014 at 7:42 AM, Mike Tutkowski <
> > > mike.tutkow...@solidfire.com
> > > > wrote:
> > >
> > > > +1 (binding)
> > > >
> > > > On Monday, October 6, 2014, Daan Hoogland 
> > > wrote:
> > > >
> > > > > Hi All,
> > > > >
> > > > > I've created a 4.4.1 release, with the following artifacts up for a
> > > vote:
> > > > >
> > > > > Git Branch and Commit SH:
> > > > >
> > > > >
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20141006T1046
> > > > > Commit: 3d8c09dd146241fedda2f0167dcd60fdf66b0b1d
> > > > >
> > > > > List of changes:
> > > > >
> > > > >
> > > >
> > >
> >
> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/
> > > > >
> > > > > Source release (checksums and signatures are available at the same
> > > > > location):
> > > > > https://dist.apache.org/repos/dist/dev/cloudstack/4.4.1/
> > > > >
> > > > > PGP release keys (signed using 4096R/AA4736F3):
> > > > > https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> > > > >
> > > > > Vote will be open for 72 hours.
> > > > >
> > > > > For sanity in tallying the vote, can PMC members please be sure to
> > > > > indicate "(binding)" with their vote?
> > > > >
> > > > > [ ] +1  approve
> > > > > [ ] +0  no opinion
> > > > > [ ] -1  disapprove (and reason why)
> > > > >
> > > > > --
> > > > > 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
> > > > *™*
> > > >
> > >
> >
> >
> >
> > --
> > *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: [VOTE][ACS44]Apache CloudStack 4.4.1 RC 1 in branch 4.4-RC20141006T1046

[Daan Hoogland]

it is all but me, Marcus
I forgot to push The tar-ball is there I hope.

On Mon, Oct 6, 2014 at 7:59 PM, Marcus  wrote:

> Is it just me, or does this branch/commit not exist?
>
> On Mon, Oct 6, 2014 at 7:42 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com
> > wrote:
>
> > +1 (binding)
> >
> > On Monday, October 6, 2014, Daan Hoogland 
> wrote:
> >
> > > Hi All,
> > >
> > > I've created a 4.4.1 release, with the following artifacts up for a
> vote:
> > >
> > > Git Branch and Commit SH:
> > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20141006T1046
> > > Commit: 3d8c09dd146241fedda2f0167dcd60fdf66b0b1d
> > >
> > > List of changes:
> > >
> > >
> >
> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/
> > >
> > > Source release (checksums and signatures are available at the same
> > > location):
> > > https://dist.apache.org/repos/dist/dev/cloudstack/4.4.1/
> > >
> > > PGP release keys (signed using 4096R/AA4736F3):
> > > https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> > >
> > > Vote will be open for 72 hours.
> > >
> > > For sanity in tallying the vote, can PMC members please be sure to
> > > indicate "(binding)" with their vote?
> > >
> > > [ ] +1  approve
> > > [ ] +0  no opinion
> > > [ ] -1  disapprove (and reason why)
> > >
> > > --
> > > 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
> > *™*
> >
>



-- 
Daan

Re: Checking in to 4.5

[David Nalley]

On Mon, Oct 6, 2014 at 12:49 PM, Mike Tutkowski
 wrote:
> Hi David,
>
> So, I know we're a ways past code freeze, but we seem to have been (rightly)
> focusing more of our dev effort as a community on 4.3.1 and 4.4.1 lately.
>

Yes, as I've stated elsewhere, I am in some ways waiting for 4.4.1. to
close before we try and process a 4.5.0 release.

> It seems that check-ins have gone into master in the recent past and that
> you felt they should not be reverted.

I actually think several of these should be reverted. In particular,
some of the current 4.5 blockers would not exist if not for those.
I am contemplating whether the right way forward is to continue with
master as the release branch or whether I should branch 4.5 before the
problematic features landed and cherry pick over bug fixes as
appropriate.

>
> That being the case, Marcus and I have completed a review of the following
> and were wondering if it would be OK to put it in master?
>
> https://reviews.apache.org/r/25772/
>
> Thanks!
>

I'd prefer not to, regardless, I wouldn't expect it to be in 4.5.0

--David

Re: [VOTE][ACS44]Apache CloudStack 4.4.1 RC 1 in branch 4.4-RC20141006T1046

[Marcus]

Thanks! I did fall back to the tarball.
On Oct 6, 2014 12:07 PM, "Daan Hoogland"  wrote:

> it is all but me, Marcus
> I forgot to push The tar-ball is there I hope.
>
> On Mon, Oct 6, 2014 at 7:59 PM, Marcus  wrote:
>
> > Is it just me, or does this branch/commit not exist?
> >
> > On Mon, Oct 6, 2014 at 7:42 AM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com
> > > wrote:
> >
> > > +1 (binding)
> > >
> > > On Monday, October 6, 2014, Daan Hoogland 
> > wrote:
> > >
> > > > Hi All,
> > > >
> > > > I've created a 4.4.1 release, with the following artifacts up for a
> > vote:
> > > >
> > > > Git Branch and Commit SH:
> > > >
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20141006T1046
> > > > Commit: 3d8c09dd146241fedda2f0167dcd60fdf66b0b1d
> > > >
> > > > List of changes:
> > > >
> > > >
> > >
> >
> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/
> > > >
> > > > Source release (checksums and signatures are available at the same
> > > > location):
> > > > https://dist.apache.org/repos/dist/dev/cloudstack/4.4.1/
> > > >
> > > > PGP release keys (signed using 4096R/AA4736F3):
> > > > https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> > > >
> > > > Vote will be open for 72 hours.
> > > >
> > > > For sanity in tallying the vote, can PMC members please be sure to
> > > > indicate "(binding)" with their vote?
> > > >
> > > > [ ] +1  approve
> > > > [ ] +0  no opinion
> > > > [ ] -1  disapprove (and reason why)
> > > >
> > > > --
> > > > 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
> > > *™*
> > >
> >
>
>
>
> --
> Daan
>

Re: Checking in to 4.5

[Mike Tutkowski]

OK, thanks, David.

We can create a new branch for this Review Request and merge it to master
once 4.5 is cut.

On Mon, Oct 6, 2014 at 12:09 PM, David Nalley  wrote:

> On Mon, Oct 6, 2014 at 12:49 PM, Mike Tutkowski
>  wrote:
> > Hi David,
> >
> > So, I know we're a ways past code freeze, but we seem to have been
> (rightly)
> > focusing more of our dev effort as a community on 4.3.1 and 4.4.1 lately.
> >
>
> Yes, as I've stated elsewhere, I am in some ways waiting for 4.4.1. to
> close before we try and process a 4.5.0 release.
>
> > It seems that check-ins have gone into master in the recent past and that
> > you felt they should not be reverted.
>
> I actually think several of these should be reverted. In particular,
> some of the current 4.5 blockers would not exist if not for those.
> I am contemplating whether the right way forward is to continue with
> master as the release branch or whether I should branch 4.5 before the
> problematic features landed and cherry pick over bug fixes as
> appropriate.
>
> >
> > That being the case, Marcus and I have completed a review of the
> following
> > and were wondering if it would be OK to put it in master?
> >
> > https://reviews.apache.org/r/25772/
> >
> > Thanks!
> >
>
> I'd prefer not to, regardless, I wouldn't expect it to be in 4.5.0
>
> --David
>



-- 
*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: Can't launch VMs

[Daan Hoogland]

H Carlos,

This still deludes me. The code to replace empty broadcastUris is in branch
4.3 and below the tag for 4.3.1. Your system should have been upgraded. Do
you still have the logs for the first start after upgrading?

On Mon, Oct 6, 2014 at 8:00 PM, Carlos Reátegui  wrote:

> Let me know if you require more detail:
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-7674
>
>
>
> On Oct 6, 2014, at 1:53 AM, Daan Hoogland  wrote:
>
> I am not sure Carlos, but I think it was due to a fix of some other
> network related issue in 4.3.1. I thought we wrote an update/fix for it. So
> I am looking at how your env missed out.
>
> On Sun, Oct 5, 2014 at 1:10 AM, Carlos Reátegui 
> wrote:
>
>> Sure, but I am not sure if the problem happened when I upgraded to 4.3.0
>> or 4.3.1.  When (what version) did the broadcast_uri in the network table
>> require an entry for Guest networks and not able to be null?
>>
>>
>> On Oct 4, 2014, at 4:15 AM, Daan Hoogland 
>> wrote:
>>
>> Carlos, I think you found a bug in our upgrade scripts. Can you describe
>> the scenario in a ticket?
>>
>> On Sat, Oct 4, 2014 at 1:48 AM, Carlos Reátegui 
>> wrote:
>>
>>> Hmm.  I just checked another deployment I did with 4.4.0 using the same
>>> zone type and network offering and it has the broadcast_uri set to
>>> vlan://untagged.
>>>
>>> I also checked previous backups from older versions (4.10 and 4.2.1) and
>>> in all of those the broadcast_uri was blank.  I am wondering if this is a
>>> bug in the upgrade scripts.
>>>
>>> I updated network 204 and set the broadcast_uri and now I am able to
>>> start new instances.
>>>
>>> thank you for your help!
>>>
>>> I am including my nics table just in case you spot something else out of
>>> the ordinary.
>>>
>>> mysql> select id, instance_id, network_id, netmask, gateway,
>>> ip4_address, broadcast_uri, mode, state, strategy from nics where
>>> network_id=204 order by ip4_address;
>>>
>>> +-+-++---+-+---+-+--+--+-+
>>> | id  | instance_id | network_id | netmask   | gateway |
>>> ip4_address   | broadcast_uri   | mode | state| strategy|
>>>
>>> +-+-++---+-+---+-+--+--+-+
>>> |  60 |  52 |204 | NULL  | NULL| NULL
>>>| NULL| Dhcp | Deallocating | Start   |
>>> |  64 |  53 |204 | NULL  | NULL| NULL
>>>| NULL| Dhcp | Deallocating | Start   |
>>> |  68 |  54 |204 | NULL  | NULL| NULL
>>>| NULL| Dhcp | Deallocating | Start   |
>>> |  72 |  55 |204 | NULL  | NULL| NULL
>>>| NULL| Dhcp | Deallocating | Start   |
>>> |  76 |  56 |204 | NULL  | NULL| NULL
>>>| NULL| Dhcp | Deallocating | Start   |
>>> |  30 |  21 |204 | 255.255.255.0 | 172.30.45.1 |
>>> 172.30.45.100 | vlan://untagged | Dhcp | Deallocating | Start   |
>>> |  32 |  23 |204 | 255.255.255.0 | 172.30.45.1 |
>>> 172.30.45.100 | vlan://untagged | Dhcp | Deallocating | Start   |
>>> |  43 |  34 |204 | 255.255.255.0 | 172.30.45.1 |
>>> 172.30.45.100 | vlan://untagged | Dhcp | Deallocating | Start   |
>>> |  47 |  38 |204 | 255.255.255.0 | 172.30.45.1 |
>>> 172.30.45.100 | vlan://untagged | Dhcp | Reserved | Start   |
>>> |   1 |   1 |204 | 255.255.255.0 | 172.30.45.1 |
>>> 172.30.45.101 | vlan://untagged | Dhcp | Deallocating | Start   |
>>> |  13 |   5 |204 | 255.255.255.0 | 172.30.45.1 |
>>> 172.30.45.101 | vlan://untagged | Dhcp | Deallocating | Start   |
>>> |  87 |  59 |204 | 255.255.255.0 | 172.30.45.1 |
>>> 172.30.45.101 | vlan://untagged | Dhcp | Deallocating | Start   |
>>> | 116 |NULL |204 | NULL  | 172.30.45.1 |
>>> 172.30.45.101 | NULL| NULL | Reserved | PlaceHolder |
>>> | 120 |  91 |204 | 255.255.255.0 | 172.30.45.1 |
>>> 172.30.45.101 | vlan://untagged | Dhcp | Reserved | Start   |
>>> |  23 |  14 |204 | 255.255.255.0 | 172.30.45.1 |
>>> 172.30.45.102 | vlan://untagged | Dhcp | Reserved | Start   |
>>> |  21 |  12 |204 | 255.255.255.0 | 172.30.45.1 |
>>> 172.30.45.103 | vlan://untagged | Dhcp | Deallocating | Start   |
>>> | 109 |  81 |204 | 255.255.255.0 | 172.30.45.1 |
>>> 172.30.45.103 | vlan://untagged | Dhcp | Deallocating | Start   |
>>> |   4 |   2 |204 | 255.255.255.0 | 172.30.45.1 |
>>> 172.30.45.104 | vlan://untagged | Dhcp | Deallocating | Start   |
>>> |  84 |  58 |204 | 255.255.255.0 | 172.30.45.1 |
>>> 172.30.45

Re: [VOTE][ACS44]Apache CloudStack 4.4.1 RC 1 in branch 4.4-RC20141006T1046

[Daan Hoogland]

Marcus, I use release branches, so if you look in the 4.3 branch only you
might miss it. It is a short fork from that. the branch name is
4.4-RC20141006T1046 (as in the title of this mail

On Mon, Oct 6, 2014 at 8:24 PM, Marcus  wrote:

> Thanks! I did fall back to the tarball.
> On Oct 6, 2014 12:07 PM, "Daan Hoogland"  wrote:
>
> > it is all but me, Marcus
> > I forgot to push The tar-ball is there I hope.
> >
> > On Mon, Oct 6, 2014 at 7:59 PM, Marcus  wrote:
> >
> > > Is it just me, or does this branch/commit not exist?
> > >
> > > On Mon, Oct 6, 2014 at 7:42 AM, Mike Tutkowski <
> > > mike.tutkow...@solidfire.com
> > > > wrote:
> > >
> > > > +1 (binding)
> > > >
> > > > On Monday, October 6, 2014, Daan Hoogland 
> > > wrote:
> > > >
> > > > > Hi All,
> > > > >
> > > > > I've created a 4.4.1 release, with the following artifacts up for a
> > > vote:
> > > > >
> > > > > Git Branch and Commit SH:
> > > > >
> > > > >
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20141006T1046
> > > > > Commit: 3d8c09dd146241fedda2f0167dcd60fdf66b0b1d
> > > > >
> > > > > List of changes:
> > > > >
> > > > >
> > > >
> > >
> >
> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/
> > > > >
> > > > > Source release (checksums and signatures are available at the same
> > > > > location):
> > > > > https://dist.apache.org/repos/dist/dev/cloudstack/4.4.1/
> > > > >
> > > > > PGP release keys (signed using 4096R/AA4736F3):
> > > > > https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> > > > >
> > > > > Vote will be open for 72 hours.
> > > > >
> > > > > For sanity in tallying the vote, can PMC members please be sure to
> > > > > indicate "(binding)" with their vote?
> > > > >
> > > > > [ ] +1  approve
> > > > > [ ] +0  no opinion
> > > > > [ ] -1  disapprove (and reason why)
> > > > >
> > > > > --
> > > > > 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
> > > > *™*
> > > >
> > >
> >
> >
> >
> > --
> > Daan
> >
>



-- 
Daan

Reserved Guest VM CIDR Question

[Logan Barfield]

We have decided internally to set up a CIDR reservation with all new
accounts to give us the ability to easily attach dedicated hosts to
existing VM networks.

We were thinking it would be easier to set up the reservation before
deploying VMs.  Setting up reservation after the fact can get complicated
if a VM happens to be outside the intended reservation range.

The issue we're having is that reservation is not allowed until the network
is in the "Implemented" state (i.e. after the first VM is deployed).

Why is reservation not allowed upon initial network creation?  If we try to
apply reservation after the first VM is online the command will fail
occasionally because the first VM is deployed outside the CIDR range.

Example:

Guest Net: 10.1.1.0/24
Reserved CIDR: 10.1.1.0/25

- Attempt reservation before deploying a VM: Fails due to network not being
"Implemented"
- Attempt reservation after many VMs are deployed: Fails due to VMs being
outside Reserved CIDR (e.g., 10.1.1.150), and requires a lot of work to
change the VM's IP
- Attempt reservation after first VM is deployed: Either succeeds, or fails
if the first VMs IP is outside of the reserved CIDR.

How can we fix this without hacking work arounds into the deployment logic?
 (ex: Check network for 10.1.1.10, if it doesn't exist deploy the VM on
that IP, if it already exists deploy it wherever.)

Thank You,

Logan Barfield
Tranquil Hosting

[GitHub] cloudstack pull request: Vpc refactor clean for pr

[wilderrodrigues]

Github user wilderrodrigues commented on the pull request:

https://github.com/apache/cloudstack/pull/22#issuecomment-58073492
  
Hi @bhaisaab,

This is a new Pull Request in order to fix the conflicts we found in the 
old pull request #19 .

Travis-CI is 100% green and this PR has been extensively tested.

I will put the most update version of the description here:

Pull request of changes in the "cloud-server" module

In the last 14 weeks we have worked in the cloud-server, focusing our time 
in the refactor of the 

![puml_routerdeployment](https://cloud.githubusercontent.com/assets/5129209/4531522/04b0ad16-4d8b-11e4-9c9f-493f71c9e88e.png)
[Vpc]VirtualNetworkApplianceManagerImpl. We had a mains goals increase of 
Maintainability, Extensibility, Readability and test coverage. That was just a 
first step towards the development, still in progress, of the Redundant Virtual 
Routers for VPC.

== What has been done so far:

• The VirtualNetworkApplianceManagerImpl class line numbers dropped from 
4440 to 2558
• The VpcVirtualNetworkApplianceImpl class line numbers dropped from 1484 
to 749
• We created 35 new classes in order to split the code/responsibility
• We added 97.8% unit test coverage for com.cloud.network.element/router 
and org.cloud.network.router.deployment packages
o The most complex classes we changed are in those packages
o About 1700 lines of unit tests
• We executed many Marvin tests that we got from ACS and made compliant 
with our domain:
o test_01_create_account
o test_01_add_vm_to_subdomain
o test_DeleteDomain
o test_forceDeleteDomain
o test_updateAdminDetails
o test_updateDomainAdminDetails
o test_updateUserDetails
o test_LoginApiDomain
o test_LoginApiUuidResponse
o test_privategw_acl
o test_01_reset_vm_on_reboot
o test_03_restart_network_cleanup
o test_05_router_basic
o test_06_router_advanced
o test_07_stop_router
o test_08_start_router
o test_09_reboot_router
o test_01_create_service_offering
o test_02_edit_service_offering
o test_03_delete_service_offering
o test_01_start_stop_router_after_addition_of_one_guest_network
o test_02_reboot_router_after_addition_of_one_guest_network
o test_04_chg_srv_off_router_after_addition_of_one_guest_network
o test_05_destroy_router_after_addition_of_one_guest_network
o test_01_stop_start_router_after_creating_vpc
o test_02_reboot_router_after_creating_vpc
o test_04_change_service_offerring_vpc
o test_05_destroy_router_after_creating_vpc
o test_vpc_remote_access_vpn
o test_vpc_site2site_vpn

We started the changes in the network area, trying to identify the 
differences in the 2 types of network we have. For that we created Basic and 
Advanced Network Topology classes. The network topology classes are responsible 
by invoking the Apply/Setup/Create/Save rules that were previously done by the 
[Vpc]VirtualNetworkAppliance. A topology instance is retrieved via a context 
object that is injected in the [Vpc]VirtualElement. The context object will 
return the most appropriate topology instance based on the Network Type, which 
is defined in the Data Centre. That was the first step towards the refactor.

From the topology class we reach the Rule Applier implementation that will 
be used to do all the rule setup preparation (i.e. invoke DAOs and prepare the 
command object). The RuleApplier interface was extracted from the 
VirtualNetworkApplianceManagerImpl, where it use to be an inner interface. For 
each anonymous implementation of the RuleApplier we created a concrete class. 
The rules are used as elements of a Visitor class, which will perform some 
extra logic, depending on the rule it's visiting, and call the send commands to 
router method. The latter has also been extracted from the 
VirtualNetworkApplianceManagerImpl and is now in a new helper class: 
NetworkHelperImpl.

The visitor has been used because we were aiming to split the 
responsibility and also because the way the RuleApplier was implemented before, 
it was clear that every command sent to the router was following a 2-steps 
approach: gather information to create the commands, apply some logic to send 
to the router. For those reason we implemented the visitor pattern. Since we 
already had the Basic/Advanced Network Topology classes, we created 2 concrete 
classes to visit the rules: Basic/Advanced Network Visitors. Both classes 
extend the abstract class NetworkTopologyVisitor, which defines all the visit 
methods per type of rule. By doing so, we can use the same rule and separate 
the logic based on the type of visitor that we have - Basic or Advanced.

Continuing on the refactor, we also added some helper classes for the 
"getSomething" related methods. Following this approach we ended up having the 
following classes:

Re: [MASTER-SNMP Alerts] - Trying to test Master, but building is failing

[Wilder Rodrigues]

Never mindŠ it¹s working again.

The problem was related to the test trying to reach my machine based on
the hostname.

I just added the hostname on the /etc/hosts and it worked.

Cheers,
Wilder

On 06/10/14 14:11, "Wilder Rodrigues" 
wrote:

>Hi all,
>
>Just clone master and tried to build the simulator in order to start
>testing. Unfortunately, did not pass SNMP Alerts module:
>
>
>---
>
> T E S T S
>
>---
>
>Running org.apache.cloudstack.alert.snmp.SnmpEnhancedPatternLayoutTest
>
>Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.293 sec
>
>Running org.apache.cloudstack.alert.snmp.SnmpTrapAppenderTest
>
>log4j:ERROR  Error in crearting snmp object, sbpltk1zffh04:
>sbpltk1zffh04: nodename nor servname provided, or not known
>
>log4j:ERROR  Invalid format for the IP Addresses or Ports parameter
>
>log4j:ERROR  size of ip addresses , communities, and ports list doesn't
>match, setting all to null
>
>log4j:ERROR  size of ip addresses , communities, and ports list doesn't
>match, setting all to null
>
>log4j:ERROR  Invalid format for the IP Addresses or Ports parameter
>
>Tests run: 5, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.058 sec
><<< FAILURE!
>
>
>Results :
>
>
>Failed tests:   
>appendTest(org.apache.cloudstack.alert.snmp.SnmpTrapAppenderTest):  error
>snmpHelper list size not as expected  expected:<0> but was:<2>
>
>
>Tests run: 9, Failures: 1, Errors: 0, Skipped: 0
>
>Is there anyone looking into this already?
>
>Cheers,
>Wilder

Re: Reserved Guest VM CIDR Question

[Marcus]

Do startip and endip createNetwork parameters not work for that (when
creating the network? That should carve out a subset of the network for
cloudstack use and leave the rest untouched.
On Oct 6, 2014 12:57 PM, "Logan Barfield"  wrote:

> We have decided internally to set up a CIDR reservation with all new
> accounts to give us the ability to easily attach dedicated hosts to
> existing VM networks.
>
> We were thinking it would be easier to set up the reservation before
> deploying VMs.  Setting up reservation after the fact can get complicated
> if a VM happens to be outside the intended reservation range.
>
> The issue we're having is that reservation is not allowed until the network
> is in the "Implemented" state (i.e. after the first VM is deployed).
>
> Why is reservation not allowed upon initial network creation?  If we try to
> apply reservation after the first VM is online the command will fail
> occasionally because the first VM is deployed outside the CIDR range.
>
> Example:
>
> Guest Net: 10.1.1.0/24
> Reserved CIDR: 10.1.1.0/25
>
> - Attempt reservation before deploying a VM: Fails due to network not being
> "Implemented"
> - Attempt reservation after many VMs are deployed: Fails due to VMs being
> outside Reserved CIDR (e.g., 10.1.1.150), and requires a lot of work to
> change the VM's IP
> - Attempt reservation after first VM is deployed: Either succeeds, or fails
> if the first VMs IP is outside of the reserved CIDR.
>
> How can we fix this without hacking work arounds into the deployment logic?
>  (ex: Check network for 10.1.1.10, if it doesn't exist deploy the VM on
> that IP, if it already exists deploy it wherever.)
>
> Thank You,
>
> Logan Barfield
> Tranquil Hosting
>

Re: [VOTE][ACS44]Apache CloudStack 4.4.1 RC 1 in branch 4.4-RC20141006T1046

[Marcus]

I see it now. Thanks for pushing it.

On Mon, Oct 6, 2014 at 12:34 PM, Daan Hoogland 
wrote:

> Marcus, I use release branches, so if you look in the 4.3 branch only you
> might miss it. It is a short fork from that. the branch name is
> 4.4-RC20141006T1046 (as in the title of this mail
>
> On Mon, Oct 6, 2014 at 8:24 PM, Marcus  wrote:
>
> > Thanks! I did fall back to the tarball.
> > On Oct 6, 2014 12:07 PM, "Daan Hoogland" 
> wrote:
> >
> > > it is all but me, Marcus
> > > I forgot to push The tar-ball is there I hope.
> > >
> > > On Mon, Oct 6, 2014 at 7:59 PM, Marcus  wrote:
> > >
> > > > Is it just me, or does this branch/commit not exist?
> > > >
> > > > On Mon, Oct 6, 2014 at 7:42 AM, Mike Tutkowski <
> > > > mike.tutkow...@solidfire.com
> > > > > wrote:
> > > >
> > > > > +1 (binding)
> > > > >
> > > > > On Monday, October 6, 2014, Daan Hoogland  >
> > > > wrote:
> > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > I've created a 4.4.1 release, with the following artifacts up
> for a
> > > > vote:
> > > > > >
> > > > > > Git Branch and Commit SH:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.4-RC20141006T1046
> > > > > > Commit: 3d8c09dd146241fedda2f0167dcd60fdf66b0b1d
> > > > > >
> > > > > > List of changes:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/
> > > > > >
> > > > > > Source release (checksums and signatures are available at the
> same
> > > > > > location):
> > > > > > https://dist.apache.org/repos/dist/dev/cloudstack/4.4.1/
> > > > > >
> > > > > > PGP release keys (signed using 4096R/AA4736F3):
> > > > > > https://dist.apache.org/repos/dist/release/cloudstack/KEYS
> > > > > >
> > > > > > Vote will be open for 72 hours.
> > > > > >
> > > > > > For sanity in tallying the vote, can PMC members please be sure
> to
> > > > > > indicate "(binding)" with their vote?
> > > > > >
> > > > > > [ ] +1  approve
> > > > > > [ ] +0  no opinion
> > > > > > [ ] -1  disapprove (and reason why)
> > > > > >
> > > > > > --
> > > > > > 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
> > > > > *™*
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Daan
> > >
> >
>
>
>
> --
> Daan
>

Re: Reserved Guest VM CIDR Question

[Logan Barfield]

Hi Marcus,

I'll give that a shot.  I didn't know if those parameters specified the
network CIDR or the guest CIDR.


Thank You,

Logan Barfield
Tranquil Hosting

On Mon, Oct 6, 2014 at 3:15 PM, Marcus  wrote:

> Do startip and endip createNetwork parameters not work for that (when
> creating the network? That should carve out a subset of the network for
> cloudstack use and leave the rest untouched.
> On Oct 6, 2014 12:57 PM, "Logan Barfield"  wrote:
>
> > We have decided internally to set up a CIDR reservation with all new
> > accounts to give us the ability to easily attach dedicated hosts to
> > existing VM networks.
> >
> > We were thinking it would be easier to set up the reservation before
> > deploying VMs.  Setting up reservation after the fact can get complicated
> > if a VM happens to be outside the intended reservation range.
> >
> > The issue we're having is that reservation is not allowed until the
> network
> > is in the "Implemented" state (i.e. after the first VM is deployed).
> >
> > Why is reservation not allowed upon initial network creation?  If we try
> to
> > apply reservation after the first VM is online the command will fail
> > occasionally because the first VM is deployed outside the CIDR range.
> >
> > Example:
> >
> > Guest Net: 10.1.1.0/24
> > Reserved CIDR: 10.1.1.0/25
> >
> > - Attempt reservation before deploying a VM: Fails due to network not
> being
> > "Implemented"
> > - Attempt reservation after many VMs are deployed: Fails due to VMs being
> > outside Reserved CIDR (e.g., 10.1.1.150), and requires a lot of work to
> > change the VM's IP
> > - Attempt reservation after first VM is deployed: Either succeeds, or
> fails
> > if the first VMs IP is outside of the reserved CIDR.
> >
> > How can we fix this without hacking work arounds into the deployment
> logic?
> >  (ex: Check network for 10.1.1.10, if it doesn't exist deploy the VM on
> > that IP, if it already exists deploy it wherever.)
> >
> > Thank You,
> >
> > Logan Barfield
> > Tranquil Hosting
> >
>

Re: Can't launch VMs

[Carlos Reátegui]

Yes I do.  Anything in particular I should look for?

2014-09-29 09:56:03,115 INFO  [c.c.u.d.T.Transaction] (main:null) Is Data Base 
High Availiability enabled? Ans : false
2014-09-29 09:56:03,381 DEBUG [c.c.u.d.ConnectionConcierge] (main:null) 
Registering a database connection for LockMaster1
2014-09-29 09:56:03,381 INFO  [c.c.u.d.Merovingian2] (main:null) Cleaning up 
locks for 233845174730255
2014-09-29 09:56:03,393 INFO  [c.c.u.d.Merovingian2] (main:null) Released 0 
locks for 233845174730255
2014-09-29 09:56:03,430 INFO  [o.a.c.s.l.CloudStackExtendedLifeCycle] 
(main:null) Running system integrity checker 
com.cloud.upgrade.DatabaseUpgradeChecker@55ea8912
2014-09-29 09:56:03,431 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) 
Grabbing lock to check for database upgrade.
2014-09-29 09:56:03,474 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-09-29 09:56:03,515 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) DB 
version = 4.3.0 Code Version = 4.3.1
2014-09-29 09:56:03,517 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) 
Database upgrade must be performed from 4.3.0 to 4.3.1
2014-09-29 09:56:03,518 DEBUG [c.c.u.DatabaseUpgradeChecker] (main:null) 
Running upgrade Upgrade430to431 to upgrade from 4.3.0-4.3.1 to 4.3.1
2014-09-29 09:56:03,519 DEBUG [c.c.u.d.Upgrade430to431] (main:null) updating 
vlan URIs
2014-09-29 09:56:03,523 DEBUG [c.c.u.d.Upgrade430to431] (main:null) Done 
updateing vlan URIs
2014-09-29 09:56:03,542 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) 
Cleaning upgrades because all management server are now at the same version
2014-09-29 09:56:03,545 DEBUG [c.c.u.DatabaseUpgradeChecker] (main:null) 
Upgrading to version 4.3.1...
2014-09-29 09:56:03,545 INFO  [c.c.u.DatabaseUpgradeChecker] (main:null) 
Cleanup upgrade Upgrade430to431 to upgrade from 4.3.0-4.3.1 to 4.3.1
2014-09-29 09:56:03,564 DEBUG [c.c.u.DatabaseUpgradeChecker] (main:null) 
Upgrade completed for version 4.3.1
2014-09-29 09:56:03,568 INFO  [o.a.c.s.l.CloudStackExtendedLifeCycle] 
(main:null) Configuring CloudStack Components
2014-09-29 09:56:03,570 INFO  [o.a.c.s.l.CloudStackExtendedLifeCycle] 
(main:null) Done Configuring CloudStack Components
2014-09-29 09:56:03,570 INFO  [o.a.c.s.m.m.i.DefaultModuleDefinitionSet] 
(main:null) Loaded module context [system] in 2268 ms




On Oct 6, 2014, at 1:53 AM, Daan Hoogland  wrote:

> I am not sure Carlos, but I think it was due to a fix of some other network 
> related issue in 4.3.1. I thought we wrote an update/fix for it. So I am 
> looking at how your env missed out.
> 
> On Sun, Oct 5, 2014 at 1:10 AM, Carlos Reátegui  wrote:
> Sure, but I am not sure if the problem happened when I upgraded to 4.3.0 or 
> 4.3.1.  When (what version) did the broadcast_uri in the network table 
> require an entry for Guest networks and not able to be null?
> 
> 
> On Oct 4, 2014, at 4:15 AM, Daan Hoogland  wrote:
> 
>> Carlos, I think you found a bug in our upgrade scripts. Can you describe the 
>> scenario in a ticket?
>> 
>> On Sat, Oct 4, 2014 at 1:48 AM, Carlos Reátegui  wrote:
>> Hmm.  I just checked another deployment I did with 4.4.0 using the same zone 
>> type and network offering and it has the broadcast_uri set to 
>> vlan://untagged.
>> 
>> I also checked previous backups from older versions (4.10 and 4.2.1) and in 
>> all of those the broadcast_uri was blank.  I am wondering if this is a bug 
>> in the upgrade scripts. 
>> 
>> I updated network 204 and set the broadcast_uri and now I am able to start 
>> new instances.
>> 
>> thank you for your help!
>> 
>> I am including my nics table just in case you spot something else out of the 
>> ordinary.
>> 
>> mysql> select id, instance_id, network_id, netmask, gateway, ip4_address, 
>> broadcast_uri, mode, state, strategy from nics where network_id=204 order by 
>> ip4_address;
>> +-+-++---+-+---+-+--+--+-+
>> | id  | instance_id | network_id | netmask   | gateway | ip4_address 
>>   | broadcast_uri   | mode | state| strategy|
>> +-+-++---+-+---+-+--+--+-+
>> |  60 |  52 |204 | NULL  | NULL| NULL
>>   | NULL| Dhcp | Deallocating | Start   |
>> |  64 |  53 |204 | NULL  | NULL| NULL
>>   | NULL| Dhcp | Deallocating | Start   |
>> |  68 |  54 |204 | NULL  | NULL| NULL
>>   | NULL| Dhcp | Deallocating | Start   |
>> |  72 |  55 |204 | NULL  | NULL| NULL
>>   | NULL| Dhcp | Deallocating | Start   |
>> |  76 |  56 |204 | NULL  | NULL| NULL
>>   | NULL   

Re: Reserved Guest VM CIDR Question

[Logan Barfield]

Specifying IPs doesn't work, and in the network details I see that
"specifyipranges" is set to false.

I should probably note that this is using Advanced Networking with an
Isolated Guest Network.


Thank You,

Logan Barfield
Tranquil Hosting

On Mon, Oct 6, 2014 at 3:34 PM, Logan Barfield 
wrote:

> Hi Marcus,
>
> I'll give that a shot.  I didn't know if those parameters specified the
> network CIDR or the guest CIDR.
>
>
> Thank You,
>
> Logan Barfield
> Tranquil Hosting
>
> On Mon, Oct 6, 2014 at 3:15 PM, Marcus  wrote:
>
>> Do startip and endip createNetwork parameters not work for that (when
>> creating the network? That should carve out a subset of the network for
>> cloudstack use and leave the rest untouched.
>> On Oct 6, 2014 12:57 PM, "Logan Barfield" 
>> wrote:
>>
>> > We have decided internally to set up a CIDR reservation with all new
>> > accounts to give us the ability to easily attach dedicated hosts to
>> > existing VM networks.
>> >
>> > We were thinking it would be easier to set up the reservation before
>> > deploying VMs.  Setting up reservation after the fact can get
>> complicated
>> > if a VM happens to be outside the intended reservation range.
>> >
>> > The issue we're having is that reservation is not allowed until the
>> network
>> > is in the "Implemented" state (i.e. after the first VM is deployed).
>> >
>> > Why is reservation not allowed upon initial network creation?  If we
>> try to
>> > apply reservation after the first VM is online the command will fail
>> > occasionally because the first VM is deployed outside the CIDR range.
>> >
>> > Example:
>> >
>> > Guest Net: 10.1.1.0/24
>> > Reserved CIDR: 10.1.1.0/25
>> >
>> > - Attempt reservation before deploying a VM: Fails due to network not
>> being
>> > "Implemented"
>> > - Attempt reservation after many VMs are deployed: Fails due to VMs
>> being
>> > outside Reserved CIDR (e.g., 10.1.1.150), and requires a lot of work to
>> > change the VM's IP
>> > - Attempt reservation after first VM is deployed: Either succeeds, or
>> fails
>> > if the first VMs IP is outside of the reserved CIDR.
>> >
>> > How can we fix this without hacking work arounds into the deployment
>> logic?
>> >  (ex: Check network for 10.1.1.10, if it doesn't exist deploy the VM on
>> > that IP, if it already exists deploy it wherever.)
>> >
>> > Thank You,
>> >
>> > Logan Barfield
>> > Tranquil Hosting
>> >
>>
>
>

Re: Reserved Guest VM CIDR Question

[Marcus]

Here's an example:

create network vpcid=7276bcca-469c-4d23-9dd1-3391e964c453
displaytext=testnet zoneid=5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4
name=testnet networkofferingid=82c67af0-f92e-479d-b1b4-8732abeef9b7
gateway=10.10.10.1 netmask=255.255.255.0 startip=10.10.10.100
endip=10.10.10.110

This results in a 10.10.10.0/24 network created in this vpc, with
cloudstack allocating 10.10.10.100 through 10.10.10.110. I'm using it in a
VPC, but it should work the same for any guest network.seqselect * from

{
  "network": {
"account": "admin",
"acltype": "Account",
"broadcastdomaintype": "Vxlan",
"broadcasturi": "vxlan://10124",
"canusefordeploy": true,
"cidr": "10.10.10.0/24",
"displaynetwork": true,
"displaytext": "testnet",
"dns1": "199.58.198.240",
"domain": "ROOT",
"domainid": "d86c4370-bbdf-11e2-8bb5-52540014c04d",
"gateway": "10.10.10.1",
"id": "97b72d89-d81b-4582-a049-469dc42ad806",
"ispersistent": true,
"issystem": false,
"name": "testnet",
"netmask": "255.255.255.0",
"networkdomain": "cs2cloud.internal",
"networkofferingavailability": "Optional",
"networkofferingconservemode": false,
"networkofferingdisplaytext": "customer internal networks",
"networkofferingid": "82c67af0-f92e-479d-b1b4-8732abeef9b7",
"networkofferingname": "VPC Private Without Load Balancer",
"physicalnetworkid": "51617cd5-4715-495d-8931-f5d56e2af2bc",
"related": "97b72d89-d81b-4582-a049-469dc42ad806",
"restartrequired": false,
"specifyipranges": false,
"state": "Implemented",
"strechedl2subnet": false,
"tags": [],
"traffictype": "Guest",
"type": "Isolated",
"vlan": "10124",
"vpcid": "7276bcca-469c-4d23-9dd1-3391e964c453",
"zoneid": "5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4",
"zonename": "testzone"
  }
}


On Mon, Oct 6, 2014 at 1:49 PM, Logan Barfield 
wrote:

> Specifying IPs doesn't work, and in the network details I see that
> "specifyipranges" is set to false.
>
> I should probably note that this is using Advanced Networking with an
> Isolated Guest Network.
>
>
> Thank You,
>
> Logan Barfield
> Tranquil Hosting
>
> On Mon, Oct 6, 2014 at 3:34 PM, Logan Barfield 
> wrote:
>
> > Hi Marcus,
> >
> > I'll give that a shot.  I didn't know if those parameters specified the
> > network CIDR or the guest CIDR.
> >
> >
> > Thank You,
> >
> > Logan Barfield
> > Tranquil Hosting
> >
> > On Mon, Oct 6, 2014 at 3:15 PM, Marcus  wrote:
> >
> >> Do startip and endip createNetwork parameters not work for that (when
> >> creating the network? That should carve out a subset of the network for
> >> cloudstack use and leave the rest untouched.
> >> On Oct 6, 2014 12:57 PM, "Logan Barfield" 
> >> wrote:
> >>
> >> > We have decided internally to set up a CIDR reservation with all new
> >> > accounts to give us the ability to easily attach dedicated hosts to
> >> > existing VM networks.
> >> >
> >> > We were thinking it would be easier to set up the reservation before
> >> > deploying VMs.  Setting up reservation after the fact can get
> >> complicated
> >> > if a VM happens to be outside the intended reservation range.
> >> >
> >> > The issue we're having is that reservation is not allowed until the
> >> network
> >> > is in the "Implemented" state (i.e. after the first VM is deployed).
> >> >
> >> > Why is reservation not allowed upon initial network creation?  If we
> >> try to
> >> > apply reservation after the first VM is online the command will fail
> >> > occasionally because the first VM is deployed outside the CIDR range.
> >> >
> >> > Example:
> >> >
> >> > Guest Net: 10.1.1.0/24
> >> > Reserved CIDR: 10.1.1.0/25
> >> >
> >> > - Attempt reservation before deploying a VM: Fails due to network not
> >> being
> >> > "Implemented"
> >> > - Attempt reservation after many VMs are deployed: Fails due to VMs
> >> being
> >> > outside Reserved CIDR (e.g., 10.1.1.150), and requires a lot of work
> to
> >> > change the VM's IP
> >> > - Attempt reservation after first VM is deployed: Either succeeds, or
> >> fails
> >> > if the first VMs IP is outside of the reserved CIDR.
> >> >
> >> > How can we fix this without hacking work arounds into the deployment
> >> logic?
> >> >  (ex: Check network for 10.1.1.10, if it doesn't exist deploy the VM
> on
> >> > that IP, if it already exists deploy it wherever.)
> >> >
> >> > Thank You,
> >> >
> >> > Logan Barfield
> >> > Tranquil Hosting
> >> >
> >>
> >
> >
>

Re: Reserved Guest VM CIDR Question

[Marcus]

Hmm, well that used to work, but I just tried it with a 4.4 release and it
completely ignored the startip and endip parameters. I know at one point
there was a db entry allocated for every ip in the range. It was not a good
way to keep the info (large networks == lots of entries), so it may have
been refactored out recently and as a result this may no longer work. Just
speculation.

On Mon, Oct 6, 2014 at 2:00 PM, Marcus  wrote:

> Here's an example:
>
> create network vpcid=7276bcca-469c-4d23-9dd1-3391e964c453
> displaytext=testnet zoneid=5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4
> name=testnet networkofferingid=82c67af0-f92e-479d-b1b4-8732abeef9b7
> gateway=10.10.10.1 netmask=255.255.255.0 startip=10.10.10.100
> endip=10.10.10.110
>
> This results in a 10.10.10.0/24 network created in this vpc, with
> cloudstack allocating 10.10.10.100 through 10.10.10.110. I'm using it in a
> VPC, but it should work the same for any guest network.seqselect * from
>
> {
>   "network": {
> "account": "admin",
> "acltype": "Account",
> "broadcastdomaintype": "Vxlan",
> "broadcasturi": "vxlan://10124",
> "canusefordeploy": true,
> "cidr": "10.10.10.0/24",
> "displaynetwork": true,
> "displaytext": "testnet",
> "dns1": "199.58.198.240",
> "domain": "ROOT",
> "domainid": "d86c4370-bbdf-11e2-8bb5-52540014c04d",
> "gateway": "10.10.10.1",
> "id": "97b72d89-d81b-4582-a049-469dc42ad806",
> "ispersistent": true,
> "issystem": false,
> "name": "testnet",
> "netmask": "255.255.255.0",
> "networkdomain": "cs2cloud.internal",
> "networkofferingavailability": "Optional",
> "networkofferingconservemode": false,
> "networkofferingdisplaytext": "customer internal networks",
> "networkofferingid": "82c67af0-f92e-479d-b1b4-8732abeef9b7",
> "networkofferingname": "VPC Private Without Load Balancer",
> "physicalnetworkid": "51617cd5-4715-495d-8931-f5d56e2af2bc",
> "related": "97b72d89-d81b-4582-a049-469dc42ad806",
> "restartrequired": false,
> "specifyipranges": false,
> "state": "Implemented",
> "strechedl2subnet": false,
> "tags": [],
> "traffictype": "Guest",
> "type": "Isolated",
> "vlan": "10124",
> "vpcid": "7276bcca-469c-4d23-9dd1-3391e964c453",
> "zoneid": "5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4",
> "zonename": "testzone"
>   }
> }
>
>
> On Mon, Oct 6, 2014 at 1:49 PM, Logan Barfield 
> wrote:
>
>> Specifying IPs doesn't work, and in the network details I see that
>> "specifyipranges" is set to false.
>>
>> I should probably note that this is using Advanced Networking with an
>> Isolated Guest Network.
>>
>>
>> Thank You,
>>
>> Logan Barfield
>> Tranquil Hosting
>>
>> On Mon, Oct 6, 2014 at 3:34 PM, Logan Barfield 
>> wrote:
>>
>> > Hi Marcus,
>> >
>> > I'll give that a shot.  I didn't know if those parameters specified the
>> > network CIDR or the guest CIDR.
>> >
>> >
>> > Thank You,
>> >
>> > Logan Barfield
>> > Tranquil Hosting
>> >
>> > On Mon, Oct 6, 2014 at 3:15 PM, Marcus  wrote:
>> >
>> >> Do startip and endip createNetwork parameters not work for that (when
>> >> creating the network? That should carve out a subset of the network for
>> >> cloudstack use and leave the rest untouched.
>> >> On Oct 6, 2014 12:57 PM, "Logan Barfield" 
>> >> wrote:
>> >>
>> >> > We have decided internally to set up a CIDR reservation with all new
>> >> > accounts to give us the ability to easily attach dedicated hosts to
>> >> > existing VM networks.
>> >> >
>> >> > We were thinking it would be easier to set up the reservation before
>> >> > deploying VMs.  Setting up reservation after the fact can get
>> >> complicated
>> >> > if a VM happens to be outside the intended reservation range.
>> >> >
>> >> > The issue we're having is that reservation is not allowed until the
>> >> network
>> >> > is in the "Implemented" state (i.e. after the first VM is deployed).
>> >> >
>> >> > Why is reservation not allowed upon initial network creation?  If we
>> >> try to
>> >> > apply reservation after the first VM is online the command will fail
>> >> > occasionally because the first VM is deployed outside the CIDR range.
>> >> >
>> >> > Example:
>> >> >
>> >> > Guest Net: 10.1.1.0/24
>> >> > Reserved CIDR: 10.1.1.0/25
>> >> >
>> >> > - Attempt reservation before deploying a VM: Fails due to network not
>> >> being
>> >> > "Implemented"
>> >> > - Attempt reservation after many VMs are deployed: Fails due to VMs
>> >> being
>> >> > outside Reserved CIDR (e.g., 10.1.1.150), and requires a lot of work
>> to
>> >> > change the VM's IP
>> >> > - Attempt reservation after first VM is deployed: Either succeeds, or
>> >> fails
>> >> > if the first VMs IP is outside of the reserved CIDR.
>> >> >
>> >> > How can we fix this without hacking work arounds into the deployment
>> >> logic?
>> >> >  (ex: Check network for 10.1.1.10, if it doesn't exist deploy the VM
>> on
>> >> > that IP, if it already exists deploy it wherever.)
>> >> >
>>

Re: Reserved Guest VM CIDR Question

[Logan Barfield]

Yeah, that was my result as well.

It seems like you should be able to specify a 'guestcidr' when creating the
network, or at least with 'updateNetwork' without the network being in the
"Implemented" state.  I'm sure there's a reason for it being that way, but
it doesn't make much intuitive sense.

Unless I'm missing the point of the IP reservation feature this issue is
probably just the result of bad design decisions somewhere.

Does anyone know why it's required for the network to be "Implemented"
before specifying the reserved CIDR?  Does "Implemented" indicate that the
Virtual Router has been created/online, or that a VM has been deployed on
the network?  If it's just a Virtual Router check, is there a way to force
the Virtual Router to be created when creating the network, instead of
having it deploy when the first VM is created?


Thank You,

Logan Barfield
Tranquil Hosting

On Mon, Oct 6, 2014 at 4:04 PM, Marcus  wrote:

> Hmm, well that used to work, but I just tried it with a 4.4 release and it
> completely ignored the startip and endip parameters. I know at one point
> there was a db entry allocated for every ip in the range. It was not a good
> way to keep the info (large networks == lots of entries), so it may have
> been refactored out recently and as a result this may no longer work. Just
> speculation.
>
> On Mon, Oct 6, 2014 at 2:00 PM, Marcus  wrote:
>
> > Here's an example:
> >
> > create network vpcid=7276bcca-469c-4d23-9dd1-3391e964c453
> > displaytext=testnet zoneid=5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4
> > name=testnet networkofferingid=82c67af0-f92e-479d-b1b4-8732abeef9b7
> > gateway=10.10.10.1 netmask=255.255.255.0 startip=10.10.10.100
> > endip=10.10.10.110
> >
> > This results in a 10.10.10.0/24 network created in this vpc, with
> > cloudstack allocating 10.10.10.100 through 10.10.10.110. I'm using it in
> a
> > VPC, but it should work the same for any guest network.seqselect * from
> >
> > {
> >   "network": {
> > "account": "admin",
> > "acltype": "Account",
> > "broadcastdomaintype": "Vxlan",
> > "broadcasturi": "vxlan://10124",
> > "canusefordeploy": true,
> > "cidr": "10.10.10.0/24",
> > "displaynetwork": true,
> > "displaytext": "testnet",
> > "dns1": "199.58.198.240",
> > "domain": "ROOT",
> > "domainid": "d86c4370-bbdf-11e2-8bb5-52540014c04d",
> > "gateway": "10.10.10.1",
> > "id": "97b72d89-d81b-4582-a049-469dc42ad806",
> > "ispersistent": true,
> > "issystem": false,
> > "name": "testnet",
> > "netmask": "255.255.255.0",
> > "networkdomain": "cs2cloud.internal",
> > "networkofferingavailability": "Optional",
> > "networkofferingconservemode": false,
> > "networkofferingdisplaytext": "customer internal networks",
> > "networkofferingid": "82c67af0-f92e-479d-b1b4-8732abeef9b7",
> > "networkofferingname": "VPC Private Without Load Balancer",
> > "physicalnetworkid": "51617cd5-4715-495d-8931-f5d56e2af2bc",
> > "related": "97b72d89-d81b-4582-a049-469dc42ad806",
> > "restartrequired": false,
> > "specifyipranges": false,
> > "state": "Implemented",
> > "strechedl2subnet": false,
> > "tags": [],
> > "traffictype": "Guest",
> > "type": "Isolated",
> > "vlan": "10124",
> > "vpcid": "7276bcca-469c-4d23-9dd1-3391e964c453",
> > "zoneid": "5e5f35d3-acb1-4142-84c2-e7f0ea7a36f4",
> > "zonename": "testzone"
> >   }
> > }
> >
> >
> > On Mon, Oct 6, 2014 at 1:49 PM, Logan Barfield 
> > wrote:
> >
> >> Specifying IPs doesn't work, and in the network details I see that
> >> "specifyipranges" is set to false.
> >>
> >> I should probably note that this is using Advanced Networking with an
> >> Isolated Guest Network.
> >>
> >>
> >> Thank You,
> >>
> >> Logan Barfield
> >> Tranquil Hosting
> >>
> >> On Mon, Oct 6, 2014 at 3:34 PM, Logan Barfield  >
> >> wrote:
> >>
> >> > Hi Marcus,
> >> >
> >> > I'll give that a shot.  I didn't know if those parameters specified
> the
> >> > network CIDR or the guest CIDR.
> >> >
> >> >
> >> > Thank You,
> >> >
> >> > Logan Barfield
> >> > Tranquil Hosting
> >> >
> >> > On Mon, Oct 6, 2014 at 3:15 PM, Marcus  wrote:
> >> >
> >> >> Do startip and endip createNetwork parameters not work for that (when
> >> >> creating the network? That should carve out a subset of the network
> for
> >> >> cloudstack use and leave the rest untouched.
> >> >> On Oct 6, 2014 12:57 PM, "Logan Barfield" 
> >> >> wrote:
> >> >>
> >> >> > We have decided internally to set up a CIDR reservation with all
> new
> >> >> > accounts to give us the ability to easily attach dedicated hosts to
> >> >> > existing VM networks.
> >> >> >
> >> >> > We were thinking it would be easier to set up the reservation
> before
> >> >> > deploying VMs.  Setting up reservation after the fact can get
> >> >> complicated
> >> >> > if a VM happens to be outside the intended reservation range.
> >> >> >
> >> >> > The issue we're having is that reservation is not allowed 

Review Request 26404: Usage server failed to start if default java version is 1.6

[Rayees Namathponnan]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/26404/
---

Review request for cloudstack and Frank Zhang.


Bugs: CLOUDSTACK-7676
https://issues.apache.org/jira/browse/CLOUDSTACK-7676


Repository: cloudstack-git


Description
---

Install usage server on RHEL 6.3 machine
check default. java version
start usage server


Result
If default java versionis java 1.6, then management serer will fails to start

Solution
While starting usage server, we need to check java 1.7 exist or not, if exist 
then we need to start usage server with java 1.7


Diffs
-

  packaging/centos63/cloud-usage.rc 7741137 

Diff: https://reviews.apache.org/r/26404/diff/


Testing
---

Tested


Thanks,

Rayees Namathponnan

RE: Reserved Guest VM CIDR Question

[Saksham Srivastava]

Logan,

The reason why reservation is not enabled in create stage is the case of 
External network devices. 
When using external devices like NetScaler, CloudStack will not have a 'real' 
cidr unless the network has been implemented.
So a cidr like /24 used at time of create may turn to /20 when the network has 
been implemented and then it make no sense for reservation in initial stage.
What I will suggest is to create a network offering with 'Persistent' as true.
So your network will be implemented when you create it and VR will be up. Once 
the network has been implemented you can apply reservation.


Thanks,
Saksham


-Original Message-
From: Logan Barfield [mailto:lbarfi...@tqhosting.com] 
Sent: Tuesday, October 7, 2014 12:27 AM
To: dev@cloudstack.apache.org
Subject: Reserved Guest VM CIDR Question

We have decided internally to set up a CIDR reservation with all new accounts 
to give us the ability to easily attach dedicated hosts to existing VM networks.

We were thinking it would be easier to set up the reservation before deploying 
VMs.  Setting up reservation after the fact can get complicated if a VM happens 
to be outside the intended reservation range.

The issue we're having is that reservation is not allowed until the network is 
in the "Implemented" state (i.e. after the first VM is deployed).

Why is reservation not allowed upon initial network creation?  If we try to 
apply reservation after the first VM is online the command will fail 
occasionally because the first VM is deployed outside the CIDR range.

Example:

Guest Net: 10.1.1.0/24
Reserved CIDR: 10.1.1.0/25

- Attempt reservation before deploying a VM: Fails due to network not being 
"Implemented"
- Attempt reservation after many VMs are deployed: Fails due to VMs being 
outside Reserved CIDR (e.g., 10.1.1.150), and requires a lot of work to change 
the VM's IP
- Attempt reservation after first VM is deployed: Either succeeds, or fails if 
the first VMs IP is outside of the reserved CIDR.

How can we fix this without hacking work arounds into the deployment logic?
 (ex: Check network for 10.1.1.10, if it doesn't exist deploy the VM on that 
IP, if it already exists deploy it wherever.)

Thank You,

Logan Barfield
Tranquil Hosting

Re: Can't launch VMs

[Daan Hoogland]

On Mon, Oct 6, 2014 at 9:41 PM, Carlos Reátegui  wrote:

> 2014-09-29 09:56:03,519 DEBUG [c.c.u.d.Upgrade430to431] (main:null)
> updating vlan URIs
> 2014-09-29 09:56:03,523 DEBUG [c.c.u.d.Upgrade430to431] (main:null) Done
> updateing vlan URIs
>

​This is what I wanted to have confirmed. It should have done the trick.​



-- 
Daan

Re: Can't launch VMs

[Carlos Reátegui]

What is it looking for?

Where is that code?  Maybe I can have a look.

On Oct 6, 2014, at 10:54 PM, Daan Hoogland  wrote:

> 
> On Mon, Oct 6, 2014 at 9:41 PM, Carlos Reátegui  wrote:
> 2014-09-29 09:56:03,519 DEBUG [c.c.u.d.Upgrade430to431] (main:null) updating 
> vlan URIs
> 2014-09-29 09:56:03,523 DEBUG [c.c.u.d.Upgrade430to431] (main:null) Done 
> updateing vlan URIs
> 
> ​This is what I wanted to have confirmed. It should have done the trick.​
> 
> 
> 
> -- 
> Daan

Re: Can't launch VMs

[Daan Hoogland]

I just had a look at the code and found a bug. It might have not thrown an
exception where it should have. sorry about that. I am fixing that and will
port it to later versions.

On Tue, Oct 7, 2014 at 7:56 AM, Carlos Reátegui  wrote:

> What is it looking for?
>
> Where is that code?  Maybe I can have a look.
>
> On Oct 6, 2014, at 10:54 PM, Daan Hoogland 
> wrote:
>
>
> On Mon, Oct 6, 2014 at 9:41 PM, Carlos Reátegui 
> wrote:
>
>> 2014-09-29 09:56:03,519 DEBUG [c.c.u.d.Upgrade430to431] (main:null)
>> updating vlan URIs
>> 2014-09-29 09:56:03,523 DEBUG [c.c.u.d.Upgrade430to431] (main:null) Done
>> updateing vlan URIs
>>
>
> ​This is what I wanted to have confirmed. It should have done the trick.​
>
>
>
> --
> Daan
>
>
>


-- 
Daan

Re: Can't launch VMs

[Carlos Reátegui]

That was definitely a bug but will not fix my problem.  See my comment in the 
JIRA.


On Oct 6, 2014, at 11:04 PM, Daan Hoogland  wrote:

> I just had a look at the code and found a bug. It might have not thrown an 
> exception where it should have. sorry about that. I am fixing that and will 
> port it to later versions.
> 
> On Tue, Oct 7, 2014 at 7:56 AM, Carlos Reátegui  wrote:
> What is it looking for?
> 
> Where is that code?  Maybe I can have a look.
> 
> On Oct 6, 2014, at 10:54 PM, Daan Hoogland  wrote:
> 
>> 
>> On Mon, Oct 6, 2014 at 9:41 PM, Carlos Reátegui  wrote:
>> 2014-09-29 09:56:03,519 DEBUG [c.c.u.d.Upgrade430to431] (main:null) updating 
>> vlan URIs
>> 2014-09-29 09:56:03,523 DEBUG [c.c.u.d.Upgrade430to431] (main:null) Done 
>> updateing vlan URIs
>> 
>> ​This is what I wanted to have confirmed. It should have done the trick.​
>> 
>> 
>> 
>> -- 
>> Daan
> 
> 
> 
> 
> -- 
> Daan