[jira] [Updated] (CLOUDSTACK-72) Error label in traffic type edit dialog in zoneWizard
[ https://issues.apache.org/jira/browse/CLOUDSTACK-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mice Xia updated CLOUDSTACK-72: --- Attachment: CS72.png screenshot Error label in traffic type edit dialog in zoneWizard - Key: CLOUDSTACK-72 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-72 Project: CloudStack Issue Type: Bug Components: Third-Party Bugs, UI Affects Versions: pre-4.0.0 Reporter: Mice Xia Assignee: Mice Xia Priority: Minor Fix For: pre-4.0.0 Attachments: CS72.png following labels are incorrectly shown on UI, zone wizard message.edit.traffic.type label.edit.traffic.type label.traffic.label -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-72) Error label in traffic type edit dialog in zoneWizard
[ https://issues.apache.org/jira/browse/CLOUDSTACK-72?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mice Xia resolved CLOUDSTACK-72. Resolution: Fixed commit in master 87ecde648f94e8d8069bf8011fb1829dd42cbd5f Error label in traffic type edit dialog in zoneWizard - Key: CLOUDSTACK-72 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-72 Project: CloudStack Issue Type: Bug Components: Third-Party Bugs, UI Affects Versions: pre-4.0.0 Reporter: Mice Xia Assignee: Mice Xia Priority: Minor Fix For: pre-4.0.0 Attachments: CS72.png following labels are incorrectly shown on UI, zone wizard message.edit.traffic.type label.edit.traffic.type label.traffic.label -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: combining vmware-base and plugin/hypervisor/vmware?
Hey Chip, Good point, but by looking at the code it seems the other way around. Most of the generic stuff is inside the plugin (including parts of the code for the cisco nexus integration and the vmware version of the SSVM) and in particular the hypervisor code is in the vmware-base. For now I think it is more clear if we combine everything in the vmware plugin directory, should there be a need we can always separate the interface. For now I think it's unlikely that something is done via the vmware api that is not directly related to the vmware hypervisor (or used by peeps that don't use the vmware hypervisor). Cheers, Hugo -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Monday, September 10, 2012 3:39 PM To: cloudstack-dev@incubator.apache.org Subject: Re: combining vmware-base and plugin/hypervisor/vmware? On Mon, Sep 10, 2012 at 3:23 AM, Hugo Trippaers htrippa...@schubergphilis.com wrote: Heya, Anybody against moving all sources from vmware-base to plugin/hypervisors/vmware? It seems more logical to combine these two trees and make it a single plugin. Cheers, Hugo Hey Hugo, There might be a reason to keep it broken out. For example, let's say that I wanted to build a different plugin type that uses the VMware API. -chip
Re: Review Request: apache 4.0 docs
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6978/#review11317 --- Ship it! Spot checked. These are the same files Radhika and I have been using to generate docs for a commercial version of CloudStack and they have passed review and built properly in that context. - Jessica Tomechak On Sept. 10, 2012, 10:21 a.m., Radhika PC wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6978/ --- (Updated Sept. 10, 2012, 10:21 a.m.) Review request for cloudstack. Description --- This patch includes defect fixes and the new feature documentation: site-to-site vpn, inter-vlan routing, and autoscale. The issues pointed out for the Review Request #6328 has also been fixed. Updated the ASF license header for other files. Diffs - docs/en-US/Book_Info_Admin.xml PRE-CREATION docs/en-US/LDAPserver-for-user-authentication.xml 5fcb300 docs/en-US/about-clusters.xml e328cba docs/en-US/about-hosts.xml 956c695 docs/en-US/about-physical-networks.xml 8edb9e0 docs/en-US/about-pods.xml ed3520c docs/en-US/about-primary-storage.xml 68d7a25 docs/en-US/about-secondary-storage.xml c4df0b8 docs/en-US/about-security-groups.xml PRE-CREATION docs/en-US/about-virtual-networks.xml 2fc6ba9 docs/en-US/about-working-with-vms.xml 47153e2 docs/en-US/about-zones.xml a05a9a6 docs/en-US/accessing-vms.xml d69d021 docs/en-US/accounts-users-domains.xml 8549129 docs/en-US/accounts.xml 5292a9c docs/en-US/acquire-new-ip-for-vpc.xml PRE-CREATION docs/en-US/add-additional-guest-network.xml 57e7ffd docs/en-US/add-clusters-kvm-xenserver.xml PRE-CREATION docs/en-US/add-clusters-ovm.xml PRE-CREATION docs/en-US/add-clusters-vsphere.xml PRE-CREATION docs/en-US/add-gateway-vpc.xml PRE-CREATION docs/en-US/add-ingress-egress-rules.xml 964045f docs/en-US/add-iso.xml f56d10c docs/en-US/add-load-balancer-rule.xml ddbce95 docs/en-US/add-loadbalancer-rule-vpc.xml PRE-CREATION docs/en-US/add-more-clusters.xml PRE-CREATION docs/en-US/add-portforward-rule-vpc.xml PRE-CREATION docs/en-US/add-primary-storage.xml PRE-CREATION docs/en-US/add-secondary-storage.xml PRE-CREATION docs/en-US/add-security-group.xml e4c8b3c docs/en-US/add-tier.xml PRE-CREATION docs/en-US/add-vm-to-tier.xml PRE-CREATION docs/en-US/add-vpc.xml PRE-CREATION docs/en-US/advanced-zone-configuration.xml 85909e3 docs/en-US/advanced-zone-guest-ip-addresses.xml b5d10a0 docs/en-US/advanced-zone-network-traffic-types.xml 9f475cf docs/en-US/advanced-zone-physical-network-configuration.xml 4c44c7d docs/en-US/advanced-zone-public-ip-addresses.xml eeb9404 docs/en-US/alerts.xml f903023 docs/en-US/api-overview.xml PRE-CREATION docs/en-US/attach-iso-to-vm.xml 30e5d51 docs/en-US/automatic-snapshot-creation-retention.xml ee4cf73 docs/en-US/autoscale.xml PRE-CREATION docs/en-US/basic-zone-configuration.xml 18afa84 docs/en-US/basic-zone-guest-ip-addresses.xml d1d9135 docs/en-US/basic-zone-network-traffic-types.xml fa3be0f docs/en-US/basic-zone-physical-network-configuration.xml 83833a7 docs/en-US/best-practices-for-vms.xml a67add4 docs/en-US/change-database-config.xml PRE-CREATION docs/en-US/change-network-offering-on-guest-network.xml 98f1b63 docs/en-US/change-ssvm-service-offering.xml PRE-CREATION docs/en-US/changing-root-password.xml 0d2333a docs/en-US/changing-secondary-storage-ip.xml 7e146de docs/en-US/changing-service-offering-for-vm.xml 5a42912 docs/en-US/changing-vm-name-os-group.xml f16ffda docs/en-US/cloud-infrastructure-concepts.xml 58f8844 docs/en-US/cloud-infrastructure-overview.xml 5b467a3 docs/en-US/cloudstack_admin.xml c80c94f docs/en-US/cluster-add-xenserver-kvm.xml PRE-CREATION docs/en-US/cluster-add.xml 5210bd8 docs/en-US/compute-disk-service-offerings.xml 2469dfe docs/en-US/concepts.xml 1912c23 docs/en-US/configure-acl.xml PRE-CREATION docs/en-US/configure-guest-traffic-in-advanced-zone.xml 95df473 docs/en-US/configure-snmp-rhel.xml PRE-CREATION docs/en-US/configure-usage-server.xml d167a49 docs/en-US/configure-vpc.xml PRE-CREATION docs/en-US/configure-vpn.xml 9e059f7 docs/en-US/console-proxy.xml df29c42 docs/en-US/convert-hyperv-vm-to-template.xml c6294d4 docs/en-US/create-template-from-existing-vm.xml c22b7ec docs/en-US/create-template-from-snapshot.xml 3075032 docs/en-US/create-templates-overview.xml 818b42d docs/en-US/create-vpn-connection-vpc.xml PRE-CREATION docs/en-US/create-vpn-customer-gateway.xml PRE-CREATION
Review Request: cloud.spec centos6 Requires package name fix.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7009/ --- Review request for cloudstack. Description --- On centos 6.3, jakarta-commons-lang is the package name for apache-commons-lang which is the name on fedora. Without this patch, rpm installation will fail. Diffs - cloud.spec c31fe5b Diff: https://reviews.apache.org/r/7009/diff/ Testing --- Thanks, Hiroaki Kawai
Global setting : Endpointe Url - is the e intentional?
Hi, Trivial question, is there a typo in the global setting Endpointe Url (endpointe.url)? Thanks, Vijay V.
[jira] [Created] (CLOUDSTACK-73) VPC feature related labels and messages need L10N
Mice Xia created CLOUDSTACK-73: -- Summary: VPC feature related labels and messages need L10N Key: CLOUDSTACK-73 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-73 Project: CloudStack Issue Type: Bug Components: UI Affects Versions: pre-4.0.0 Reporter: Mice Xia Fix For: pre-4.0.0 resource files of non english language are not updated for new features added in 4.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Global setting : Endpointe Url - is the e intentional?
On 09/11/2012 10:14 AM, Vijay Venkatachalam wrote: Hi, Trivial question, is there a typo in the global setting Endpointe Url (endpointe.url)? No, that doesn't seem intentional but a typo. It is the endpoint where you connect to. Wido Thanks, Vijay V.
Re: List of New Features in 4.0
On Mon, Sep 10, 2012 at 01:37:28PM -0400, Alena Prokharchyk wrote: 2 more off the top of my head: * S2S VPN for Virtual Router - can work as a part of VPC only. This is not S2S between VR and VR, correct? Just VR and an externally configured HW device, correct? * ASW-style tags for cloudStack resources - http://wiki.cloudstack.org/display/RelOps/Tags+functional+spec Can this be moved to cwiki.a.o? -Alena. On 9/10/12 10:03 AM, David Nalley da...@gnsa.us wrote: On Mon, Sep 10, 2012 at 10:40 AM, James Jeffrey james.jeff...@cpp.co.uk wrote: Hello, Sorry if it already exists - I've looked but failed to find. Is there a list of new features in 4.0 please? Thanks, James Off the top of my head (so I may be missing some): Nicira NVP support Ceph/RBD support for KVM EC2/S3 API support integrated into CloudStack (formerly a separate package) Support for Caringo as backend storage for object storage VPC support There are a couple of things I've seen questions about and some code but am unsure of their status, namely: Midokura Midonet support Support for Riak CS as backend for object storage. --David -- Prasanna.,
[jira] [Created] (CLOUDSTACK-74) CloudStack distributes incorrect IPtables rules to its KVM hosts
Vladimir Ostrovsky created CLOUDSTACK-74: Summary: CloudStack distributes incorrect IPtables rules to its KVM hosts Key: CLOUDSTACK-74 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-74 Project: CloudStack Issue Type: Bug Components: Install and Setup, KVM, Network Controller Affects Versions: pre-4.0.0 Reporter: Vladimir Ostrovsky Some strange issue with IPtables rules created by CloudStack 3.0.4 on KVM hosts: I have a Basic zone of 3 KVM hosts: • 1st host runs Console Proxy, v-2-VM • 2nd host is unused • 3rd host runs Secondary Storage VM, s-1-VM Each host has two network interfaces: • eth0 (bridge cloudbr0), connected to isolated private network (used to communicate with CloudStack management server, with Primary Secondary storages and so on). • eth1 (bridge cloudbr1), connected to public / external network (goes to Internet, used by customers to communicate with VMs in the Basic zone and with Console Proxy, used by SSVM to upload / download templates). The problem: • Console Proxy doesn’t have communication with private network (with CloudStack, in first place). • SSVM doesn’t have communication with external network (for example, Internet). Why it happens: On 1st host, the IPtables rules of FORWARD chain look like this: Chain FORWARD (policy DROP 4690 packets, 242K bytes) pkts bytes target prot opt in out source destination 996 34620 BF-cloudbr1 all -- * cloudbr1 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 0 0 BF-cloudbr1 all -- cloudbr1 * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 0 0 DROP all -- * cloudbr1 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- cloudbr1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED 0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0 0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0 0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable So we see that there are rules for traffic passing via cloudbr1 (public interface), but no rules for cloudbr0 (private interface), and the default is DROP. On 3rd host, however, it’s exactly vice versa: Chain FORWARD (policy DROP 887 packets, 28760 bytes) pkts bytes target prot opt in out source destination 597K 4206M BF-cloudbr0 all -- * cloudbr0 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 0 0 BF-cloudbr0 all -- cloudbr0 * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 0 0 DROP all -- * cloudbr0 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- cloudbr0 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED 0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0 0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0 0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable And on 2nd host, there are no rules for both interfaces: Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED 0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0 0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0 0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable After I migrated the SSVM to the 1st host, the rules changed to: Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 98 15967 BF-cloudbr0 all -- * cloudbr0 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 6 192 BF-cloudbr0 all -- cloudbr0 * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 6 192 DROP all -- * cloudbr0 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- cloudbr0 * 0.0.0.0/0 0.0.0.0/0 1107 38228 BF-cloudbr1 all -- * cloudbr1 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 3 96 BF-cloudbr1 all -- cloudbr1 * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 3 96 DROP all -- * cloudbr1 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- cloudbr1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED 0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0 0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0 0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable It seems like the logic that CloudStack implements is this: •
[jira] [Commented] (CLOUDSTACK-74) CloudStack distributes incorrect IPtables rules to its KVM hosts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13452830#comment-13452830 ] Wido den Hollander commented on CLOUDSTACK-74: -- This has been fixed some time ago and will be in the 4.0 release. The commit: bdec29b3dcf916ee8260b3011928a70f513ce145 Link: https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=commitdiff;h=bdec29b3dcf916ee8260b3011928a70f513ce145 CloudStack distributes incorrect IPtables rules to its KVM hosts Key: CLOUDSTACK-74 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-74 Project: CloudStack Issue Type: Bug Components: Install and Setup, KVM, Network Controller Affects Versions: pre-4.0.0 Reporter: Vladimir Ostrovsky Some strange issue with IPtables rules created by CloudStack 3.0.4 on KVM hosts: I have a Basic zone of 3 KVM hosts: • 1st host runs Console Proxy, v-2-VM • 2nd host is unused • 3rd host runs Secondary Storage VM, s-1-VM Each host has two network interfaces: • eth0 (bridge cloudbr0), connected to isolated private network (used to communicate with CloudStack management server, with Primary Secondary storages and so on). • eth1 (bridge cloudbr1), connected to public / external network (goes to Internet, used by customers to communicate with VMs in the Basic zone and with Console Proxy, used by SSVM to upload / download templates). The problem: • Console Proxy doesn’t have communication with private network (with CloudStack, in first place). • SSVM doesn’t have communication with external network (for example, Internet). Why it happens: On 1st host, the IPtables rules of FORWARD chain look like this: Chain FORWARD (policy DROP 4690 packets, 242K bytes) pkts bytes target prot opt in out source destination 996 34620 BF-cloudbr1 all -- * cloudbr1 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 0 0 BF-cloudbr1 all -- cloudbr1 * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 0 0 DROP all -- * cloudbr1 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- cloudbr1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED 0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0 0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0 0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable So we see that there are rules for traffic passing via cloudbr1 (public interface), but no rules for cloudbr0 (private interface), and the default is DROP. On 3rd host, however, it’s exactly vice versa: Chain FORWARD (policy DROP 887 packets, 28760 bytes) pkts bytes target prot opt in out source destination 597K 4206M BF-cloudbr0 all -- * cloudbr0 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 0 0 BF-cloudbr0 all -- cloudbr0 * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 0 0 DROP all -- * cloudbr0 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- cloudbr0 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED 0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0 0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0 0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable And on 2nd host, there are no rules for both interfaces: Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED 0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0 0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0 0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable After I migrated the SSVM to the 1st host, the rules changed to: Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 98 15967 BF-cloudbr0 all -- * cloudbr0 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 6 192 BF-cloudbr0 all -- cloudbr0 * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 6 192 DROP all -- * cloudbr0 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- cloudbr0 * 0.0.0.0/0 0.0.0.0/0 1107 38228 BF-cloudbr1 all -- * cloudbr1 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 3 96 BF-cloudbr1 all -- cloudbr1 * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 3
[jira] [Created] (CLOUDSTACK-75) Install: need to changed Installer description found cllud.com in the installer description
sadhu suresh created CLOUDSTACK-75: -- Summary: Install: need to changed Installer description found cllud.com in the installer description Key: CLOUDSTACK-75 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-75 Project: CloudStack Issue Type: Bug Components: Install and Setup Affects Versions: pre-4.0.0 Reporter: sadhu suresh Noticed cloud.com in the installer description. steps: 1.down the latest build from jenkins http://jenkins.cloudstack.org/job/build-cloudstack-4.0-ubuntu12.04/lastSuccessfulBuild/artifact/CloudStack-oss-4.0.1-ubuntu12.04.tar.gz 2.Install the setup on ubuntu and check the shown test on the Installer description sadhu@ubuntu:~/CloudStack-oss-4.0.1-ubuntu12.04$ sudo ./install.sh Actual result: Noticed cloud.clom in the installer description Welcome to the Cloud.com CloudStack Installer Hit http://us.archive.ubuntu.com precise-backports/universe Translation-en Fetched 1,204 kB in 22s (54.1 kB/s) Welcome to the Cloud.com CloudStack Installer. What would you like to do? M) Install the Management Server A) Install the Agent S) Install the Usage Monitor D) Install the database server Q) Quit Expected result: description should be like this welcome to the CloudStack Installer. What would you like to do?..don't show the cloud.com in the description. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-54) awsapi contains (more) deprecated docs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13452839#comment-13452839 ] Jessica Tomechak commented on CLOUDSTACK-54: Those are ancient. We have much more up to date documentation about our AWS API compatibility in the Installation Guide. awsapi contains (more) deprecated docs -- Key: CLOUDSTACK-54 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-54 Project: CloudStack Issue Type: Bug Components: AWSAPI, Doc Affects Versions: pre-4.0.0 Reporter: David Nalley Assignee: sebastien goasguen Labels: deprecated, doc Fix For: pre-4.0.0 awsapi/docs contains EC2 and S3 documentation, which is probably 1/2 accurate at this point. We should likely purge them or migrate them to docbook (after correcting them) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: Review Request: apache 4.0 docs
Hello Community, Here is one question: AutoScale code is committed to a private branch. Where the autoscale documentation should go ? Documentation does not have a private branch yet. Therefore, I have pushed the AutoScale documentation to the master branch as of now. Do I need to revert it ? Looking forward to the right direction in this matter. Thanks -Radhika From: Jessica Tomechak [mailto:nore...@reviews.apache.org] On Behalf Of Jessica Tomechak Sent: Tuesday, September 11, 2012 1:23 PM To: cloudstack; Radhika Puthiyetath; Jessica Tomechak Subject: Re: Review Request: apache 4.0 docs This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6978/ Ship it! Spot checked. These are the same files Radhika and I have been using to generate docs for a commercial version of CloudStack and they have passed review and built properly in that context. - Jessica On September 10th, 2012, 10:21 a.m., Radhika PC wrote: Review request for cloudstack. By Radhika PC. Updated Sept. 10, 2012, 10:21 a.m. Description This patch includes defect fixes and the new feature documentation: site-to-site vpn, inter-vlan routing, and autoscale. The issues pointed out for the Review Request #6328 has also been fixed. Updated the ASF license header for other files. Testing reviewed for the commercial release Diffs * docs/en-US/Book_Info_Admin.xml (PRE-CREATION) * docs/en-US/LDAPserver-for-user-authentication.xml (5fcb300) * docs/en-US/about-clusters.xml (e328cba) * docs/en-US/about-hosts.xml (956c695) * docs/en-US/about-physical-networks.xml (8edb9e0) * docs/en-US/about-pods.xml (ed3520c) * docs/en-US/about-primary-storage.xml (68d7a25) * docs/en-US/about-secondary-storage.xml (c4df0b8) * docs/en-US/about-security-groups.xml (PRE-CREATION) * docs/en-US/about-virtual-networks.xml (2fc6ba9) * docs/en-US/about-working-with-vms.xml (47153e2) * docs/en-US/about-zones.xml (a05a9a6) * docs/en-US/accessing-vms.xml (d69d021) * docs/en-US/accounts-users-domains.xml (8549129) * docs/en-US/accounts.xml (5292a9c) * docs/en-US/acquire-new-ip-for-vpc.xml (PRE-CREATION) * docs/en-US/add-additional-guest-network.xml (57e7ffd) * docs/en-US/add-clusters-kvm-xenserver.xml (PRE-CREATION) * docs/en-US/add-clusters-ovm.xml (PRE-CREATION) * docs/en-US/add-clusters-vsphere.xml (PRE-CREATION) * docs/en-US/add-gateway-vpc.xml (PRE-CREATION) * docs/en-US/add-ingress-egress-rules.xml (964045f) * docs/en-US/add-iso.xml (f56d10c) * docs/en-US/add-load-balancer-rule.xml (ddbce95) * docs/en-US/add-loadbalancer-rule-vpc.xml (PRE-CREATION) * docs/en-US/add-more-clusters.xml (PRE-CREATION) * docs/en-US/add-portforward-rule-vpc.xml (PRE-CREATION) * docs/en-US/add-primary-storage.xml (PRE-CREATION) * docs/en-US/add-secondary-storage.xml (PRE-CREATION) * docs/en-US/add-security-group.xml (e4c8b3c) * docs/en-US/add-tier.xml (PRE-CREATION) * docs/en-US/add-vm-to-tier.xml (PRE-CREATION) * docs/en-US/add-vpc.xml (PRE-CREATION) * docs/en-US/advanced-zone-configuration.xml (85909e3) * docs/en-US/advanced-zone-guest-ip-addresses.xml (b5d10a0) * docs/en-US/advanced-zone-network-traffic-types.xml (9f475cf) * docs/en-US/advanced-zone-physical-network-configuration.xml (4c44c7d) * docs/en-US/advanced-zone-public-ip-addresses.xml (eeb9404) * docs/en-US/alerts.xml (f903023) * docs/en-US/api-overview.xml (PRE-CREATION) * docs/en-US/attach-iso-to-vm.xml (30e5d51) * docs/en-US/automatic-snapshot-creation-retention.xml (ee4cf73) * docs/en-US/autoscale.xml (PRE-CREATION) * docs/en-US/basic-zone-configuration.xml (18afa84) * docs/en-US/basic-zone-guest-ip-addresses.xml (d1d9135) * docs/en-US/basic-zone-network-traffic-types.xml (fa3be0f) * docs/en-US/basic-zone-physical-network-configuration.xml (83833a7) * docs/en-US/best-practices-for-vms.xml (a67add4) * docs/en-US/change-database-config.xml (PRE-CREATION) * docs/en-US/change-network-offering-on-guest-network.xml (98f1b63) * docs/en-US/change-ssvm-service-offering.xml (PRE-CREATION) * docs/en-US/changing-root-password.xml (0d2333a) * docs/en-US/changing-secondary-storage-ip.xml (7e146de) * docs/en-US/changing-service-offering-for-vm.xml (5a42912) * docs/en-US/changing-vm-name-os-group.xml (f16ffda) * docs/en-US/cloud-infrastructure-concepts.xml (58f8844) * docs/en-US/cloud-infrastructure-overview.xml (5b467a3) * docs/en-US/cloudstack_admin.xml (c80c94f) * docs/en-US/cluster-add-xenserver-kvm.xml (PRE-CREATION) * docs/en-US/cluster-add.xml (5210bd8) * docs/en-US/compute-disk-service-offerings.xml (2469dfe) * docs/en-US/concepts.xml (1912c23) * docs/en-US/configure-acl.xml (PRE-CREATION) * docs/en-US/configure-guest-traffic-in-advanced-zone.xml (95df473) * docs/en-US/configure-snmp-rhel.xml (PRE-CREATION) * docs/en-US/configure-usage-server.xml (d167a49) *
[jira] [Commented] (CLOUDSTACK-54) awsapi contains (more) deprecated docs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13452846#comment-13452846 ] sebastien goasguen commented on CLOUDSTACK-54: -- Jessica, can I remove all of it, or do I keep the non-duplicated content in docbook format. I am almost and will submit a patch by tomorrow. awsapi contains (more) deprecated docs -- Key: CLOUDSTACK-54 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-54 Project: CloudStack Issue Type: Bug Components: AWSAPI, Doc Affects Versions: pre-4.0.0 Reporter: David Nalley Assignee: sebastien goasguen Labels: deprecated, doc Fix For: pre-4.0.0 awsapi/docs contains EC2 and S3 documentation, which is probably 1/2 accurate at this point. We should likely purge them or migrate them to docbook (after correcting them) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CLOUDSTACK-76) ubuntu: Installer fail to install the Management Server
sadhu suresh created CLOUDSTACK-76: -- Summary: ubuntu: Installer fail to install the Management Server Key: CLOUDSTACK-76 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-76 Project: CloudStack Issue Type: Bug Components: Install and Setup Affects Versions: pre-4.0.0 Environment: http://jenkins.cloudstack.org/job/build-cloudstack-4.0-ubuntu12.04/lastSuccessfulBuild/artifact/CloudStack-oss-4.0.52-ubuntu12.04.tar.gz Reporter: sadhu suresh Priority: Blocker Steps: 1.download the latest build from jenkins http://jenkins.cloudstack.org/job/build-cloudstack-4.0-ubuntu12.04/lastSuccessfulBuild/artifact/CloudStack-oss-4.0.52-ubuntu12.04.tar.gz 2. run the installer script and observe the behavior sudo ./install.sh actual result: Installation management server not succeed .it shows cloud not find any packages whose name or description matched with cloud-client expected result:Installation should be successful with out any errors. sadhu@ubuntu:~/CloudStack-oss-4.0.1-ubuntu12.04$ sudo ./install.sh Setting up the temporary repository... Fetching updated listings... Ign file: ./ InRelease Ign file: ./ Release.gpg Ign file: ./ Release Ign file: ./ Translation-en_US Ign file: ./ Translation-en Ign http://us.archive.ubuntu.com precise InRelease Ign http://us.archive.ubuntu.com precise-updates InRelease Ign http://us.archive.ubuntu.com precise-backports InRelease Ign http://security.ubuntu.com precise-security InRelease Hit http://us.archive.ubuntu.com precise Release.gpg Get: 1 http://security.ubuntu.com precise-security Release.gpg [198 B] Get: 2 http://us.archive.ubuntu.com precise-updates Release.gpg [198 B] Get: 3 http://us.archive.ubuntu.com precise-backports Release.gpg [198 B] Get: 4 http://security.ubuntu.com precise-security Release [49.6 kB] Hit http://us.archive.ubuntu.com precise Release Get: 5 http://us.archive.ubuntu.com precise-updates Release [49.6 kB] Get: 6 http://us.archive.ubuntu.com precise-backports Release [49.6 kB] Get: 7 http://security.ubuntu.com precise-security/main Sources [42.8 kB] Hit http://us.archive.ubuntu.com precise/main Sources Hit http://us.archive.ubuntu.com precise/restricted Sources Hit http://us.archive.ubuntu.com precise/universe Sources Hit http://us.archive.ubuntu.com precise/multiverse Sources Hit http://us.archive.ubuntu.com precise/main i386 Packages Hit http://us.archive.ubuntu.com precise/restricted i386 Packages Hit http://us.archive.ubuntu.com precise/universe i386 Packages Hit http://us.archive.ubuntu.com precise/multiverse i386 Packages Hit http://us.archive.ubuntu.com precise/main TranslationIndex Hit http://us.archive.ubuntu.com precise/multiverse TranslationIndex Hit http://us.archive.ubuntu.com precise/restricted TranslationIndex Hit http://us.archive.ubuntu.com precise/universe TranslationIndex Get: 8 http://us.archive.ubuntu.com precise-updates/main Sources [162 kB] Get: 9 http://security.ubuntu.com precise-security/restricted Sources [1,950 B] Get: 10 http://security.ubuntu.com precise-security/universe Sources [12.6 kB] Get: 11 http://security.ubuntu.com precise-security/multiverse Sources [1,386 B] Get: 12 http://security.ubuntu.com precise-security/main i386 Packages [165 kB] Get: 13 http://security.ubuntu.com precise-security/restricted i386 Packages [3,968 B] Get: 14 http://us.archive.ubuntu.com precise-updates/restricted Sources [3,285 B] Get: 15 http://us.archive.ubuntu.com precise-updates/universe Sources [50.8 kB] Get: 16 http://security.ubuntu.com precise-security/universe i386 Packages [42.2 kB] Get: 17 http://security.ubuntu.com precise-security/multiverse i386 Packages [2,369 B] Hit http://security.ubuntu.com precise-security/main TranslationIndex Hit http://security.ubuntu.com precise-security/multiverse TranslationIndex Hit http://security.ubuntu.com precise-security/restricted TranslationIndex Hit http://security.ubuntu.com precise-security/universe TranslationIndex Hit http://security.ubuntu.com precise-security/main Translation-en Hit http://security.ubuntu.com precise-security/multiverse Translation-en Hit http://security.ubuntu.com precise-security/restricted Translation-en Hit http://security.ubuntu.com precise-security/universe Translation-en Get: 18 http://us.archive.ubuntu.com precise-updates/multiverse Sources [4,241 B] Get: 19 http://us.archive.ubuntu.com precise-updates/main i386 Packages [386 kB] Get: 20 http://us.archive.ubuntu.com precise-updates/restricted i386 Packages [6,732 B] Get: 21 http://us.archive.ubuntu.com precise-updates/universe i386 Packages [129 kB] Get: 22 http://us.archive.ubuntu.com precise-updates/universe i386 Packages [129 kB] Get: 23 http://us.archive.ubuntu.com precise-updates/multiverse i386 Packages [9,672 B] Hit http://us.archive.ubuntu.com precise-updates/main TranslationIndex Hit http://us.archive.ubuntu.com
Re: Review Request: Support for local data disk feature. (CS-14277)
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6431/ --- (Updated Sept. 11, 2012, 9:50 a.m.) Review request for cloudstack, Abhinandan Prateek and Nitin Mehta. Changes --- Rebased with latest code. Description --- Support for local data disk. Currently enable/disable config is at zone level, in subsequent checkins it can be made more granular. Following changes are made: - Create disk offering API now takes an extra parameter to denote storage type (local or shared). This is similar to storage type in service offering. - Create/delete of data volume on local storage - Attach/detach for local data volumes. Re-attach is allowed as long as vm host and data volume storage pool host is same. - Migration of VM instance is not supported if it uses local root or data volumes. - Migrate is not supported for local volumes. - Zone level config to enable/disable local storage usage for service and disk offerings. - Local storage gets discovered when a host is added/reconnected if zone level config is enabled. When disabled existing local storages are not removed but any new local storage is not added. - Deploy VM command validates service and disk offerings based on local storage config. - Upgrade uses the global config 'use.local.storage' to set the zone level config for local storage. Diffs (updated) - api/src/com/cloud/api/ApiConstants.java 425b9fb api/src/com/cloud/api/commands/CreateDiskOfferingCmd.java b3d9962 api/src/com/cloud/api/commands/CreateZoneCmd.java b36c721 api/src/com/cloud/api/commands/DeployVMCmd.java 9e2bc24 api/src/com/cloud/api/commands/UpdateZoneCmd.java c22bff7 api/src/com/cloud/api/response/DiskOfferingResponse.java 9b4f891 api/src/com/cloud/api/response/ZoneResponse.java f591d70 api/src/com/cloud/dc/DataCenter.java 2d3064f client/WEB-INF/classes/resources/messages.properties 1ec75ba server/src/com/cloud/api/ApiResponseHelper.java aee6af0 server/src/com/cloud/configuration/Config.java ebcd070 server/src/com/cloud/configuration/ConfigurationManager.java df28251 server/src/com/cloud/configuration/ConfigurationManagerImpl.java f9da08d server/src/com/cloud/dc/DataCenterVO.java a2b7d5f server/src/com/cloud/storage/LocalStoragePoolListener.java 1be7a55 server/src/com/cloud/storage/StorageManagerImpl.java 4425b71 server/src/com/cloud/storage/allocator/AbstractStoragePoolAllocator.java 87cb065 server/src/com/cloud/storage/allocator/FirstFitStoragePoolAllocator.java 006931d server/src/com/cloud/storage/allocator/LocalStoragePoolAllocator.java 991baad server/src/com/cloud/storage/allocator/StoragePoolAllocator.java 13f44e7 server/src/com/cloud/storage/allocator/UseLocalForRootAllocator.java 38e116a server/src/com/cloud/test/DatabaseConfig.java a6aa094 server/src/com/cloud/vm/UserVmManagerImpl.java cc48b2f setup/db/create-schema.sql 9e01d28 setup/db/db/schema-302to40.sql d1a5ea9 ui/scripts/configuration.js 5e76456 ui/scripts/storage.js e75244f ui/scripts/system.js 3bf43d3 Diff: https://reviews.apache.org/r/6431/diff/ Testing --- Tested on XS. Thanks, Koushik Das
Re: Review Request: Support for local data disk feature. (CS-14277)
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6431/ --- (Updated Sept. 11, 2012, 9:50 a.m.) Review request for cloudstack, Abhinandan Prateek and Nitin Mehta. Description --- Support for local data disk. Currently enable/disable config is at zone level, in subsequent checkins it can be made more granular. Following changes are made: - Create disk offering API now takes an extra parameter to denote storage type (local or shared). This is similar to storage type in service offering. - Create/delete of data volume on local storage - Attach/detach for local data volumes. Re-attach is allowed as long as vm host and data volume storage pool host is same. - Migration of VM instance is not supported if it uses local root or data volumes. - Migrate is not supported for local volumes. - Zone level config to enable/disable local storage usage for service and disk offerings. - Local storage gets discovered when a host is added/reconnected if zone level config is enabled. When disabled existing local storages are not removed but any new local storage is not added. - Deploy VM command validates service and disk offerings based on local storage config. - Upgrade uses the global config 'use.local.storage' to set the zone level config for local storage. Diffs - api/src/com/cloud/api/ApiConstants.java 425b9fb api/src/com/cloud/api/commands/CreateDiskOfferingCmd.java b3d9962 api/src/com/cloud/api/commands/CreateZoneCmd.java b36c721 api/src/com/cloud/api/commands/DeployVMCmd.java 9e2bc24 api/src/com/cloud/api/commands/UpdateZoneCmd.java c22bff7 api/src/com/cloud/api/response/DiskOfferingResponse.java 9b4f891 api/src/com/cloud/api/response/ZoneResponse.java f591d70 api/src/com/cloud/dc/DataCenter.java 2d3064f client/WEB-INF/classes/resources/messages.properties 1ec75ba server/src/com/cloud/api/ApiResponseHelper.java aee6af0 server/src/com/cloud/configuration/Config.java ebcd070 server/src/com/cloud/configuration/ConfigurationManager.java df28251 server/src/com/cloud/configuration/ConfigurationManagerImpl.java f9da08d server/src/com/cloud/dc/DataCenterVO.java a2b7d5f server/src/com/cloud/storage/LocalStoragePoolListener.java 1be7a55 server/src/com/cloud/storage/StorageManagerImpl.java 4425b71 server/src/com/cloud/storage/allocator/AbstractStoragePoolAllocator.java 87cb065 server/src/com/cloud/storage/allocator/FirstFitStoragePoolAllocator.java 006931d server/src/com/cloud/storage/allocator/LocalStoragePoolAllocator.java 991baad server/src/com/cloud/storage/allocator/StoragePoolAllocator.java 13f44e7 server/src/com/cloud/storage/allocator/UseLocalForRootAllocator.java 38e116a server/src/com/cloud/test/DatabaseConfig.java a6aa094 server/src/com/cloud/vm/UserVmManagerImpl.java cc48b2f setup/db/create-schema.sql 9e01d28 setup/db/db/schema-302to40.sql d1a5ea9 ui/scripts/configuration.js 5e76456 ui/scripts/storage.js e75244f ui/scripts/system.js 3bf43d3 Diff: https://reviews.apache.org/r/6431/diff/ Testing --- Tested on XS. Thanks, Koushik Das
ant debug failed to launch
I followed the instruction [1] to setup maven build environment. Everything went well except the last step: ant debug I can use mvn -P client -pl client jetty:run but encounter some other issue such as system vm could not start. I want to attach eclipse debug. Does anybody encounter following issue when using: ant debug? [java] SEVERE: Error deploying web application directory awsapi [java] java.lang.NoSuchMethodError: javax.servlet.ServletContext.getContextPath()Ljava/lang/String; [java] at org.apache.catalina.core.StandardHost$MemoryLeakTrackingListener.lifecycleEvent(StandardHost.java:616) [java] at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) [java] at org.apache.catalina.core.StandardContext.start(StandardContext.java:4700) [java] at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799) [java] at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779) [java] at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:601) [java] at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1079) [java] at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1002) [java] at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:506) [java] at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1317) [java] at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:324) [java] at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) [java] at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1065) [java] at org.apache.catalina.core.StandardHost.start(StandardHost.java:840) [java] at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057) [java] at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463) [java] at org.apache.catalina.core.StandardService.start(StandardService.java:525) [java] at org.apache.catalina.core.StandardServer.start(StandardServer.java:754) [java] at org.apache.catalina.startup.Catalina.start(Catalina.java:595) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [java] at java.lang.reflect.Method.invoke(Method.java:616) [java] at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) [java] at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) [java] Sep 11, 2012 5:52:39 PM org.apache.coyote.http11.Http11NioProtocol start [java] INFO: Starting Coyote HTTP/1.1 on http-7080 [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Building+with+Maven -- Gavin
Re: marvin live tests into master
On Sun, Sep 09, 2012 at 02:21:39AM -0400, prasanna wrote: On 8 September 2012 22:04, Noah Slater nsla...@tumbolia.org wrote: How big is the code contribution? Sizable: 11 new test suites. I've moved the pending updates here: https://github.com/vogxn/asf-marvin-updates. This is branched out of asf/cloudstack/master The purpose of IP clearance is to vet any sizeable incoming code that was done outside of the project. (That the original authors now hold ICLAs and are happy to contribute it is relatively unimportant, as far as I know.) Understood. Many tests are already part of the asf repo under test/integration/. The work that has happened outside of the project are 1) fixes to the existing tests and 2) additional test suites. These are the ones I propose to move. Hoping to get some consensus and clarity on this: 1) Only apply fixes to existing tests. Additional test suites added outside of the project can come in later after IP clearance. 2) Get IP clearance for all new test suites and push to repo. Option 1) should be okay for us to start setting up the test environment and connect the results to jenkins. Option 2) can be done later. -- Prasanna.,
[jira] [Resolved] (CLOUDSTACK-74) CloudStack distributes incorrect IPtables rules to its KVM hosts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav resolved CLOUDSTACK-74. --- Resolution: Fixed As per Wido on IRC: From bdec29b3dcf916ee8260b3011928a70f513ce145 Mon Sep 17 00:00:00 2001 From: Wido den Hollander w...@widodh.nl Date: Tue, 19 Jun 2012 12:20:22 +0200 Subject: [PATCH] Create iptable rules for all bridges assigned to a system VM CloudStack distributes incorrect IPtables rules to its KVM hosts Key: CLOUDSTACK-74 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-74 Project: CloudStack Issue Type: Bug Components: Install and Setup, KVM, Network Controller Affects Versions: pre-4.0.0 Reporter: Vladimir Ostrovsky Some strange issue with IPtables rules created by CloudStack 3.0.4 on KVM hosts: I have a Basic zone of 3 KVM hosts: • 1st host runs Console Proxy, v-2-VM • 2nd host is unused • 3rd host runs Secondary Storage VM, s-1-VM Each host has two network interfaces: • eth0 (bridge cloudbr0), connected to isolated private network (used to communicate with CloudStack management server, with Primary Secondary storages and so on). • eth1 (bridge cloudbr1), connected to public / external network (goes to Internet, used by customers to communicate with VMs in the Basic zone and with Console Proxy, used by SSVM to upload / download templates). The problem: • Console Proxy doesn’t have communication with private network (with CloudStack, in first place). • SSVM doesn’t have communication with external network (for example, Internet). Why it happens: On 1st host, the IPtables rules of FORWARD chain look like this: Chain FORWARD (policy DROP 4690 packets, 242K bytes) pkts bytes target prot opt in out source destination 996 34620 BF-cloudbr1 all -- * cloudbr1 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 0 0 BF-cloudbr1 all -- cloudbr1 * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 0 0 DROP all -- * cloudbr1 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- cloudbr1 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED 0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0 0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0 0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable So we see that there are rules for traffic passing via cloudbr1 (public interface), but no rules for cloudbr0 (private interface), and the default is DROP. On 3rd host, however, it’s exactly vice versa: Chain FORWARD (policy DROP 887 packets, 28760 bytes) pkts bytes target prot opt in out source destination 597K 4206M BF-cloudbr0 all -- * cloudbr0 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 0 0 BF-cloudbr0 all -- cloudbr0 * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 0 0 DROP all -- * cloudbr0 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- cloudbr0 * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED 0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0 0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0 0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable And on 2nd host, there are no rules for both interfaces: Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED 0 0 ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0 0 0 ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0 0 0 REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable After I migrated the SSVM to the 1st host, the rules changed to: Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 98 15967 BF-cloudbr0 all -- * cloudbr0 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 6 192 BF-cloudbr0 all -- cloudbr0 * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 6 192 DROP all -- * cloudbr0 0.0.0.0/0 0.0.0.0/0 0 0 DROP all -- cloudbr0 * 0.0.0.0/0 0.0.0.0/0 1107 38228 BF-cloudbr1 all -- * cloudbr1 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 3 96 BF-cloudbr1 all -- cloudbr1 * 0.0.0.0/0 0.0.0.0/0 PHYSDEV match --physdev-is-bridged 3 96 DROP all -- * cloudbr1 0.0.0.0/0 0.0.0.0/0
Review Request: Set correct version for database version check
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7013/ --- Review request for cloudstack. Description --- Reading com.cloud.maint.Version in server, version numbers must be x.x.x and artifacts should be appneded with -. This patch will fix startup database check errors in management server. Diffs - wscript f1c9b62 wscript_configure dcea410 Diff: https://reviews.apache.org/r/7013/diff/ Testing --- Thanks, Hiroaki Kawai
[jira] [Created] (CLOUDSTACK-77) console proxy display issues
Jasper Wonnink created CLOUDSTACK-77: Summary: console proxy display issues Key: CLOUDSTACK-77 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-77 Project: CloudStack Issue Type: Bug Components: VNC Proxy Affects Versions: pre-4.0.0 Environment: KMV, FC14, CS 2.2.14 Reporter: Jasper Wonnink As an addition to ticket: http://bugs.cloudstack.org/browse/CS-5273 I encountered the same problem as mentioned above. White squares, screen not updating. The fix for me was to turn off GSO and TSO via ethtool on the console proxy. After turning it off it did not have the issue anymore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
fail to install MS on UBuntu12.04
HI All, Installer fail to read the cloud packages and MS installation on Ubuntu 12.04 was not successful(No packages were installed) Raised a blocker bug. Please find the issue details in the below mentioned issue: https://issues.apache.org/jira/browse/CLOUDSTACK-76 Welcome to the Cloud.com CloudStack Installer. What would you like to do? M) Install the Management Server A) Install the Agent S) Install the Usage Monitor D) Install the database server Q) Quit M Installing the Management Server... Couldn't find any package whose name or description matched cloud-client Couldn't find any package whose name or description matched cloud-client No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 9 not upgraded. Need to get 0 B of archives. After unpacking 0 B will be used. Regards Sadhu
[jira] [Updated] (CLOUDSTACK-76) ubuntu: Installer fail to install the Management Server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-76?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-76: --- Fix Version/s: pre-4.0.0 Assignee: edison su ubuntu: Installer fail to install the Management Server --- Key: CLOUDSTACK-76 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-76 Project: CloudStack Issue Type: Bug Components: Install and Setup Affects Versions: pre-4.0.0 Environment: http://jenkins.cloudstack.org/job/build-cloudstack-4.0-ubuntu12.04/lastSuccessfulBuild/artifact/CloudStack-oss-4.0.52-ubuntu12.04.tar.gz Reporter: sadhu suresh Assignee: edison su Priority: Blocker Fix For: pre-4.0.0 Steps: 1.download the latest build from jenkins http://jenkins.cloudstack.org/job/build-cloudstack-4.0-ubuntu12.04/lastSuccessfulBuild/artifact/CloudStack-oss-4.0.52-ubuntu12.04.tar.gz 2. run the installer script and observe the behavior sudo ./install.sh actual result: Installation management server not succeed .it shows cloud not find any packages whose name or description matched with cloud-client expected result:Installation should be successful with out any errors. sadhu@ubuntu:~/CloudStack-oss-4.0.1-ubuntu12.04$ sudo ./install.sh Setting up the temporary repository... Fetching updated listings... Ign file: ./ InRelease Ign file: ./ Release.gpg Ign file: ./ Release Ign file: ./ Translation-en_US Ign file: ./ Translation-en Ign http://us.archive.ubuntu.com precise InRelease Ign http://us.archive.ubuntu.com precise-updates InRelease Ign http://us.archive.ubuntu.com precise-backports InRelease Ign http://security.ubuntu.com precise-security InRelease Hit http://us.archive.ubuntu.com precise Release.gpg Get: 1 http://security.ubuntu.com precise-security Release.gpg [198 B] Get: 2 http://us.archive.ubuntu.com precise-updates Release.gpg [198 B] Get: 3 http://us.archive.ubuntu.com precise-backports Release.gpg [198 B] Get: 4 http://security.ubuntu.com precise-security Release [49.6 kB] Hit http://us.archive.ubuntu.com precise Release Get: 5 http://us.archive.ubuntu.com precise-updates Release [49.6 kB] Get: 6 http://us.archive.ubuntu.com precise-backports Release [49.6 kB] Get: 7 http://security.ubuntu.com precise-security/main Sources [42.8 kB] Hit http://us.archive.ubuntu.com precise/main Sources Hit http://us.archive.ubuntu.com precise/restricted Sources Hit http://us.archive.ubuntu.com precise/universe Sources Hit http://us.archive.ubuntu.com precise/multiverse Sources Hit http://us.archive.ubuntu.com precise/main i386 Packages Hit http://us.archive.ubuntu.com precise/restricted i386 Packages Hit http://us.archive.ubuntu.com precise/universe i386 Packages Hit http://us.archive.ubuntu.com precise/multiverse i386 Packages Hit http://us.archive.ubuntu.com precise/main TranslationIndex Hit http://us.archive.ubuntu.com precise/multiverse TranslationIndex Hit http://us.archive.ubuntu.com precise/restricted TranslationIndex Hit http://us.archive.ubuntu.com precise/universe TranslationIndex Get: 8 http://us.archive.ubuntu.com precise-updates/main Sources [162 kB] Get: 9 http://security.ubuntu.com precise-security/restricted Sources [1,950 B] Get: 10 http://security.ubuntu.com precise-security/universe Sources [12.6 kB] Get: 11 http://security.ubuntu.com precise-security/multiverse Sources [1,386 B] Get: 12 http://security.ubuntu.com precise-security/main i386 Packages [165 kB] Get: 13 http://security.ubuntu.com precise-security/restricted i386 Packages [3,968 B] Get: 14 http://us.archive.ubuntu.com precise-updates/restricted Sources [3,285 B] Get: 15 http://us.archive.ubuntu.com precise-updates/universe Sources [50.8 kB] Get: 16 http://security.ubuntu.com precise-security/universe i386 Packages [42.2 kB] Get: 17 http://security.ubuntu.com precise-security/multiverse i386 Packages [2,369 B] Hit http://security.ubuntu.com precise-security/main TranslationIndex Hit http://security.ubuntu.com precise-security/multiverse TranslationIndex Hit http://security.ubuntu.com precise-security/restricted TranslationIndex Hit http://security.ubuntu.com precise-security/universe TranslationIndex Hit http://security.ubuntu.com precise-security/main Translation-en Hit http://security.ubuntu.com precise-security/multiverse Translation-en Hit http://security.ubuntu.com precise-security/restricted Translation-en Hit http://security.ubuntu.com precise-security/universe Translation-en Get: 18 http://us.archive.ubuntu.com precise-updates/multiverse Sources [4,241 B] Get: 19 http://us.archive.ubuntu.com precise-updates/main i386 Packages [386 kB] Get: 20 http://us.archive.ubuntu.com precise-updates/restricted i386 Packages [6,732 B] Get:
Re: Discuss on the Jenkins CI
I'm not entirely clear about the role of puppet here. Where exactly does puppet fit in? AFAIK, the slave nodes can be dumb slaves that just do distro specific builds for us. They can be preconfigured and reused for each build. They don't even need to have jenkins installed on them. The slave.jar is just moved into the nodes directly by jenkins and it can track and monitor their state. The packaging commands - dpkg, rpmbuild can then be run within slaves and artifacts can be copied back to master where they are hosted for download. I think this is how some of the projects build on http://build.apache.org where you can see distro specific slaves. +1 - on moving to jenkins controlled builds. External scripts should be replaced by jenkins plugins. There are a wide variety of them - SSH, git, mvn and even jClouds. -- Prasanna., On Mon, Sep 10, 2012 at 09:07:38PM -0400, Frank Zhang wrote: I thought we should use puppet anyway for future expansion. For now, for instance, installing Jenkins itself should be done by puppet, adding ssh credential, adding an account, and whatever system configuration works. What I expect is we only spring up a vm with puppet agent installed, puppet master takes care of rest work (no manually 'yum install Jenkins' anymore) And puppet should go to our test system in future as well, so now let's take this chance to make puppet warm up. It's ok to warm up puppet, but the build is more important. For example, we need to customize the version number, or the name of the artifcates(rpm/deb), it's better to move to new Jenkins, other than hacking on the existing python code. We can do that. Just step by step. As setting up puppet is easier, let's do it first. Next week I think we can move to Jenkins plugins
[jira] [Updated] (CLOUDSTACK-73) VPC feature related labels and messages need L10N
[ https://issues.apache.org/jira/browse/CLOUDSTACK-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-73: --- Assignee: Jessica Wang VPC feature related labels and messages need L10N - Key: CLOUDSTACK-73 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-73 Project: CloudStack Issue Type: Bug Components: UI Affects Versions: pre-4.0.0 Reporter: Mice Xia Assignee: Jessica Wang Fix For: pre-4.0.0 resource files of non english language are not updated for new features added in 4.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-78) Cloudstack Agent installation failed with jsvc package dependancy error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-78: --- Assignee: edison su Cloudstack Agent installation failed with jsvc package dependancy error Key: CLOUDSTACK-78 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-78 Project: CloudStack Issue Type: Bug Components: Install and Setup Affects Versions: pre-4.0.0 Reporter: Sailaja Mada Assignee: edison su Priority: Critical Steps: 1. Tried installing Agent with KVM host . Observation : Cloudstack Agent installation failed with jsvc package dependancy error Details : M) Install the Management Server A) Install the Agent B) Install BareMetal Agent S) Install the Usage Monitor D) Install the database server Q) Quit A Installing the Agent... Loaded plugins: product-id, security, subscription-manager Updating certificate-based repositories. cloud-temp | 2.6 kB 00:00 ... cloud-temp/primary_db | 10 kB 00:00 ... rhel | 4.0 kB 00:00 ... Setting up Install Process No package cloud-premium available. Resolving Dependencies -- Running transaction check --- Package cloud-agent.x86_64 0:4.0.59-0.59.el6.4.0 will be installed -- Processing Dependency: cloud-utils = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-python = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-deps = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-core = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-agent-scripts = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-agent-libs = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: jsvc for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: jna for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Running transaction check --- Package cloud-agent.x86_64 0:4.0.59-0.59.el6.4.0 will be installed -- Processing Dependency: jsvc for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 --- Package cloud-agent-libs.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-agent-scripts.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-core.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-deps.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-python.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-utils.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package jna.x86_64 0:3.2.4-2.el6 will be installed -- Finished Dependency Resolution Error: Package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 (cloud-temp) Requires: jsvc You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Done Expected Results : Installation should go thru with out any issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-75) Install: need to changed Installer description found cllud.com in the installer description
[ https://issues.apache.org/jira/browse/CLOUDSTACK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-75: --- Assignee: Chip Childers Install: need to changed Installer description found cllud.com in the installer description - Key: CLOUDSTACK-75 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-75 Project: CloudStack Issue Type: Bug Components: Install and Setup Affects Versions: pre-4.0.0 Reporter: sadhu suresh Assignee: Chip Childers Noticed cloud.com in the installer description. steps: 1.down the latest build from jenkins http://jenkins.cloudstack.org/job/build-cloudstack-4.0-ubuntu12.04/lastSuccessfulBuild/artifact/CloudStack-oss-4.0.1-ubuntu12.04.tar.gz 2.Install the setup on ubuntu and check the shown test on the Installer description sadhu@ubuntu:~/CloudStack-oss-4.0.1-ubuntu12.04$ sudo ./install.sh Actual result: Noticed cloud.clom in the installer description Welcome to the Cloud.com CloudStack Installer Hit http://us.archive.ubuntu.com precise-backports/universe Translation-en Fetched 1,204 kB in 22s (54.1 kB/s) Welcome to the Cloud.com CloudStack Installer. What would you like to do? M) Install the Management Server A) Install the Agent S) Install the Usage Monitor D) Install the database server Q) Quit Expected result: description should be like this welcome to the CloudStack Installer. What would you like to do?..don't show the cloud.com in the description. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-77) console proxy display issues
[ https://issues.apache.org/jira/browse/CLOUDSTACK-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-77: --- Assignee: edison su console proxy display issues Key: CLOUDSTACK-77 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-77 Project: CloudStack Issue Type: Bug Components: VNC Proxy Affects Versions: pre-4.0.0 Environment: KMV, FC14, CS 2.2.14 Reporter: Jasper Wonnink Assignee: edison su As an addition to ticket: http://bugs.cloudstack.org/browse/CS-5273 I encountered the same problem as mentioned above. White squares, screen not updating. The fix for me was to turn off GSO and TSO via ethtool on the console proxy. After turning it off it did not have the issue anymore. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ant debug failed to launch
Permissions -rwx- on CATALINA_HOME for the user? On 11 September 2012 15:24, Gavin Lee gavin@gmail.com wrote: I followed the instruction [1] to setup maven build environment. Everything went well except the last step: ant debug I can use mvn -P client -pl client jetty:run but encounter some other issue such as system vm could not start. I want to attach eclipse debug. Does anybody encounter following issue when using: ant debug? [java] SEVERE: Error deploying web application directory awsapi [java] java.lang.NoSuchMethodError: javax.servlet.ServletContext.getContextPath()Ljava/lang/String; [java] at org.apache.catalina.core.StandardHost$MemoryLeakTrackingListener.lifecycleEvent(StandardHost.java:616) [java] at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) [java] at org.apache.catalina.core.StandardContext.start(StandardContext.java:4700) [java] at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799) [java] at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779) [java] at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:601) [java] at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1079) [java] at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1002) [java] at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:506) [java] at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1317) [java] at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:324) [java] at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) [java] at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1065) [java] at org.apache.catalina.core.StandardHost.start(StandardHost.java:840) [java] at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057) [java] at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463) [java] at org.apache.catalina.core.StandardService.start(StandardService.java:525) [java] at org.apache.catalina.core.StandardServer.start(StandardServer.java:754) [java] at org.apache.catalina.startup.Catalina.start(Catalina.java:595) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [java] at java.lang.reflect.Method.invoke(Method.java:616) [java] at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) [java] at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) [java] Sep 11, 2012 5:52:39 PM org.apache.coyote.http11.Http11NioProtocol start [java] INFO: Starting Coyote HTTP/1.1 on http-7080 [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Building+with+Maven -- Gavin
Re: ant debug failed to launch
Make sure you're the owner on the source code (where your jars are) and on CATALINA_HOME. chown -R your-user path to tomcat and path to repo/src ant deploy-server and, ant debug! Regards, Rohit On 11-Sep-2012, at 3:24 PM, Gavin Lee gavin@gmail.com wrote: I followed the instruction [1] to setup maven build environment. Everything went well except the last step: ant debug I can use mvn -P client -pl client jetty:run but encounter some other issue such as system vm could not start. I want to attach eclipse debug. Does anybody encounter following issue when using: ant debug? [java] SEVERE: Error deploying web application directory awsapi [java] java.lang.NoSuchMethodError: javax.servlet.ServletContext.getContextPath()Ljava/lang/String; [java] at org.apache.catalina.core.StandardHost$MemoryLeakTrackingListener.lifecycleEvent(StandardHost.java:616) [java] at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) [java] at org.apache.catalina.core.StandardContext.start(StandardContext.java:4700) [java] at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799) [java] at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779) [java] at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:601) [java] at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1079) [java] at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1002) [java] at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:506) [java] at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1317) [java] at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:324) [java] at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) [java] at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1065) [java] at org.apache.catalina.core.StandardHost.start(StandardHost.java:840) [java] at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057) [java] at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463) [java] at org.apache.catalina.core.StandardService.start(StandardService.java:525) [java] at org.apache.catalina.core.StandardServer.start(StandardServer.java:754) [java] at org.apache.catalina.startup.Catalina.start(Catalina.java:595) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [java] at java.lang.reflect.Method.invoke(Method.java:616) [java] at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) [java] at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) [java] Sep 11, 2012 5:52:39 PM org.apache.coyote.http11.Http11NioProtocol start [java] INFO: Starting Coyote HTTP/1.1 on http-7080 [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Building+with+Maven -- Gavin
Re: Review Request: agent rpm package requires more package on CentOS6
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7015/#review11320 --- Fixes https://issues.apache.org/jira/browse/CLOUDSTACK-78? - Prasanna Santhanam On Sept. 11, 2012, 12:09 p.m., Hiroaki Kawai wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7015/ --- (Updated Sept. 11, 2012, 12:09 p.m.) Review request for cloudstack. Description --- On CentOS 6.3, jsvc is resolved as jakarta-commons-daemon-jsvc, but jakarta-commons-daemon was not installed with it. jakarta-commons-daemon provides /usr/share/java/commons-daemon.jar. Without this package, jsvc fails to start because of lack of necessary classes, and debugging this is quite hard that I had to pass -errfile option to jsvc. Diffs - cloud.spec c31fe5b Diff: https://reviews.apache.org/r/7015/diff/ Testing --- Thanks, Hiroaki Kawai
Re: fail to install MS on UBuntu12.04
On 09/11/2012 12:16 PM, Suresh Sadhu wrote: HI All, Installer fail to read the cloud packages and MS installation on Ubuntu 12.04 was not successful(No packages were installed) Raised a blocker bug. Please find the issue details in the below mentioned issue: I'd like to bring this up again, do we REALLY want this install.sh script? When manually installing the packages with dpkg you have to resolve all the dependencies manually. If we had a Ubuntu/Debian repo like I created on http://cloudstack.apt-get.eu/ we could just apt-get install all the packages we need. Imho there is no role for install.sh here. Wido https://issues.apache.org/jira/browse/CLOUDSTACK-76 Welcome to the Cloud.com CloudStack Installer. What would you like to do? M) Install the Management Server A) Install the Agent S) Install the Usage Monitor D) Install the database server Q) Quit M Installing the Management Server... Couldn't find any package whose name or description matched cloud-client Couldn't find any package whose name or description matched cloud-client No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 9 not upgraded. Need to get 0 B of archives. After unpacking 0 B will be used. Regards Sadhu
Re: Review Request: Fix CS-15603
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6515/ --- (Updated Sept. 11, 2012, 12:32 p.m.) Review request for cloudstack and Abhinandan Prateek. Changes --- Ignoring sync for VMs that doesn't follow CS naming convention Description --- When a VM is force deleted and the host is not available then CS simply marks the state in db as Destroyed/Expunging. The VM is still running on the host and once it becomes available again there is a discrepancy in state of the VM. In this scenario the VM is removed from the host when the next full cluster sync happens. Diffs (updated) - server/src/com/cloud/vm/VirtualMachineManagerImpl.java 605ce57 Diff: https://reviews.apache.org/r/6515/diff/ Testing --- Thanks, Koushik Das
Re: Review Request: CS-16104: Improve restart network behaviour for basic network
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6781/#review11323 --- I'm splitting the fix. Will send DAO related fix separately. - Rohit Yadav On Aug. 27, 2012, 11:10 a.m., Rohit Yadav wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6781/ --- (Updated Aug. 27, 2012, 11:10 a.m.) Review request for cloudstack, Abhinandan Prateek, Alena Prokharchyk, and Chiradeep Vittal. Description --- Patch as per discussion on ML and http://bugs.cloudstack.org/browse/CS-16104 For git am: Download original patch: http://patchbin.baagi.org/p?id=yfawv5 This addresses bug CS-16104. Diffs - server/src/com/cloud/network/NetworkManagerImpl.java 817075e server/src/com/cloud/vm/dao/DomainRouterDao.java 01e3258 server/src/com/cloud/vm/dao/DomainRouterDaoImpl.java 175d3f2 server/src/com/cloud/vm/dao/VMInstanceDao.java 2cf3d75 server/src/com/cloud/vm/dao/VMInstanceDaoImpl.java 571b5d1 ui/scripts/network.js ec32c49 Diff: https://reviews.apache.org/r/6781/diff/ Testing --- Thanks, Rohit Yadav
Review Request: Add helper for DAO based on podId
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7017/ --- Review request for cloudstack, Murali Reddy, Alena Prokharchyk, and Alex Huang. Description --- They will be used by https://reviews.apache.org/r/6781/ Dao: Add helpers for listing based on podId - added listByPodId - fixed listByTypeAndState to accept type and then state as arguments - added listByPodIdTypeAndState in VMInstanceDao Download original patch: http://patchbin.baagi.org/p?id=ue9o0z Diffs - server/src/com/cloud/vm/dao/DomainRouterDao.java 01e3258 server/src/com/cloud/vm/dao/DomainRouterDaoImpl.java 175d3f2 server/src/com/cloud/vm/dao/VMInstanceDao.java 2cf3d75 server/src/com/cloud/vm/dao/VMInstanceDaoImpl.java 571b5d1 Diff: https://reviews.apache.org/r/7017/diff/ Testing --- Thanks, Rohit Yadav
[jira] [Commented] (CLOUDSTACK-76) ubuntu: Installer fail to install the Management Server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13452976#comment-13452976 ] Abhinav Roy commented on CLOUDSTACK-76: --- I tried Installing the same build on Ubuntu 12.4, and I faced different issues. For me the installation process started but had following errors during the process and at the end. unpacking cloud-deps (from .../cloud-deps_4.0.0-rc1_amd64.deb) ... dpkg: error processing /abhinavr/CloudStack-oss-4.0.52-ubuntu12.04/./cloud-deps_4.0.0-rc1_amd64.deb (--unpack): trying to overwrite '/usr/share/java/commons-dbcp-1.4.jar', which is also in package libcommons-dbcp-java 1.4-1ubuntu1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: /abhinavr/CloudStack-oss-4.0.52-ubuntu12.04/./cloud-deps_4.0.0-rc1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: Setting up libws-commons-util-java (1.0.1-7) ... dpkg: dependency problems prevent configuration of cloud-setup: cloud-setup depends on cloud-deps (= 4.0.0-rc1); however: Package cloud-deps is not installed. ldconfig deferred processing now taking place Errors were encountered while processing: cloud-setup cloud-client cloud-client-ui cloud-server Since it was all because of dependency on cloud-deps package which failed to install, I tried to install this package manually but again got this error, bhinavr@MS-ubuntu12:/abhinavr/CloudStack-oss-4.0.52-ubuntu12.04$ sudo dpkg -i cloud-deps_4.0.0-rc1_amd64.deb (Reading database ... 55269 files and directories currently installed.) Unpacking cloud-deps (from cloud-deps_4.0.0-rc1_amd64.deb) ... dpkg: error processing cloud-deps_4.0.0-rc1_amd64.deb (--install): trying to overwrite '/usr/share/java/commons-dbcp-1.4.jar', which is also in package libcommons-dbcp-java 1.4-1ubuntu1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: cloud-deps_4.0.0-rc1_amd64.deb ubuntu: Installer fail to install the Management Server --- Key: CLOUDSTACK-76 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-76 Project: CloudStack Issue Type: Bug Components: Install and Setup Affects Versions: pre-4.0.0 Environment: http://jenkins.cloudstack.org/job/build-cloudstack-4.0-ubuntu12.04/lastSuccessfulBuild/artifact/CloudStack-oss-4.0.52-ubuntu12.04.tar.gz Reporter: sadhu suresh Assignee: edison su Priority: Blocker Fix For: pre-4.0.0 Steps: 1.download the latest build from jenkins http://jenkins.cloudstack.org/job/build-cloudstack-4.0-ubuntu12.04/lastSuccessfulBuild/artifact/CloudStack-oss-4.0.52-ubuntu12.04.tar.gz 2. run the installer script and observe the behavior sudo ./install.sh actual result: Installation management server not succeed .it shows cloud not find any packages whose name or description matched with cloud-client expected result:Installation should be successful with out any errors. sadhu@ubuntu:~/CloudStack-oss-4.0.1-ubuntu12.04$ sudo ./install.sh Setting up the temporary repository... Fetching updated listings... Ign file: ./ InRelease Ign file: ./ Release.gpg Ign file: ./ Release Ign file: ./ Translation-en_US Ign file: ./ Translation-en Ign http://us.archive.ubuntu.com precise InRelease Ign http://us.archive.ubuntu.com precise-updates InRelease Ign http://us.archive.ubuntu.com precise-backports InRelease Ign http://security.ubuntu.com precise-security InRelease Hit http://us.archive.ubuntu.com precise Release.gpg Get: 1 http://security.ubuntu.com precise-security Release.gpg [198 B] Get: 2 http://us.archive.ubuntu.com precise-updates Release.gpg [198 B] Get: 3 http://us.archive.ubuntu.com precise-backports Release.gpg [198 B] Get: 4 http://security.ubuntu.com precise-security Release [49.6 kB] Hit http://us.archive.ubuntu.com precise Release Get: 5 http://us.archive.ubuntu.com precise-updates Release [49.6 kB] Get: 6 http://us.archive.ubuntu.com precise-backports Release [49.6 kB] Get: 7 http://security.ubuntu.com precise-security/main Sources [42.8 kB] Hit http://us.archive.ubuntu.com precise/main Sources Hit http://us.archive.ubuntu.com precise/restricted Sources Hit http://us.archive.ubuntu.com precise/universe Sources Hit http://us.archive.ubuntu.com precise/multiverse Sources Hit http://us.archive.ubuntu.com precise/main i386 Packages Hit http://us.archive.ubuntu.com precise/restricted i386 Packages Hit http://us.archive.ubuntu.com precise/universe i386 Packages Hit http://us.archive.ubuntu.com precise/multiverse i386 Packages Hit http://us.archive.ubuntu.com precise/main TranslationIndex Hit
[jira] [Commented] (CLOUDSTACK-76) ubuntu: Installer fail to install the Management Server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13452977#comment-13452977 ] Wido den Hollander commented on CLOUDSTACK-76: -- This is know and I've fixed this in commit 664927948a3b2cf10320221db6247a4c20887ac2 Since then I've done a couple of similar commits with fixing files which are also in different packages. You might want to take very recent Deb packages for further testing. ubuntu: Installer fail to install the Management Server --- Key: CLOUDSTACK-76 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-76 Project: CloudStack Issue Type: Bug Components: Install and Setup Affects Versions: pre-4.0.0 Environment: http://jenkins.cloudstack.org/job/build-cloudstack-4.0-ubuntu12.04/lastSuccessfulBuild/artifact/CloudStack-oss-4.0.52-ubuntu12.04.tar.gz Reporter: sadhu suresh Assignee: edison su Priority: Blocker Fix For: pre-4.0.0 Steps: 1.download the latest build from jenkins http://jenkins.cloudstack.org/job/build-cloudstack-4.0-ubuntu12.04/lastSuccessfulBuild/artifact/CloudStack-oss-4.0.52-ubuntu12.04.tar.gz 2. run the installer script and observe the behavior sudo ./install.sh actual result: Installation management server not succeed .it shows cloud not find any packages whose name or description matched with cloud-client expected result:Installation should be successful with out any errors. sadhu@ubuntu:~/CloudStack-oss-4.0.1-ubuntu12.04$ sudo ./install.sh Setting up the temporary repository... Fetching updated listings... Ign file: ./ InRelease Ign file: ./ Release.gpg Ign file: ./ Release Ign file: ./ Translation-en_US Ign file: ./ Translation-en Ign http://us.archive.ubuntu.com precise InRelease Ign http://us.archive.ubuntu.com precise-updates InRelease Ign http://us.archive.ubuntu.com precise-backports InRelease Ign http://security.ubuntu.com precise-security InRelease Hit http://us.archive.ubuntu.com precise Release.gpg Get: 1 http://security.ubuntu.com precise-security Release.gpg [198 B] Get: 2 http://us.archive.ubuntu.com precise-updates Release.gpg [198 B] Get: 3 http://us.archive.ubuntu.com precise-backports Release.gpg [198 B] Get: 4 http://security.ubuntu.com precise-security Release [49.6 kB] Hit http://us.archive.ubuntu.com precise Release Get: 5 http://us.archive.ubuntu.com precise-updates Release [49.6 kB] Get: 6 http://us.archive.ubuntu.com precise-backports Release [49.6 kB] Get: 7 http://security.ubuntu.com precise-security/main Sources [42.8 kB] Hit http://us.archive.ubuntu.com precise/main Sources Hit http://us.archive.ubuntu.com precise/restricted Sources Hit http://us.archive.ubuntu.com precise/universe Sources Hit http://us.archive.ubuntu.com precise/multiverse Sources Hit http://us.archive.ubuntu.com precise/main i386 Packages Hit http://us.archive.ubuntu.com precise/restricted i386 Packages Hit http://us.archive.ubuntu.com precise/universe i386 Packages Hit http://us.archive.ubuntu.com precise/multiverse i386 Packages Hit http://us.archive.ubuntu.com precise/main TranslationIndex Hit http://us.archive.ubuntu.com precise/multiverse TranslationIndex Hit http://us.archive.ubuntu.com precise/restricted TranslationIndex Hit http://us.archive.ubuntu.com precise/universe TranslationIndex Get: 8 http://us.archive.ubuntu.com precise-updates/main Sources [162 kB] Get: 9 http://security.ubuntu.com precise-security/restricted Sources [1,950 B] Get: 10 http://security.ubuntu.com precise-security/universe Sources [12.6 kB] Get: 11 http://security.ubuntu.com precise-security/multiverse Sources [1,386 B] Get: 12 http://security.ubuntu.com precise-security/main i386 Packages [165 kB] Get: 13 http://security.ubuntu.com precise-security/restricted i386 Packages [3,968 B] Get: 14 http://us.archive.ubuntu.com precise-updates/restricted Sources [3,285 B] Get: 15 http://us.archive.ubuntu.com precise-updates/universe Sources [50.8 kB] Get: 16 http://security.ubuntu.com precise-security/universe i386 Packages [42.2 kB] Get: 17 http://security.ubuntu.com precise-security/multiverse i386 Packages [2,369 B] Hit http://security.ubuntu.com precise-security/main TranslationIndex Hit http://security.ubuntu.com precise-security/multiverse TranslationIndex Hit http://security.ubuntu.com precise-security/restricted TranslationIndex Hit http://security.ubuntu.com precise-security/universe TranslationIndex Hit http://security.ubuntu.com precise-security/main Translation-en Hit http://security.ubuntu.com precise-security/multiverse Translation-en Hit http://security.ubuntu.com precise-security/restricted Translation-en Hit http://security.ubuntu.com precise-security/universe
Re: Review Request: agent rpm package requires more package on CentOS6
On Sept. 11, 2012, 12:22 p.m., Prasanna Santhanam wrote: Fixes https://issues.apache.org/jira/browse/CLOUDSTACK-78? No, I think. In my computing node od centos 6,jsvc was installed successfully. Issue 78 requires more information about the explicit distribution on which KVM is running. - Hiroaki --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7015/#review11320 --- On Sept. 11, 2012, 12:09 p.m., Hiroaki Kawai wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7015/ --- (Updated Sept. 11, 2012, 12:09 p.m.) Review request for cloudstack. Description --- On CentOS 6.3, jsvc is resolved as jakarta-commons-daemon-jsvc, but jakarta-commons-daemon was not installed with it. jakarta-commons-daemon provides /usr/share/java/commons-daemon.jar. Without this package, jsvc fails to start because of lack of necessary classes, and debugging this is quite hard that I had to pass -errfile option to jsvc. Diffs - cloud.spec c31fe5b Diff: https://reviews.apache.org/r/7015/diff/ Testing --- Thanks, Hiroaki Kawai
Re: Review Request: Add helper for DAO based on podId
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7017/ --- (Updated Sept. 11, 2012, 1:45 p.m.) Review request for cloudstack, Murali Reddy, Alena Prokharchyk, and Alex Huang. Description --- They will be used by https://reviews.apache.org/r/6781/ Dao: Add helpers for listing based on podId - added listByPodId - fixed listByTypeAndState to accept type and then state as arguments - added listByPodIdTypeAndState in VMInstanceDao Download original patch: http://patchbin.baagi.org/p?id=ue9o0z Diffs (updated) - server/src/com/cloud/vm/dao/DomainRouterDao.java 01e3258 server/src/com/cloud/vm/dao/DomainRouterDaoImpl.java 175d3f2 server/src/com/cloud/vm/dao/VMInstanceDao.java 2cf3d75 server/src/com/cloud/vm/dao/VMInstanceDaoImpl.java 571b5d1 Diff: https://reviews.apache.org/r/7017/diff/ Testing --- Thanks, Rohit Yadav
Re: Review Request: Add helper for DAO based on podId
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7017/ --- (Updated Sept. 11, 2012, 1:45 p.m.) Review request for cloudstack, Murali Reddy, Alena Prokharchyk, and Alex Huang. Description (updated) --- They will be used by https://reviews.apache.org/r/6781/ Dao: Add helpers for listing based on podId - added listByPodId - fixed listByTypeAndState to accept type and then state as arguments - added listByPodIdTypeAndState in VMInstanceDao - added countByPodIdVMTypeAndState in VMInstanceDao Download original patch: http://patchbin.baagi.org/p?id=ue9o0z Diffs - server/src/com/cloud/vm/dao/DomainRouterDao.java 01e3258 server/src/com/cloud/vm/dao/DomainRouterDaoImpl.java 175d3f2 server/src/com/cloud/vm/dao/VMInstanceDao.java 2cf3d75 server/src/com/cloud/vm/dao/VMInstanceDaoImpl.java 571b5d1 Diff: https://reviews.apache.org/r/7017/diff/ Testing --- Thanks, Rohit Yadav
RE: combining vmware-base and plugin/hypervisor/vmware?
Hey Murali, If that is the case, should the Premium storage class not be in vmware-base? It is now in the plugin, so the plugin needs to be installed in the system vm for vmware support to work anyway? Cheers, Hugo -Original Message- From: Murali Reddy [mailto:murali.re...@citrix.com] Sent: Tuesday, September 11, 2012 12:25 PM To: cloudstack-dev@incubator.apache.org Subject: Re: combining vmware-base and plugin/hypervisor/vmware? On 11/09/12 1:18 PM, Hugo Trippaers htrippa...@schubergphilis.com wrote: Hey Chip, Good point, but by looking at the code it seems the other way around. Most of the generic stuff is inside the plugin (including parts of the code for the cisco nexus integration and the vmware version of the SSVM) and in particular the hypervisor code is in the vmware-base. For now I think it is more clear if we combine everything in the vmware plugin directory, should there be a need we can always separate the interface. For now I think it's unlikely that something is done via the vmware api that is not directly related to the vmware hypervisor (or used by peeps that don't use the vmware hypervisor). Cheers, Hugo When I initially moved vmware into a plug-in, I left vmware-base as independently buildable jar, so that it can packaged to systemvm.iso and management server separately. SSVM (which gets vmware version of secondary storage resource from systemvm.iso) just need vmware-base, not complete vmware plug-in. How about moving vmware-base stuff into plugin/hypervisor/vmware folder but still retain project jar for it? So if need arises its easy to move it out. -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Monday, September 10, 2012 3:39 PM To: cloudstack-dev@incubator.apache.org Subject: Re: combining vmware-base and plugin/hypervisor/vmware? On Mon, Sep 10, 2012 at 3:23 AM, Hugo Trippaers htrippa...@schubergphilis.com wrote: Heya, Anybody against moving all sources from vmware-base to plugin/hypervisors/vmware? It seems more logical to combine these two trees and make it a single plugin. Cheers, Hugo Hey Hugo, There might be a reason to keep it broken out. For example, let's say that I wanted to build a different plugin type that uses the VMware API. -chip
RE: Discuss on the Jenkins CI
+1 for using Jenkins. I'm currenly using Jenkins + Jenkins-clouds + cloudstack 4.0.0 at the office and it works great (with a small tweak to jclouds for the 4.0.0 api). Would be nice to eat our own dogfood and have a cloudstack that we can use to provision the machines on using Jenkins-jclouds. Cheers, Hugo -Original Message- From: Prasanna Santhanam [mailto:prasanna.santha...@citrix.com] Sent: Tuesday, September 11, 2012 12:21 PM To: cloudstack-dev@incubator.apache.org Subject: Re: Discuss on the Jenkins CI I'm not entirely clear about the role of puppet here. Where exactly does puppet fit in? AFAIK, the slave nodes can be dumb slaves that just do distro specific builds for us. They can be preconfigured and reused for each build. They don't even need to have jenkins installed on them. The slave.jar is just moved into the nodes directly by jenkins and it can track and monitor their state. The packaging commands - dpkg, rpmbuild can then be run within slaves and artifacts can be copied back to master where they are hosted for download. I think this is how some of the projects build on http://build.apache.org where you can see distro specific slaves. +1 - on moving to jenkins controlled builds. External scripts should be replaced by jenkins plugins. There are a wide variety of them - SSH, git, mvn and even jClouds. -- Prasanna., On Mon, Sep 10, 2012 at 09:07:38PM -0400, Frank Zhang wrote: I thought we should use puppet anyway for future expansion. For now, for instance, installing Jenkins itself should be done by puppet, adding ssh credential, adding an account, and whatever system configuration works. What I expect is we only spring up a vm with puppet agent installed, puppet master takes care of rest work (no manually 'yum install Jenkins' anymore) And puppet should go to our test system in future as well, so now let's take this chance to make puppet warm up. It's ok to warm up puppet, but the build is more important. For example, we need to customize the version number, or the name of the artifcates(rpm/deb), it's better to move to new Jenkins, other than hacking on the existing python code. We can do that. Just step by step. As setting up puppet is easier, let's do it first. Next week I think we can move to Jenkins plugins
Re: ant debug failed to launch
My environment was ok yesterday for ant debug before I update the source code. I use root account, I know it's not good, I checked both CATALINA_HOME and src folder, the folder permission/ownership is correct. On Tue, Sep 11, 2012 at 8:05 PM, Rohit Yadav rohit.ya...@citrix.com wrote: Make sure you're the owner on the source code (where your jars are) and on CATALINA_HOME. chown -R your-user path to tomcat and path to repo/src ant deploy-server and, ant debug! Regards, Rohit On 11-Sep-2012, at 3:24 PM, Gavin Lee gavin@gmail.com wrote: I followed the instruction [1] to setup maven build environment. Everything went well except the last step: ant debug I can use mvn -P client -pl client jetty:run but encounter some other issue such as system vm could not start. I want to attach eclipse debug. Does anybody encounter following issue when using: ant debug? [java] SEVERE: Error deploying web application directory awsapi [java] java.lang.NoSuchMethodError: javax.servlet.ServletContext.getContextPath()Ljava/lang/String; [java] at org.apache.catalina.core.StandardHost$MemoryLeakTrackingListener.lifecycleEvent(StandardHost.java:616) [java] at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) [java] at org.apache.catalina.core.StandardContext.start(StandardContext.java:4700) [java] at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:799) [java] at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:779) [java] at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:601) [java] at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1079) [java] at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:1002) [java] at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:506) [java] at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1317) [java] at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:324) [java] at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) [java] at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1065) [java] at org.apache.catalina.core.StandardHost.start(StandardHost.java:840) [java] at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057) [java] at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463) [java] at org.apache.catalina.core.StandardService.start(StandardService.java:525) [java] at org.apache.catalina.core.StandardServer.start(StandardServer.java:754) [java] at org.apache.catalina.startup.Catalina.start(Catalina.java:595) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [java] at java.lang.reflect.Method.invoke(Method.java:616) [java] at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) [java] at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) [java] Sep 11, 2012 5:52:39 PM org.apache.coyote.http11.Http11NioProtocol start [java] INFO: Starting Coyote HTTP/1.1 on http-7080 [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Building+with+Maven -- Gavin -- Gavin
Re: Review Request: cloud.spec centos6 Requires package name fix.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7009/#review11326 --- Ship it! Committed to master at: 739d4baf5542ae89a29288abb3487aeb9852d0a9 Please close this review as submitted. - Chip Childers On Sept. 11, 2012, 8:07 a.m., Hiroaki Kawai wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7009/ --- (Updated Sept. 11, 2012, 8:07 a.m.) Review request for cloudstack. Description --- On centos 6.3, jakarta-commons-lang is the package name for apache-commons-lang which is the name on fedora. Without this patch, rpm installation will fail. Diffs - cloud.spec c31fe5b Diff: https://reviews.apache.org/r/7009/diff/ Testing --- Thanks, Hiroaki Kawai
Re: Review Request: apache 4.0 docs
On Tue, Sep 11, 2012 at 5:28 AM, Radhika Puthiyetath radhika.puthiyet...@citrix.com wrote: Hello Community, Here is one question: AutoScale code is committed to a private branch. Where the autoscale documentation should go ? Documentation does not have a private branch yet. Therefore, I have pushed the AutoScale documentation to the master branch as of now. Do I need to revert it ? Looking forward to the right direction in this matter. Thanks -Radhika Shouldn't the auto-scale documentation be in the autoscale feature branch until it's merged? -chip From: Jessica Tomechak [mailto:nore...@reviews.apache.org] On Behalf Of Jessica Tomechak Sent: Tuesday, September 11, 2012 1:23 PM To: cloudstack; Radhika Puthiyetath; Jessica Tomechak Subject: Re: Review Request: apache 4.0 docs This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6978/ Ship it! Spot checked. These are the same files Radhika and I have been using to generate docs for a commercial version of CloudStack and they have passed review and built properly in that context. - Jessica On September 10th, 2012, 10:21 a.m., Radhika PC wrote: Review request for cloudstack. By Radhika PC. Updated Sept. 10, 2012, 10:21 a.m. Description This patch includes defect fixes and the new feature documentation: site-to-site vpn, inter-vlan routing, and autoscale. The issues pointed out for the Review Request #6328 has also been fixed. Updated the ASF license header for other files. Testing reviewed for the commercial release Diffs * docs/en-US/Book_Info_Admin.xml (PRE-CREATION) * docs/en-US/LDAPserver-for-user-authentication.xml (5fcb300) * docs/en-US/about-clusters.xml (e328cba) * docs/en-US/about-hosts.xml (956c695) * docs/en-US/about-physical-networks.xml (8edb9e0) * docs/en-US/about-pods.xml (ed3520c) * docs/en-US/about-primary-storage.xml (68d7a25) * docs/en-US/about-secondary-storage.xml (c4df0b8) * docs/en-US/about-security-groups.xml (PRE-CREATION) * docs/en-US/about-virtual-networks.xml (2fc6ba9) * docs/en-US/about-working-with-vms.xml (47153e2) * docs/en-US/about-zones.xml (a05a9a6) * docs/en-US/accessing-vms.xml (d69d021) * docs/en-US/accounts-users-domains.xml (8549129) * docs/en-US/accounts.xml (5292a9c) * docs/en-US/acquire-new-ip-for-vpc.xml (PRE-CREATION) * docs/en-US/add-additional-guest-network.xml (57e7ffd) * docs/en-US/add-clusters-kvm-xenserver.xml (PRE-CREATION) * docs/en-US/add-clusters-ovm.xml (PRE-CREATION) * docs/en-US/add-clusters-vsphere.xml (PRE-CREATION) * docs/en-US/add-gateway-vpc.xml (PRE-CREATION) * docs/en-US/add-ingress-egress-rules.xml (964045f) * docs/en-US/add-iso.xml (f56d10c) * docs/en-US/add-load-balancer-rule.xml (ddbce95) * docs/en-US/add-loadbalancer-rule-vpc.xml (PRE-CREATION) * docs/en-US/add-more-clusters.xml (PRE-CREATION) * docs/en-US/add-portforward-rule-vpc.xml (PRE-CREATION) * docs/en-US/add-primary-storage.xml (PRE-CREATION) * docs/en-US/add-secondary-storage.xml (PRE-CREATION) * docs/en-US/add-security-group.xml (e4c8b3c) * docs/en-US/add-tier.xml (PRE-CREATION) * docs/en-US/add-vm-to-tier.xml (PRE-CREATION) * docs/en-US/add-vpc.xml (PRE-CREATION) * docs/en-US/advanced-zone-configuration.xml (85909e3) * docs/en-US/advanced-zone-guest-ip-addresses.xml (b5d10a0) * docs/en-US/advanced-zone-network-traffic-types.xml (9f475cf) * docs/en-US/advanced-zone-physical-network-configuration.xml (4c44c7d) * docs/en-US/advanced-zone-public-ip-addresses.xml (eeb9404) * docs/en-US/alerts.xml (f903023) * docs/en-US/api-overview.xml (PRE-CREATION) * docs/en-US/attach-iso-to-vm.xml (30e5d51) * docs/en-US/automatic-snapshot-creation-retention.xml (ee4cf73) * docs/en-US/autoscale.xml (PRE-CREATION) * docs/en-US/basic-zone-configuration.xml (18afa84) * docs/en-US/basic-zone-guest-ip-addresses.xml (d1d9135) * docs/en-US/basic-zone-network-traffic-types.xml (fa3be0f) * docs/en-US/basic-zone-physical-network-configuration.xml (83833a7) * docs/en-US/best-practices-for-vms.xml (a67add4) * docs/en-US/change-database-config.xml (PRE-CREATION) * docs/en-US/change-network-offering-on-guest-network.xml (98f1b63) * docs/en-US/change-ssvm-service-offering.xml (PRE-CREATION) * docs/en-US/changing-root-password.xml (0d2333a) * docs/en-US/changing-secondary-storage-ip.xml (7e146de) * docs/en-US/changing-service-offering-for-vm.xml (5a42912) * docs/en-US/changing-vm-name-os-group.xml (f16ffda) * docs/en-US/cloud-infrastructure-concepts.xml (58f8844) * docs/en-US/cloud-infrastructure-overview.xml (5b467a3) * docs/en-US/cloudstack_admin.xml (c80c94f) * docs/en-US/cluster-add-xenserver-kvm.xml (PRE-CREATION) * docs/en-US/cluster-add.xml (5210bd8) * docs/en-US/compute-disk-service-offerings.xml (2469dfe) *
Re: marvin live tests into master
On Tue, Sep 11, 2012 at 5:57 AM, Prasanna Santhanam prasanna.santha...@citrix.com wrote: On Sun, Sep 09, 2012 at 02:21:39AM -0400, prasanna wrote: On 8 September 2012 22:04, Noah Slater nsla...@tumbolia.org wrote: How big is the code contribution? Sizable: 11 new test suites. I've moved the pending updates here: https://github.com/vogxn/asf-marvin-updates. This is branched out of asf/cloudstack/master The purpose of IP clearance is to vet any sizeable incoming code that was done outside of the project. (That the original authors now hold ICLAs and are happy to contribute it is relatively unimportant, as far as I know.) Understood. Many tests are already part of the asf repo under test/integration/. The work that has happened outside of the project are 1) fixes to the existing tests and 2) additional test suites. These are the ones I propose to move. Hoping to get some consensus and clarity on this: 1) Only apply fixes to existing tests. Additional test suites added outside of the project can come in later after IP clearance. 2) Get IP clearance for all new test suites and push to repo. Option 1) should be okay for us to start setting up the test environment and connect the results to jenkins. Option 2) can be done later. -- Prasanna., I would prefer option 1, because I'd love to see the tests. As long as the authors of the fixes submit through review board, it should be fine. IMO, for the new tests, they can either come in from the author via reviewboard as smaller patches, or go through IP clearance for the bulk transfer.
Re: marvin live tests into master
This sounds like a reasonable plan. If we need to put it through IP clearance, we should get that process started ASAP. I'd be very interested in hearing what the other mentors think about this. On Tue, Sep 11, 2012 at 3:19 PM, Chip Childers chip.child...@sungard.comwrote: On Tue, Sep 11, 2012 at 5:57 AM, Prasanna Santhanam prasanna.santha...@citrix.com wrote: On Sun, Sep 09, 2012 at 02:21:39AM -0400, prasanna wrote: On 8 September 2012 22:04, Noah Slater nsla...@tumbolia.org wrote: How big is the code contribution? Sizable: 11 new test suites. I've moved the pending updates here: https://github.com/vogxn/asf-marvin-updates. This is branched out of asf/cloudstack/master The purpose of IP clearance is to vet any sizeable incoming code that was done outside of the project. (That the original authors now hold ICLAs and are happy to contribute it is relatively unimportant, as far as I know.) Understood. Many tests are already part of the asf repo under test/integration/. The work that has happened outside of the project are 1) fixes to the existing tests and 2) additional test suites. These are the ones I propose to move. Hoping to get some consensus and clarity on this: 1) Only apply fixes to existing tests. Additional test suites added outside of the project can come in later after IP clearance. 2) Get IP clearance for all new test suites and push to repo. Option 1) should be okay for us to start setting up the test environment and connect the results to jenkins. Option 2) can be done later. -- Prasanna., I would prefer option 1, because I'd love to see the tests. As long as the authors of the fixes submit through review board, it should be fine. IMO, for the new tests, they can either come in from the author via reviewboard as smaller patches, or go through IP clearance for the bulk transfer. -- NS
Review Request: Sumarry of changes: Changed the function addTemplateToZone VMTemplateDaoImpl.java. This was needed as the previous version tried to update the removed column of the row in template_zon
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7018/ --- Review request for cloudstack and Nitin Mehta. Description --- This bug fix (CS-14673) deals with the database aspects of template creation, this changes the way in which the entries are added and removed from template_zone_ref and template_host_ref. Diffs - server/src/com/cloud/storage/dao/VMTemplateDaoImpl.java 2a0dfc8 server/src/com/cloud/template/HyervisorTemplateAdapter.java bdb89f6 server/src/com/cloud/template/TemplateManagerImpl.java 1e87de2 Diff: https://reviews.apache.org/r/7018/diff/ Testing --- I have tested this on the asf branch. Thanks, bharat kumar
Re: marvin live tests into master
On Tue, Sep 11, 2012 at 10:19 AM, Chip Childers chip.child...@sungard.com wrote: On Tue, Sep 11, 2012 at 5:57 AM, Prasanna Santhanam prasanna.santha...@citrix.com wrote: On Sun, Sep 09, 2012 at 02:21:39AM -0400, prasanna wrote: On 8 September 2012 22:04, Noah Slater nsla...@tumbolia.org wrote: How big is the code contribution? Sizable: 11 new test suites. I've moved the pending updates here: https://github.com/vogxn/asf-marvin-updates. This is branched out of asf/cloudstack/master The purpose of IP clearance is to vet any sizeable incoming code that was done outside of the project. (That the original authors now hold ICLAs and are happy to contribute it is relatively unimportant, as far as I know.) Understood. Many tests are already part of the asf repo under test/integration/. The work that has happened outside of the project are 1) fixes to the existing tests and 2) additional test suites. These are the ones I propose to move. Hoping to get some consensus and clarity on this: 1) Only apply fixes to existing tests. Additional test suites added outside of the project can come in later after IP clearance. 2) Get IP clearance for all new test suites and push to repo. Option 1) should be okay for us to start setting up the test environment and connect the results to jenkins. Option 2) can be done later. -- Prasanna., I would prefer option 1, because I'd love to see the tests. As long as the authors of the fixes submit through review board, it should be fine. IMO, for the new tests, they can either come in from the author via reviewboard as smaller patches, or go through IP clearance for the bulk transfer. To make it easier to compare, I diffed the test directory of Prasanna's repo with what is in our repo. The patch is here, and it is about 4MB http://ke4qqq.fedorapeople.org/tests.patch --David
Re: Review Request: Sumarry of changes: Changed the function addTemplateToZone VMTemplateDaoImpl.java. This was needed as the previous version tried to update the removed column of the row in template
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7018/ --- (Updated Sept. 11, 2012, 2:32 p.m.) Review request for cloudstack and Nitin Mehta. Summary (updated) - Sumarry of changes: Changed the function addTemplateToZone VMTemplateDaoImpl.java. This was needed as the previous version tried to update the removed column of the row in template_zone_ref table in database. The removed column cannot be updated once it is set to some value other than NULL (i.e. Description --- This bug fix (CS-14673) deals with the database aspects of template creation, this changes the way in which the entries are added and removed from template_zone_ref and template_host_ref. Diffs - server/src/com/cloud/storage/dao/VMTemplateDaoImpl.java 2a0dfc8 server/src/com/cloud/template/HyervisorTemplateAdapter.java bdb89f6 server/src/com/cloud/template/TemplateManagerImpl.java 1e87de2 Diff: https://reviews.apache.org/r/7018/diff/ Testing --- I have tested this on the asf branch. Thanks, bharat kumar
[jira] [Commented] (CLOUDSTACK-78) Cloudstack Agent installation failed with jsvc package dependancy error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453056#comment-13453056 ] Hiroaki Kawai commented on CLOUDSTACK-78: - What is the distribution you were using when you got this error. Red hat, fedora, centos 5 or 6, Ubuntu, or something other? Cloudstack Agent installation failed with jsvc package dependancy error Key: CLOUDSTACK-78 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-78 Project: CloudStack Issue Type: Bug Components: Install and Setup Affects Versions: pre-4.0.0 Reporter: Sailaja Mada Assignee: edison su Priority: Critical Steps: 1. Tried installing Agent with KVM host . Observation : Cloudstack Agent installation failed with jsvc package dependancy error Details : M) Install the Management Server A) Install the Agent B) Install BareMetal Agent S) Install the Usage Monitor D) Install the database server Q) Quit A Installing the Agent... Loaded plugins: product-id, security, subscription-manager Updating certificate-based repositories. cloud-temp | 2.6 kB 00:00 ... cloud-temp/primary_db | 10 kB 00:00 ... rhel | 4.0 kB 00:00 ... Setting up Install Process No package cloud-premium available. Resolving Dependencies -- Running transaction check --- Package cloud-agent.x86_64 0:4.0.59-0.59.el6.4.0 will be installed -- Processing Dependency: cloud-utils = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-python = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-deps = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-core = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-agent-scripts = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-agent-libs = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: jsvc for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: jna for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Running transaction check --- Package cloud-agent.x86_64 0:4.0.59-0.59.el6.4.0 will be installed -- Processing Dependency: jsvc for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 --- Package cloud-agent-libs.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-agent-scripts.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-core.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-deps.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-python.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-utils.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package jna.x86_64 0:3.2.4-2.el6 will be installed -- Finished Dependency Resolution Error: Package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 (cloud-temp) Requires: jsvc You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Done Expected Results : Installation should go thru with out any issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CLOUDSTACK-78) Cloudstack Agent installation failed with jsvc package dependancy error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453059#comment-13453059 ] Sailaja Mada commented on CLOUDSTACK-78: KVM Host version is RHEL 6.2. Cloudstack Agent installation tried with RHEL build. Cloudstack Agent installation failed with jsvc package dependancy error Key: CLOUDSTACK-78 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-78 Project: CloudStack Issue Type: Bug Components: Install and Setup Affects Versions: pre-4.0.0 Reporter: Sailaja Mada Assignee: edison su Priority: Critical Steps: 1. Tried installing Agent with KVM host . Observation : Cloudstack Agent installation failed with jsvc package dependancy error Details : M) Install the Management Server A) Install the Agent B) Install BareMetal Agent S) Install the Usage Monitor D) Install the database server Q) Quit A Installing the Agent... Loaded plugins: product-id, security, subscription-manager Updating certificate-based repositories. cloud-temp | 2.6 kB 00:00 ... cloud-temp/primary_db | 10 kB 00:00 ... rhel | 4.0 kB 00:00 ... Setting up Install Process No package cloud-premium available. Resolving Dependencies -- Running transaction check --- Package cloud-agent.x86_64 0:4.0.59-0.59.el6.4.0 will be installed -- Processing Dependency: cloud-utils = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-python = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-deps = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-core = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-agent-scripts = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-agent-libs = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: jsvc for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: jna for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Running transaction check --- Package cloud-agent.x86_64 0:4.0.59-0.59.el6.4.0 will be installed -- Processing Dependency: jsvc for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 --- Package cloud-agent-libs.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-agent-scripts.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-core.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-deps.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-python.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-utils.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package jna.x86_64 0:3.2.4-2.el6 will be installed -- Finished Dependency Resolution Error: Package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 (cloud-temp) Requires: jsvc You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Done Expected Results : Installation should go thru with out any issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Review Request: when a template is deleted and then copied over again , it is still marked as Removed in template_zone_ref table.
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7018/ --- (Updated Sept. 11, 2012, 2:41 p.m.) Review request for cloudstack and Nitin Mehta. Summary (updated) - when a template is deleted and then copied over again , it is still marked as Removed in template_zone_ref table. Description --- This bug fix (CS-14673) deals with the database aspects of template creation, this changes the way in which the entries are added and removed from template_zone_ref and template_host_ref. Diffs - server/src/com/cloud/storage/dao/VMTemplateDaoImpl.java 2a0dfc8 server/src/com/cloud/template/HyervisorTemplateAdapter.java bdb89f6 server/src/com/cloud/template/TemplateManagerImpl.java 1e87de2 Diff: https://reviews.apache.org/r/7018/diff/ Testing --- I have tested this on the asf branch. Thanks, bharat kumar
maven build error when compile-utils . steps follow cwiki.apache.org's instruction
so grieved,never build it correctly. mybe the article lacks something. my environment, CentOS Linux release 6.0 .maven 3.0.4. mvn install -P deps [exec] [INFO] Building Apache CloudStack Dependencies 4.0.0-SNAPSHOT [exec] [INFO] [exec] [WARNING] The POM for org.apache.rampart:rampart-policy:jar:1.5 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details [exec] [WARNING] The POM for org.apache.rampart:rampart-trust:jar:1.5 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details [exec] [WARNING] The POM for org.apache.axis2:axis2-kernel:jar:1.5.1 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details [exec] [WARNING] The POM for org.apache.axis2:mex:jar:impl:1.5.1 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details [exec] [WARNING] The POM for org.apache.axis2:axis2-mtompolicy:jar:1.5.1 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details [exec] [WARNING] The POM for org.apache.ws.security:wss4j:jar:1.5.8 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details [exec] [WARNING] The POM for opensaml:opensaml:jar:1.1 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details [exec] [WARNING] The POM for bouncycastle:bcprov-jdk14:jar:140 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details [exec] [INFO] [exec] [INFO] --- maven-remote-resources-plugin:1.3:process (default) @ cloud-deps --- [exec] [WARNING] Invalid POM for org.apache.rampart:rampart-policy:jar:1.5, transitive dependencies (if any) will not be available, enable debug logging for more details [exec] [WARNING] Invalid POM for org.apache.rampart:rampart-trust:jar:1.5, transitive dependencies (if any) will not be available, enable debug logging for more details [exec] [WARNING] Invalid POM for org.apache.axis2:axis2-kernel:jar:1.5.1, transitive dependencies (if any) will not be available, enable debug logging for more details [exec] [WARNING] Invalid POM for org.apache.axis2:mex:jar:impl:1.5.1, transitive dependencies (if any) will not be available, enable debug logging for more details [exec] [WARNING] Invalid POM for org.apache.axis2:axis2-mtompolicy:jar:1.5.1, transitive dependencies (if any) will not be available, enable debug logging for more details ant build-all [exec] [INFO] [exec] [INFO] BUILD SUCCESS [exec] [INFO] [exec] [INFO] Total time: 15.174s [exec] [INFO] Finished at: Tue Sep 11 22:21:54 CST 2012 [exec] [INFO] Final Memory: 17M/52M [exec] [INFO] compile-utils: [mkdir] Created dir: /mnt/incubator-cloudstack/target/classes/cloud-utils.jar [echo] Compiling /mnt/incubator-cloudstack/utils/src [javac] Compiling 149 source files to /mnt/incubator-cloudstack/target/classes/cloud-utils.jar [javac] error: error reading /mnt/incubator-cloudstack/deps/axis2-mtompolicy-1.5.1.jar; error in opening zip file [javac] error: error reading /mnt/incubator-cloudstack/deps/bcprov-jdk14-140.jar; error in opening zip file [javac] error: error reading /mnt/incubator-cloudstack/deps/mex-1.5.1-impl.jar; error in opening zip file [javac] 3 errors BUILD FAILED /mnt/incubator-cloudstack/build/build-cloud.xml:186: The following error occurred while executing this line: /mnt/incubator-cloudstack/build/build-common.xml:65: Compile failed; see the compiler error output for details. Total time: 19 seconds
Re: fail to install MS on UBuntu12.04
Sent from my iPhone On Sep 11, 2012, at 5:24 AM, Wido den Hollander w...@widodh.nl wrote: On 09/11/2012 12:16 PM, Suresh Sadhu wrote: HI All, Installer fail to read the cloud packages and MS installation on Ubuntu 12.04 was not successful(No packages were installed) Raised a blocker bug. Please find the issue details in the below mentioned issue: I'd like to bring this up again, do we REALLY want this install.sh script? When manually installing the packages with dpkg you have to resolve all the dependencies manually. If we had a Ubuntu/Debian repo like I created on http://cloudstack.apt-get.eu/ we could just apt-get install all the packages we need. As long as we have a formal repository, then install.sh can be dropped. Imho there is no role for install.sh here. Wido https://issues.apache.org/jira/browse/CLOUDSTACK-76 Welcome to the Cloud.com CloudStack Installer. What would you like to do? M) Install the Management Server A) Install the Agent S) Install the Usage Monitor D) Install the database server Q) Quit M Installing the Management Server... Couldn't find any package whose name or description matched cloud-client Couldn't find any package whose name or description matched cloud-client No packages will be installed, upgraded, or removed. 0 packages upgraded, 0 newly installed, 0 to remove and 9 not upgraded. Need to get 0 B of archives. After unpacking 0 B will be used. Regards Sadhu
Re: Review Request: CS-16168 [AutoScale] : Deletion of Account doesn't delete the AutoScale LB rule
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6825/#review11328 --- The fix takes care of only Basic Network. There is a bug still lying in the advance network cleanup. My take is to checkin this and follow it with a subsequent checkin for Advanced Network. The advanced network clean should be done shutdownNetwork path. If no else has objections on this strategy we can ship it. - Vijay Venkatachalam On Aug. 29, 2012, 8:01 a.m., Deepak Garg wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6825/ --- (Updated Aug. 29, 2012, 8:01 a.m.) Review request for cloudstack, Pranav Saxena and Vijay Venkatachalam. Description --- CS-16168 [AutoScale] : Deletion of Account doesn't delete the AutoScale LB rule Steps == 1. Create a Domain inside the ROOT domain, and then create a user for that domain. 2. Login to CS as that user and create an Autoscale LB rule. 3. Let the LB rule get created and the minimum number of VM deployed. Now Delete the Account. Observation == 1. The LB rule Doesn't get deleted (The attached VM gets deleted but the AutoScale LB rule stays) This addresses bug CS-16168. Diffs - server/src/com/cloud/network/as/AutoScaleManager.java 7ea7807 server/src/com/cloud/network/as/AutoScaleManagerImpl.java 8c39097 server/src/com/cloud/network/as/dao/AutoScalePolicyDao.java 8edfa94 server/src/com/cloud/network/as/dao/AutoScalePolicyDaoImpl.java 5dfe080 server/src/com/cloud/network/as/dao/AutoScaleVmProfileDao.java 0803571 server/src/com/cloud/network/as/dao/AutoScaleVmProfileDaoImpl.java 12392c3 server/src/com/cloud/network/as/dao/ConditionDao.java bb0f77f server/src/com/cloud/network/as/dao/ConditionDaoImpl.java 338fe19 server/src/com/cloud/network/lb/LoadBalancingRulesManagerImpl.java 8671151 server/src/com/cloud/user/AccountManagerImpl.java 0a11dc4 Diff: https://reviews.apache.org/r/6825/diff/ Testing --- Manually tested on my setup. Thanks, Deepak Garg
Re: combining vmware-base and plugin/hypervisor/vmware?
Sent from my iPhone On Sep 11, 2012, at 6:56 AM, Hugo Trippaers htrippa...@schubergphilis.com wrote: Hey Murali, If that is the case, should the Premium storage class not be in vmware-base? It is now in the plugin, so the plugin needs to be installed in the system vm for vmware support to work anyway? +1 Cheers, Hugo -Original Message- From: Murali Reddy [mailto:murali.re...@citrix.com] Sent: Tuesday, September 11, 2012 12:25 PM To: cloudstack-dev@incubator.apache.org Subject: Re: combining vmware-base and plugin/hypervisor/vmware? On 11/09/12 1:18 PM, Hugo Trippaers htrippa...@schubergphilis.com wrote: Hey Chip, Good point, but by looking at the code it seems the other way around. Most of the generic stuff is inside the plugin (including parts of the code for the cisco nexus integration and the vmware version of the SSVM) and in particular the hypervisor code is in the vmware-base. For now I think it is more clear if we combine everything in the vmware plugin directory, should there be a need we can always separate the interface. For now I think it's unlikely that something is done via the vmware api that is not directly related to the vmware hypervisor (or used by peeps that don't use the vmware hypervisor). Cheers, Hugo When I initially moved vmware into a plug-in, I left vmware-base as independently buildable jar, so that it can packaged to systemvm.iso and management server separately. SSVM (which gets vmware version of secondary storage resource from systemvm.iso) just need vmware-base, not complete vmware plug-in. How about moving vmware-base stuff into plugin/hypervisor/vmware folder but still retain project jar for it? So if need arises its easy to move it out. -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Monday, September 10, 2012 3:39 PM To: cloudstack-dev@incubator.apache.org Subject: Re: combining vmware-base and plugin/hypervisor/vmware? On Mon, Sep 10, 2012 at 3:23 AM, Hugo Trippaers htrippa...@schubergphilis.com wrote: Heya, Anybody against moving all sources from vmware-base to plugin/hypervisors/vmware? It seems more logical to combine these two trees and make it a single plugin. Cheers, Hugo Hey Hugo, There might be a reason to keep it broken out. For example, let's say that I wanted to build a different plugin type that uses the VMware API. -chip
RE: List of New Features in 4.0
6825 - It is a part fix, looks like it only cleans basic network. My take is to ship it and fix the advance network in a subsequent checkin. I will submit the advanced network fix this week or early next week. 6895 - There are minor changes to uploaded diff I will send an updated diff today. 6899 - is reviewed, can someone commit? There is still an outstanding issue that the Autoscale API should not refer to snmp counters but should use key value pairs instead I have done changes for this, I will send a patch by tomorrow for review. Thanks, Vijay V. -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Tuesday, September 11, 2012 2:16 AM To: CloudStack DeveloperList Subject: Re: List of New Features in 4.0 There are this set of reviews: 6825, 6895, 6899 already open? There is still an outstanding issue that the Autoscale API should not refer to snmp counters but should use key value pairs instead. This has not been addressed. http://markmail.org/message/74sw3efn3mupfqc2 http://markmail.org/thread/nb262oyznlnkigkb On 9/10/12 12:03 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: Ok thanks, so if I understand this right, I will be sending the patches for review with the changes to source code but without the appropriate jar files. For AutoScale branch, user downloads the right jar files to deps folder and he can build. For master, user still download to deps folder and runs install-non-oss.sh (I can see the netscaler jar file entries already present). I will upload the necessary jar files (for master and autoscale branch) tomorrow to a public location and send out a separate mail. Thanks, Vijay V. -Original Message- From: Chip Childers [mailto:chip.child...@sungard.com] Sent: Tuesday, September 11, 2012 12:02 AM To: cloudstack-dev@incubator.apache.org Subject: Re: List of New Features in 4.0 Moved to the dev list: On Mon, Sep 10, 2012 at 2:22 PM, Vijay Venkatachalam vijay.venkatacha...@citrix.com wrote: For Autoscale feature, the re-licensing of NetScaler SDK Jar is held up in the Citrix legal :-( , and meanwhile, can I send patches with the latest NetScaler jar files (still without the new license) to the autoscale branch alone (not master)? We have about 10 pending patches waiting for inclusion. There are 2 issues with that. First, we are moving ALL jar / mar / war files out of the code repo, so please don't try to put one back in (even on a branch). The second issue is that we should not be moving backwards on the state of our licensing compliance. If the NetScaler jar is still a non-Apache 2 compatible license (per ASF standards on this), then it needs to be thought of as an optional build target. We need to be able have an optional build flag to include it after the user downloads the file manually somehow (probably the same way we do others like this: install-non-oss.sh ). -chip I haven't checked the 4.0 code, but it seems that all NetScaler support is removed from 4.0 master (besides autoscale), Am I right here? Is this pending the NetScaler SDK jar re-licensing? Thanks, Vijay V. -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Monday, September 10, 2012 10:53 PM To: CloudStack Users Subject: Re: List of New Features in 4.0 Autoscaling is still pending a merge and is unlikely to make it into 4.0. On 9/10/12 9:49 AM, Shanker Balan m...@shankerbalan.net wrote: On 10-Sep-2012, at 8:10 PM, James Jeffrey james.jeff...@cpp.co.uk wrote: Hello, Sorry if it already exists - I've looked but failed to find. Is there a list of new features in 4.0 please? AFAIK, the 2 significant features are VPC and autoscaling. Maybe the release manager(s) can comment further. Hth @shankerbalan
Re: Review Request: CS-15783: Creating mapping between job ids and autoscale entity ids
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6899/#review11330 --- Changes pushed to asf/autoscale. Please mark the ticket as Submitted. Thanks ! - Pranav Saxena On Sept. 4, 2012, 12:24 p.m., Vijay Venkatachalam wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6899/ --- (Updated Sept. 4, 2012, 12:24 p.m.) Review request for cloudstack, Devdeep Singh and Deepak Garg. Description --- 1. After AutoScaleVmGroup creation, the asynchronous jobs cannot be listed momentarily. This happened because there was a mapping missing between the job instance id and autoscale vm group instance id. Fix: Introducing the mapping between job instance id and autoscale entity instance ids. 2. Updated JobInstance type in VmGroup commands. 3. Removing action as a mandatory parameter for listAutoScalePolicies command. This addresses bug CS-15783. Diffs - api/src/com/cloud/api/commands/DeleteAutoScaleVmGroupCmd.java b97d734 api/src/com/cloud/api/commands/DisableAutoScaleVmGroupCmd.java fa90fff api/src/com/cloud/api/commands/EnableAutoScaleVmGroupCmd.java 4b4d1c3 api/src/com/cloud/api/commands/ListAutoScalePoliciesCmd.java 1d61641 api/src/com/cloud/api/response/AsyncJobResponse.java 3644595 Diff: https://reviews.apache.org/r/6899/diff/ Testing --- 1. Create AutoScalePolicyVmGroup through UI, the return values of query async job does not return errors. 2. Fire api request command = listAutoScalePolicies with id alone. Thanks, Vijay Venkatachalam
[jira] [Commented] (CLOUDSTACK-78) Cloudstack Agent installation failed with jsvc package dependancy error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453143#comment-13453143 ] David Nalley commented on CLOUDSTACK-78: This is interesting. Do you have access to the distros yum repos? (jsvc is provided by jakarta-commons-daemon-jsvc (which Provides: jsvc) What happens when you try yum install jsvc? If that fails, can you install jarkarta-commons-daemon-jsvc? Cloudstack Agent installation failed with jsvc package dependancy error Key: CLOUDSTACK-78 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-78 Project: CloudStack Issue Type: Bug Components: Install and Setup Affects Versions: pre-4.0.0 Reporter: Sailaja Mada Assignee: edison su Priority: Critical Steps: 1. Tried installing Agent with KVM host . Observation : Cloudstack Agent installation failed with jsvc package dependancy error Details : M) Install the Management Server A) Install the Agent B) Install BareMetal Agent S) Install the Usage Monitor D) Install the database server Q) Quit A Installing the Agent... Loaded plugins: product-id, security, subscription-manager Updating certificate-based repositories. cloud-temp | 2.6 kB 00:00 ... cloud-temp/primary_db | 10 kB 00:00 ... rhel | 4.0 kB 00:00 ... Setting up Install Process No package cloud-premium available. Resolving Dependencies -- Running transaction check --- Package cloud-agent.x86_64 0:4.0.59-0.59.el6.4.0 will be installed -- Processing Dependency: cloud-utils = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-python = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-deps = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-core = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-agent-scripts = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-agent-libs = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: jsvc for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: jna for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Running transaction check --- Package cloud-agent.x86_64 0:4.0.59-0.59.el6.4.0 will be installed -- Processing Dependency: jsvc for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 --- Package cloud-agent-libs.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-agent-scripts.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-core.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-deps.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-python.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-utils.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package jna.x86_64 0:3.2.4-2.el6 will be installed -- Finished Dependency Resolution Error: Package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 (cloud-temp) Requires: jsvc You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Done Expected Results : Installation should go thru with out any issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-78) Cloudstack Agent installation failed with jsvc package dependancy error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Nalley reassigned CLOUDSTACK-78: -- Assignee: David Nalley (was: edison su) Cloudstack Agent installation failed with jsvc package dependancy error Key: CLOUDSTACK-78 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-78 Project: CloudStack Issue Type: Bug Components: Install and Setup Affects Versions: pre-4.0.0 Reporter: Sailaja Mada Assignee: David Nalley Priority: Critical Steps: 1. Tried installing Agent with KVM host . Observation : Cloudstack Agent installation failed with jsvc package dependancy error Details : M) Install the Management Server A) Install the Agent B) Install BareMetal Agent S) Install the Usage Monitor D) Install the database server Q) Quit A Installing the Agent... Loaded plugins: product-id, security, subscription-manager Updating certificate-based repositories. cloud-temp | 2.6 kB 00:00 ... cloud-temp/primary_db | 10 kB 00:00 ... rhel | 4.0 kB 00:00 ... Setting up Install Process No package cloud-premium available. Resolving Dependencies -- Running transaction check --- Package cloud-agent.x86_64 0:4.0.59-0.59.el6.4.0 will be installed -- Processing Dependency: cloud-utils = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-python = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-deps = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-core = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-agent-scripts = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-agent-libs = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: jsvc for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: jna for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Running transaction check --- Package cloud-agent.x86_64 0:4.0.59-0.59.el6.4.0 will be installed -- Processing Dependency: jsvc for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 --- Package cloud-agent-libs.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-agent-scripts.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-core.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-deps.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-python.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-utils.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package jna.x86_64 0:3.2.4-2.el6 will be installed -- Finished Dependency Resolution Error: Package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 (cloud-temp) Requires: jsvc You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Done Expected Results : Installation should go thru with out any issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Review Request: CS-16104: Improve restart network behaviour for basic network
On 9/11/12 7:42 AM, Rohit Yadav rohit.ya...@citrix.com wrote:
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/6781/
On September 10th, 2012, 9:31 p.m., Alena Prokharchyk wrote:
1) Have to hange the logic below; we have to reduce the number of
iteration.
* start with getting the PODs having user vms.
* Only for those pods check if there are any VRs running.
Now you are doing it the other way around, and it increases the number of
iterations. Plus see all the comments that I've made, inline:
+DataCenter dc = _dcDao.findById(network.getDataCenterId());
+//Pod based network restart for basic network, one VR per pod
+if (dc.getNetworkType() == NetworkType.Basic) {
+//Loop through all pods with running user vms and
restart network
+for (HostPodVO pod:
_podDao.listByDataCenterId(dc.getId())) {
+s_logger.debug(Trying to restart network for Pod:
+ pod.getName() + , id= + pod.getId());
+//If cleanup is false, don't implement network on
running VRs
+ListDomainRouterVO virtualRouters =
_domainRouterDao.listByPodId(pod.getId());
+Boolean podHasSingleVR = (virtualRouters.size() ==
1);
+if (!podHasSingleVR) { - COMMENT: wrong assumptions
to make. Pod might not have any VRs if there are no user vms exist.
+s_logger.warn(Pod should have only one VR in
Basic Zone, please check!); - COMMENT: put assert statement for
developers here
+}
+if (!cleanup virtualRouters != null
podHasSingleVR
+ virtualRouters.get(0).getState() ==
VirtualMachine.State.Running) { - COMMENT: check for Starting state as
well. If the router is starting, no need to start a new one. Also remove
(virtualRouters != null) as DAO never returns NULL, it always returns an
empty set.
+s_logger.debug(Cleanup=false: Found a running
VR, skipping network implementation for the pod);
+continue;
+}
+//Implement network only if there are running user
vms in 'pod'
+ListVMInstanceVO vms =
_vmDao.listByPodId(pod.getId()); COMMENT: instead of pulling all vms, and
then iterating through them one by one and checking state and type, call
Dao method to return you only user vms, and only in Running state.
Besides, never call list, call COUNT function inside the DAO as we just
need to know how many vms are running, and don't need to know the details
+for (VMInstanceVO vm: vms) { - COMMENT - incorrect
kind of logic. We shouldn't call implementNetworkElementsAndResources per
each pod as this call actually does netowrk rules implementation for the
ENTIRE network, and you manage to call it per each Pod. And the provider
for Basic network is not always the Virtual router, it can be Netscaler
as well. Placing VR implementation details in Network manager, and do the
determination based on the fact that VR is the only one provider, is
incorrect. See my comment #2 showing how this logic needs to be changed.
All the changes affecting Virtual Router behavior, should be placed in
the Virtual Router manager.
+// implement the network elements and rules again
+if (vm.getType() == Type.User vm.getState()
== VirtualMachine.State.Running) {
+DeployDestination dest = new
DeployDestination(dc, pod, null, null);
+implementNetworkElementsAndResources(dest,
context, network, offering);
+break;
+}
+}
+}
+} else {
+// implement the network elements and rules again
+DeployDestination dest = new DeployDestination(dc, null,
null, null);
+implementNetworkElementsAndResources(dest, context,
network, offering);
+}
setRestartRequired(network, true);
2) The logic shouldn't be a part of NetworkManagerImpl. It's wrong to
call implementNetworkElementsAndResources() per each POD as this call
don't just triggers VR restart, but also does network rules re-implement.
For each and every pod in the network, it's going to re-implement ALL the
rules in each iteration. Plus network manager should never know how
All the logic should be done in the VirtualRouterManager instead:
* From the networkManagerImpl, don't distinguish what Zone the restart is
called for. Use the same logic as we used to use before:
try {
implementNetworkElementsAndResources(dest, context, network,
offering);
setRestartRequired(network, true);
} catch (Exception ex) {
s_logger.warn(Failed to
[jira] [Resolved] (CLOUDSTACK-21) Create a secondary binary build containing KVM support
[ https://issues.apache.org/jira/browse/CLOUDSTACK-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pradeep Soundararajan resolved CLOUDSTACK-21. - Resolution: Won't Fix Already, KVM is made as a default build option. Create a secondary binary build containing KVM support -- Key: CLOUDSTACK-21 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-21 Project: CloudStack Issue Type: Task Reporter: Ewan Mellor Assignee: Pradeep Soundararajan Priority: Blocker Fix For: pre-4.0.0 We have permission to ship a secondary convenience build containing KVM support, even though that library is LGPL-licensed. This will sit alongside the default binaries, which will have KVM support turned off. We need to build this as part of the CI infrastructure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-27) JARs are still present in the tools directory
[ https://issues.apache.org/jira/browse/CLOUDSTACK-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pradeep Soundararajan reassigned CLOUDSTACK-27: --- Assignee: edison su (was: Pradeep Soundararajan) Hi Edison, as per the discussion. I hope you have resolved this bug already. Please make sure the list once again and resolve this ticket. JARs are still present in the tools directory - Key: CLOUDSTACK-27 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-27 Project: CloudStack Issue Type: Bug Components: Test Tools Affects Versions: pre-4.0.0 Reporter: David Nalley Assignee: edison su Priority: Blocker Fix For: pre-4.0.0 As a general rule binaries should not live in the source tree. The tools directory still has the following jars present. ./tools/gcc/compiler.jar ./tools/junit/junit-4.8.1.jar ./tools/ant/apache-ant-1.7.1/lib/ant-swing.jar ./tools/ant/apache-ant-1.7.1/lib/ant-apache-bsf.jar ./tools/ant/apache-ant-1.7.1/lib/ant-apache-log4j.jar ./tools/ant/apache-ant-1.7.1/lib/ant.jar ./tools/ant/apache-ant-1.7.1/lib/ant-commons-net.jar ./tools/ant/apache-ant-1.7.1/lib/ant-apache-regexp.jar ./tools/ant/apache-ant-1.7.1/lib/ant-trax.jar ./tools/ant/apache-ant-1.7.1/lib/ant-jmf.jar ./tools/ant/apache-ant-1.7.1/lib/ant-javamail.jar ./tools/ant/apache-ant-1.7.1/lib/ant-jai.jar ./tools/ant/apache-ant-1.7.1/lib/ant-junit.jar ./tools/ant/apache-ant-1.7.1/lib/ant-jsch.jar ./tools/ant/apache-ant-1.7.1/lib/xercesImpl.jar ./tools/ant/apache-ant-1.7.1/lib/ant-jdepend.jar ./tools/ant/apache-ant-1.7.1/lib/ant-apache-oro.jar ./tools/ant/apache-ant-1.7.1/lib/ant-antlr.jar ./tools/ant/apache-ant-1.7.1/lib/ant-nodeps.jar ./tools/ant/apache-ant-1.7.1/lib/ant-commons-logging.jar ./tools/ant/apache-ant-1.7.1/lib/ant-netrexx.jar ./tools/ant/apache-ant-1.7.1/lib/ant-weblogic.jar ./tools/ant/apache-ant-1.7.1/lib/ant-starteam.jar ./tools/ant/apache-ant-1.7.1/lib/xml-apis.jar ./tools/ant/apache-ant-1.7.1/lib/ant-apache-resolver.jar ./tools/ant/apache-ant-1.7.1/lib/ant-testutil.jar ./tools/ant/apache-ant-1.7.1/lib/ant-stylebook.jar ./tools/ant/apache-ant-1.7.1/lib/ant-launcher.jar ./tools/ant/apache-ant-1.7.1/lib/ant-apache-bcel.jar ./tools/ant/apache-ant-1.7.1/etc/ant-bootstrap.jar -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CLOUDSTACK-16) Final release version number changes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pradeep Soundararajan resolved CLOUDSTACK-16. - Resolution: Duplicate CLOUDSTACK-44 Final release version number changes Key: CLOUDSTACK-16 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-16 Project: CloudStack Issue Type: Task Reporter: Ewan Mellor Assignee: Pradeep Soundararajan Priority: Blocker Fix For: pre-4.0.0 Update all the version numbers before final RC is created. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Review Request: After 3.0.x we will use Uuid for vm-id and instance-id. For pre 3.0.x, keep them intact (uuid is null).
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7025/ --- Review request for cloudstack and Alena Prokharchyk. Description --- For pre 3.0.x, there is no uuid generated for vm instance. Keep the vm-id and instance-id the original value, instead of using uuid. This addresses bug CS-15627. Diffs - server/src/com/cloud/network/element/CloudZonesNetworkElement.java 0d4c1c1 server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 613548b Diff: https://reviews.apache.org/r/7025/diff/ Testing --- Tested on upgrade. Thanks, Fang Wang
Removing .classpath and .project files for the modules.
Hi, There are .classpath and .project files in each module present. I found them to be eclipse configuration files or we using them anywhere else (i am not much acquainted with the codebase yet) . Problem is these classpath files are having lib jar locations from deps module. As the codebase is moved to maven and the jars themselves are removed, these files are obsolete. Can we remove the .classpath and .project files or we can fix the projects in eclipse and replace these files with new sensible ones according to maven practices.. Mani.
Re: Review Request: After 3.0.x we will use Uuid for vm-id and instance-id. For pre 3.0.x, keep them intact (uuid is null).
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7025/#review11338 --- Both methods generateVmDataCommand() contain a lot of duplicated code. Please take out whatever is common for the methods, and extract it to the separate method. - Alena Prokharchyk On Sept. 11, 2012, 5:30 p.m., Fang Wang wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7025/ --- (Updated Sept. 11, 2012, 5:30 p.m.) Review request for cloudstack and Alena Prokharchyk. Description --- For pre 3.0.x, there is no uuid generated for vm instance. Keep the vm-id and instance-id the original value, instead of using uuid. This addresses bug CS-15627. Diffs - server/src/com/cloud/network/element/CloudZonesNetworkElement.java 0d4c1c1 server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 613548b Diff: https://reviews.apache.org/r/7025/diff/ Testing --- Tested on upgrade. Thanks, Fang Wang
[jira] [Resolved] (CLOUDSTACK-71) Upgrade checker needs modification to allow for minor upgrades to work
[ https://issues.apache.org/jira/browse/CLOUDSTACK-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] edison su resolved CLOUDSTACK-71. - Resolution: Fixed It's the issue of build system, passed in a wrong package version, fixed in build-cloudstack-master-rhel6.3 Upgrade checker needs modification to allow for minor upgrades to work -- Key: CLOUDSTACK-71 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-71 Project: CloudStack Issue Type: Bug Components: Management Server Affects Versions: 4.0.0 Environment: Management server: CentOS 6.3 Reporter: Ahmad Emneina Assignee: edison su Priority: Minor I did a minor binary upgrade, using rpm's, between build 4.0.46 and 4.0.59 and the server failed to start citing: 2012-09-10 15:32:06,903 DEBUG [upgrade.dao.VersionDaoImpl] (main:null) Checking to see if the database is at a version before it was the version table is created 2012-09-10 15:32:06,909 INFO [cloud.upgrade.DatabaseUpgradeChecker] (main:null) DB version = 4.0.46.20120907075031 Code Version = 4.0.59.20120908055459 2012-09-10 15:32:06,910 INFO [cloud.upgrade.DatabaseUpgradeChecker] (main:null) Database upgrade must be performed from 4.0.46.20120907075031 to 4.0.59.20120908055459 2012-09-10 15:32:06,910 ERROR [cloud.upgrade.DatabaseUpgradeChecker] (main:null) There is no upgrade path from 4.0.46.20120907075031 to 4.0.59.20120908055459 2012-09-10 15:32:06,915 ERROR [utils.component.ComponentLocator] (main:null) Problems with running checker:DatabaseUpgradeChecker com.cloud.utils.exception.CloudRuntimeException: There is no upgrade path from 4.0.46.20120907075031 to 4.0.59.20120908055459 at com.cloud.upgrade.DatabaseUpgradeChecker.upgrade(DatabaseUpgradeChecker.java:188) at com.cloud.upgrade.DatabaseUpgradeChecker.check(DatabaseUpgradeChecker.java:351) at com.cloud.utils.component.ComponentLocator.runCheckers(ComponentLocator.java:273) at com.cloud.utils.component.ComponentLocator.parse(ComponentLocator.java:245) at com.cloud.utils.component.ComponentLocator.getLocatorInternal(ComponentLocator.java:836) at com.cloud.utils.component.ComponentLocator.getLocator(ComponentLocator.java:874) at com.cloud.utils.component.ComponentLocator.getComponent(ComponentLocator.java:416) at com.cloud.utils.component.ComponentLocator.getComponent(ComponentLocator.java:409) at com.cloud.servlet.CloudStartupServlet.init(CloudStartupServlet.java:44) at javax.servlet.GenericServlet.init(GenericServlet.java:212) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4187) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4496) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:722) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:593) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289)
Re: [DISCUSS] Install.sh vs. pacakge repos
On Tue, Sep 11, 2012 at 11:45 AM, David Nalley da...@gnsa.us wrote: On Tue, Sep 11, 2012 at 8:23 AM, Wido den Hollander w...@widodh.nl wrote: On 09/11/2012 12:16 PM, Suresh Sadhu wrote: HI All, Installer fail to read the cloud packages and MS installation on Ubuntu 12.04 was not successful(No packages were installed) Raised a blocker bug. Please find the issue details in the below mentioned issue: I'd like to bring this up again, do we REALLY want this install.sh script? This really deserves its own thread, because it won't receive the attention it deserves in the original thread. I talked with infra about this a few weeks back, and while they said they really wanted downstreams to package, they weren't vehemently opposed to use creating our own repo, but we'd have to figure out how to make it work with the mirror system. Personally - the packages as they exist are great for people doing a first, small scale install, but it doesn't scale. While I am not necessarily opposed to the installer, I also recognize the problems from a real world deployment perspective. However, there is an impact, at a minimum all of our documentation will need rewriting, so personally, I'd prefer that for 4.0.0 - that we do repos if we can figure it out in time, and keep the installer as an option as well. --David Thanks for starting the thread David (you beat me to it). My thoughts: Having downstream packagers is the way to go for official package distribution of the software for each OS. However, I would like us to include the RPMs and DEB packages that we agreed to previously (Ubuntu 12.04 and RHEL/CentOS 6.2 and 6.3) as a binary distro via ASF infrastructure. I'd also like us to include this install script (functionally working for its intended purpose) with the RPMs. My thinking is similar to David's, in that it's easy to get started with that model. I don't believe that the tarball that includes packages and the install script hurts more advanced installers at all, since we can have other methods of getting the packages (perhaps ALSO hosting the packages on public repos that use the ASF mirrors, or even on repos that aren't on ASF infrastructure). Just my thoughts... looking for others to chime in. -chip
RE: [ASFCS40]Drive to clear the review board...
Hi everyone, Here is the third pass. We cleared quite a few reviews yesterday but there were more submitted so we actually have more. The good news the action for about a quarter of the reviews is to Commit it or Mark as submitted. Please take a look. Especially the people with reviews that says Mark as submitted, please take a quick action item to check the fix is in and mark it as submitted to get it out of the review board. Note that for everyone's convenience I added another column call Updated. - The first column is the review #. - The second column is for who to take action. - The third column is the version this patch should go into. If it is 4+, you don't have to take action before 4.0 release. - The fourth column is if the review has changed since last push. If you're following this email daily, you should be able to just monitor this column to determine if there's new action item for you since the last push. - The fifth column is what I believe is the action needed to close out this review. Review Assign To Version Updated Action to Take 5625Vijay 4 Retract the review request and resubmit when review is done 5655Hugo4+ Respond to Review 5806Deepti/Nitin4 Y Nitin to respond to diff and commit if okay to ship 5871Vijay 4 Y Mark as submit 6287Edison 4+ Respond to Wido 6328Jessica T 4 Commit it 6425Likitha 4 Redo the patch with the new DAO 6427Jessica T 4 Doc change. Not sure if Jessica can commit it. If not then pradeep. 6428Likitha 4 Fix according to review? 6431Anthony 4 Y Review and Commit 6470Marcus 4 Take this off the review board as it is committed 6492Krishna 4+ Respond to review comments 6502Fang4 Ship it 6515Abhi4+ Y Review fix 6523Nitin 4+ Respond to Rohit 6547Sheng 4 Commit it 6614Krishna 4+ Respond to review. 6615Marcus 4 Mark as submit 6658Marcus 4 Mark as submit Marcus 4 Mark as submit 6701Vijay/Murali4 Make sure the diff has been committed and remove if it is. If not committed, then Murali needs to commit it. 6702Vijay 4 Respond to review 6720Sheng 4 Commit it 6733Gregg 4 Y Mark as submit 6765Anthony 4 Review and Commit. 6781Rohit 4+ Y Submit new patches 6793Sheng 4 Review and Commit. 6814Alena 4 Review and Commit. 6825Chiradeep 4 Y Review and Commit. 6845Alena 4 Review and Commit. 6858Nitin 4 Y Commit it 6859Sheng 4 Commit it 6873Anthony 4 Review it 6881Jessica T 4 Review it 6883Sheng 4 Commit it 6895Chiradeep 4 Review and Commit 6899Vijay/Pranav4 Y Pranav to provide commit id and Vijya to mark as Submitted 6917Jessica T 4 Review and Commit 6926Sheng 4 Review and Commit 6941Pradeep 4 Review and Commit 6978Radhika 4 Mark as submit 7009Hiroaki 4 Y Mark as submit 7013Alena 4 Y Review 7015Sheng 4 Y Review 7017Alena 4+ Y Review and Commit 7018Nitin 4 Y Review 7025Fang4 Y Fix according to review
RE: ant debug failed to launch
Ant clean-tomcat doesn't work? -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Tuesday, September 11, 2012 11:16 AM To: CloudStack DeveloperList Subject: Re: ant debug failed to launch To get even further, here are the additional steps: rm $CATALINA_HOME/lib/axis*.jar rm $CATALINA_HOME/lib/slf4j* rm $CATALINA_HOME/lib/*jcl* rm $CATALINA_HOME/webapps7080/awsapi/WEB-INF/lib/log4j-1.2.15.jar Not sure where the problem is -- maven or ant. On 9/11/12 10:28 AM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I found that I had to remove $CATALINA_HOME/lib/servlet-api-2.3.jar to move past this error. On 9/11/12 7:04 AM, Gavin Lee gavin@gmail.com wrote: My environment was ok yesterday for ant debug before I update the source code. I use root account, I know it's not good, I checked both CATALINA_HOME and src folder, the folder permission/ownership is correct. On Tue, Sep 11, 2012 at 8:05 PM, Rohit Yadav rohit.ya...@citrix.com wrote: Make sure you're the owner on the source code (where your jars are) and on CATALINA_HOME. chown -R your-user path to tomcat and path to repo/src ant deploy-server and, ant debug! Regards, Rohit On 11-Sep-2012, at 3:24 PM, Gavin Lee gavin@gmail.com wrote: I followed the instruction [1] to setup maven build environment. Everything went well except the last step: ant debug I can use mvn -P client -pl client jetty:run but encounter some other issue such as system vm could not start. I want to attach eclipse debug. Does anybody encounter following issue when using: ant debug? [java] SEVERE: Error deploying web application directory awsapi [java] java.lang.NoSuchMethodError: javax.servlet.ServletContext.getContextPath()Ljava/lang/String; [java] at org.apache.catalina.core.StandardHost$MemoryLeakTrackingListener.li fecy c leEvent(StandardHost.java:616) [java] at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecy cleS u pport.java:142) [java] at org.apache.catalina.core.StandardContext.start(StandardContext.java :470 0 ) [java] at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBa se.j a va:799) [java] at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java: 779) [java] at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:601) [java] at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.j ava: 1 079) [java] at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig .jav a :1002) [java] at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:506) [java] at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1317) [java] at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.ja va:3 2 4) [java] at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecy cleS u pport.java:142) [java] at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1065) [java] at org.apache.catalina.core.StandardHost.start(StandardHost.java:840) [java] at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057) [java] at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463) [java] at org.apache.catalina.core.StandardService.start(StandardService.java :525 ) [java] at org.apache.catalina.core.StandardServer.start(StandardServer.java:754) [java] at org.apache.catalina.startup.Catalina.start(Catalina.java:595) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImp l.ja v a:57) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcc esso r Impl.java:43) [java] at java.lang.reflect.Method.invoke(Method.java:616) [java] at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) [java] at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) [java] Sep 11, 2012 5:52:39 PM org.apache.coyote.http11.Http11NioProtocol start [java] INFO: Starting Coyote HTTP/1.1 on http-7080 [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Building+wit h+Ma v en -- Gavin -- Gavin
[jira] [Commented] (CLOUDSTACK-79) CloudStack 3.0.4: firewall rules not restored on KVM host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453272#comment-13453272 ] Wido den Hollander commented on CLOUDSTACK-79: -- This is known, the security rules are only applied when a instance is started, but are not checked afterwards. A couple of approaches can be taken here: * Have the agent flush all the rules every X minutes/seconds/hours and apply all the rules again. * Have the agent parse the iptable rules and have it find out which are not applied anymore * Have a button/API call: Re-apply rules The first one could disrupt traffic for a short moment, probably not desirable. The second one is however not that easy to implement and could potentially hurt stuff when parsing goes wrong. I think option 3 is more doable. CloudStack 3.0.4: firewall rules not restored on KVM host - Key: CLOUDSTACK-79 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-79 Project: CloudStack Issue Type: Bug Components: KVM, Network Controller Affects Versions: pre-4.0.0 Reporter: Vladimir Ostrovsky I have CloudStack 3.0.4 with a Basic Zone defined. The Zone includes several KVM hosts and uses Security Groups (in other words, IPtables on the hosts) to isolate traffic between VMs. The problem: if, for some reason, IPtables on the host are flushed or the iptables service is restarted, the cloud-agent doesn't pull the correct rules from the management server and doesn't synchronize the host with Security Groups definitions in CloudStack. Restart of the cloud-agent service doesn't help as well. Shouldn't the agent do it? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Removing .classpath and .project files for the modules.
On Tue, Sep 11, 2012 at 2:33 PM, Edison Su edison...@citrix.com wrote: -Original Message- From: Manikanta Kattamuri [mailto:manikanta.kattam...@sungard.com] Sent: Tuesday, September 11, 2012 10:36 AM To: cloudstack-dev@incubator.apache.org Subject: Removing .classpath and .project files for the modules. Hi, There are .classpath and .project files in each module present. I found them to be eclipse configuration files or we using them anywhere else (i am not much acquainted with the codebase yet) . Problem is these classpath files are having lib jar locations from deps module. As the codebase is moved to maven and the jars themselves are removed, these files are obsolete. Can we remove the .classpath and .project files or we can fix the projects in eclipse and replace these files with new sensible ones according to maven practices.. +1, to remove them, as these files are managed by eclipse + maven now. From http://maven.apache.org/guides/mini/guide-ide-eclipse.html, It recommends to add .classpath and .project into .gitignore. +1 from me as well. Mani - Do you want to follow the reviewboard submission process to do this as your first patch for the project? Mani.
Re: Review Request: Removing the older xenapi jar and adding an ant target to build one from the source
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6873/#review11347 --- Ship it! Ship It! - anthony xu On Aug. 31, 2012, 4:29 p.m., Devdeep Singh wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6873/ --- (Updated Aug. 31, 2012, 4:29 p.m.) Review request for cloudstack. Description --- Removing the older xenapi jar and adding an ant target to build one from the source. Diffs - build/build-cloud.xml 2ad3715 cloud.spec 0670ec6 deps/.classpath 1376b4f deps/cloud-xenserver-5.6.100-1.jar ff3744fa9d813a9580d616147ce71d69ba2dc845 Diff: https://reviews.apache.org/r/6873/diff/ Testing --- ant clean-all compile-server ant clean-all build-all Thanks, Devdeep Singh
RE: [ASFCS40] bug count
The bug count for the pre-4.0 is now at 32. However, even though the bugs are assigned, each one remains in Open status. If you're actively working on a bug please change the status so we know you're working on them. Thank you! --Alex -Original Message- From: Alex Huang Sent: Monday, September 10, 2012 1:19 PM To: cloudstack-dev@incubator.apache.org Subject: [ASFCS40] bug count Currently for the 4.0 release, there are 35 bugs open. All bugs have been assigned. Quite a few of them are bugs related to build/install and docs. Please take a look at [1]. --Alex [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truejqlQ uery=project+%3D+CLOUDSTACK+AND+fixVersion+%3D+%22pre- 4.0.0%22+AND+status+%3D+Open+ORDER+BY+priority+DESCmode=hide
Re: Removing .classpath and .project files for the modules.
Yes i would like to do it in that way. On Wed, Sep 12, 2012 at 12:05 AM, Chip Childers chip.child...@sungard.comwrote: On Tue, Sep 11, 2012 at 2:33 PM, Edison Su edison...@citrix.com wrote: -Original Message- From: Manikanta Kattamuri [mailto:manikanta.kattam...@sungard.com] Sent: Tuesday, September 11, 2012 10:36 AM To: cloudstack-dev@incubator.apache.org Subject: Removing .classpath and .project files for the modules. Hi, There are .classpath and .project files in each module present. I found them to be eclipse configuration files or we using them anywhere else (i am not much acquainted with the codebase yet) . Problem is these classpath files are having lib jar locations from deps module. As the codebase is moved to maven and the jars themselves are removed, these files are obsolete. Can we remove the .classpath and .project files or we can fix the projects in eclipse and replace these files with new sensible ones according to maven practices.. +1, to remove them, as these files are managed by eclipse + maven now. From http://maven.apache.org/guides/mini/guide-ide-eclipse.html, It recommends to add .classpath and .project into .gitignore. +1 from me as well. Mani - Do you want to follow the reviewboard submission process to do this as your first patch for the project? Mani.
Re: [DISCUSS] Install.sh vs. pacakge repos
On 09/11/2012 05:45 PM, David Nalley wrote: On Tue, Sep 11, 2012 at 8:23 AM, Wido den Hollander w...@widodh.nl wrote: On 09/11/2012 12:16 PM, Suresh Sadhu wrote: HI All, Installer fail to read the cloud packages and MS installation on Ubuntu 12.04 was not successful(No packages were installed) Raised a blocker bug. Please find the issue details in the below mentioned issue: I'd like to bring this up again, do we REALLY want this install.sh script? This really deserves its own thread, because it won't receive the attention it deserves in the original thread. I talked with infra about this a few weeks back, and while they said they really wanted downstreams to package, they weren't vehemently opposed to use creating our own repo, but we'd have to figure out how to make it work with the mirror system. A Debian/Ubutnu repository is just a bunch of directories and files, that could be distributed I think? The question is, do we want this to go on ASF infra or us an external mirror for it? Personally - the packages as they exist are great for people doing a first, small scale install, but it doesn't scale. While I am not necessarily opposed to the installer, I also recognize the problems from a real world deployment perspective. I disagree on the first point. When manually installing packages with dpkg you will run into dependency hell. You (you=install script) manually have to apt-get install several packages. The problem you run into here is that you start doing redundant work. In the control file you specify which packages you depend on. If you'd use apt(itude) it will resolve those dependencies for you. But when doing a manual install with dpkg it will complain about every single package which is missing. This leads to having install.sh a couple of directives to install packages we already specific in the control file. On the longer run you get packages installed by install.sh which are no longer required, but apt has no way of knowing they can be removed. Packages should always enter a Debian system through apt to know which package was depending on which package so apt(itude) can do their work. Adding a repository and install CloudStack is just 4 commands, isn't that simple enough? $ echo deb http://cloudstack.apt-get.eu/ubuntu $(lsb_release -s -c) 4.0 /etc/apt/sources.list.d/cloudstack.list $ wget -O - http://cloudstack.apt-get.eu/release.asc|apt-key add - $ apt-get update $ apt-get install cloud-agent Again, the repo of mine is just an example :) However, there is an impact, at a minimum all of our documentation will need rewriting, so personally, I'd prefer that for 4.0.0 - that we do repos if we can figure it out in time, and keep the installer as an option as well. Re-writing the docs is a couple of hours work I'd be more then happy to do for 4.0 if we go for a repo. I honestly must admit that in some recent docs I already assumed there would be a repo for 4.0... It would be awesome if Jenkins could produce packages and send them to the mirror, but it's more then doable to build the packages locally and upload them, it's not like we are doing 10 releases a month. It's just placing the packages in the pool directory and have a script re-scan the repo. The question remains: Do we want this to be on ASF infra or do we host this externally? Wido
[jira] [Assigned] (CLOUDSTACK-75) Install: need to changed Installer description found cllud.com in the installer description
[ https://issues.apache.org/jira/browse/CLOUDSTACK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Huang reassigned CLOUDSTACK-75: Assignee: Pradeep Soundararajan (was: edison su) Install: need to changed Installer description found cllud.com in the installer description - Key: CLOUDSTACK-75 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-75 Project: CloudStack Issue Type: Bug Components: Install and Setup Affects Versions: pre-4.0.0 Reporter: sadhu suresh Assignee: Pradeep Soundararajan Fix For: pre-4.0.0 Noticed cloud.com in the installer description. steps: 1.down the latest build from jenkins http://jenkins.cloudstack.org/job/build-cloudstack-4.0-ubuntu12.04/lastSuccessfulBuild/artifact/CloudStack-oss-4.0.1-ubuntu12.04.tar.gz 2.Install the setup on ubuntu and check the shown test on the Installer description sadhu@ubuntu:~/CloudStack-oss-4.0.1-ubuntu12.04$ sudo ./install.sh Actual result: Noticed cloud.clom in the installer description Welcome to the Cloud.com CloudStack Installer Hit http://us.archive.ubuntu.com precise-backports/universe Translation-en Fetched 1,204 kB in 22s (54.1 kB/s) Welcome to the Cloud.com CloudStack Installer. What would you like to do? M) Install the Management Server A) Install the Agent S) Install the Usage Monitor D) Install the database server Q) Quit Expected result: description should be like this welcome to the CloudStack Installer. What would you like to do?..don't show the cloud.com in the description. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-78) Cloudstack Agent installation failed with jsvc package dependancy error
[ https://issues.apache.org/jira/browse/CLOUDSTACK-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Huang updated CLOUDSTACK-78: - Fix Version/s: pre-4.0.0 Cloudstack Agent installation failed with jsvc package dependancy error Key: CLOUDSTACK-78 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-78 Project: CloudStack Issue Type: Bug Components: Install and Setup Affects Versions: pre-4.0.0 Reporter: Sailaja Mada Assignee: David Nalley Priority: Critical Fix For: pre-4.0.0 Steps: 1. Tried installing Agent with KVM host . Observation : Cloudstack Agent installation failed with jsvc package dependancy error Details : M) Install the Management Server A) Install the Agent B) Install BareMetal Agent S) Install the Usage Monitor D) Install the database server Q) Quit A Installing the Agent... Loaded plugins: product-id, security, subscription-manager Updating certificate-based repositories. cloud-temp | 2.6 kB 00:00 ... cloud-temp/primary_db | 10 kB 00:00 ... rhel | 4.0 kB 00:00 ... Setting up Install Process No package cloud-premium available. Resolving Dependencies -- Running transaction check --- Package cloud-agent.x86_64 0:4.0.59-0.59.el6.4.0 will be installed -- Processing Dependency: cloud-utils = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-python = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-deps = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-core = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-agent-scripts = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: cloud-agent-libs = 4.0.59 for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: jsvc for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Processing Dependency: jna for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 -- Running transaction check --- Package cloud-agent.x86_64 0:4.0.59-0.59.el6.4.0 will be installed -- Processing Dependency: jsvc for package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 --- Package cloud-agent-libs.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-agent-scripts.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-core.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-deps.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-python.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package cloud-utils.x86_64 0:4.0.59-0.59.el6.4.0 will be installed --- Package jna.x86_64 0:3.2.4-2.el6 will be installed -- Finished Dependency Resolution Error: Package: cloud-agent-4.0.59-0.59.el6.4.0.x86_64 (cloud-temp) Requires: jsvc You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest Done Expected Results : Installation should go thru with out any issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ant debug failed to launch
clean-tomcat does not clean out the $CATALINA_HOME/libs directory. But even after manually deleting all the copied-over libs there, 'ant deploy-server' re-introduces the same problems. On 9/11/12 11:34 AM, Edison Su edison...@citrix.com wrote: Ant clean-tomcat doesn't work? -Original Message- From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com] Sent: Tuesday, September 11, 2012 11:16 AM To: CloudStack DeveloperList Subject: Re: ant debug failed to launch To get even further, here are the additional steps: rm $CATALINA_HOME/lib/axis*.jar rm $CATALINA_HOME/lib/slf4j* rm $CATALINA_HOME/lib/*jcl* rm $CATALINA_HOME/webapps7080/awsapi/WEB-INF/lib/log4j-1.2.15.jar Not sure where the problem is -- maven or ant. On 9/11/12 10:28 AM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote: I found that I had to remove $CATALINA_HOME/lib/servlet-api-2.3.jar to move past this error. On 9/11/12 7:04 AM, Gavin Lee gavin@gmail.com wrote: My environment was ok yesterday for ant debug before I update the source code. I use root account, I know it's not good, I checked both CATALINA_HOME and src folder, the folder permission/ownership is correct. On Tue, Sep 11, 2012 at 8:05 PM, Rohit Yadav rohit.ya...@citrix.com wrote: Make sure you're the owner on the source code (where your jars are) and on CATALINA_HOME. chown -R your-user path to tomcat and path to repo/src ant deploy-server and, ant debug! Regards, Rohit On 11-Sep-2012, at 3:24 PM, Gavin Lee gavin@gmail.com wrote: I followed the instruction [1] to setup maven build environment. Everything went well except the last step: ant debug I can use mvn -P client -pl client jetty:run but encounter some other issue such as system vm could not start. I want to attach eclipse debug. Does anybody encounter following issue when using: ant debug? [java] SEVERE: Error deploying web application directory awsapi [java] java.lang.NoSuchMethodError: javax.servlet.ServletContext.getContextPath()Ljava/lang/String; [java] at org.apache.catalina.core.StandardHost$MemoryLeakTrackingListener.li fecy c leEvent(StandardHost.java:616) [java] at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecy cleS u pport.java:142) [java] at org.apache.catalina.core.StandardContext.start(StandardContext.java :470 0 ) [java] at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBa se.j a va:799) [java] at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java: 779) [java] at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:601) [java] at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.j ava: 1 079) [java] at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig .jav a :1002) [java] at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:506) [java] at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1317) [java] at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.ja va:3 2 4) [java] at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecy cleS u pport.java:142) [java] at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1065) [java] at org.apache.catalina.core.StandardHost.start(StandardHost.java:840) [java] at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1057) [java] at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:463) [java] at org.apache.catalina.core.StandardService.start(StandardService.java :525 ) [java] at org.apache.catalina.core.StandardServer.start(StandardServer.java:754) [java] at org.apache.catalina.startup.Catalina.start(Catalina.java:595) [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [java] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImp l.ja v a:57) [java] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcc esso r Impl.java:43) [java] at java.lang.reflect.Method.invoke(Method.java:616) [java] at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) [java] at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) [java] Sep 11, 2012 5:52:39 PM org.apache.coyote.http11.Http11NioProtocol start [java] INFO: Starting Coyote HTTP/1.1 on http-7080 [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Building+wit h+Ma v en -- Gavin -- Gavin
[jira] [Commented] (CLOUDSTACK-75) Install: need to changed Installer description found cllud.com in the installer description
[ https://issues.apache.org/jira/browse/CLOUDSTACK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453300#comment-13453300 ] Chip Childers commented on CLOUDSTACK-75: - So I have the fix as a patch, but I don't have permission to push to the repo right now (even though David added me to the Owners group for CloudStack on Github). Edison, if you want to just knock this out, I was modifying from Cloud.com Cloudstack to Apache CloudStack (Incubating) Install: need to changed Installer description found cllud.com in the installer description - Key: CLOUDSTACK-75 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-75 Project: CloudStack Issue Type: Bug Components: Install and Setup Affects Versions: pre-4.0.0 Reporter: sadhu suresh Assignee: Pradeep Soundararajan Fix For: pre-4.0.0 Noticed cloud.com in the installer description. steps: 1.down the latest build from jenkins http://jenkins.cloudstack.org/job/build-cloudstack-4.0-ubuntu12.04/lastSuccessfulBuild/artifact/CloudStack-oss-4.0.1-ubuntu12.04.tar.gz 2.Install the setup on ubuntu and check the shown test on the Installer description sadhu@ubuntu:~/CloudStack-oss-4.0.1-ubuntu12.04$ sudo ./install.sh Actual result: Noticed cloud.clom in the installer description Welcome to the Cloud.com CloudStack Installer Hit http://us.archive.ubuntu.com precise-backports/universe Translation-en Fetched 1,204 kB in 22s (54.1 kB/s) Welcome to the Cloud.com CloudStack Installer. What would you like to do? M) Install the Management Server A) Install the Agent S) Install the Usage Monitor D) Install the database server Q) Quit Expected result: description should be like this welcome to the CloudStack Installer. What would you like to do?..don't show the cloud.com in the description. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] Install.sh vs. pacakge repos
Wido, see my comments about the problems with hosting an APT repository on ASF infra. * Can't think of a way it would work with the mirrors. * If you don't use the mirrors, infra might not like the bandwidth. However: * Do we already host repositories for Java? * Can we set something up for debs? On Tue, Sep 11, 2012 at 7:50 PM, Wido den Hollander w...@widodh.nl wrote: On 09/11/2012 05:45 PM, David Nalley wrote: On Tue, Sep 11, 2012 at 8:23 AM, Wido den Hollander w...@widodh.nl wrote: On 09/11/2012 12:16 PM, Suresh Sadhu wrote: HI All, Installer fail to read the cloud packages and MS installation on Ubuntu 12.04 was not successful(No packages were installed) Raised a blocker bug. Please find the issue details in the below mentioned issue: I'd like to bring this up again, do we REALLY want this install.sh script? This really deserves its own thread, because it won't receive the attention it deserves in the original thread. I talked with infra about this a few weeks back, and while they said they really wanted downstreams to package, they weren't vehemently opposed to use creating our own repo, but we'd have to figure out how to make it work with the mirror system. A Debian/Ubutnu repository is just a bunch of directories and files, that could be distributed I think? The question is, do we want this to go on ASF infra or us an external mirror for it? Personally - the packages as they exist are great for people doing a first, small scale install, but it doesn't scale. While I am not necessarily opposed to the installer, I also recognize the problems from a real world deployment perspective. I disagree on the first point. When manually installing packages with dpkg you will run into dependency hell. You (you=install script) manually have to apt-get install several packages. The problem you run into here is that you start doing redundant work. In the control file you specify which packages you depend on. If you'd use apt(itude) it will resolve those dependencies for you. But when doing a manual install with dpkg it will complain about every single package which is missing. This leads to having install.sh a couple of directives to install packages we already specific in the control file. On the longer run you get packages installed by install.sh which are no longer required, but apt has no way of knowing they can be removed. Packages should always enter a Debian system through apt to know which package was depending on which package so apt(itude) can do their work. Adding a repository and install CloudStack is just 4 commands, isn't that simple enough? $ echo deb http://cloudstack.apt-get.eu/**ubuntuhttp://cloudstack.apt-get.eu/ubuntu$(lsb_release -s -c) 4.0 /etc/apt/sources.list.d/ **cloudstack.list $ wget -O - http://cloudstack.apt-get.eu/**release.asc|apt-keyhttp://cloudstack.apt-get.eu/release.asc%7Capt-keyadd - $ apt-get update $ apt-get install cloud-agent Again, the repo of mine is just an example :) However, there is an impact, at a minimum all of our documentation will need rewriting, so personally, I'd prefer that for 4.0.0 - that we do repos if we can figure it out in time, and keep the installer as an option as well. Re-writing the docs is a couple of hours work I'd be more then happy to do for 4.0 if we go for a repo. I honestly must admit that in some recent docs I already assumed there would be a repo for 4.0... It would be awesome if Jenkins could produce packages and send them to the mirror, but it's more then doable to build the packages locally and upload them, it's not like we are doing 10 releases a month. It's just placing the packages in the pool directory and have a script re-scan the repo. The question remains: Do we want this to be on ASF infra or do we host this externally? Wido -- NS
[jira] [Created] (CLOUDSTACK-80) /ovm is empty
sebastien goasguen created CLOUDSTACK-80: Summary: /ovm is empty Key: CLOUDSTACK-80 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-80 Project: CloudStack Issue Type: Bug Reporter: sebastien goasguen Priority: Minor Fix For: pre-4.0.0 /ovm is empty, I don't know if it's intentional. but can probably be deleted ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [DISCUSS] Install.sh vs. pacakge repos
On 09/11/2012 08:56 PM, Noah Slater wrote: Wido, see my comments about the problems with hosting an APT repository on ASF infra. Yes, our e-mails crossed. Yours arrived while I was typing mine. * Can't think of a way it would work with the mirrors. * If you don't use the mirrors, infra might not like the bandwidth. However: * Do we already host repositories for Java? No, we don't. * Can we set something up for debs? I'm offering bandwidth on our company servers under cloudstack.apt-get.eu, more then enough bandwidth available. We should probably use a cloudstack.org hostname just to make sure we can switch without users knowing. Wido On Tue, Sep 11, 2012 at 7:50 PM, Wido den Hollander w...@widodh.nl wrote: On 09/11/2012 05:45 PM, David Nalley wrote: On Tue, Sep 11, 2012 at 8:23 AM, Wido den Hollander w...@widodh.nl wrote: On 09/11/2012 12:16 PM, Suresh Sadhu wrote: HI All, Installer fail to read the cloud packages and MS installation on Ubuntu 12.04 was not successful(No packages were installed) Raised a blocker bug. Please find the issue details in the below mentioned issue: I'd like to bring this up again, do we REALLY want this install.sh script? This really deserves its own thread, because it won't receive the attention it deserves in the original thread. I talked with infra about this a few weeks back, and while they said they really wanted downstreams to package, they weren't vehemently opposed to use creating our own repo, but we'd have to figure out how to make it work with the mirror system. A Debian/Ubutnu repository is just a bunch of directories and files, that could be distributed I think? The question is, do we want this to go on ASF infra or us an external mirror for it? Personally - the packages as they exist are great for people doing a first, small scale install, but it doesn't scale. While I am not necessarily opposed to the installer, I also recognize the problems from a real world deployment perspective. I disagree on the first point. When manually installing packages with dpkg you will run into dependency hell. You (you=install script) manually have to apt-get install several packages. The problem you run into here is that you start doing redundant work. In the control file you specify which packages you depend on. If you'd use apt(itude) it will resolve those dependencies for you. But when doing a manual install with dpkg it will complain about every single package which is missing. This leads to having install.sh a couple of directives to install packages we already specific in the control file. On the longer run you get packages installed by install.sh which are no longer required, but apt has no way of knowing they can be removed. Packages should always enter a Debian system through apt to know which package was depending on which package so apt(itude) can do their work. Adding a repository and install CloudStack is just 4 commands, isn't that simple enough? $ echo deb http://cloudstack.apt-get.eu/**ubuntuhttp://cloudstack.apt-get.eu/ubuntu$(lsb_release -s -c) 4.0 /etc/apt/sources.list.d/ **cloudstack.list $ wget -O - http://cloudstack.apt-get.eu/**release.asc|apt-keyhttp://cloudstack.apt-get.eu/release.asc%7Capt-keyadd - $ apt-get update $ apt-get install cloud-agent Again, the repo of mine is just an example :) However, there is an impact, at a minimum all of our documentation will need rewriting, so personally, I'd prefer that for 4.0.0 - that we do repos if we can figure it out in time, and keep the installer as an option as well. Re-writing the docs is a couple of hours work I'd be more then happy to do for 4.0 if we go for a repo. I honestly must admit that in some recent docs I already assumed there would be a repo for 4.0... It would be awesome if Jenkins could produce packages and send them to the mirror, but it's more then doable to build the packages locally and upload them, it's not like we are doing 10 releases a month. It's just placing the packages in the pool directory and have a script re-scan the repo. The question remains: Do we want this to be on ASF infra or do we host this externally? Wido
[jira] [Updated] (CLOUDSTACK-80) /ovm is empty
[ https://issues.apache.org/jira/browse/CLOUDSTACK-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudha Ponnaganti updated CLOUDSTACK-80: --- Affects Version/s: pre-4.0.0 Assignee: edison su /ovm is empty - Key: CLOUDSTACK-80 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-80 Project: CloudStack Issue Type: Bug Affects Versions: pre-4.0.0 Reporter: sebastien goasguen Assignee: edison su Priority: Minor Fix For: pre-4.0.0 /ovm is empty, I don't know if it's intentional. but can probably be deleted ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[utils.crypt.DBEncryptionUtil] (main:null) Error while decrypting: true
Hi,
I upgraded my 3.0.2 database to 4.0 today and tried to run the latest
code on it.
After long trial and error for other issues I'm stuck at the last one:
2012-09-11 17:56:26,387 DEBUG [utils.crypt.DBEncryptionUtil] (main:null)
Error while decrypting: true
2012-09-11 17:56:26,388 ERROR [cloud.servlet.CloudStartupServlet]
(main:null) Exception starting management server
org.jasypt.exceptions.EncryptionOperationNotPossibleException
at
org.jasypt.encryption.pbe.StandardPBEByteEncryptor.decrypt(StandardPBEByteEncryptor.java:918)
at
org.jasypt.encryption.pbe.StandardPBEStringEncryptor.decrypt(StandardPBEStringEncryptor.java:725)
at
com.cloud.utils.crypt.DBEncryptionUtil.decrypt(DBEncryptionUtil.java:65)
at
com.cloud.configuration.ConfigurationVO.getValue(ConfigurationVO.java:92)
at
com.cloud.configuration.dao.ConfigurationDaoImpl.getValue(ConfigurationDaoImpl.java:158)
at
com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34)
at
com.cloud.server.ConfigurationServerImpl.persistDefaultValues(ConfigurationServerImpl.java:153)
at
com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34)
See this:
Error while decrypting: true
When you open ConfigurationServerImpl.java and look at line 153:
String init = _configDao.getValue(init);
init is in the category Hidden in the database and these go to the
DBEncryptionUtil (ConfigurationVO.java):
public String getValue() {
return ((Hidden.equals(getCategory()) ||
Secure.equals(getCategory())) ? DBEncryptionUtil.decrypt(value) : value);
}
In my case the value of init is just true and doesn't need any
decryption, it's in the database plain-text, but what is going wrong here?
Any suggestions?
Wido
Re: Review Request: Add helper for DAO based on podId
On Sept. 11, 2012, 6:05 p.m., Alex Huang wrote: What is this change for? There was no method to get list of VMs by podId, count by podId etc. The patch adds them. They will be used in restartNetwork and may be useful elsewhere. - Rohit --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7017/#review11342 --- On Sept. 11, 2012, 1:45 p.m., Rohit Yadav wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/7017/ --- (Updated Sept. 11, 2012, 1:45 p.m.) Review request for cloudstack, Murali Reddy, Alena Prokharchyk, and Alex Huang. Description --- They will be used by https://reviews.apache.org/r/6781/ Dao: Add helpers for listing based on podId - added listByPodId - fixed listByTypeAndState to accept type and then state as arguments - added listByPodIdTypeAndState in VMInstanceDao - added countByPodIdVMTypeAndState in VMInstanceDao Download original patch: http://patchbin.baagi.org/p?id=ue9o0z Diffs - server/src/com/cloud/vm/dao/DomainRouterDao.java 01e3258 server/src/com/cloud/vm/dao/DomainRouterDaoImpl.java 175d3f2 server/src/com/cloud/vm/dao/VMInstanceDao.java 2cf3d75 server/src/com/cloud/vm/dao/VMInstanceDaoImpl.java 571b5d1 Diff: https://reviews.apache.org/r/7017/diff/ Testing --- Thanks, Rohit Yadav
Do we still need to patch the SystemVM ISO on the management server?
Hi, Currently the management server does some magic stuff with systemvm.iso like injecting keys into it with injectkeys.sh on boot. However, is this still required? I can't find any reference that we transfer this modified ISO from the management server to the Hypervisor, do we? As it seems the SSH keys are injected by the Agent and no longer by the management server. I'd like to get rid of this code as it seems to confuse people. injectkeys.sh is also part of the cloud-agent-scripts package which I don't want to have installed on a management server. I think it can be removed, but I'd just want conformation. Wido
Re: Do we still need to patch the SystemVM ISO on the management server?
On 9/11/12 12:55 PM, Wido den Hollander w...@widodh.nl wrote: Hi, Currently the management server does some magic stuff with systemvm.iso like injecting keys into it with injectkeys.sh on boot. However, is this still required? I can't find any reference that we transfer this modified ISO from the management server to the Hypervisor, do we? As it seems the SSH keys are injected by the Agent and no longer by the management server. The ssh keys are generated by the management server on first startup and injected into the ISO. This ISO is copied down to the XenServer (CitrixResourceBase.setupServer) and mounted by the system vm. When the system vm boots, it checks for this key and copies it into authorized keys. See patches/systemvm/debian/config/etc/init.d/cloud-early-config I'd like to get rid of this code as it seems to confuse people. injectkeys.sh is also part of the cloud-agent-scripts package which I don't want to have installed on a management server. I think it can be removed, but I'd just want conformation. No, for the above reasons. -- Chiradeep
Re: Review Request: AutoScale. Aligning the NetScaler response time counter, and correcting duration check against interval
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/6895/ --- (Updated Sept. 11, 2012, 9:11 p.m.) Review request for cloudstack, Devdeep Singh and Deepak Garg. Changes --- Quiet time is made independent of interval. Description --- 1. Better names for default counters (removed special characters etc) 2. Aligning the Netscaler response time counter to the right unit. (changing from milliseconds to microseconds) 3. Duration cannot be less than interval and making QuietTime independent of interval. This addresses bug CS-15729. Diffs (updated) - server/src/com/cloud/network/as/AutoScaleManagerImpl.java 8c39097 setup/db/create-schema.sql 2b0b01a Diff: https://reviews.apache.org/r/6895/diff/ Testing --- 1. deploydb succeeds. 2. Testing duration check. a. create autoscale config (duration=300), (interval=30) b. fire updateAutoScalePolicy with duration=25. #checks update path. 3. Testing quiettime independency. a. create autoscale config (quiettime=25), (interval=30) #verifies create path b. fire updateAutoScalePolicy with quiettime=24. #verifies update path Thanks, Vijay Venkatachalam
RE: [utils.crypt.DBEncryptionUtil] (main:null) Error while decrypting: true
On my 4.0 setup, the value of init is encrypted. Do you upgrade from a fresh
install 3.0.2 installation? From the code, in 3.0.2, the value is already
encrypted.
-Original Message-
From: Wido den Hollander [mailto:w...@widodh.nl]
Sent: Tuesday, September 11, 2012 12:11 PM
To: cloudstack-dev@incubator.apache.org
Subject: [utils.crypt.DBEncryptionUtil] (main:null) Error while
decrypting: true
Hi,
I upgraded my 3.0.2 database to 4.0 today and tried to run the latest
code on it.
After long trial and error for other issues I'm stuck at the last one:
2012-09-11 17:56:26,387 DEBUG [utils.crypt.DBEncryptionUtil] (main:null)
Error while decrypting: true
2012-09-11 17:56:26,388 ERROR [cloud.servlet.CloudStartupServlet]
(main:null) Exception starting management server
org.jasypt.exceptions.EncryptionOperationNotPossibleException
at
org.jasypt.encryption.pbe.StandardPBEByteEncryptor.decrypt(StandardPBEB
yteEncryptor.java:918)
at
org.jasypt.encryption.pbe.StandardPBEStringEncryptor.decrypt(StandardPB
EStringEncryptor.java:725)
at
com.cloud.utils.crypt.DBEncryptionUtil.decrypt(DBEncryptionUtil.java:65)
at
com.cloud.configuration.ConfigurationVO.getValue(ConfigurationVO.java:9
2)
at
com.cloud.configuration.dao.ConfigurationDaoImpl.getValue(Configuration
DaoImpl.java:158)
at
com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34)
at
com.cloud.server.ConfigurationServerImpl.persistDefaultValues(Configura
tionServerImpl.java:153)
at
com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34)
See this:
Error while decrypting: true
When you open ConfigurationServerImpl.java and look at line 153:
String init = _configDao.getValue(init);
init is in the category Hidden in the database and these go to the
DBEncryptionUtil (ConfigurationVO.java):
public String getValue() {
return ((Hidden.equals(getCategory()) ||
Secure.equals(getCategory())) ? DBEncryptionUtil.decrypt(value) :
value);
}
In my case the value of init is just true and doesn't need any
decryption, it's in the database plain-text, but what is going wrong
here?
Any suggestions?
Wido
Re: Do we still need to patch the SystemVM ISO on the management server?
On 09/11/2012 10:10 PM, Chiradeep Vittal wrote: On 9/11/12 12:55 PM, Wido den Hollander w...@widodh.nl wrote: Hi, Currently the management server does some magic stuff with systemvm.iso like injecting keys into it with injectkeys.sh on boot. However, is this still required? I can't find any reference that we transfer this modified ISO from the management server to the Hypervisor, do we? As it seems the SSH keys are injected by the Agent and no longer by the management server. The ssh keys are generated by the management server on first startup and injected into the ISO. This ISO is copied down to the XenServer (CitrixResourceBase.setupServer) and mounted by the system vm. When the system vm boots, it checks for this key and copies it into authorized keys. See patches/systemvm/debian/config/etc/init.d/cloud-early-config Ah, yes. I was confused by KVM, the process there works differently. It's the Agent which injects the key into the systemvm. I'd like to get rid of this code as it seems to confuse people. injectkeys.sh is also part of the cloud-agent-scripts package which I don't want to have installed on a management server. The script should then however be moved from package. Imho it's not correct to install cloud-agent-scripts on a management server. Wido I think it can be removed, but I'd just want conformation. No, for the above reasons. -- Chiradeep
Re: [utils.crypt.DBEncryptionUtil] (main:null) Error while decrypting: true
On 09/11/2012 11:15 PM, Edison Su wrote:
On my 4.0 setup, the value of init is encrypted. Do you upgrade from a fresh
install 3.0.2 installation? From the code, in 3.0.2, the value is already encrypted.
My 3.0.2 install was fresh and I upgraded an existing database from
3.0.2 to 4.0 with the SQL files.
Seems that I've ran into some weird corner-case then with all my playing
around.
It seems that nothing in my database is actually encrypted. I disabled
encryption in db.properties and now everything seems to be working.
Wido
-Original Message-
From: Wido den Hollander [mailto:w...@widodh.nl]
Sent: Tuesday, September 11, 2012 12:11 PM
To: cloudstack-dev@incubator.apache.org
Subject: [utils.crypt.DBEncryptionUtil] (main:null) Error while
decrypting: true
Hi,
I upgraded my 3.0.2 database to 4.0 today and tried to run the latest
code on it.
After long trial and error for other issues I'm stuck at the last one:
2012-09-11 17:56:26,387 DEBUG [utils.crypt.DBEncryptionUtil] (main:null)
Error while decrypting: true
2012-09-11 17:56:26,388 ERROR [cloud.servlet.CloudStartupServlet]
(main:null) Exception starting management server
org.jasypt.exceptions.EncryptionOperationNotPossibleException
at
org.jasypt.encryption.pbe.StandardPBEByteEncryptor.decrypt(StandardPBEB
yteEncryptor.java:918)
at
org.jasypt.encryption.pbe.StandardPBEStringEncryptor.decrypt(StandardPB
EStringEncryptor.java:725)
at
com.cloud.utils.crypt.DBEncryptionUtil.decrypt(DBEncryptionUtil.java:65)
at
com.cloud.configuration.ConfigurationVO.getValue(ConfigurationVO.java:9
2)
at
com.cloud.configuration.dao.ConfigurationDaoImpl.getValue(Configuration
DaoImpl.java:158)
at
com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34)
at
com.cloud.server.ConfigurationServerImpl.persistDefaultValues(Configura
tionServerImpl.java:153)
at
com.cloud.utils.db.DatabaseCallback.intercept(DatabaseCallback.java:34)
See this:
Error while decrypting: true
When you open ConfigurationServerImpl.java and look at line 153:
String init = _configDao.getValue(init);
init is in the category Hidden in the database and these go to the
DBEncryptionUtil (ConfigurationVO.java):
public String getValue() {
return ((Hidden.equals(getCategory()) ||
Secure.equals(getCategory())) ? DBEncryptionUtil.decrypt(value) :
value);
}
In my case the value of init is just true and doesn't need any
decryption, it's in the database plain-text, but what is going wrong
here?
Any suggestions?
Wido
[jira] [Commented] (CLOUDSTACK-79) CloudStack 3.0.4: firewall rules not restored on KVM host
[ https://issues.apache.org/jira/browse/CLOUDSTACK-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13453429#comment-13453429 ] Wido den Hollander commented on CLOUDSTACK-79: -- Oh, sorry, I didn't make this really clear. In CS 3.0.2 and the upcoming 4.0 release this isn't possible yet. What you could do is run the security_group.py script by hand with the same parameters as the agent did. You can find this in the agent.log if the loglevel is high enough. The three options I proposed where actually development options which could be implemented. CloudStack 3.0.4: firewall rules not restored on KVM host - Key: CLOUDSTACK-79 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-79 Project: CloudStack Issue Type: Bug Components: KVM, Network Controller Affects Versions: pre-4.0.0 Reporter: Vladimir Ostrovsky Fix For: 4.1.0 I have CloudStack 3.0.4 with a Basic Zone defined. The Zone includes several KVM hosts and uses Security Groups (in other words, IPtables on the hosts) to isolate traffic between VMs. The problem: if, for some reason, IPtables on the host are flushed or the iptables service is restarted, the cloud-agent doesn't pull the correct rules from the management server and doesn't synchronize the host with Security Groups definitions in CloudStack. Restart of the cloud-agent service doesn't help as well. Shouldn't the agent do it? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-12) Audit Review Board
[ https://issues.apache.org/jira/browse/CLOUDSTACK-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Huang updated CLOUDSTACK-12: - Fix Version/s: (was: pre-4.0.0) 4.0.0 Audit Review Board -- Key: CLOUDSTACK-12 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-12 Project: CloudStack Issue Type: Task Reporter: Ewan Mellor Assignee: Alex Huang Fix For: 4.0.0 Audit Review Board and check that all patches have been applied to master and 4.0, or reasonably deferred to the next release. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CLOUDSTACK-22) Sign the release artifacts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Huang updated CLOUDSTACK-22: - Fix Version/s: (was: pre-4.0.0) 4.0.0 Sign the release artifacts -- Key: CLOUDSTACK-22 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-22 Project: CloudStack Issue Type: Task Reporter: Ewan Mellor Assignee: Chip Childers Priority: Blocker Fix For: 4.0.0 The release artifacts need to be signed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CLOUDSTACK-80) /ovm is empty
[ https://issues.apache.org/jira/browse/CLOUDSTACK-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Huang reassigned CLOUDSTACK-80: Assignee: Pradeep Soundararajan (was: edison su) /ovm is empty - Key: CLOUDSTACK-80 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-80 Project: CloudStack Issue Type: Bug Affects Versions: pre-4.0.0 Reporter: sebastien goasguen Assignee: Pradeep Soundararajan Priority: Minor Fix For: pre-4.0.0 /ovm is empty, I don't know if it's intentional. but can probably be deleted ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
