Right...yeah, I didn't mean we'd commit to 4.2, but maybe I should work off of 4.2 since master seems to be un-stable in this regard.
I plan to set up a machine in the lab tomorrow with Ubuntu 12.04 from scratch to see if it works when I start clean, but - if it doesn't - I should just use 4.2 for development. On Mon, Oct 7, 2013 at 7:05 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > We can't. This patch will never see 4.2. You can still start working on > your plugin on 4.2, but the change represented by this patch can only go > into master. > On Oct 7, 2013 5:01 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> > wrote: > >> So, now that I'm getting back to this, do you think I should just try to >> make this work with 4.2 (like we originally talked about)? >> >> I updated again from master, rebuilt, redeployed DEBs and still get this >> JNA error message: >> >> log4j:WARN No appenders could be found for logger >> (org.apache.commons.httpclient.params.DefaultHttpParams). >> log4j:WARN Please initialize the log4j system properly. >> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for >> more info. >> java.lang.reflect.InvocationTargetException >> 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:606) >> at >> org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:243) >> Caused by: java.lang.UnsatisfiedLinkError: Can't obtain updateLastError >> method for class com.sun.jna.Native >> at com.sun.jna.Native.initIDs(Native Method) >> at com.sun.jna.Native.<clinit>(Native.java:139) >> at org.libvirt.jna.Libvirt.<clinit>(Unknown Source) >> at org.libvirt.Library.<clinit>(Unknown Source) >> at org.libvirt.Connect.<init>(Unknown Source) >> at >> com.cloud.hypervisor.kvm.resource.LibvirtConnection.getConnection(LibvirtConnection.java:44) >> at >> com.cloud.hypervisor.kvm.resource.LibvirtConnection.getConnection(LibvirtConnection.java:37) >> at >> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.configure(LibvirtComputingResource.java:733) >> at com.cloud.agent.Agent.<init>(Agent.java:161) >> at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:415) >> at >> com.cloud.agent.AgentShell.launchAgentFromClassInfo(AgentShell.java:370) >> at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:351) >> at com.cloud.agent.AgentShell.start(AgentShell.java:448) >> ... 5 more >> Cannot start daemon >> Service exit with a return value of 5 >> >> >> On Mon, Oct 7, 2013 at 2:31 PM, Mike Tutkowski < >> mike.tutkow...@solidfire.com> wrote: >> >>> Sure, that's a good plan. >>> >>> I'll get to it. >>> >>> >>> On Mon, Oct 7, 2013 at 2:29 PM, Marcus Sorensen <shadow...@gmail.com>wrote: >>> >>>> I know you mentioned you might need some minor changes to it, as well >>>> as other minor changes just for master (attach volume switched to pool vs >>>> adapter or something). My hope was that you would be able to send an update >>>> that works for your plugin on master, I'll test against existing libvirtd >>>> storage and apply it. >>>> On Oct 7, 2013 1:49 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> >>>> wrote: >>>> >>>>> This is an automatically generated e-mail. To reply, visit: >>>>> https://reviews.apache.org/r/14381/ >>>>> >>>>> This looks reasonable to me, Marcus. >>>>> >>>>> When do you think you might start the process of getting this into master? >>>>> >>>>> >>>>> - Mike Tutkowski >>>>> >>>>> On September 30th, 2013, 5:14 p.m. UTC, Marcus Sorensen wrote: >>>>> Review request for cloudstack, edison su and Mike Tutkowski. >>>>> By Marcus Sorensen. >>>>> >>>>> *Updated Sept. 30, 2013, 5:14 p.m.* >>>>> *Repository: * cloudstack-git >>>>> Description >>>>> >>>>> With custom storage plugins comes the need to prep the KVM host prior to >>>>> utilizing the disks. e.g. an iscsi initiator needs to log into the target >>>>> and scan for the lun before it can be used on the host. This patch is an >>>>> example I developed against 4.2, minor changes may be necessary to apply >>>>> to master, but I want to share with others who are working on storage so >>>>> they can ensure it works for them. Please tweak as you see fit. >>>>> >>>>> MigrateCommand: pass vmTO object so we can see which disks/storage pool >>>>> types belong to the vm when migrating a VM. This facilitates being able >>>>> to call disconnectPhysicalDisksViaVmSpec >>>>> >>>>> VirtualMachineManagerImpl: pass VirtualMachineTO when migrating so that >>>>> we can see which disks belong to the VM and what storage pools/adaptors >>>>> should be used >>>>> >>>>> LibvirtComputingResource: add calls KVMStoragePoolManager's >>>>> connectPhysicalDiskViaVmSpec and disconnectPhysicalDiskViaVmSpec calls >>>>> where appropriate (when starting a vm, migrating a vm). Ensure that we >>>>> create 'raw' format XML disk definitions when the storage format is RAW. >>>>> Move cleanupDisk logic to storage adaptors so that each adaptor type can >>>>> clean up its disks in is own way. >>>>> >>>>> KVMStoragePoolManager: add connectPhysicalDisk, disconnectPhysicalDisk, >>>>> connectPhysicalDiskViaVmSpec, disconnectPhysicalDiskViaVmSpec, >>>>> disconnectPhysicalDiskByPath. These all call the specific >>>>> StorageAdaptor's connectPhysicalDisk, disconnectPhysicalDisk, or >>>>> disconnectPhysicalDiskByPath calls. >>>>> >>>>> KVMStorageProcessor: Call connectPhysicalDisk/disconnectPhysicalDisk on >>>>> the storage adaptor. Whether or not this is implemented is up to the >>>>> storage adaptor. >>>>> >>>>> LibvirtStorageAdaptor: implement dummy >>>>> connectPhysicalDisk/disconnectPhysicalDisk, move cleanupDisk logic from >>>>> LibvirtComputingResource to disconnectPhysicalDiskByPath >>>>> >>>>> StorageAdaptor: define >>>>> connectPhysicalDisk/disconnectPhysicalDisk/disconnectPhysicalDiskByPath >>>>> in the interface >>>>> >>>>> >>>>> Testing >>>>> >>>>> Basic testing with my storage adaptor >>>>> >>>>> Diffs >>>>> >>>>> - core/src/com/cloud/agent/api/MigrateCommand.java (5042b8c) >>>>> - >>>>> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java >>>>> (3ee811f) >>>>> - >>>>> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStoragePoolManager.java >>>>> (e09c9ba) >>>>> - >>>>> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/KVMStorageProcessor.java >>>>> (c69f9b0) >>>>> - >>>>> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/LibvirtStorageAdaptor.java >>>>> (123a9f1) >>>>> - >>>>> plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/storage/StorageAdaptor.java >>>>> (4956d8d) >>>>> - server/src/com/cloud/vm/VirtualMachineManagerImpl.java (d46bbb0) >>>>> >>>>> View Diff <https://reviews.apache.org/r/14381/diff/> >>>>> >>>> >>> >>> >>> -- >>> *Mike Tutkowski* >>> *Senior CloudStack Developer, SolidFire Inc.* >>> e: mike.tutkow...@solidfire.com >>> o: 303.746.7302 >>> Advancing the way the world uses the >>> cloud<http://solidfire.com/solution/overview/?video=play> >>> *™* >>> >> >> >> >> -- >> *Mike Tutkowski* >> *Senior CloudStack Developer, SolidFire Inc.* >> e: mike.tutkow...@solidfire.com >> o: 303.746.7302 >> Advancing the way the world uses the >> cloud<http://solidfire.com/solution/overview/?video=play> >> *™* >> > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
