Re: Review Request 13771: CLOUDSTACK-4346 replace URI getHost() and create(String) calls

[Daan Hoogland]

Sheng, Dave, Chiradeep and Hugo,

Can you please review this? In my experience the time that this patch will
expire is rather short, I have been resolving conflicts on this a lot. If
now, given the 4.2 release is inconvenient, I would like to set a window
for submitting this in which I will rebase it a couple of times so as to
make sure it works in the end.

thanks,
Daan


On Fri, Aug 23, 2013 at 10:48 AM, daan Hoogland wrote:

>This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13771/
>   Review request for cloudstack, Chiradeep Vittal, Dave Cahill, Hugo
> Trippaers, and Sheng Yang.
> By daan Hoogland.
>  *Bugs: * CLOUDSTACK-4346
>  *Repository: * cloudstack-git
> Description
>
> After global search and replace all calls to retrieve ids for networks from 
> URIs using getHost() should be gone. Creating URI should now all use 
> appropriate calls as well so maitaining the way uris are built can now be 
> done centrally.
>
>   Testing
>
> tested with old style uris in regular networks and vpc based networks as well 
> as in nicira based networks
> test build in nonoss but not all code has probably been touched yet. or at 
> least I am unsure of that.
>
>   Diffs
>
>- 
> plugins/hypervisors/baremetal/src/com/cloud/baremetal/networkservice/BaremetaNetworkGuru.java
>(07ee12d)
>- 
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>(195cf40)
>- 
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>(a156ae6)
>- 
> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/OvsVifDriver.java
>(7038d7e)
>- plugins/hypervisors/ovm/src/com/cloud/ovm/hypervisor/OvmResourceBase.java
>(59ba001)
>- 
> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>(5ab2216)
>- 
> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>(ecdec1e)
>- 
> plugins/network-elements/bigswitch-vns/src/com/cloud/network/element/BigSwitchVnsElement.java
>(54623e9)
>- 
> plugins/network-elements/cisco-vnmc/src/com/cloud/network/element/CiscoVnmcElement.java
>(3ae6a08)
>- 
> plugins/network-elements/f5/src/com/cloud/network/resource/F5BigIpResource.java
>(1733712)
>- 
> plugins/network-elements/juniper-srx/src/com/cloud/network/resource/JuniperSrxResource.java
>(3d3d797)
>- 
> plugins/network-elements/nicira-nvp/src/com/cloud/network/element/NiciraNvpElement.java
>(c7d0884)
>- 
> plugins/network-elements/nicira-nvp/src/com/cloud/network/guru/NiciraNvpGuestNetworkGuru.java
>(ff238ed)
>- 
> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsTunnelManagerImpl.java
>(36a807f)
>- server/src/com/cloud/api/ApiResponseHelper.java (c771431)
>- server/src/com/cloud/configuration/ConfigurationManagerImpl.java
>(57dc0b3)
>- server/src/com/cloud/network/ExternalDeviceUsageManagerImpl.java
>(e91dcfa)
>- server/src/com/cloud/network/ExternalFirewallDeviceManagerImpl.java
>(a934024)
>- server/src/com/cloud/network/ExternalLoadBalancerDeviceManagerImpl.java
>(c14d5c7)
>- server/src/com/cloud/network/NetworkManagerImpl.java (00103e3)
>- server/src/com/cloud/network/guru/DirectPodBasedNetworkGuru.java
>(5b87d54)
>- server/src/com/cloud/network/guru/ExternalGuestNetworkGuru.java
>(00598dd)
>- server/src/com/cloud/network/guru/GuestNetworkGuru.java (b0da42f)
>- server/src/com/cloud/network/guru/PrivateNetworkGuru.java (6521cf4)
>- server/src/com/cloud/network/guru/PublicNetworkGuru.java (d109468)
>- 
> server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java
>(ee0d058)
>- utils/src/com/cloud/utils/net/NetUtils.java (05b485b)
>
> View Diff 
>

Re: [DISCUSS/PROPOSAL] Upgrading Driver Model

[Daan Hoogland]

It seems I am the only one not sharing your reservations regarding
OSGi, so let's go for it, John.

I would personally  try to not bother with the hot-loading and
-unloading of drivers and create a install and a drivers directory for
all running processes, where these will be checked upon starting to
update or install any new stuff. If a real life-cycle management is
needed on run-time I would once again urge to go with OSGi.

I would love to help on this not withstanding any objection I have on
the way to go. It seems like fun to implement:)
Daan

On Fri, Aug 23, 2013 at 1:44 AM, Kelven Yang  wrote:
> Spring is not meant to be used as a solution for run-time "plug-ins".
> Darren is correct that Spring XML should be treated as code (ideal place
> for it is the resource section inside the jar). Why we end up the way now
> is mainly for practical reason. Since most of our current pluggable
> features are not yet designed to be fully run-time loadable, most of them
> have compile time linkage to other framework components that are solved at
> loading time by Spring.
>
> Only after we have cleaned up all these tightly coupled loading time
> bindings, can we have a much simpler plugin configuration. And this
> run-time loadable framework does not necessary to be based on any complex
> ones (i.e., OSGi).
>
> Kelven
>
> On 8/21/13 8:42 AM, "Darren Shepherd"  wrote:
>
>>I also agree with this.  Spring XML should always be treated as code not
>>really configuration.  It's not good to have a sysadmin touch spring
>>config and frankly it's just mean to force them to.
>>
>>I would ideally like to see that registering a module is as simple as
>>putting a jar in a directory.  If its in the directory it gets loaded.
>>Then additionally you should have a way such that you can explicitly tell
>>it not to load modules based on some configuration.  That way, if for
>>some reason moving the jar is not possible, you can still disallow it.
>>
>>So for example the directory based approach works well with rpm/deb's so
>>"yum install mycoolplugin" will just place jar somewhere.  But say your
>>troubleshooting or whatever, you don't really want to have to do "yum
>>remove..." just to troubleshoot.  It would be nice to just edit some file
>>and say "plugin.mycoolplugin.load=false" (or env variable or whatever)
>>
>>Darren
>>
>>On Aug 21, 2013, at 6:51 AM, Prasanna Santhanam  wrote:
>>
>>> On Tue, Aug 20, 2013 at 05:43:17PM -0400, John Burwell wrote:
 Leaky Abstraction:  Plugins are registered through a Spring
 configuration file.  In addition to being operator unfriendly (most
 sysadmins are not Spring experts nor do they want to be), we expose
 the core bootstrapping mechanism to operators.  Therefore, a
 misconfiguration could negatively impact the injection/configuration
 of internal management server components.  Essentially handing them
 a loaded shotgun pointed at our right foot.
>>>
>>> This has been my pet-peeve too and I was told you can write properties
>>>files
>>> above the spring contexts to make it simpler for operators to look at.
>>>
>>> Overall a great proposal and look forward to see more concrete steps
>>> that follow on the implementation details.
>>>
>>> --
>>> Prasanna.,
>>>
>>> 
>>> Powered by BigRock.com
>>>
>

Review Request 13798: CLOUDSTACK-1525: [DOC] Added - Accessing System VMs via SSH

[Marty Sweet]

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

Review request for cloudstack.


Bugs: CLOUDSTACK-1525


Repository: cloudstack-git


Description
---

Added two files (accessing-system-vms.xml and images/view-systemvm-details.png) 
which covers details explained in CLOUDSTACK-1525 on how to use private keys to 
access System VMs.
Added menu item to working-with-system-vm.xml


Diffs
-

  docs/en-US/accessing-system-vms.xml PRE-CREATION 
  docs/en-US/images/view-systemvm-details.png PRE-CREATION 
  docs/en-US/working-with-system-vm.xml 70f7dd1 

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


Testing
---

Built successfully with Publican


Thanks,

Marty Sweet

Re: [ACS4.2] Don;t use libvirt 0.10.2+ if you are using NFS as primary storage on KVM

[David Nalley]

Have you filed this on RHT's Bugzilla? If so whats the BZ#? If not,
can you please do so?

--David

On Sun, Aug 25, 2013 at 1:20 AM, Edison Su  wrote:
> There is a "bug" in libvirt 0.10.2+:
>
>  /* Short-circuit if already mounted */
> 385
>  if ((rc = virStorageBackendFileSystemIsMounted(pool)) != 0) {
> 386
>  if (rc == 1) {
> 387
>  virReportError(VIR_ERR_OPERATION_INVALID,
> 388
> _("Target '%s' is already mounted"),
> 389
> pool->def->target.path);
> 390
>  }
> 391
>  return -1;
> 392
>  }
> 393
>
> If the NFS mount point exists on KVM host, and if the libvirt storage is 
> missing for some reason(BUG CLOUDSTACk-2729), then the storage pool will 
> never be created in libvirt unless you stop all the VMs, and umount the mount 
> point.
>
> While, on libvirt 0.9.10, the code handles the situation is different:
>/* Short-circuit if already mounted */
> 409
>  if ((ret = virStorageBackendFileSystemIsMounted(pool)) != 0) {
> 410
>  if (ret < 0)
> 411
>  return -1;
> 412
>  else
> 413
>  return 0;
> 414
>  }
>
> So please stay on libvirt 0.9.10, or ask Redhat to fix the issue.

Re: Review Request 13798: CLOUDSTACK-1525: [DOC] Added - Accessing System VMs via SSH

[David Nalley]

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


Marty: On the new file can you put in a license header. See 
http://www.apache.org/legal/src-headers.html for details on the policy - and 
see any of the other XML files in publican for examples. Can you fix and 
resubmit? 
Otherwise this looks good. 
--David

- David Nalley


On Aug. 25, 2013, 12:23 p.m., Marty Sweet wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13798/
> ---
> 
> (Updated Aug. 25, 2013, 12:23 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Bugs: CLOUDSTACK-1525
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Added two files (accessing-system-vms.xml and 
> images/view-systemvm-details.png) which covers details explained in 
> CLOUDSTACK-1525 on how to use private keys to access System VMs.
> Added menu item to working-with-system-vm.xml
> 
> 
> Diffs
> -
> 
>   docs/en-US/accessing-system-vms.xml PRE-CREATION 
>   docs/en-US/images/view-systemvm-details.png PRE-CREATION 
>   docs/en-US/working-with-system-vm.xml 70f7dd1 
> 
> Diff: https://reviews.apache.org/r/13798/diff/
> 
> 
> Testing
> ---
> 
> Built successfully with Publican
> 
> 
> Thanks,
> 
> Marty Sweet
> 
>

Templates via Vagrant Provider and Veewee

[Ian Duffy]

Hey,

Has anybody tried to use the vagrant provider through veewee in order to
create templates?

Re: Review Request 13798: CLOUDSTACK-1525: [DOC] Added - Accessing System VMs via SSH

[Marty Sweet]

> On Aug. 25, 2013, 3:42 p.m., David Nalley wrote:
> > Marty: On the new file can you put in a license header. See 
> > http://www.apache.org/legal/src-headers.html for details on the policy - 
> > and see any of the other XML files in publican for examples. Can you fix 
> > and resubmit? 
> > Otherwise this looks good. 
> > --David

Hi David,

As far as I can tell this notice is already on lines 7-23 of 
docs/en-US/accessing-system-vms.xml. Do you mean another file?

Thanks,
Marty


- Marty


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


On Aug. 25, 2013, 12:23 p.m., Marty Sweet wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13798/
> ---
> 
> (Updated Aug. 25, 2013, 12:23 p.m.)
> 
> 
> Review request for cloudstack.
> 
> 
> Bugs: CLOUDSTACK-1525
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Added two files (accessing-system-vms.xml and 
> images/view-systemvm-details.png) which covers details explained in 
> CLOUDSTACK-1525 on how to use private keys to access System VMs.
> Added menu item to working-with-system-vm.xml
> 
> 
> Diffs
> -
> 
>   docs/en-US/accessing-system-vms.xml PRE-CREATION 
>   docs/en-US/images/view-systemvm-details.png PRE-CREATION 
>   docs/en-US/working-with-system-vm.xml 70f7dd1 
> 
> Diff: https://reviews.apache.org/r/13798/diff/
> 
> 
> Testing
> ---
> 
> Built successfully with Publican
> 
> 
> Thanks,
> 
> Marty Sweet
> 
>

Review Request 13800: CLOUDSTACK-4487 Offering deletes are not enforced including the waits

[Sowmya Krishnan]

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

Review request for cloudstack and Prasanna Santhanam.


Bugs: CLOUDSTACK-4487


Repository: cloudstack-git


Description
---

Fixes CLOUDSTACK-4487.
Offering deletes are not needed anymore - hence removing them. So also the 
unnecessary waits on the same


Diffs
-

  test/integration/component/test_netscaler_configs.py bcea254 
  test/integration/component/test_netscaler_lb.py 3942f94 
  test/integration/component/test_netscaler_lb_algo.py 477bd69 
  test/integration/component/test_netscaler_lb_sticky.py 1edfd7b 
  test/integration/component/test_netscaler_nw_off.py 84616e1 

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


Testing
---

Tested locally and it passes


Thanks,

Sowmya Krishnan

Re: Templates via Vagrant Provider and Veewee

[Prasanna Santhanam]

All our systemVMs come from veewee + vagrant.

see tools/appliance

On Sun, Aug 25, 2013 at 05:57:50PM +0100, Ian Duffy wrote:
> Hey,
> 
> Has anybody tried to use the vagrant provider through veewee in order to
> create templates?

-- 
Prasanna.,


Powered by BigRock.com

OT: XenServer dev list

[David Nalley]

Folks:

Was asked to point out that XenServer development is now out in the
open and if we need to ask questions/request features or help we can
do so now on their mailing list:

xs-de...@lists.xenserver.org

--David

Re: [DISCUSS/PROPOSAL] Upgrading Driver Model

[John Burwell]

Daan,

Please see my responses in-line below.  The TL;DR is that I am extremely 
skeptical of the complexity and flexibility of OSGi.  My experience with it in 
practice has not been positive.  However, I want to focus on our requirements 
for a driver mechanism, and then determine the best implementation.

Thanks,
-John

On Aug 21, 2013, at 4:14 AM, Daan Hoogland  wrote:

> John,
> 
> You do want 'In-process Installation and Upgrade', 'Introspection' and
> 'Discoverability' says that you do want flexibility. You disqualify
> Spring and OSGi on this quality however.

On the surface, it would appear the OSGi fits into In-process Installation and 
Upgrade.  However, OSGi assumes a consistency attribute that is too rigid for 
CloudStack.   As I understand the specification, when a bundle is upgraded, all 
instances in the container are upgraded simultaneously.  Based on my reading of 
it, there is no way to customize this behavior.  I think we need the upgrade 
process will be eventually consistent where by the underlying driver instance 
for a resource will be upgraded when it is both a consistent and upgradeable 
state. For example, we have 10,000 KVM hosts, and the KVM driver is upgraded. 
9,000 of them are idle, and can take the upgrade immediately.  The other 1,000 
are in some state of operation (creating and destroying VMs, taking snapshots, 
etc).  For these 1,000, we want to the upgrade to happen when they complete 
their current work.  Most importantly, we don't want any work bound for these 
10,000 resources during the upgrade to be lost only delayed.

When I say discoverability, I mean end-users finding drivers to install.  The 
more I think about it, the more I explicitly do not want drivers to depend on 
each other.  Drivers should be self-contained, stateless mechanisms that 
interact with some piece of infrastructure.  I think the path to madness lies 
in having a messy web of cross-vendor driver dependencies.  

> 
> If we can restrict the use of bundles to those that adhere to some
> interfaces we prescribe I don't think either complexity nor dependency
> are an issue.

The only restriction I see is the ability of a bundle to control what is 
publicly exported.  However, I see no way to restrict how bundles depend on 
each other -- opening the door to cross vendor driver dependencies.

> 
> Most every bit of complexity of writing a bundle can be hidden from
> the bundle-developer nowadays. If we can not hide enough it is not an
> option indeed. The main focus of OSGI is life cycle management which
> is exactly what we need. the use that eclipse makes of it is a good
> example not to follow but doesn't disqualify the entire thing.

Personally, I am dubious that a build process can mask complexity.  More 
importantly, I don't like creating designs that require tooling and code 
generation with a veneer of simplicity but actually create a spooky action at a 
distance.  I prefer creating truly simple systems that can be easily 
comprehended.

> 
> The dependency hell is not different from what we have as regular
> monolithical development group. We control what we package and how. A
> valid point is that some libraries might have issues that prevent them
> from being bundled and that needs investigation. So we need to package
> those libraries as bundles ourselves so 3rd parties don't need to. We
> package them now anyway.

In my experience, the dependency management problem is magnified by the added 
hurdle that every dependency be an OSGi bundle.  Many projects do not natively 
ship OSGi bundles, leaving third-parties or the project itself to repackage 
them.  Often OSGi bundled versions are behind the most current project 
releases.  

> 
> The erector set fear you have is just as valid with as without osgi or
> any existing framework.

Agreed.  I prefer inaction on this topic than create said erector set.

> 
> I don't insist on OSGi and I do agree with your initial set of
> requirements. When I read it I think, "let's use OSGi". And I don't
> see anything but fear of the beast in your arguments against it. Maybe
> your fear is just in my perception or maybe it is very valid. I'm not
> perceptible to it after your reply, yet.

To my mind, OSGi is a wonderful idea.  We need it, or something like it, 
standard in the JVM.  However, in practice, it is a difficult beast because it 
working around limitations in the JVM.  When it works, it is awesome until it 
breaks or you hit the dependency hell I described.  If we adopt it, we need to 
ensure it will fit our needs and the functional gain merits taking on the 
burden of its risks.

> 
> regards,
> Daan
> 
> On Wed, Aug 21, 2013 at 9:00 AM, John Burwell  wrote:
>> Daan,
>> 
>> I have the following issues with OSGi:
>> 
>> Complexity:  Building OSGi components adds a tremendous amount of complexity
>> to both the building drivers and debugging runtime issues.  Additionally,
>> OSGi has a much broader feature set than I think CloudStack needs to
>

Re: [DISCUSS/PROPOSAL] Upgrading Driver Model

[John Burwell]

Prasanna,

Generally, Spring configuration files should be packaged in their associated 
JARs with property substitution for configurable items (e.g. connection pool 
min and max sizes).  Unfortunately, Spring does not allow component wiring to 
be modified through property files.  Since plugins are new components, we have 
to expose the underlying Spring configuration files to allow plugins to be 
loaded.  I think our current approach was a solid pragmatic step forward -- a 
nice midpoint between nothing and a complete driver/plugin model.

Thanks,
-John

On Aug 21, 2013, at 9:51 AM, Prasanna Santhanam  wrote:

> On Tue, Aug 20, 2013 at 05:43:17PM -0400, John Burwell wrote:
>> Leaky Abstraction:  Plugins are registered through a Spring
>> configuration file.  In addition to being operator unfriendly (most
>> sysadmins are not Spring experts nor do they want to be), we expose
>> the core bootstrapping mechanism to operators.  Therefore, a
>> misconfiguration could negatively impact the injection/configuration
>> of internal management server components.  Essentially handing them
>> a loaded shotgun pointed at our right foot.
> 
> This has been my pet-peeve too and I was told you can write properties files
> above the spring contexts to make it simpler for operators to look at.
> 
> Overall a great proposal and look forward to see more concrete steps
> that follow on the implementation details.
> 
> -- 
> Prasanna.,
> 
> 
> Powered by BigRock.com
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [DISCUSS/PROPOSAL] Upgrading Driver Model

[John Burwell]

Darren,

Please see my responses in-line below.

Thanks,
-John

On Aug 21, 2013, at 11:42 AM, Darren Shepherd  
wrote:

> I also agree with this.  Spring XML should always be treated as code not 
> really configuration.  It's not good to have a sysadmin touch spring config 
> and frankly it's just mean to force them to.

+1.  I will take it a step further, with Spring 3, I don't even want to see a 
Spring configuration file.  The @Configuration facility allows all wiring to be 
programatic with no Spring dependencies in actual domain objects or service 
code (previous rant on this subject [1]).

[1]: http://markmail.org/thread/2b2egdruxvcognsz

> 
> I would ideally like to see that registering a module is as simple as putting 
> a jar in a directory.  If its in the directory it gets loaded.  Then 
> additionally you should have a way such that you can explicitly tell it not 
> to load modules based on some configuration.  That way, if for some reason 
> moving the jar is not possible, you can still disallow it.

Large agree (as I laid in my original proposal).  However, I would like to 
extend the can to a URL not just a filesystem path.  In a clustered 
environment, operators may want to put their drivers in a S3/Swift bucket or 
simple deploy them as static assets on an HTTP server.  Generally, we need to 
break CloudStack of the assumption that everything is stored in a filesystem.  
I don't see a need to complicate the mechanism with an exclusion list.  If the 
file is present, it will be used.  

I also believe that we will need our own archive format to support the 
deployment of additional capabilities such as UI plugins to actually 
configure/control a plugin, provide internalization resources, and bundle up 
dependencies.  Finally, by default, CloudStack should only accept signed 
components.  We can provide a configuration option to disable this requirement, 
but I would like to see such a mechanism start on the proper security footing 
by requiring it by default.

> 
> So for example the directory based approach works well with rpm/deb's so "yum 
> install mycoolplugin" will just place jar somewhere.  But say your 
> troubleshooting or whatever, you don't really want to have to do "yum 
> remove..." just to troubleshoot.  It would be nice to just edit some file and 
> say "plugin.mycoolplugin.load=false" (or env variable or whatever)

I agree regarding the repository model.  I would like a simple, decentralized 
repository mechanism such as Yum (apt is more powerful but also more difficult 
to configure).  Vendors publish their repositories and operators point to them. 
 We could make the discovery of vendor repositories a little easier by putting 
the repository definition for each GPG key issued to vendors.  As a project, we 
don't want to get near driver distribution.  We only want to define a common 
repository structure, and possibly, provide pointers to vendor repos.

> 
> Darren
> 
> On Aug 21, 2013, at 6:51 AM, Prasanna Santhanam  wrote:
> 
>> On Tue, Aug 20, 2013 at 05:43:17PM -0400, John Burwell wrote:
>>> Leaky Abstraction:  Plugins are registered through a Spring
>>> configuration file.  In addition to being operator unfriendly (most
>>> sysadmins are not Spring experts nor do they want to be), we expose
>>> the core bootstrapping mechanism to operators.  Therefore, a
>>> misconfiguration could negatively impact the injection/configuration
>>> of internal management server components.  Essentially handing them
>>> a loaded shotgun pointed at our right foot.
>> 
>> This has been my pet-peeve too and I was told you can write properties files
>> above the spring contexts to make it simpler for operators to look at.
>> 
>> Overall a great proposal and look forward to see more concrete steps
>> that follow on the implementation details.
>> 
>> -- 
>> Prasanna.,
>> 
>> 
>> Powered by BigRock.com
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [DISCUSS/PROPOSAL] Upgrading Driver Model

[John Burwell]

Daan,

I think I mentioned in my proposal to defer hot loading/unloading to a later 
release.  It is a hard issue, and not required to address the current pain 
points.

Thanks,
-John

On Aug 25, 2013, at 7:43 AM, Daan Hoogland  wrote:

> It seems I am the only one not sharing your reservations regarding
> OSGi, so let's go for it, John.
> 
> I would personally  try to not bother with the hot-loading and
> -unloading of drivers and create a install and a drivers directory for
> all running processes, where these will be checked upon starting to
> update or install any new stuff. If a real life-cycle management is
> needed on run-time I would once again urge to go with OSGi.
> 
> I would love to help on this not withstanding any objection I have on
> the way to go. It seems like fun to implement:)
> Daan
> 
> On Fri, Aug 23, 2013 at 1:44 AM, Kelven Yang  wrote:
>> Spring is not meant to be used as a solution for run-time "plug-ins".
>> Darren is correct that Spring XML should be treated as code (ideal place
>> for it is the resource section inside the jar). Why we end up the way now
>> is mainly for practical reason. Since most of our current pluggable
>> features are not yet designed to be fully run-time loadable, most of them
>> have compile time linkage to other framework components that are solved at
>> loading time by Spring.
>> 
>> Only after we have cleaned up all these tightly coupled loading time
>> bindings, can we have a much simpler plugin configuration. And this
>> run-time loadable framework does not necessary to be based on any complex
>> ones (i.e., OSGi).
>> 
>> Kelven
>> 
>> On 8/21/13 8:42 AM, "Darren Shepherd"  wrote:
>> 
>>> I also agree with this.  Spring XML should always be treated as code not
>>> really configuration.  It's not good to have a sysadmin touch spring
>>> config and frankly it's just mean to force them to.
>>> 
>>> I would ideally like to see that registering a module is as simple as
>>> putting a jar in a directory.  If its in the directory it gets loaded.
>>> Then additionally you should have a way such that you can explicitly tell
>>> it not to load modules based on some configuration.  That way, if for
>>> some reason moving the jar is not possible, you can still disallow it.
>>> 
>>> So for example the directory based approach works well with rpm/deb's so
>>> "yum install mycoolplugin" will just place jar somewhere.  But say your
>>> troubleshooting or whatever, you don't really want to have to do "yum
>>> remove..." just to troubleshoot.  It would be nice to just edit some file
>>> and say "plugin.mycoolplugin.load=false" (or env variable or whatever)
>>> 
>>> Darren
>>> 
>>> On Aug 21, 2013, at 6:51 AM, Prasanna Santhanam  wrote:
>>> 
 On Tue, Aug 20, 2013 at 05:43:17PM -0400, John Burwell wrote:
> Leaky Abstraction:  Plugins are registered through a Spring
> configuration file.  In addition to being operator unfriendly (most
> sysadmins are not Spring experts nor do they want to be), we expose
> the core bootstrapping mechanism to operators.  Therefore, a
> misconfiguration could negatively impact the injection/configuration
> of internal management server components.  Essentially handing them
> a loaded shotgun pointed at our right foot.
 
 This has been my pet-peeve too and I was told you can write properties
 files
 above the spring contexts to make it simpler for operators to look at.
 
 Overall a great proposal and look forward to see more concrete steps
 that follow on the implementation details.
 
 --
 Prasanna.,
 
 
 Powered by BigRock.com
 
>> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [DISCUSS/PROPOSAL] Upgrading Driver Model

[John Burwell]

Kelven,

Please don't take my proposal as a criticism of the approach taken in 4.1.  I 
think the current model is a big improvement over the previous approach.  Given 
the time constraints and ambitions of that work, I think it was a solid, 
pragmatic first step.  I believe we are at a point to assess our needs, and 
determine a good next step that (hopefully) further improves the model.

Thanks,
-John

On Aug 22, 2013, at 7:44 PM, Kelven Yang  wrote:

> Spring is not meant to be used as a solution for run-time "plug-ins".
> Darren is correct that Spring XML should be treated as code (ideal place
> for it is the resource section inside the jar). Why we end up the way now
> is mainly for practical reason. Since most of our current pluggable
> features are not yet designed to be fully run-time loadable, most of them
> have compile time linkage to other framework components that are solved at
> loading time by Spring.
> 
> Only after we have cleaned up all these tightly coupled loading time
> bindings, can we have a much simpler plugin configuration. And this
> run-time loadable framework does not necessary to be based on any complex
> ones (i.e., OSGi).
> 
> Kelven 
> 
> On 8/21/13 8:42 AM, "Darren Shepherd"  wrote:
> 
>> I also agree with this.  Spring XML should always be treated as code not
>> really configuration.  It's not good to have a sysadmin touch spring
>> config and frankly it's just mean to force them to.
>> 
>> I would ideally like to see that registering a module is as simple as
>> putting a jar in a directory.  If its in the directory it gets loaded.
>> Then additionally you should have a way such that you can explicitly tell
>> it not to load modules based on some configuration.  That way, if for
>> some reason moving the jar is not possible, you can still disallow it.
>> 
>> So for example the directory based approach works well with rpm/deb's so
>> "yum install mycoolplugin" will just place jar somewhere.  But say your
>> troubleshooting or whatever, you don't really want to have to do "yum
>> remove..." just to troubleshoot.  It would be nice to just edit some file
>> and say "plugin.mycoolplugin.load=false" (or env variable or whatever)
>> 
>> Darren
>> 
>> On Aug 21, 2013, at 6:51 AM, Prasanna Santhanam  wrote:
>> 
>>> On Tue, Aug 20, 2013 at 05:43:17PM -0400, John Burwell wrote:
 Leaky Abstraction:  Plugins are registered through a Spring
 configuration file.  In addition to being operator unfriendly (most
 sysadmins are not Spring experts nor do they want to be), we expose
 the core bootstrapping mechanism to operators.  Therefore, a
 misconfiguration could negatively impact the injection/configuration
 of internal management server components.  Essentially handing them
 a loaded shotgun pointed at our right foot.
>>> 
>>> This has been my pet-peeve too and I was told you can write properties
>>> files
>>> above the spring contexts to make it simpler for operators to look at.
>>> 
>>> Overall a great proposal and look forward to see more concrete steps
>>> that follow on the implementation details.
>>> 
>>> -- 
>>> Prasanna.,
>>> 
>>> 
>>> Powered by BigRock.com
>>> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Review Request 13771: CLOUDSTACK-4346 replace URI getHost() and create(String) calls

[Dave Cahill]

Hi Daan,

I started to take a look - the diff is ~10k lines long, most of which
appears to be whitespace changes.

Are the whitespace changes important? Without them, the patch might be a
lot easier to review.

Thanks,
Dave.




On Sun, Aug 25, 2013 at 7:37 PM, Daan Hoogland wrote:

> Sheng, Dave, Chiradeep and Hugo,
>
> Can you please review this? In my experience the time that this patch will
> expire is rather short, I have been resolving conflicts on this a lot. If
> now, given the 4.2 release is inconvenient, I would like to set a window
> for submitting this in which I will rebase it a couple of times so as to
> make sure it works in the end.
>
> thanks,
> Daan
>
>
> On Fri, Aug 23, 2013 at 10:48 AM, daan Hoogland 
> wrote:
>
>>This is an automatically generated e-mail. To reply, visit:
>> https://reviews.apache.org/r/13771/
>>   Review request for cloudstack, Chiradeep Vittal, Dave Cahill, Hugo
>> Trippaers, and Sheng Yang.
>> By daan Hoogland.
>>  *Bugs: * CLOUDSTACK-4346
>>  *Repository: * cloudstack-git
>> Description
>>
>> After global search and replace all calls to retrieve ids for networks from 
>> URIs using getHost() should be gone. Creating URI should now all use 
>> appropriate calls as well so maitaining the way uris are built can now be 
>> done centrally.
>>
>>   Testing
>>
>> tested with old style uris in regular networks and vpc based networks as 
>> well as in nicira based networks
>> test build in nonoss but not all code has probably been touched yet. or at 
>> least I am unsure of that.
>>
>>   Diffs
>>
>>- 
>> plugins/hypervisors/baremetal/src/com/cloud/baremetal/networkservice/BaremetaNetworkGuru.java
>>(07ee12d)
>>- 
>> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>>(195cf40)
>>- 
>> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>>(a156ae6)
>>- 
>> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/OvsVifDriver.java
>>(7038d7e)
>>- 
>> plugins/hypervisors/ovm/src/com/cloud/ovm/hypervisor/OvmResourceBase.java
>>(59ba001)
>>- 
>> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>>(5ab2216)
>>- 
>> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>>(ecdec1e)
>>- 
>> plugins/network-elements/bigswitch-vns/src/com/cloud/network/element/BigSwitchVnsElement.java
>>(54623e9)
>>- 
>> plugins/network-elements/cisco-vnmc/src/com/cloud/network/element/CiscoVnmcElement.java
>>(3ae6a08)
>>- 
>> plugins/network-elements/f5/src/com/cloud/network/resource/F5BigIpResource.java
>>(1733712)
>>- 
>> plugins/network-elements/juniper-srx/src/com/cloud/network/resource/JuniperSrxResource.java
>>(3d3d797)
>>- 
>> plugins/network-elements/nicira-nvp/src/com/cloud/network/element/NiciraNvpElement.java
>>(c7d0884)
>>- 
>> plugins/network-elements/nicira-nvp/src/com/cloud/network/guru/NiciraNvpGuestNetworkGuru.java
>>(ff238ed)
>>- 
>> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsTunnelManagerImpl.java
>>(36a807f)
>>- server/src/com/cloud/api/ApiResponseHelper.java (c771431)
>>- server/src/com/cloud/configuration/ConfigurationManagerImpl.java
>>(57dc0b3)
>>- server/src/com/cloud/network/ExternalDeviceUsageManagerImpl.java
>>(e91dcfa)
>>- server/src/com/cloud/network/ExternalFirewallDeviceManagerImpl.java
>>(a934024)
>>- server/src/com/cloud/network/ExternalLoadBalancerDeviceManagerImpl.java
>>(c14d5c7)
>>- server/src/com/cloud/network/NetworkManagerImpl.java (00103e3)
>>- server/src/com/cloud/network/guru/DirectPodBasedNetworkGuru.java
>>(5b87d54)
>>- server/src/com/cloud/network/guru/ExternalGuestNetworkGuru.java
>>(00598dd)
>>- server/src/com/cloud/network/guru/GuestNetworkGuru.java (b0da42f)
>>- server/src/com/cloud/network/guru/PrivateNetworkGuru.java (6521cf4)
>>- server/src/com/cloud/network/guru/PublicNetworkGuru.java (d109468)
>>- 
>> server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java
>>(ee0d058)
>>- utils/src/com/cloud/utils/net/NetUtils.java (05b485b)
>>
>> View Diff 
>>
>
>

Re: System VM stuck in Expunging State

[Mike Tutkowski]

I'm not seeing any recognition from CS that this VM exists at all...no
print outs in the console at least.


On Sat, Aug 24, 2013 at 7:08 PM, Marcus Sorensen wrote:

> Yes, there are expunge global settings.
> On Aug 24, 2013 6:35 PM, "Mike Tutkowski" 
> wrote:
>
> > That would be great.
> >
> > Is there a global setting for that, Marcus?
> >
> > Thanks
> >
> >
> > On Sat, Aug 24, 2013 at 5:26 PM, Marcus Sorensen  > >wrote:
> >
> > > It might be better to take a look and see why it fails to expunge. In
> > > the past I've seen things like null pointers that have led to fixed
> > > bugs. You can turn down the expunge intervals to get it to try every
> > > 60 seconds or something, so you can watch what goes wrong.
> > >
> > > On Sat, Aug 24, 2013 at 3:53 PM, Mike Tutkowski
> > >  wrote:
> > > > Hi,
> > > >
> > > > I have a VM (SSVM) that's stuck in the Expunging State.
> > > >
> > > > It's not interfering with anything that I'm aware of as I have
> another
> > > SSVM
> > > > up and running just fine, but I'd like to remove it from the
> database.
> > > >
> > > > Does anyone know which table/tables I need to modify to make sure I
> get
> > > rid
> > > > of all of the necessary data?
> > > >
> > > > Thanks!
> > > >
> > > > --
> > > > *Mike Tutkowski*
> > > > *Senior CloudStack Developer, SolidFire Inc.*
> > > > e: mike.tutkow...@solidfire.com
> > > > o: 303.746.7302
> > > > Advancing the way the world uses the
> > > > cloud
> > > > *™*
> > >
> >
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud
> > *™*
> >
>



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

Re: Review Request 13800: CLOUDSTACK-4487 Offering deletes are not enforced including the waits

[Prasanna Santhanam]

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

Ship it!


- Prasanna Santhanam


On Aug. 25, 2013, 5:10 p.m., Sowmya Krishnan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13800/
> ---
> 
> (Updated Aug. 25, 2013, 5:10 p.m.)
> 
> 
> Review request for cloudstack and Prasanna Santhanam.
> 
> 
> Bugs: CLOUDSTACK-4487
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixes CLOUDSTACK-4487.
> Offering deletes are not needed anymore - hence removing them. So also the 
> unnecessary waits on the same
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_netscaler_configs.py bcea254 
>   test/integration/component/test_netscaler_lb.py 3942f94 
>   test/integration/component/test_netscaler_lb_algo.py 477bd69 
>   test/integration/component/test_netscaler_lb_sticky.py 1edfd7b 
>   test/integration/component/test_netscaler_nw_off.py 84616e1 
> 
> Diff: https://reviews.apache.org/r/13800/diff/
> 
> 
> Testing
> ---
> 
> Tested locally and it passes
> 
> 
> Thanks,
> 
> Sowmya Krishnan
> 
>

Re: Review Request 13800: CLOUDSTACK-4487 Offering deletes are not enforced including the waits

[ASF Subversion and Git Services]

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


Commit f724c912969fb4c6fcfe02d48d31afcd82480b43 in branch refs/heads/master 
from Sowmya Krishnan
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=f724c91 ]

CLOUDSTACK-4487: No need to delete offerings or wait on offering cleanup

Signed-off-by: Prasanna Santhanam 
(cherry picked from commit bc5b6ae0e41a04ab2c892ce53199c1d7f1d0902c)


- ASF Subversion and Git Services


On Aug. 25, 2013, 5:10 p.m., Sowmya Krishnan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13800/
> ---
> 
> (Updated Aug. 25, 2013, 5:10 p.m.)
> 
> 
> Review request for cloudstack and Prasanna Santhanam.
> 
> 
> Bugs: CLOUDSTACK-4487
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixes CLOUDSTACK-4487.
> Offering deletes are not needed anymore - hence removing them. So also the 
> unnecessary waits on the same
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_netscaler_configs.py bcea254 
>   test/integration/component/test_netscaler_lb.py 3942f94 
>   test/integration/component/test_netscaler_lb_algo.py 477bd69 
>   test/integration/component/test_netscaler_lb_sticky.py 1edfd7b 
>   test/integration/component/test_netscaler_nw_off.py 84616e1 
> 
> Diff: https://reviews.apache.org/r/13800/diff/
> 
> 
> Testing
> ---
> 
> Tested locally and it passes
> 
> 
> Thanks,
> 
> Sowmya Krishnan
> 
>

Re: Review Request 13800: CLOUDSTACK-4487 Offering deletes are not enforced including the waits

[ASF Subversion and Git Services]

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


Commit bc5b6ae0e41a04ab2c892ce53199c1d7f1d0902c in branch 
refs/heads/4.2-forward from Sowmya Krishnan
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=bc5b6ae ]

CLOUDSTACK-4487: No need to delete offerings or wait on offering cleanup

Signed-off-by: Prasanna Santhanam 


- ASF Subversion and Git Services


On Aug. 25, 2013, 5:10 p.m., Sowmya Krishnan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/13800/
> ---
> 
> (Updated Aug. 25, 2013, 5:10 p.m.)
> 
> 
> Review request for cloudstack and Prasanna Santhanam.
> 
> 
> Bugs: CLOUDSTACK-4487
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Fixes CLOUDSTACK-4487.
> Offering deletes are not needed anymore - hence removing them. So also the 
> unnecessary waits on the same
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_netscaler_configs.py bcea254 
>   test/integration/component/test_netscaler_lb.py 3942f94 
>   test/integration/component/test_netscaler_lb_algo.py 477bd69 
>   test/integration/component/test_netscaler_lb_sticky.py 1edfd7b 
>   test/integration/component/test_netscaler_nw_off.py 84616e1 
> 
> Diff: https://reviews.apache.org/r/13800/diff/
> 
> 
> Testing
> ---
> 
> Tested locally and it passes
> 
> 
> Thanks,
> 
> Sowmya Krishnan
> 
>

Review Request 13803: CLOUDSTACK-4491: Added NS setup

[Sowmya Krishnan]

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

Review request for cloudstack, venkata swamy babu  budumuru and Prasanna 
Santhanam.


Bugs: CLOUDSTACK-4491


Repository: cloudstack-git


Description
---

test_netscaler_config.TestGuestNetworkShutDown
Netscaler addition was never included in this class. Added the same now.


Diffs
-

  test/integration/component/test_netscaler_configs.py df4e707 

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


Testing
---

Tested locally - test passes


Thanks,

Sowmya Krishnan

Re: System VMs not running

[Amit Das]

Thanks Nitin. This helped.

Setting the verbose mode & running the script manually showed me
'Permission Denied' error on vhd-util file.

I had to change the permission on vhd-util for things to work.

Regards,
Amit
*CloudByte Inc.* 


On Fri, Aug 23, 2013 at 3:56 PM, Nitin Mehta  wrote:

> Donal - nice blog.
> One more thing you might want to add is that for these shell scripts you
> can uncomment the set -x option in the scripts and run them yourself.
> SmLog sometimes might not narrow down the issue but has the info about the
> script path and the arguments. Once you uncomment the set -x and run it
> yourself you can see the verbose output of the run.
> Or better just uncomment the set -x option in the script and rerun the
> entire operation. You should see a verbose output :)
>
> Thanks,
> -Nitin
>
> On 23/08/13 2:56 PM, "Amit Das"  wrote:
>
> >Thanks Donal for the site. It explains the issue pretty well.
> >
> >I had already gone through the SMLog by observing some already raised jira
> >tickets. However, did not understand much then.
> >
> >Now i can see some *difference *between the logs on your blog vs. the ones
> >in my XenServer.
> >
> >[28437] 2013-08-23 07:37:28.703267   VMOPS enter
> > copy_vhd_from_secondarystorage 
> >[28437] 2013-08-23 07:37:28.703390  ['bash', '/opt/xensource/bin/*
> >copy_vhd_from_secondarystorage.sh*', '10.10.171.155:*
> >/export/secondary/template/tmpl/1/1/*',
> >'b45c8c85-4e55-983c-cb16-4c2f2356951c',
> >'cloud-ebed83d7-afde-4470-b867-312bad7c21c7']
> >[28437] 2013-08-23 07:37:28.826465  SUCCESS
> >[28437] 2013-08-23 07:37:28.826691   VMOPS exit
> > copy_vhd_from_secondarystorage 
> >[28463] 2013-08-23 07:37:29.787555   VMOPS enter
> >kill_copy_process
> >
> >[28463] 2013-08-23 07:37:29.787680  ['bash',
> >'/opt/xensource/bin/kill_copy_process.sh', '']
> >[28463] 2013-08-23 07:37:29.800439  SUCCESS
> >[28463] 2013-08-23 07:37:29.800565   VMOPS exit  kill_copy_process
> >
> >
> >The difference that I find here is the .vhd template is never mentioned in
> >the copy_vhd_from_secondarystorage.sh
> >Not sure if logic has changed.
> >
> >
> >Regards,
> >Amit
> >*CloudByte Inc.* 
> >
> >
> >On Fri, Aug 23, 2013 at 1:59 PM, Donal Lafferty
> >wrote:
> >
> >> HI Amit,
> >>
> >> Still having problems?
> >>
> >> Probably time to have a look at the logs on XenServer.  There's a guide
> >>
> >>
> http://dlafferty.blogspot.co.uk/2013/08/using-cloudstacks-log-files-xense
> >>rver.html
> >>
> >> DL
> >>
> >> > -Original Message-
> >> > From: Amit Das [mailto:amit@cloudbyte.com]
> >> > Sent: 23 August 2013 05:52
> >> > To: dev@cloudstack.apache.org; aemne...@gmail.com
> >> > Subject: Re: System VMs not running
> >> >
> >> > Yes. The step was missed.
> >> >
> >> > However, i tried out the steps on 'vhd_util' later & restarted nfs,
> >> rpcbind &
> >> > management services.
> >> >
> >> > Do i need to reset the DB as well ?
> >> >
> >> > Is there any work around for this ?
> >> >
> >> > Regards,
> >> > Amit
> >> > *CloudByte Inc.* 
> >> >
> >> >
> >> > On Fri, Aug 23, 2013 at 9:56 AM, Ahmad Emneina 
> >> > wrote:
> >> >
> >> > > this usually indicates that you missed the step where you prep
> >> > > vhd-util on the hypervisor.
> >> > >
> >> > >
> >> > > On Thu, Aug 22, 2013 at 9:18 PM, Amit Das 
> >> > wrote:
> >> > >
> >> > > > The step worked fine after seeding system VM into secondary
> >>storage
> >> > > > location.
> >> > > >
> >> > > > However, i see the next error:
> >> > > >
> >> > > > WARN  [xen.resource.CitrixResourceBase] (DirectAgent-446:) Catch
> >> > > Exception
> >> > > > com.cloud.utils.exception.CloudRuntimeException on
> >> > > > host:21318624-cfd9-412d-aeb4-b1418424f287 for template: nfs://
> >> > > > 10.10.171.155/export/secondary/template/tmpl/1/1/ due to
> >> > > > com.cloud.utils.exception.CloudRuntimeException: *can not create
> >>vdi
> >> > > > in
> >> > > sr
> >> > > > *
> >> > > > b45c8c85-4e55-983c-cb16-4c2f2356951c
> >> > > > com.cloud.utils.exception.CloudRuntimeException: can not create
> >>vdi
> >> > > > in sr b45c8c85-4e55-983c-cb16-4c2f2356951c
> >> > > > at
> >> > > >
> >> > > >
> >> > >
> >> > com.cloud.hypervisor.xen.resource.CitrixResourceBase.copy_vhd_from_sec
> >> > > ondarystorage(CitrixResourceBase.java:2707)
> >> > > >
> >> > > > ...
> >> > > >
> >> > > > 2013-08-23 09:46:12,815 DEBUG [agent.transport.Request]
> >> > > (secstorage-1:null)
> >> > > > Seq 12-90517578: Sending  { Cmd , MgmtId: 268749071320359, via:
> >>12,
> >> Ver:
> >> > > > v1, Flags: 100111, [{"storage.*PrimaryStorageDownloadCommand*
> >> > > >
> >> > > >
> >> > >
> >>":{"localPath":"/mnt/15370e0e-c8ae-32bb-94e1-74f1fad0cce3","poolUuid":
> >> > >
> >>"15370e0e-c8ae-32bb-94e1-74f1fad0cce3","poolId":211,"primaryPool":{"id
> >> > >
> >>":211,"uuid":"15370e0e-c8ae-32bb-94e1-74f1fad0cce3","host":"10.10.171.
> >> > >
> >>15

Re: registerSSHKeyPair

[Harikrishna Patnala]

I have created a bug ticket for tracking 
https://issues.apache.org/jira/browse/CLOUDSTACK-4493 and this needs to be 
resolved.

-Harikrishna

On 23-Aug-2013, at 6:41 PM, Chip Childers  wrote:

> On Thu, Aug 22, 2013 at 08:33:42AM -0400, Sebastien Goasguen wrote:
>> 
>> On Aug 22, 2013, at 7:57 AM, Harikrishna Patnala 
>>  wrote:
>> 
>>> We generate docs based on the response object. Since we use the same 
>>> response object for create/register ssh key pair APIs, doc shows same 
>>> return values.
>>> We follow this for all API responses. Say list virtual machine API response 
>>> does not include all the fields that are in api doc.
>>> 
>> 
>> I understand, but that's a case where it's misleading. Maybe the response 
>> objects should not be the same after all.
> 
> +1 - this is another example of where the CS API leaks implementation
> details all over the place, in this case manifested as a documentation
> issue.

Re: [ACS42] Closing resolved issues

[Nitin Mehta]

Sudha - I understand, but its always better that another pair of eyes look
into it. 
The fixer has already verified the fix when he/she is committing it but
devs are always biased or looking for happy cases only :).
I have numerous bugs filed against myself as well, so better someone else
verifies them. If you disagree, I can close them right away.

Thanks,
-Nitin

On 24/08/13 3:42 AM, "Sudha Ponnaganti" 
wrote:

>Even so, expectation is those would also be picked up and closed.
>
>From: Alena Prokharchyk
>Sent: Friday, August 23, 2013 3:08 PM
>To: dev@cloudstack.apache.org; Sudha Ponnaganti
>Subject: Re: [ACS42] Closing resolved issues
>
>Sudha, I think we should change the filter to exclude the bugs when the
>reporter and assignee is the same person. Like I sometimes file bugs for
>myself, and in this case the bug should be Verified/Closed by somebody
>else.
>Do you think its a valid suggestion?
>
>Thank you,
>-Alena.
>
>From: Sudha Ponnaganti
>mailto:sudha.ponnaga...@citrix.com>>
>Reply-To: "dev@cloudstack.apache.org"
>mailto:dev@cloudstack.apache.org>>
>Date: Friday, August 23, 2013 11:46 AM
>To: "dev@cloudstack.apache.org"
>mailto:dev@cloudstack.apache.org>>
>Subject: [ACS42] Closing resolved issues
>
>Hi All,
>
>Community has closed 1477 defects in 4.2. However still another 274
>resolved defects are pending to be closed. Please validate the fix done
>for the issue reported by you and close it if you are happy with the fix.
>If issue is not fixed, pl reopen it so whoever fixed would get a chance
>to review it again before release.  Below are outstanding items
>
>project = CLOUDSTACK AND issuetype = Bug AND fixVersion in ("4.2.0",
>"4.2.1") AND status = Resolved
>
>Reporter  Total
>Abhinandan Prateek  2
>Abhinav Roy   1
>Ahmad Emneina   2
>Alena Prokharchyk  18
>angeline shen3
>Anthony Xu4
>Bharat Kumar10
>Brian Angus1
>Brian Federle 1
>Brian Spindler1
>Chandan Purushothama   13
>Chiradeep Vittal   1
>Dave Brosius  1
>Dave Cahill  1
>David Noland 1
>david vz1
>Devdeep Singh 3
>Diogo Monteiro1
>edison su 1
>Fang Wang  4
>Francois Gaudreault   1
>frank zhang1
>Gaurav Aradhye   1
>Harikrishna Patnala 7
>Hiroaki Kawai 2
>Hongtu Zang  2
>Hugo Trippaers 1
>ilya musayev  3
>Isaac Chiang   3
>Jayapal Reddy   6
>Jessica Tomechak2
>Jessica Wang  2
>John Burwell  3
>Kelven Yang   2
>Kishan Kavala 9
>Koushik Das4
>Likitha Shetty 6
>Max Clark1
>Mice Xia   1
>Milamber2
>Min Chen1
>Minying Bao   1
>Murali Reddy 9
>Nick Wales  1
>Nitin Mehta20
>Parth Jagirdar1
>Paul Angus  1
>Pavan Kumar Bandarupally  1
>Prachi Damle  8
>Pranav Saxena  1
>Prasanna Santhanam 2
>Radhika Nair   4
>Rajesh Battala   4
>Ram Ganesh  2
>Rayees Namathponnan9
>roxanne chang  1
>sadhu suresh 5
>Sailaja Mada   6
>Saksham Srivastava 7
>Sangeetha Hariharan  20
>Sanjay Tripathi  1
>Sanjeev N   3
>Sateesh Chodapuneedi 11
>sebastien goasguen1
>Shane Witbeck  1
>Shanker Balan   1
>Sharad Yadav 1
>Sheng Yang 2
>shweta agarwal4
>Simon Weller 1
>Sowmya Krishnan4
>Srikanteswararao Talluri2
>Toshiaki Hatano2
>Venkata Siva Vijayendra Bhamidipati  4
>venkata swamybabu budumuru   3
>Grand Total274
>
>Thanks
>/sudha
>

Re: Review Request 13771: CLOUDSTACK-4346 replace URI getHost() and create(String) calls

[Daan Hoogland]

You are right, I incorporated Alex' auto format for eclipse. Sorry for
that. Being sick at home today, I will try to submit an update without it
tomorrow.

regards,



On Mon, Aug 26, 2013 at 6:04 AM, Dave Cahill  wrote:

> Hi Daan,
>
> I started to take a look - the diff is ~10k lines long, most of which
> appears to be whitespace changes.
>
> Are the whitespace changes important? Without them, the patch might be a
> lot easier to review.
>
> Thanks,
> Dave.
>
>
>
>
> On Sun, Aug 25, 2013 at 7:37 PM, Daan Hoogland wrote:
>
>> Sheng, Dave, Chiradeep and Hugo,
>>
>> Can you please review this? In my experience the time that this patch
>> will expire is rather short, I have been resolving conflicts on this a lot.
>> If now, given the 4.2 release is inconvenient, I would like to set a window
>> for submitting this in which I will rebase it a couple of times so as to
>> make sure it works in the end.
>>
>> thanks,
>> Daan
>>
>>
>> On Fri, Aug 23, 2013 at 10:48 AM, daan Hoogland 
>> wrote:
>>
>>>This is an automatically generated e-mail. To reply, visit:
>>> https://reviews.apache.org/r/13771/
>>>   Review request for cloudstack, Chiradeep Vittal, Dave Cahill, Hugo
>>> Trippaers, and Sheng Yang.
>>> By daan Hoogland.
>>>  *Bugs: * CLOUDSTACK-4346
>>>  *Repository: * cloudstack-git
>>> Description
>>>
>>> After global search and replace all calls to retrieve ids for networks from 
>>> URIs using getHost() should be gone. Creating URI should now all use 
>>> appropriate calls as well so maitaining the way uris are built can now be 
>>> done centrally.
>>>
>>>   Testing
>>>
>>> tested with old style uris in regular networks and vpc based networks as 
>>> well as in nicira based networks
>>> test build in nonoss but not all code has probably been touched yet. or at 
>>> least I am unsure of that.
>>>
>>>   Diffs
>>>
>>>- 
>>> plugins/hypervisors/baremetal/src/com/cloud/baremetal/networkservice/BaremetaNetworkGuru.java
>>>(07ee12d)
>>>- 
>>> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/BridgeVifDriver.java
>>>(195cf40)
>>>- 
>>> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java
>>>(a156ae6)
>>>- 
>>> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/OvsVifDriver.java
>>>(7038d7e)
>>>- 
>>> plugins/hypervisors/ovm/src/com/cloud/ovm/hypervisor/OvmResourceBase.java
>>>(59ba001)
>>>- 
>>> plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
>>>(5ab2216)
>>>- 
>>> plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java
>>>(ecdec1e)
>>>- 
>>> plugins/network-elements/bigswitch-vns/src/com/cloud/network/element/BigSwitchVnsElement.java
>>>(54623e9)
>>>- 
>>> plugins/network-elements/cisco-vnmc/src/com/cloud/network/element/CiscoVnmcElement.java
>>>(3ae6a08)
>>>- 
>>> plugins/network-elements/f5/src/com/cloud/network/resource/F5BigIpResource.java
>>>(1733712)
>>>- 
>>> plugins/network-elements/juniper-srx/src/com/cloud/network/resource/JuniperSrxResource.java
>>>(3d3d797)
>>>- 
>>> plugins/network-elements/nicira-nvp/src/com/cloud/network/element/NiciraNvpElement.java
>>>(c7d0884)
>>>- 
>>> plugins/network-elements/nicira-nvp/src/com/cloud/network/guru/NiciraNvpGuestNetworkGuru.java
>>>(ff238ed)
>>>- 
>>> plugins/network-elements/ovs/src/com/cloud/network/ovs/OvsTunnelManagerImpl.java
>>>(36a807f)
>>>- server/src/com/cloud/api/ApiResponseHelper.java (c771431)
>>>- server/src/com/cloud/configuration/ConfigurationManagerImpl.java
>>>(57dc0b3)
>>>- server/src/com/cloud/network/ExternalDeviceUsageManagerImpl.java
>>>(e91dcfa)
>>>- server/src/com/cloud/network/ExternalFirewallDeviceManagerImpl.java
>>>(a934024)
>>>- server/src/com/cloud/network/ExternalLoadBalancerDeviceManagerImpl.java
>>>(c14d5c7)
>>>- server/src/com/cloud/network/NetworkManagerImpl.java (00103e3)
>>>- server/src/com/cloud/network/guru/DirectPodBasedNetworkGuru.java
>>>(5b87d54)
>>>- server/src/com/cloud/network/guru/ExternalGuestNetworkGuru.java
>>>(00598dd)
>>>- server/src/com/cloud/network/guru/GuestNetworkGuru.java (b0da42f)
>>>- server/src/com/cloud/network/guru/PrivateNetworkGuru.java (6521cf4)
>>>- server/src/com/cloud/network/guru/PublicNetworkGuru.java (d109468)
>>>- 
>>> server/src/com/cloud/network/router/VpcVirtualNetworkApplianceManagerImpl.java
>>>(ee0d058)
>>>- utils/src/com/cloud/utils/net/NetUtils.java (05b485b)
>>>
>>> View Diff 
>>>
>>
>>
>