Re: Managed storage with KVM
Yes, see my previous email from the 13th. You can create your own
KVMStoragePool class, and StorageAdaptor class, like the libvirt ones
have. The previous email outlines how to add your own StorageAdaptor
alongside LibvirtStorageAdaptor to take over all of the calls
(createStoragePool, getStoragePool, etc). As mentioned,
getPhysicalDisk I believe will be the one you use to actually attach a
lun.
Ignore CreateStoragePoolCommand. When the agent connects to the
management server, it registers all pools in the cluster with the
agent. It will call ModifyStoragePoolCommand, passing your storage
pool object (with all of the settings for your SAN). This in turn
calls _storagePoolMgr.createStoragePool, which will route through
KVMStoragePoolManager to your storage adapter that you've registered.
The last argument to createStoragePool is the pool type, which is used
to select a StorageAdaptor.
>From then on, most calls will only pass the volume info, and the
volume will have the uuid of the storage pool. For this reason, your
adaptor class needs to have a static Map variable that contains pool
uuid and pool object. Whenever they call createStoragePool on your
adaptor you add that pool to the map so that subsequent volume calls
can look up the pool details for the volume by pool uuid. With the
Libvirt adaptor, libvirt keeps track of that for you.
When createStoragePool is called, you can log into the iscsi target
(or make sure you are already logged in, as it can be called over
again at any time), and when attach volume commands are fired off, you
can attach individual LUNs that are asked for, or rescan (say that the
plugin created a new ACL just prior to calling attach), or whatever is
necessary.
KVM is a bit more work, but you can do anything you want. Actually, I
think you can call host scripts with Xen, but having the agent there
that runs your own code gives you the flexibility to do whatever.
On Sun, Sep 15, 2013 at 10:44 PM, Mike Tutkowski
wrote:
> I see right now LibvirtComputingResource.java has the following method that
> I might be able to leverage (it's probably not called at present and would
> need to be implemented in my case to discover my iSCSI target and log in to
> it):
>
> protected Answer execute(CreateStoragePoolCommand cmd) {
>
> return new Answer(cmd, true, "success");
>
> }
>
> I would probably be able to call the KVMStorageManager to have it use my
> StorageAdaptor to do what's necessary here.
>
>
>
>
> On Sun, Sep 15, 2013 at 10:37 PM, Mike Tutkowski
> wrote:
>>
>> Hey Marcus,
>>
>> When I implemented support in the XenServer and VMware plug-ins for
>> "managed" storage, I started at the execute(AttachVolumeCommand) methods in
>> both plug-ins.
>>
>> The code there was changed to check the AttachVolumeCommand instance for a
>> "managed" property.
>>
>> If managed was false, the normal attach/detach logic would just run and
>> the volume would be attached or detached.
>>
>> If managed was true, new 4.2 logic would run to create (let's talk
>> XenServer here) a new SR and a new VDI inside of that SR (or to reattach an
>> existing VDI inside an existing SR, if this wasn't the first time the volume
>> was attached). If managed was true and we were detaching the volume, the SR
>> would be detached from the XenServer hosts.
>>
>> I am currently walking through the execute(AttachVolumeCommand) in
>> LibvirtComputingResource.java.
>>
>> I see how the XML is constructed to describe whether a disk should be
>> attached or detached. I also see how we call in to get a StorageAdapter (and
>> how I will likely need to write a new one of these).
>>
>> So, talking in XenServer terminology again, I was wondering if you think
>> the approach we took in 4.2 with creating and deleting SRs in the
>> execute(AttachVolumeCommand) method would work here or if there is some
>> other way I should be looking at this for KVM?
>>
>> As it is right now for KVM, storage has to be set up ahead of time.
>> Assuming this is the case, there probably isn't currently a place I can
>> easily inject my logic to discover and log in to iSCSI targets. This is why
>> we did it as needed in the execute(AttachVolumeCommand) for XenServer and
>> VMware, but I wanted to see if you have an alternative way that might be
>> better for KVM.
>>
>> One possible way to do this would be to modify VolumeManagerImpl (or
>> whatever its equivalent is in 4.3) before it issues an attach-volume command
>> to KVM to check to see if the volume is to be attached to managed storage.
>> If it is, then (before calling the attach-volume command in KVM) call the
>> create-storage-pool command in KVM (or whatever it might be called).
>>
>> Just wanted to get some of your thoughts on this.
>>
>> Thanks!
>>
>>
>> On Sat, Sep 14, 2013 at 12:07 AM, Mike Tutkowski
>> wrote:
>>>
>>> Yeah, I remember that StorageProcessor stuff being put in the codebase
>>> and having to merge my code into it in 4.2.
>>>
>>> Thanks for all the details, Marcus
Re: Review Request 14079: marvin tests for IP Address reservation within a network
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14079/#review26130 --- Ship it! Looks good. Can a committer have a look and apply the patch. - Saksham Srivastava On Sept. 12, 2013, 11:13 a.m., Anshul Gangwar wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/14079/ > --- > > (Updated Sept. 12, 2013, 11:13 a.m.) > > > Review request for cloudstack, Saksham Srivastava and Prasanna Santhanam. > > > Bugs: https://issues.apache.org/jira/browse/CLOUDSTACK-2266 > > > Repository: cloudstack-git > > > Description > --- > > marvin tests for IP Address reservation within a network > > > Diffs > - > > test/integration/component/test_ip_reservation.py PRE-CREATION > tools/marvin/marvin/integration/lib/base.py fa4cc82 > > Diff: https://reviews.apache.org/r/14079/diff/ > > > Testing > --- > > ran successfully on my local advanced zone setup > > > Thanks, > > Anshul Gangwar > >
Re: Managed storage with KVM
I see right now LibvirtComputingResource.java has the following method that
I might be able to leverage (it's probably not called at present and would
need to be implemented in my case to discover my iSCSI target and log in to
it):
protected Answer execute(CreateStoragePoolCommand cmd) {
return new Answer(cmd, true, "success");
}
I would probably be able to call the KVMStorageManager to have it use my
StorageAdaptor to do what's necessary here.
On Sun, Sep 15, 2013 at 10:37 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:
> Hey Marcus,
>
> When I implemented support in the XenServer and VMware plug-ins for
> "managed" storage, I started at the execute(AttachVolumeCommand) methods in
> both plug-ins.
>
> The code there was changed to check the AttachVolumeCommand instance for a
> "managed" property.
>
> If managed was false, the normal attach/detach logic would just run and
> the volume would be attached or detached.
>
> If managed was true, new 4.2 logic would run to create (let's talk
> XenServer here) a new SR and a new VDI inside of that SR (or to reattach an
> existing VDI inside an existing SR, if this wasn't the first time the
> volume was attached). If managed was true and we were detaching the volume,
> the SR would be detached from the XenServer hosts.
>
> I am currently walking through the execute(AttachVolumeCommand) in
> LibvirtComputingResource.java.
>
> I see how the XML is constructed to describe whether a disk should be
> attached or detached. I also see how we call in to get a StorageAdapter
> (and how I will likely need to write a new one of these).
>
> So, talking in XenServer terminology again, I was wondering if you think
> the approach we took in 4.2 with creating and deleting SRs in the
> execute(AttachVolumeCommand) method would work here or if there is some
> other way I should be looking at this for KVM?
>
> As it is right now for KVM, storage has to be set up ahead of time.
> Assuming this is the case, there probably isn't currently a place I can
> easily inject my logic to discover and log in to iSCSI targets. This is why
> we did it as needed in the execute(AttachVolumeCommand) for XenServer and
> VMware, but I wanted to see if you have an alternative way that might be
> better for KVM.
>
> One possible way to do this would be to modify VolumeManagerImpl (or
> whatever its equivalent is in 4.3) before it issues an attach-volume
> command to KVM to check to see if the volume is to be attached to managed
> storage. If it is, then (before calling the attach-volume command in KVM)
> call the create-storage-pool command in KVM (or whatever it might be
> called).
>
> Just wanted to get some of your thoughts on this.
>
> Thanks!
>
>
> On Sat, Sep 14, 2013 at 12:07 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> Yeah, I remember that StorageProcessor stuff being put in the codebase
>> and having to merge my code into it in 4.2.
>>
>> Thanks for all the details, Marcus! :)
>>
>> I can start digging into what you were talking about now.
>>
>>
>> On Sat, Sep 14, 2013 at 12:02 AM, Marcus Sorensen wrote:
>>
>>> Looks like things might be slightly different now in 4.2, with
>>> KVMStorageProcessor.java in the mix.This looks more or less like some
>>> of the commands were ripped out verbatim from LibvirtComputingResource
>>> and placed here, so in general what I've said is probably still true,
>>> just that the location of things like AttachVolumeCommand might be
>>> different, in this file rather than LibvirtComputingResource.java.
>>>
>>> On Fri, Sep 13, 2013 at 11:42 PM, Marcus Sorensen
>>> wrote:
>>> > Ok, KVM will be close to that, of course, because only the hypervisor
>>> > classes differ, the rest is all mgmt server. Creating a volume is just
>>> > a db entry until it's deployed for the first time. AttachVolumeCommand
>>> > on the agent side (LibvirtStorageAdaptor.java is analogous to
>>> > CitrixResourceBase.java) will do the iscsiadm commands (via a KVM
>>> > StorageAdaptor) to log in the host to the target and then you have a
>>> > block device. Maybe libvirt will do that for you, but my quick read
>>> > made it sound like the iscsi libvirt pool type is actually a pool, not
>>> > a lun or volume, so you'll need to figure out if that works or if
>>> > you'll have to use iscsiadm commands.
>>> >
>>> > If you're NOT going to use LibvirtStorageAdaptor (because Libvirt
>>> > doesn't really manage your pool the way you want), you're going to
>>> > have to create a version of KVMStoragePool class and a StorageAdaptor
>>> > class (see LibvirtStoragePool.java and LibvirtStorageAdaptor.java),
>>> > implementing all of the methods, then in KVMStorageManager.java
>>> > there's a "_storageMapper" map. This is used to select the correct
>>> > adaptor, you can see in this file that every call first pulls the
>>> > correct adaptor out of this map via getStorageAdaptor. So you can see
>>> > a comment in this file that says "add other storage adap
Re: [GSoC] Pencil down on Sept 16th
@Sebgoa: could you please apply my pending patch? So I can upload another patches, because they use files from that pending patch 2013/9/16 Abhinandan Prateek > Though the heading says code sample the google-melange site specifically > asks you to upload the full work even it partially includes bits and > pieces of other code as in a big project. > > -abhi > > On 16/09/13 8:49 am, "Nguyen Anh Tu" wrote: > > >Hi guys, > > > >Today is the deadline of uploading code template. What parts of code do > >you > >decide to upload to code template? only patches/diffs or whole of source > >tree? > > > >Thanks, > > > > > >2013/9/6 Sebastien Goasguen > > > >> > >> On Sep 3, 2013, at 6:08 PM, Ian Duffy wrote: > >> > >> > Cool, I don't have any more code to submit unless somebody finds an > >>issue > >> > between now and then. > >> > > >> > Any idea what is required within the code samples? Do we just pick > >> sections > >> > of code we're proud of or Š > >> > >> they just posted this: > >> > >> > >> > >> > http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc > >>2013/codeguidelines > >> > >> > >> > ? > >> > > >> > >> > > >> > On 3 September 2013 09:38, sebgoa wrote: > >> > > >> >> Hi guys, > >> >> > >> >> GsoC pencil down date is Sept 16th, with firm pencil down on Sept > >>23rd > >> and > >> >> Final evaluation on September 27th. > >> >> It seems that Google will require you to submit code samples on Sept > >> 27th. > >> >> > >> >> So there is still time to send your patches. > >> >> Ian has been made committer and can commit on his own, the others can > >> >> still use review board. > >> >> > >> >> I will send another email this week about final report, another > >>docbook > >> >> exercise :) > >> >> > >> >> keep it up, this is the last stretch, join IRC for questions, email > >>the > >> >> listŠ > >> >> > >> >> cheers, > >> >> > >> >> -Sebastien > >> > >> > > > > > >-- > > > >N.g.U.y.e.N.A.n.H.t.U > > -- N.g.U.y.e.N.A.n.H.t.U
Re: Managed storage with KVM
Hey Marcus, When I implemented support in the XenServer and VMware plug-ins for "managed" storage, I started at the execute(AttachVolumeCommand) methods in both plug-ins. The code there was changed to check the AttachVolumeCommand instance for a "managed" property. If managed was false, the normal attach/detach logic would just run and the volume would be attached or detached. If managed was true, new 4.2 logic would run to create (let's talk XenServer here) a new SR and a new VDI inside of that SR (or to reattach an existing VDI inside an existing SR, if this wasn't the first time the volume was attached). If managed was true and we were detaching the volume, the SR would be detached from the XenServer hosts. I am currently walking through the execute(AttachVolumeCommand) in LibvirtComputingResource.java. I see how the XML is constructed to describe whether a disk should be attached or detached. I also see how we call in to get a StorageAdapter (and how I will likely need to write a new one of these). So, talking in XenServer terminology again, I was wondering if you think the approach we took in 4.2 with creating and deleting SRs in the execute(AttachVolumeCommand) method would work here or if there is some other way I should be looking at this for KVM? As it is right now for KVM, storage has to be set up ahead of time. Assuming this is the case, there probably isn't currently a place I can easily inject my logic to discover and log in to iSCSI targets. This is why we did it as needed in the execute(AttachVolumeCommand) for XenServer and VMware, but I wanted to see if you have an alternative way that might be better for KVM. One possible way to do this would be to modify VolumeManagerImpl (or whatever its equivalent is in 4.3) before it issues an attach-volume command to KVM to check to see if the volume is to be attached to managed storage. If it is, then (before calling the attach-volume command in KVM) call the create-storage-pool command in KVM (or whatever it might be called). Just wanted to get some of your thoughts on this. Thanks! On Sat, Sep 14, 2013 at 12:07 AM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Yeah, I remember that StorageProcessor stuff being put in the codebase and > having to merge my code into it in 4.2. > > Thanks for all the details, Marcus! :) > > I can start digging into what you were talking about now. > > > On Sat, Sep 14, 2013 at 12:02 AM, Marcus Sorensen wrote: > >> Looks like things might be slightly different now in 4.2, with >> KVMStorageProcessor.java in the mix.This looks more or less like some >> of the commands were ripped out verbatim from LibvirtComputingResource >> and placed here, so in general what I've said is probably still true, >> just that the location of things like AttachVolumeCommand might be >> different, in this file rather than LibvirtComputingResource.java. >> >> On Fri, Sep 13, 2013 at 11:42 PM, Marcus Sorensen >> wrote: >> > Ok, KVM will be close to that, of course, because only the hypervisor >> > classes differ, the rest is all mgmt server. Creating a volume is just >> > a db entry until it's deployed for the first time. AttachVolumeCommand >> > on the agent side (LibvirtStorageAdaptor.java is analogous to >> > CitrixResourceBase.java) will do the iscsiadm commands (via a KVM >> > StorageAdaptor) to log in the host to the target and then you have a >> > block device. Maybe libvirt will do that for you, but my quick read >> > made it sound like the iscsi libvirt pool type is actually a pool, not >> > a lun or volume, so you'll need to figure out if that works or if >> > you'll have to use iscsiadm commands. >> > >> > If you're NOT going to use LibvirtStorageAdaptor (because Libvirt >> > doesn't really manage your pool the way you want), you're going to >> > have to create a version of KVMStoragePool class and a StorageAdaptor >> > class (see LibvirtStoragePool.java and LibvirtStorageAdaptor.java), >> > implementing all of the methods, then in KVMStorageManager.java >> > there's a "_storageMapper" map. This is used to select the correct >> > adaptor, you can see in this file that every call first pulls the >> > correct adaptor out of this map via getStorageAdaptor. So you can see >> > a comment in this file that says "add other storage adaptors here", >> > where it puts to this map, this is where you'd register your adaptor. >> > >> > So, referencing StorageAdaptor.java, createStoragePool accepts all of >> > the pool data (host, port, name, path) which would be used to log the >> > host into the initiator. I *believe* the method getPhysicalDisk will >> > need to do the work of attaching the lun. AttachVolumeCommand calls >> > this and then creates the XML diskdef and attaches it to the VM. Now, >> > one thing you need to know is that createStoragePool is called often, >> > sometimes just to make sure the pool is there. You may want to create >> > a map in your adaptor class and keep track of pools that have been >> >
Re: Q's about UserAuthenticators and getName()
On 13/09/13 10:04 pm, "Darren Shepherd" wrote: >On 09/13/2013 03:48 AM, Abhinandan Prateek wrote: >> The code already has the name set to ³LDAP² in 4.2. What branch are you >>on >> ? >> Will also prefer if we can use getClass().getSimpleName() to get the >> classname, but we should check the possibility of the adapter classnames >> getting enhanced by underlying framework. >> > >I'm on master but that doesn't matter, its actually broke in 4.2 also. >I originally stated that the DefaultUserAuthenticator masks _name in >ComponentLifecycleBase so even though the XML is setting the property to >LDAP it doesn't work. That was sort of my original question, why was it >done like that? > >I can clean up all the authenticators and submit a patch if we want. > Looking at git history it appears that _name got masked when the DefaultUserAuthenticator was made to extend AdapterBase. A cleanup will help. -abhi >
Re: Apache CloudStack 4.2.0 (fifth round)
+1 Tested VM life cycle with Xen in advanced zone. On 16/09/13 7:48 am, "Chip Childers" wrote: >+1 (binding) > >Tested with simulator. > > > >On Sep 14, 2013, at 5:59 PM, Marcus Sorensen wrote: > >> +1 (binding) >> >> Tested CentOS 6.4 and Ubuntu 12.04.3: >> create advanced zone >> create VPC >> register template >> create VPC tier >> create VM on tier w/NFS >> create VM on tier w/CLM >> create VM on tier w/Local storage >> create static NAT to vm, ssh in >> >> On Sat, Sep 14, 2013 at 10:28 AM, Rajesh Battala >> wrote: >>> +1 >>> >>> Tested VM Life cycle in Xenserver and KVM with Advance Zone >>>configuration. >>> >>> Thanks >>> Rajesh Battala >>> >>> -Original Message- >>> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] >>> Sent: Saturday, September 14, 2013 4:43 AM >>> To: dev@cloudstack.apache.org >>> Subject: Apache CloudStack 4.2.0 (fifth round) >>> >>> >>> I've created a 4.2.0 release, with the following artifacts up for a >>>vote: >>> >>> Git Branch and Commit SH: >>> >>>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=re >>>fs/heads/4.2 >>> Commit: c1e24ff89f6d14d6ae74d12dbca108c35449030f >>> >>> List of changes: >>> >>>https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f= >>>CHANGES;hb=4.2 >>> >>> Source release (checksums and signatures are available at the same >>> location): >>> https://dist.apache.org/repos/dist/dev/cloudstack/4.2.0/ >>> >>> PGP release keys (signed using 94BE0D7C): >>> https://dist.apache.org/repos/dist/release/cloudstack/KEYS >>> >>> Testing instructions are here: >>> >>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+proc >>>edure >>> >>> Vote will be open for 72 hours (Wednesday 9/18 End of Day PST). >>> >>> For sanity in tallying the vote, can PMC members please be sure to >>>indicate "(binding)" with their vote? >>> >>> [ ] +1 approve >>> [ ] +0 no opinion >>> [ ] -1 disapprove (and reason why) >>
Re: [GSoC] Pencil down on Sept 16th
Though the heading says code sample the google-melange site specifically asks you to upload the full work even it partially includes bits and pieces of other code as in a big project. -abhi On 16/09/13 8:49 am, "Nguyen Anh Tu" wrote: >Hi guys, > >Today is the deadline of uploading code template. What parts of code do >you >decide to upload to code template? only patches/diffs or whole of source >tree? > >Thanks, > > >2013/9/6 Sebastien Goasguen > >> >> On Sep 3, 2013, at 6:08 PM, Ian Duffy wrote: >> >> > Cool, I don't have any more code to submit unless somebody finds an >>issue >> > between now and then. >> > >> > Any idea what is required within the code samples? Do we just pick >> sections >> > of code we're proud of or Š >> >> they just posted this: >> >> >> >>http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc >>2013/codeguidelines >> >> >> > ? >> > >> >> > >> > On 3 September 2013 09:38, sebgoa wrote: >> > >> >> Hi guys, >> >> >> >> GsoC pencil down date is Sept 16th, with firm pencil down on Sept >>23rd >> and >> >> Final evaluation on September 27th. >> >> It seems that Google will require you to submit code samples on Sept >> 27th. >> >> >> >> So there is still time to send your patches. >> >> Ian has been made committer and can commit on his own, the others can >> >> still use review board. >> >> >> >> I will send another email this week about final report, another >>docbook >> >> exercise :) >> >> >> >> keep it up, this is the last stretch, join IRC for questions, email >>the >> >> listŠ >> >> >> >> cheers, >> >> >> >> -Sebastien >> >> > > >-- > >N.g.U.y.e.N.A.n.H.t.U
Re: com.cloud.ha.RecreatableFencer used?
It is/was used in baremetal setup where to HA a VM it has to be recreated. On 13/09/13 2:13 pm, "Darren Shepherd" wrote: >com.cloud.ha.RecreatableFencer is registered in applicationContext.xml >but never in a componentContext.xml. So it appears that fencer is never >used. Is there a specific reason for this? > >Darren
Re: [GSoC] Pencil down on Sept 16th
Hi guys, Today is the deadline of uploading code template. What parts of code do you decide to upload to code template? only patches/diffs or whole of source tree? Thanks, 2013/9/6 Sebastien Goasguen > > On Sep 3, 2013, at 6:08 PM, Ian Duffy wrote: > > > Cool, I don't have any more code to submit unless somebody finds an issue > > between now and then. > > > > Any idea what is required within the code samples? Do we just pick > sections > > of code we're proud of or … > > they just posted this: > > > http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2013/codeguidelines > > > > ? > > > > > > > On 3 September 2013 09:38, sebgoa wrote: > > > >> Hi guys, > >> > >> GsoC pencil down date is Sept 16th, with firm pencil down on Sept 23rd > and > >> Final evaluation on September 27th. > >> It seems that Google will require you to submit code samples on Sept > 27th. > >> > >> So there is still time to send your patches. > >> Ian has been made committer and can commit on his own, the others can > >> still use review board. > >> > >> I will send another email this week about final report, another docbook > >> exercise :) > >> > >> keep it up, this is the last stretch, join IRC for questions, email the > >> list… > >> > >> cheers, > >> > >> -Sebastien > > -- N.g.U.y.e.N.A.n.H.t.U
Re: Apache CloudStack 4.2.0 (fifth round)
+1 (binding) Tested with simulator. On Sep 14, 2013, at 5:59 PM, Marcus Sorensen wrote: > +1 (binding) > > Tested CentOS 6.4 and Ubuntu 12.04.3: > create advanced zone > create VPC > register template > create VPC tier > create VM on tier w/NFS > create VM on tier w/CLM > create VM on tier w/Local storage > create static NAT to vm, ssh in > > On Sat, Sep 14, 2013 at 10:28 AM, Rajesh Battala > wrote: >> +1 >> >> Tested VM Life cycle in Xenserver and KVM with Advance Zone configuration. >> >> Thanks >> Rajesh Battala >> >> -Original Message- >> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] >> Sent: Saturday, September 14, 2013 4:43 AM >> To: dev@cloudstack.apache.org >> Subject: Apache CloudStack 4.2.0 (fifth round) >> >> >> I've created a 4.2.0 release, with the following artifacts up for a vote: >> >> Git Branch and Commit SH: >> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/4.2 >> Commit: c1e24ff89f6d14d6ae74d12dbca108c35449030f >> >> List of changes: >> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=CHANGES;hb=4.2 >> >> Source release (checksums and signatures are available at the same >> location): >> https://dist.apache.org/repos/dist/dev/cloudstack/4.2.0/ >> >> PGP release keys (signed using 94BE0D7C): >> https://dist.apache.org/repos/dist/release/cloudstack/KEYS >> >> Testing instructions are here: >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+test+procedure >> >> Vote will be open for 72 hours (Wednesday 9/18 End of Day PST). >> >> For sanity in tallying the vote, can PMC members please be sure to indicate >> "(binding)" with their vote? >> >> [ ] +1 approve >> [ ] +0 no opinion >> [ ] -1 disapprove (and reason why) >
Re: [PROPOSAL][SIMPLIFY] Future ACS RC testing
Sebastien, Are you thinking november in Amsterdam, or before? On Thu, Sep 12, 2013 at 9:06 AM, sebgoa wrote: > > On Sep 11, 2013, at 5:25 PM, "Musayev, Ilya" wrote: > >> As mentioned on private, I think the reason we have so few responders when >> it comes to voting - is because it takes considerable amount of time to >> build, test and QA. And if you take voting serious as everyone should, you >> have to QA before you can vote. >> >> >> >> Perhaps we should spent some time on automation and take an automation step >> further. >> >> >> >> My next dream project is to create a set of 3 virtual appliances. >> >> >> >> Set 1: >> >> 2 KVM Hypervisors preconfigured with NFS >> >> 1 CloudStack MS with latest RC code >> >> >> >> Set 2: >> >> 2 XEN Hypervisors preconfigured with NFS >> >> 1 CloudStack MS with latest RC code >> >> >> >> Set 3: >> >> 1 CloudStack MS with latest RC code >> >> >> >> Set 3 get a bit hairy because of Virtual Center and licensing, so we >> abstract it and let folks QA what they have. >> >> - >> >> Do you find this approach useful, or do you believe the build tests we do is >> sufficient? >> >> Who can join or atleast share scripts they use to automate provisioning of >> KVM and XEN hosts? >> >> I'm looking for set of "post" scripts they can configure XEN and KVM end 2 >> end. >> >> Thanks >> ilya > > Ilya, I think this is in-line with what Marcus is proposing. > > In another thread on testing I proposed to have a meeting where anyone > interested in testing can join and where we can hash out a plan, then report > back to the list. > > > > -sebastien
Re: [VOTE] Apache CloudStack CloudMonkey 5.0.0 (first round)
+1 (binding) Downloaded release artifacts, installed in ubuntu devcloud-kvm, tested various sync, async calls and cloudmonkey scripts. Seems to work as well or better than previous releases. On Sun, Sep 15, 2013 at 6:09 AM, Rohit Yadav wrote: > +1 > > Build with cache, checked readme etc. files and installed: > https://pbs.twimg.com/media/BUM97ZjCQAAOM5v.png:large > > Since the build cache was created from/against ACS 4.2, as long as the APIs > were compatible so will cloudmonkey be for 4.2 and previous releases > including 4.x, 3.x ones. > > Thanks Chip! > > Regards. > > > On Fri, Sep 13, 2013 at 6:53 PM, Chip Childers > wrote: > >> I've created a 5.0.0 release of cloudmonkey, with the following artifacts >> up for a >> vote: >> >> Git Branch and Commit SH: >> >> https://git-wip-us.apache.org/repos/asf?p=cloudstack-cloudmonkey.git;a=shortlog;h=refs/heads/5.0 >> Commit: 767bfbe084e24d441f1ad73ace183c09f26a276b >> >> List of changes: >> >> https://git-wip-us.apache.org/repos/asf?p=cloudstack-cloudmonkey.git;a=blob;f=CHANGES;h=54f2e32357b0a726dc6f202e4897ed4af531f8ab;hb=refs/heads/5.0 >> >> Source release (checksums and signatures are available at the same >> location): >> https://dist.apache.org/repos/dist/dev/cloudstack/cloudmonkey-5.0.0/ >> >> PGP release keys (signed using 94BE0D7C): >> https://dist.apache.org/repos/dist/release/cloudstack/KEYS >> >> I have not created testing instructions for this release artifact, but >> would appreciate help documenting it as people to it. >> >> Vote will be open for at least 72 hours. >> >> For sanity in tallying the vote, can PMC members please be sure to indicate >> "(binding)" with their vote? >> >> [ ] +1 approve >> [ ] +0 no opinion >> [ ] -1 disapprove (and reason why) >> >> Thanks, >> >> -chip >>
Re: Which DevCloud2 Usage Mode is good for Development and Debugging ????
#3 is best and also since devcloud2 was created to provide host-only mode so that it could be used a throw away appliance for a faster CloudStack development. #3: CloudStack will run on your host OS so debugging becomes easier. HTH. On Thu, Sep 12, 2013 at 2:49 PM, Punith s wrote: > hi folks, > > i'm using Devcloud2 to build cloudstack 4.2 , currently i'm using *full > sandbox mode* , > > devcloud allows following modes , > *1.full sandbox mode - *build and deploy inside devcloud > *2.deployment mode - *build code in localhost and deploying in devcloud > *3.host only mode - *using devcloud only as host > > > which mode do you think its feasible for development and interactive > debugging ? > can you elaborate more on setting up remote debugging in Devcloud2 > (fullsandbox mode) using eclipse ?? > > thanks, > punith s >
Re: [VOTE] Apache CloudStack CloudMonkey 5.0.0 (first round)
+1 Build with cache, checked readme etc. files and installed: https://pbs.twimg.com/media/BUM97ZjCQAAOM5v.png:large Since the build cache was created from/against ACS 4.2, as long as the APIs were compatible so will cloudmonkey be for 4.2 and previous releases including 4.x, 3.x ones. Thanks Chip! Regards. On Fri, Sep 13, 2013 at 6:53 PM, Chip Childers wrote: > I've created a 5.0.0 release of cloudmonkey, with the following artifacts > up for a > vote: > > Git Branch and Commit SH: > > https://git-wip-us.apache.org/repos/asf?p=cloudstack-cloudmonkey.git;a=shortlog;h=refs/heads/5.0 > Commit: 767bfbe084e24d441f1ad73ace183c09f26a276b > > List of changes: > > https://git-wip-us.apache.org/repos/asf?p=cloudstack-cloudmonkey.git;a=blob;f=CHANGES;h=54f2e32357b0a726dc6f202e4897ed4af531f8ab;hb=refs/heads/5.0 > > Source release (checksums and signatures are available at the same > location): > https://dist.apache.org/repos/dist/dev/cloudstack/cloudmonkey-5.0.0/ > > PGP release keys (signed using 94BE0D7C): > https://dist.apache.org/repos/dist/release/cloudstack/KEYS > > I have not created testing instructions for this release artifact, but > would appreciate help documenting it as people to it. > > Vote will be open for at least 72 hours. > > For sanity in tallying the vote, can PMC members please be sure to indicate > "(binding)" with their vote? > > [ ] +1 approve > [ ] +0 no opinion > [ ] -1 disapprove (and reason why) > > Thanks, > > -chip >
