Re: Libvirt-java 0.5.0 has been released

[Mike Tutkowski]

Thanks for investigating this!

Talk to you soon!


On Fri, Sep 27, 2013 at 12:54 AM, Wei ZHOU  wrote:

> good night
>
>
> 2013/9/27 Mike Tutkowski 
>
> > Sounds good
> >
> > Might have to get back to you tomorrow, though. I have to get up early.
> :)
> >
> >
> > On Fri, Sep 27, 2013 at 12:43 AM, Wei ZHOU 
> wrote:
> >
> > > ok. Thanks for your reply!
> > > The last question, could you try to download the cloudstack-agent and
> > > cloudstack-common deb packages, and "dpkg -i" to install it?
> > >
> > > I will test it on my local machine.
> > >
> > >
> > >
> > > 2013/9/27 Mike Tutkowski 
> > >
> > > > Before re-installing the DEBs I run the following:
> > > >
> > > > #sudo apt-get remove --purge cloudstack-agent
> > > >
> > > > #sudo apt-get clean
> > > > Would that be sufficient with regards to what you were asking?
> > > >
> > > >
> > > > On Fri, Sep 27, 2013 at 12:36 AM, Wei ZHOU 
> > > wrote:
> > > >
> > > > > What if you apt-get remove and apt-get install again?
> > > > >
> > > > >
> > > > > 2013/9/27 Mike Tutkowski 
> > > > >
> > > > > > Yeah, I had cleaned, rebuilt the codebase, regenerated the DEBs,
> > then
> > > > > > apt-get update and apt-get install cloudstack-agent.
> > > > > >
> > > > > > I can try it again and see what happens. I thought I tried the
> > > process
> > > > > > twice and got the same results.
> > > > > >
> > > > > > I did a search for cloudstack-agent-upgrade on my file system and
> > > only
> > > > > > found references in the source directory.
> > > > > >
> > > > > >
> > > > > > On Fri, Sep 27, 2013 at 12:30 AM, Wei ZHOU <
> ustcweiz...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > It is correct.
> > > > > > > Have you re-created the cloudstack-agent deb files and uploaded
> > to
> > > > your
> > > > > > > local apt repository?
> > > > > > >
> > > > > > >
> > > > > > > 2013/9/27 Mike Tutkowski 
> > > > > > >
> > > > > > > > Here you go:
> > > > > > > >
> > > > > > > > mtutkowski@ubuntu:~/cloudstack$ grep
> cloudstack-agent-upgrade
> > > > > > > debian/rules
> > > > > > > > install -D agent/target/transformed/cloudstack-agent-upgrade
> > > > > > > > $(DESTDIR)/usr/bin/cloudstack-agent-upgrade
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Sep 27, 2013 at 12:20 AM, Wei ZHOU <
> > > ustcweiz...@gmail.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Did you build the latest source?
> > > > > > > > > Could you paste the result of the following command in your
> > > > source
> > > > > > > > > directory?
> > > > > > > > > "grep cloudstack-agent-upgrade debian/rules"
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > *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
> > > > *™*
> > > >
> > >
> >
> >
> >
> > --
> > *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: add connect method on KVM storage code

[Mike Tutkowski]

Thanks for the clarification on how that works.

Also, yeah, I think CHAP only grants you access to a volume. If multiple
hosts are using the CHAP credentials for a single volume, it's up to those
hosts to make sure they don't step on each other's toes (and this is - to
my understanding - how it works with XenServer and VMware).


On Fri, Sep 27, 2013 at 12:45 AM, Marcus Sorensen wrote:

> On Fri, Sep 27, 2013 at 12:21 AM, Mike Tutkowski
>  wrote:
> > Maybe I should seek a little clarification as to how live migration works
> > in CS with KVM.
> >
> > Before we do a live migration of VM 1 from Host 1 to Host 2, do we detach
> > all disks from VM1?
> >
> > If so, then we're good to go there.
> >
> > I'm not as clear with HA.
>
> During live migration this is what we currently do in our modified
> 4.1, I'm not sure if the new framework is set up for this, but it
> should be made to do this if not.
>
> PrepareForMigrationCommand is called on destination host. In
> PrepareForMigrationCommand we added a few lines to call
> connectPhysicalDisk. This host connects the SAN disks to this new
> host, then creates a paused VM.
>
> MigrateCommand is called on the source host. This sends the proper
> command to transfer VM memory, then atomically cuts over to the
> destination host. During this time, the disks are attached on both
> sides, but the VM is still the only thing that is using them, and it
> atomically cuts over. There's no caching on the host (qemu is using
> directio), so this is safe.
>
> After MigrateCommand completes it's VM passoff, we detach the disks
> before returning.
>
> >
> > If VM 1 goes down because Host 1 crashes, is the attach-volume command
> > invoked as many times as need be (depending on how many volumes need to
> be
> > attached) when VM 1 is restarted on Host 2?
>
> From what I can tell, the attachVolume and dettachVolume seemed to
> only be for attaching disks to existing, running VMs (i.e. inserting
> new XML into an existing domain definition).  Normally when starting a
> vm from scratch the vm definition, along with any currently attached
> disks, is passed in to StartCommand (which would also be called during
> HA restart of a VM). In our 4.1 branch we also have a call to
> connectPhysicalDisk here, where we loop through the disk definitions
> that were passed.
>
> Again, I should be able to flesh out the differences in 4.2 and how to
> go about making this suitable for everyone in the coming days, so long
> as you and anyone else writing plugins agree with the changes.
>
> These processes would make sure the disks are available on the hosts
> they need to be, but they don't really provide locking or ensure that
> only the necessary hosts can write to or see the disks at any given
> time. I don't think CHAP does that either. We currently generate ACLs
> via our SAN api during connectPhysicalDisk as a safety measure, but if
> CloudStack is working properly it will be in charge of controlling
> that the disks are only being used where they should be. The ACLs just
> ensure that if the VM somehow gets started in two different places
> (e.g. HA malfunction), only one of them will have access to the disks.
>
> >
> >
> > On Fri, Sep 27, 2013 at 12:17 AM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> >> Let me clarify this line a bit:
> >>
> >> "We get away without this with XenServer and VMware because - as far as
> I
> >> know - CS delegates HA and live migration to those clusters and they
> handle
> >> it most likely with some kind of locking protocol on the SR/datastore."
> >>
> >> When I set up a XenServer or a VMware cluster, all nodes in the cluster
> >> have the proper CHAP credentials and can access a shared SR/datastore.
> >>
> >> HA and live migrations are OK here because the cluster controls access
> to
> >> the VDI on the SR (or VMDK on the datastore) with some kind of locking
> >> protocol, I expect.
> >>
> >> Since KVM isn't really in a cluster outside of the CloudStack world,
> >> CloudStack has to handle these intricacies.
> >>
> >> In my case, I'm just presenting a raw disk to a VM on a KVM host.
> >>
> >> In that case, HA and live migration depend on the storage plug-in being
> >> able to grant and revoke access to the volume for hosts as needed.
> >>
> >> I'd actually rather not even bother with CHAP when using KVM.
> >>
> >>
> >> On Fri, Sep 27, 2013 at 12:06 AM, Mike Tutkowski <
> >> mike.tutkow...@solidfire.com> wrote:
> >>
> >>> Hey Marcus,
> >>>
> >>> I agree that CHAP does not fulfill the same role as fencing.
> >>>
> >>> I think we're going to have trouble with HA and live migrations on KVM
> if
> >>> the storage plug-in doesn't have a way of knowing when a host wants to
> >>> access a volume and when we want to revoke access to that volume.
> >>>
> >>> We get away without this with XenServer and VMware because - as far as
> I
> >>> know - CS delegates HA and live migration to those clusters and they
> handle
> >>> it most likely with some kind

Re: Libvirt-java 0.5.0 has been released

[Wei ZHOU]

good night


2013/9/27 Mike Tutkowski 

> Sounds good
>
> Might have to get back to you tomorrow, though. I have to get up early. :)
>
>
> On Fri, Sep 27, 2013 at 12:43 AM, Wei ZHOU  wrote:
>
> > ok. Thanks for your reply!
> > The last question, could you try to download the cloudstack-agent and
> > cloudstack-common deb packages, and "dpkg -i" to install it?
> >
> > I will test it on my local machine.
> >
> >
> >
> > 2013/9/27 Mike Tutkowski 
> >
> > > Before re-installing the DEBs I run the following:
> > >
> > > #sudo apt-get remove --purge cloudstack-agent
> > >
> > > #sudo apt-get clean
> > > Would that be sufficient with regards to what you were asking?
> > >
> > >
> > > On Fri, Sep 27, 2013 at 12:36 AM, Wei ZHOU 
> > wrote:
> > >
> > > > What if you apt-get remove and apt-get install again?
> > > >
> > > >
> > > > 2013/9/27 Mike Tutkowski 
> > > >
> > > > > Yeah, I had cleaned, rebuilt the codebase, regenerated the DEBs,
> then
> > > > > apt-get update and apt-get install cloudstack-agent.
> > > > >
> > > > > I can try it again and see what happens. I thought I tried the
> > process
> > > > > twice and got the same results.
> > > > >
> > > > > I did a search for cloudstack-agent-upgrade on my file system and
> > only
> > > > > found references in the source directory.
> > > > >
> > > > >
> > > > > On Fri, Sep 27, 2013 at 12:30 AM, Wei ZHOU 
> > > > wrote:
> > > > >
> > > > > > It is correct.
> > > > > > Have you re-created the cloudstack-agent deb files and uploaded
> to
> > > your
> > > > > > local apt repository?
> > > > > >
> > > > > >
> > > > > > 2013/9/27 Mike Tutkowski 
> > > > > >
> > > > > > > Here you go:
> > > > > > >
> > > > > > > mtutkowski@ubuntu:~/cloudstack$ grep cloudstack-agent-upgrade
> > > > > > debian/rules
> > > > > > > install -D agent/target/transformed/cloudstack-agent-upgrade
> > > > > > > $(DESTDIR)/usr/bin/cloudstack-agent-upgrade
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Sep 27, 2013 at 12:20 AM, Wei ZHOU <
> > ustcweiz...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > > Did you build the latest source?
> > > > > > > > Could you paste the result of the following command in your
> > > source
> > > > > > > > directory?
> > > > > > > > "grep cloudstack-agent-upgrade debian/rules"
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > *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
> > > *™*
> > >
> >
>
>
>
> --
> *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: [DISCUSS] UI: New look and feel

[sebgoa]

On Sep 27, 2013, at 6:52 AM, Shiva Teja  wrote:

> On Fri, Sep 27, 2013 at 9:28 AM, Ian Duffy  wrote:
> 
>> I think so
>> implementation of AngularJS like the way Shiva did it for his GSoC
>> project would be good.
>> 
> 
> I'm trying to setup a demo for my project. This should give an idea about
> the code.
> 
> https://github.com/shivateja/cloudstack-ui/blob/angular-rawapi/static/js/common/resources/virtualmachines.js
> https://github.com/shivateja/cloudstack-ui/blob/angular-rawapi/static/js/app/instances/instances.js
> https://github.com/shivateja/cloudstack-ui/blob/angular-rawapi/static/js/app/instances/instances.tpl.html
> 
> Thanks,
> Shiva Teja

Thanks Shiva, I was going to mention it. 

Shiva has worked on an angular.js app for a cloudstack frontend.
All the code has been contributed in tools/ngui

This could easily be used with Brian new "CSS" and it would clean up all the 
javascript.

-Sebastien

Re: add connect method on KVM storage code

[Marcus Sorensen]

On Fri, Sep 27, 2013 at 12:21 AM, Mike Tutkowski
 wrote:
> Maybe I should seek a little clarification as to how live migration works
> in CS with KVM.
>
> Before we do a live migration of VM 1 from Host 1 to Host 2, do we detach
> all disks from VM1?
>
> If so, then we're good to go there.
>
> I'm not as clear with HA.

During live migration this is what we currently do in our modified
4.1, I'm not sure if the new framework is set up for this, but it
should be made to do this if not.

PrepareForMigrationCommand is called on destination host. In
PrepareForMigrationCommand we added a few lines to call
connectPhysicalDisk. This host connects the SAN disks to this new
host, then creates a paused VM.

MigrateCommand is called on the source host. This sends the proper
command to transfer VM memory, then atomically cuts over to the
destination host. During this time, the disks are attached on both
sides, but the VM is still the only thing that is using them, and it
atomically cuts over. There's no caching on the host (qemu is using
directio), so this is safe.

After MigrateCommand completes it's VM passoff, we detach the disks
before returning.

>
> If VM 1 goes down because Host 1 crashes, is the attach-volume command
> invoked as many times as need be (depending on how many volumes need to be
> attached) when VM 1 is restarted on Host 2?

>From what I can tell, the attachVolume and dettachVolume seemed to
only be for attaching disks to existing, running VMs (i.e. inserting
new XML into an existing domain definition).  Normally when starting a
vm from scratch the vm definition, along with any currently attached
disks, is passed in to StartCommand (which would also be called during
HA restart of a VM). In our 4.1 branch we also have a call to
connectPhysicalDisk here, where we loop through the disk definitions
that were passed.

Again, I should be able to flesh out the differences in 4.2 and how to
go about making this suitable for everyone in the coming days, so long
as you and anyone else writing plugins agree with the changes.

These processes would make sure the disks are available on the hosts
they need to be, but they don't really provide locking or ensure that
only the necessary hosts can write to or see the disks at any given
time. I don't think CHAP does that either. We currently generate ACLs
via our SAN api during connectPhysicalDisk as a safety measure, but if
CloudStack is working properly it will be in charge of controlling
that the disks are only being used where they should be. The ACLs just
ensure that if the VM somehow gets started in two different places
(e.g. HA malfunction), only one of them will have access to the disks.

>
>
> On Fri, Sep 27, 2013 at 12:17 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> Let me clarify this line a bit:
>>
>> "We get away without this with XenServer and VMware because - as far as I
>> know - CS delegates HA and live migration to those clusters and they handle
>> it most likely with some kind of locking protocol on the SR/datastore."
>>
>> When I set up a XenServer or a VMware cluster, all nodes in the cluster
>> have the proper CHAP credentials and can access a shared SR/datastore.
>>
>> HA and live migrations are OK here because the cluster controls access to
>> the VDI on the SR (or VMDK on the datastore) with some kind of locking
>> protocol, I expect.
>>
>> Since KVM isn't really in a cluster outside of the CloudStack world,
>> CloudStack has to handle these intricacies.
>>
>> In my case, I'm just presenting a raw disk to a VM on a KVM host.
>>
>> In that case, HA and live migration depend on the storage plug-in being
>> able to grant and revoke access to the volume for hosts as needed.
>>
>> I'd actually rather not even bother with CHAP when using KVM.
>>
>>
>> On Fri, Sep 27, 2013 at 12:06 AM, Mike Tutkowski <
>> mike.tutkow...@solidfire.com> wrote:
>>
>>> Hey Marcus,
>>>
>>> I agree that CHAP does not fulfill the same role as fencing.
>>>
>>> I think we're going to have trouble with HA and live migrations on KVM if
>>> the storage plug-in doesn't have a way of knowing when a host wants to
>>> access a volume and when we want to revoke access to that volume.
>>>
>>> We get away without this with XenServer and VMware because - as far as I
>>> know - CS delegates HA and live migration to those clusters and they handle
>>> it most likely with some kind of locking protocol on the SR/datastore.
>>>
>>> As far as the path field is concerned, I should be able to populate it
>>> with the IQN of the volume in question.
>>>
>>> One problem I do see, however, is in the getPhysicalDisk method.
>>>
>>> How are you envisioning I keep track of KVMPhysicalDisks that I create in
>>> my connect method?
>>>
>>> Initially I was thinking I'd just keep them in a map. Storage pool UUID
>>> to KVMPhysicalDisks.
>>>
>>> The problem is, how do I reconstruct that map if the agent is restarted
>>> (say the host crashes or is restarted).
>>>
>>> For storage pools, 

Re: Libvirt-java 0.5.0 has been released

[Mike Tutkowski]

Sounds good

Might have to get back to you tomorrow, though. I have to get up early. :)


On Fri, Sep 27, 2013 at 12:43 AM, Wei ZHOU  wrote:

> ok. Thanks for your reply!
> The last question, could you try to download the cloudstack-agent and
> cloudstack-common deb packages, and "dpkg -i" to install it?
>
> I will test it on my local machine.
>
>
>
> 2013/9/27 Mike Tutkowski 
>
> > Before re-installing the DEBs I run the following:
> >
> > #sudo apt-get remove --purge cloudstack-agent
> >
> > #sudo apt-get clean
> > Would that be sufficient with regards to what you were asking?
> >
> >
> > On Fri, Sep 27, 2013 at 12:36 AM, Wei ZHOU 
> wrote:
> >
> > > What if you apt-get remove and apt-get install again?
> > >
> > >
> > > 2013/9/27 Mike Tutkowski 
> > >
> > > > Yeah, I had cleaned, rebuilt the codebase, regenerated the DEBs, then
> > > > apt-get update and apt-get install cloudstack-agent.
> > > >
> > > > I can try it again and see what happens. I thought I tried the
> process
> > > > twice and got the same results.
> > > >
> > > > I did a search for cloudstack-agent-upgrade on my file system and
> only
> > > > found references in the source directory.
> > > >
> > > >
> > > > On Fri, Sep 27, 2013 at 12:30 AM, Wei ZHOU 
> > > wrote:
> > > >
> > > > > It is correct.
> > > > > Have you re-created the cloudstack-agent deb files and uploaded to
> > your
> > > > > local apt repository?
> > > > >
> > > > >
> > > > > 2013/9/27 Mike Tutkowski 
> > > > >
> > > > > > Here you go:
> > > > > >
> > > > > > mtutkowski@ubuntu:~/cloudstack$ grep cloudstack-agent-upgrade
> > > > > debian/rules
> > > > > > install -D agent/target/transformed/cloudstack-agent-upgrade
> > > > > > $(DESTDIR)/usr/bin/cloudstack-agent-upgrade
> > > > > >
> > > > > >
> > > > > > On Fri, Sep 27, 2013 at 12:20 AM, Wei ZHOU <
> ustcweiz...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Did you build the latest source?
> > > > > > > Could you paste the result of the following command in your
> > source
> > > > > > > directory?
> > > > > > > "grep cloudstack-agent-upgrade debian/rules"
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > *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
> > *™*
> >
>



-- 
*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: Libvirt-java 0.5.0 has been released

[Wei ZHOU]

ok. Thanks for your reply!
The last question, could you try to download the cloudstack-agent and
cloudstack-common deb packages, and "dpkg -i" to install it?

I will test it on my local machine.



2013/9/27 Mike Tutkowski 

> Before re-installing the DEBs I run the following:
>
> #sudo apt-get remove --purge cloudstack-agent
>
> #sudo apt-get clean
> Would that be sufficient with regards to what you were asking?
>
>
> On Fri, Sep 27, 2013 at 12:36 AM, Wei ZHOU  wrote:
>
> > What if you apt-get remove and apt-get install again?
> >
> >
> > 2013/9/27 Mike Tutkowski 
> >
> > > Yeah, I had cleaned, rebuilt the codebase, regenerated the DEBs, then
> > > apt-get update and apt-get install cloudstack-agent.
> > >
> > > I can try it again and see what happens. I thought I tried the process
> > > twice and got the same results.
> > >
> > > I did a search for cloudstack-agent-upgrade on my file system and only
> > > found references in the source directory.
> > >
> > >
> > > On Fri, Sep 27, 2013 at 12:30 AM, Wei ZHOU 
> > wrote:
> > >
> > > > It is correct.
> > > > Have you re-created the cloudstack-agent deb files and uploaded to
> your
> > > > local apt repository?
> > > >
> > > >
> > > > 2013/9/27 Mike Tutkowski 
> > > >
> > > > > Here you go:
> > > > >
> > > > > mtutkowski@ubuntu:~/cloudstack$ grep cloudstack-agent-upgrade
> > > > debian/rules
> > > > > install -D agent/target/transformed/cloudstack-agent-upgrade
> > > > > $(DESTDIR)/usr/bin/cloudstack-agent-upgrade
> > > > >
> > > > >
> > > > > On Fri, Sep 27, 2013 at 12:20 AM, Wei ZHOU 
> > > > wrote:
> > > > >
> > > > > > Did you build the latest source?
> > > > > > Could you paste the result of the following command in your
> source
> > > > > > directory?
> > > > > > "grep cloudstack-agent-upgrade debian/rules"
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > *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: Libvirt-java 0.5.0 has been released

[Mike Tutkowski]

Before re-installing the DEBs I run the following:

#sudo apt-get remove --purge cloudstack-agent

#sudo apt-get clean
Would that be sufficient with regards to what you were asking?


On Fri, Sep 27, 2013 at 12:36 AM, Wei ZHOU  wrote:

> What if you apt-get remove and apt-get install again?
>
>
> 2013/9/27 Mike Tutkowski 
>
> > Yeah, I had cleaned, rebuilt the codebase, regenerated the DEBs, then
> > apt-get update and apt-get install cloudstack-agent.
> >
> > I can try it again and see what happens. I thought I tried the process
> > twice and got the same results.
> >
> > I did a search for cloudstack-agent-upgrade on my file system and only
> > found references in the source directory.
> >
> >
> > On Fri, Sep 27, 2013 at 12:30 AM, Wei ZHOU 
> wrote:
> >
> > > It is correct.
> > > Have you re-created the cloudstack-agent deb files and uploaded to your
> > > local apt repository?
> > >
> > >
> > > 2013/9/27 Mike Tutkowski 
> > >
> > > > Here you go:
> > > >
> > > > mtutkowski@ubuntu:~/cloudstack$ grep cloudstack-agent-upgrade
> > > debian/rules
> > > > install -D agent/target/transformed/cloudstack-agent-upgrade
> > > > $(DESTDIR)/usr/bin/cloudstack-agent-upgrade
> > > >
> > > >
> > > > On Fri, Sep 27, 2013 at 12:20 AM, Wei ZHOU 
> > > wrote:
> > > >
> > > > > Did you build the latest source?
> > > > > Could you paste the result of the following command in your source
> > > > > directory?
> > > > > "grep cloudstack-agent-upgrade debian/rules"
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > *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: Libvirt-java 0.5.0 has been released

[Wei ZHOU]

What if you apt-get remove and apt-get install again?


2013/9/27 Mike Tutkowski 

> Yeah, I had cleaned, rebuilt the codebase, regenerated the DEBs, then
> apt-get update and apt-get install cloudstack-agent.
>
> I can try it again and see what happens. I thought I tried the process
> twice and got the same results.
>
> I did a search for cloudstack-agent-upgrade on my file system and only
> found references in the source directory.
>
>
> On Fri, Sep 27, 2013 at 12:30 AM, Wei ZHOU  wrote:
>
> > It is correct.
> > Have you re-created the cloudstack-agent deb files and uploaded to your
> > local apt repository?
> >
> >
> > 2013/9/27 Mike Tutkowski 
> >
> > > Here you go:
> > >
> > > mtutkowski@ubuntu:~/cloudstack$ grep cloudstack-agent-upgrade
> > debian/rules
> > > install -D agent/target/transformed/cloudstack-agent-upgrade
> > > $(DESTDIR)/usr/bin/cloudstack-agent-upgrade
> > >
> > >
> > > On Fri, Sep 27, 2013 at 12:20 AM, Wei ZHOU 
> > wrote:
> > >
> > > > Did you build the latest source?
> > > > Could you paste the result of the following command in your source
> > > > directory?
> > > > "grep cloudstack-agent-upgrade debian/rules"
> > > >
> > >
> > >
> > >
> > > --
> > > *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: Libvirt-java 0.5.0 has been released

[Mike Tutkowski]

Yeah, I had cleaned, rebuilt the codebase, regenerated the DEBs, then
apt-get update and apt-get install cloudstack-agent.

I can try it again and see what happens. I thought I tried the process
twice and got the same results.

I did a search for cloudstack-agent-upgrade on my file system and only
found references in the source directory.


On Fri, Sep 27, 2013 at 12:30 AM, Wei ZHOU  wrote:

> It is correct.
> Have you re-created the cloudstack-agent deb files and uploaded to your
> local apt repository?
>
>
> 2013/9/27 Mike Tutkowski 
>
> > Here you go:
> >
> > mtutkowski@ubuntu:~/cloudstack$ grep cloudstack-agent-upgrade
> debian/rules
> > install -D agent/target/transformed/cloudstack-agent-upgrade
> > $(DESTDIR)/usr/bin/cloudstack-agent-upgrade
> >
> >
> > On Fri, Sep 27, 2013 at 12:20 AM, Wei ZHOU 
> wrote:
> >
> > > Did you build the latest source?
> > > Could you paste the result of the following command in your source
> > > directory?
> > > "grep cloudstack-agent-upgrade debian/rules"
> > >
> >
> >
> >
> > --
> > *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: Libvirt-java 0.5.0 has been released

[Wei ZHOU]

It is correct.
Have you re-created the cloudstack-agent deb files and uploaded to your
local apt repository?


2013/9/27 Mike Tutkowski 

> Here you go:
>
> mtutkowski@ubuntu:~/cloudstack$ grep cloudstack-agent-upgrade debian/rules
> install -D agent/target/transformed/cloudstack-agent-upgrade
> $(DESTDIR)/usr/bin/cloudstack-agent-upgrade
>
>
> On Fri, Sep 27, 2013 at 12:20 AM, Wei ZHOU  wrote:
>
> > Did you build the latest source?
> > Could you paste the result of the following command in your source
> > directory?
> > "grep cloudstack-agent-upgrade debian/rules"
> >
>
>
>
> --
> *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: Libvirt-java 0.5.0 has been released

[Mike Tutkowski]

Here you go:

mtutkowski@ubuntu:~/cloudstack$ grep cloudstack-agent-upgrade debian/rules
install -D agent/target/transformed/cloudstack-agent-upgrade
$(DESTDIR)/usr/bin/cloudstack-agent-upgrade


On Fri, Sep 27, 2013 at 12:20 AM, Wei ZHOU  wrote:

> Did you build the latest source?
> Could you paste the result of the following command in your source
> directory?
> "grep cloudstack-agent-upgrade debian/rules"
>



-- 
*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: cloud-set-guest-password script for ArchLinux?

[Wei ZHOU]

you can try ./setup/bindir/cloud-set-guest-password.in in cloudstack source
code.
https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=tree;f=setup/bindir;hb=HEAD


2013/9/27 Indra Pramana 

> Dear all,
>
> I am trying to create CloudStack OS template for ArchLinux. However, I am
> not able to find the cloud-set-guest-password password management template
> script for ArchLinux. Under the shankerbalan's github site, there are only
> scripts for CentOS, Ubuntu, Debian, FreeBSD and SLES:
>
> https://github.com/shankerbalan/cloudstack-scripts
>
> Where can I get the password management template script for ArchLinux?
>
> Looking forward to your reply, thank you.
>
> Cheers.
>

Re: add connect method on KVM storage code

[Mike Tutkowski]

Maybe I should seek a little clarification as to how live migration works
in CS with KVM.

Before we do a live migration of VM 1 from Host 1 to Host 2, do we detach
all disks from VM1?

If so, then we're good to go there.

I'm not as clear with HA.

If VM 1 goes down because Host 1 crashes, is the attach-volume command
invoked as many times as need be (depending on how many volumes need to be
attached) when VM 1 is restarted on Host 2?


On Fri, Sep 27, 2013 at 12:17 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Let me clarify this line a bit:
>
> "We get away without this with XenServer and VMware because - as far as I
> know - CS delegates HA and live migration to those clusters and they handle
> it most likely with some kind of locking protocol on the SR/datastore."
>
> When I set up a XenServer or a VMware cluster, all nodes in the cluster
> have the proper CHAP credentials and can access a shared SR/datastore.
>
> HA and live migrations are OK here because the cluster controls access to
> the VDI on the SR (or VMDK on the datastore) with some kind of locking
> protocol, I expect.
>
> Since KVM isn't really in a cluster outside of the CloudStack world,
> CloudStack has to handle these intricacies.
>
> In my case, I'm just presenting a raw disk to a VM on a KVM host.
>
> In that case, HA and live migration depend on the storage plug-in being
> able to grant and revoke access to the volume for hosts as needed.
>
> I'd actually rather not even bother with CHAP when using KVM.
>
>
> On Fri, Sep 27, 2013 at 12:06 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> Hey Marcus,
>>
>> I agree that CHAP does not fulfill the same role as fencing.
>>
>> I think we're going to have trouble with HA and live migrations on KVM if
>> the storage plug-in doesn't have a way of knowing when a host wants to
>> access a volume and when we want to revoke access to that volume.
>>
>> We get away without this with XenServer and VMware because - as far as I
>> know - CS delegates HA and live migration to those clusters and they handle
>> it most likely with some kind of locking protocol on the SR/datastore.
>>
>> As far as the path field is concerned, I should be able to populate it
>> with the IQN of the volume in question.
>>
>> One problem I do see, however, is in the getPhysicalDisk method.
>>
>> How are you envisioning I keep track of KVMPhysicalDisks that I create in
>> my connect method?
>>
>> Initially I was thinking I'd just keep them in a map. Storage pool UUID
>> to KVMPhysicalDisks.
>>
>> The problem is, how do I reconstruct that map if the agent is restarted
>> (say the host crashes or is restarted).
>>
>> For storage pools, we get a message (ModifyStoragePoolCommand) from the
>> CS MS to tell us about all of the relevant storage pools. With this
>> message, I can reconstruct my cache of storage pools. No problem there.
>>
>> But how will I know which volumes belong to a given storage pool if I
>> have to rebuild that map? How will I even know which volumes are in use at
>> all?
>>
>> Thanks
>>
>>
>> On Thu, Sep 26, 2013 at 11:37 PM, Marcus Sorensen wrote:
>>
>>> On Thu, Sep 26, 2013 at 10:23 PM, Mike Tutkowski
>>>  wrote:
>>> > My comments are inline:
>>> >
>>> >
>>> > On Thu, Sep 26, 2013 at 9:10 PM, Marcus Sorensen >> >wrote:
>>> >
>>> >> Ok, let me digest this a bit. I got the github responses but I'd also
>>> >> like to keep it on-list as well.
>>> >>
>>> >>  My initial thoughts are:
>>> >>
>>> >> 1) I don't think disk format and size are necessary parameters for
>>> >> connectPhysicalDisk, as the format can be determined by the adaptor,
>>> >> and the size is set during the createAsync call in the plugin. We
>>> >> really just need the disk path and the pool.
>>> >>
>>> > [Mike T.] I agree, format is not needed. The only reason I have size
>>> passed
>>> > in is because I need to create a KVMPhysicalDisk at the end of the
>>> connect
>>> > method. Since this KVMPhysicalDisk is (in the code on GitHub) being
>>> used to
>>> > create our XML to attach the disk, I figured we'd need that size. The
>>> > KVMPhysicalDisk I produce from my implementation of getPhysicalDisk is
>>> not
>>> > as good because I don't know the size of the disk at this point (I
>>> don't
>>> > keep that information around). The reason I don't keep that info
>>> around is
>>> > because I don't have a good way to reproduce that info if the KVM host
>>> is
>>> > rebooted. We get info about storage pools in the form of a
>>> > ModifyStoragePoolCommand, but nothing about the volumes inside of the
>>> > storage pool.
>>>
>>> getPhysicalDisk is called in a bunch of places. I'd rely on the
>>> connectPhysicalDisk to only make the block device appear on the host,
>>> and then getPhysicalDisk to find that block device and fill out things
>>> like disk size and path (the real path to the local block device) for
>>> passing and creating the disk XML. Trust me, unless things have
>>> changed significantly you need to be abl

Re: Libvirt-java 0.5.0 has been released

[Wei ZHOU]

Did you build the latest source?
Could you paste the result of the following command in your source
directory?
"grep cloudstack-agent-upgrade debian/rules"

Re: add connect method on KVM storage code

[Mike Tutkowski]

Let me clarify this line a bit:

"We get away without this with XenServer and VMware because - as far as I
know - CS delegates HA and live migration to those clusters and they handle
it most likely with some kind of locking protocol on the SR/datastore."

When I set up a XenServer or a VMware cluster, all nodes in the cluster
have the proper CHAP credentials and can access a shared SR/datastore.

HA and live migrations are OK here because the cluster controls access to
the VDI on the SR (or VMDK on the datastore) with some kind of locking
protocol, I expect.

Since KVM isn't really in a cluster outside of the CloudStack world,
CloudStack has to handle these intricacies.

In my case, I'm just presenting a raw disk to a VM on a KVM host.

In that case, HA and live migration depend on the storage plug-in being
able to grant and revoke access to the volume for hosts as needed.

I'd actually rather not even bother with CHAP when using KVM.


On Fri, Sep 27, 2013 at 12:06 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hey Marcus,
>
> I agree that CHAP does not fulfill the same role as fencing.
>
> I think we're going to have trouble with HA and live migrations on KVM if
> the storage plug-in doesn't have a way of knowing when a host wants to
> access a volume and when we want to revoke access to that volume.
>
> We get away without this with XenServer and VMware because - as far as I
> know - CS delegates HA and live migration to those clusters and they handle
> it most likely with some kind of locking protocol on the SR/datastore.
>
> As far as the path field is concerned, I should be able to populate it
> with the IQN of the volume in question.
>
> One problem I do see, however, is in the getPhysicalDisk method.
>
> How are you envisioning I keep track of KVMPhysicalDisks that I create in
> my connect method?
>
> Initially I was thinking I'd just keep them in a map. Storage pool UUID to
> KVMPhysicalDisks.
>
> The problem is, how do I reconstruct that map if the agent is restarted
> (say the host crashes or is restarted).
>
> For storage pools, we get a message (ModifyStoragePoolCommand) from the CS
> MS to tell us about all of the relevant storage pools. With this message, I
> can reconstruct my cache of storage pools. No problem there.
>
> But how will I know which volumes belong to a given storage pool if I have
> to rebuild that map? How will I even know which volumes are in use at all?
>
> Thanks
>
>
> On Thu, Sep 26, 2013 at 11:37 PM, Marcus Sorensen wrote:
>
>> On Thu, Sep 26, 2013 at 10:23 PM, Mike Tutkowski
>>  wrote:
>> > My comments are inline:
>> >
>> >
>> > On Thu, Sep 26, 2013 at 9:10 PM, Marcus Sorensen > >wrote:
>> >
>> >> Ok, let me digest this a bit. I got the github responses but I'd also
>> >> like to keep it on-list as well.
>> >>
>> >>  My initial thoughts are:
>> >>
>> >> 1) I don't think disk format and size are necessary parameters for
>> >> connectPhysicalDisk, as the format can be determined by the adaptor,
>> >> and the size is set during the createAsync call in the plugin. We
>> >> really just need the disk path and the pool.
>> >>
>> > [Mike T.] I agree, format is not needed. The only reason I have size
>> passed
>> > in is because I need to create a KVMPhysicalDisk at the end of the
>> connect
>> > method. Since this KVMPhysicalDisk is (in the code on GitHub) being
>> used to
>> > create our XML to attach the disk, I figured we'd need that size. The
>> > KVMPhysicalDisk I produce from my implementation of getPhysicalDisk is
>> not
>> > as good because I don't know the size of the disk at this point (I don't
>> > keep that information around). The reason I don't keep that info around
>> is
>> > because I don't have a good way to reproduce that info if the KVM host
>> is
>> > rebooted. We get info about storage pools in the form of a
>> > ModifyStoragePoolCommand, but nothing about the volumes inside of the
>> > storage pool.
>>
>> getPhysicalDisk is called in a bunch of places. I'd rely on the
>> connectPhysicalDisk to only make the block device appear on the host,
>> and then getPhysicalDisk to find that block device and fill out things
>> like disk size and path (the real path to the local block device) for
>> passing and creating the disk XML. Trust me, unless things have
>> changed significantly you need to be able to identify a given device
>> as a specific local disk by whatever you are setting the 'path'
>> attribute to be.  getPhysicalDisk will be called on your storage pool
>> with simply the path attribute, and via your adaptor with the pool and
>> path.
>>
>> So you may set path as some combination of iqn and target/pool info,
>> or if iqn is enough to identify a unique block device (in
>> /dev/disk/by-id maybe?) on a host then just use that. Path just needs
>> to be something, anything, to identify the disk on the host. In
>> getPhysicalDisk, identify the local block device matching the info,
>> create a new KVMPhysicalDisk with the local path, size, etc,

Re: add connect method on KVM storage code

[Marcus Sorensen]

On Fri, Sep 27, 2013 at 12:06 AM, Mike Tutkowski
 wrote:
> Hey Marcus,
>
> I agree that CHAP does not fulfill the same role as fencing.
>
> I think we're going to have trouble with HA and live migrations on KVM if
> the storage plug-in doesn't have a way of knowing when a host wants to
> access a volume and when we want to revoke access to that volume.

Well, if attachVolume and "dettachVolume" are called in the
appropriate places, it shouldn't be an issue, just like they should be
called before a VM is started to get the disks ready. I plan on
playing with this in 4.2 over the next few days, and can confirm.

>
> We get away without this with XenServer and VMware because - as far as I
> know - CS delegates HA and live migration to those clusters and they handle
> it most likely with some kind of locking protocol on the SR/datastore.
>
> As far as the path field is concerned, I should be able to populate it with
> the IQN of the volume in question.

Ok, that will be good, sounds like you'll be able to ID a local block
device by that.

>
> One problem I do see, however, is in the getPhysicalDisk method.
>
> How are you envisioning I keep track of KVMPhysicalDisks that I create in
> my connect method?

I'll need to look through the changes to be sure, but you may not have
to keep track of them. You should always be passed your iqn and you
can always find the local disk and create a new KVMPhysicalDisk object
to return.

>
> Initially I was thinking I'd just keep them in a map. Storage pool UUID to
> KVMPhysicalDisks.
>
> The problem is, how do I reconstruct that map if the agent is restarted
> (say the host crashes or is restarted).
>
> For storage pools, we get a message (ModifyStoragePoolCommand) from the CS
> MS to tell us about all of the relevant storage pools. With this message, I
> can reconstruct my cache of storage pools. No problem there.
>
> But how will I know which volumes belong to a given storage pool if I have
> to rebuild that map? How will I even know which volumes are in use at all?
>
> Thanks
>
>
> On Thu, Sep 26, 2013 at 11:37 PM, Marcus Sorensen wrote:
>
>> On Thu, Sep 26, 2013 at 10:23 PM, Mike Tutkowski
>>  wrote:
>> > My comments are inline:
>> >
>> >
>> > On Thu, Sep 26, 2013 at 9:10 PM, Marcus Sorensen > >wrote:
>> >
>> >> Ok, let me digest this a bit. I got the github responses but I'd also
>> >> like to keep it on-list as well.
>> >>
>> >>  My initial thoughts are:
>> >>
>> >> 1) I don't think disk format and size are necessary parameters for
>> >> connectPhysicalDisk, as the format can be determined by the adaptor,
>> >> and the size is set during the createAsync call in the plugin. We
>> >> really just need the disk path and the pool.
>> >>
>> > [Mike T.] I agree, format is not needed. The only reason I have size
>> passed
>> > in is because I need to create a KVMPhysicalDisk at the end of the
>> connect
>> > method. Since this KVMPhysicalDisk is (in the code on GitHub) being used
>> to
>> > create our XML to attach the disk, I figured we'd need that size. The
>> > KVMPhysicalDisk I produce from my implementation of getPhysicalDisk is
>> not
>> > as good because I don't know the size of the disk at this point (I don't
>> > keep that information around). The reason I don't keep that info around
>> is
>> > because I don't have a good way to reproduce that info if the KVM host is
>> > rebooted. We get info about storage pools in the form of a
>> > ModifyStoragePoolCommand, but nothing about the volumes inside of the
>> > storage pool.
>>
>> getPhysicalDisk is called in a bunch of places. I'd rely on the
>> connectPhysicalDisk to only make the block device appear on the host,
>> and then getPhysicalDisk to find that block device and fill out things
>> like disk size and path (the real path to the local block device) for
>> passing and creating the disk XML. Trust me, unless things have
>> changed significantly you need to be able to identify a given device
>> as a specific local disk by whatever you are setting the 'path'
>> attribute to be.  getPhysicalDisk will be called on your storage pool
>> with simply the path attribute, and via your adaptor with the pool and
>> path.
>>
>> So you may set path as some combination of iqn and target/pool info,
>> or if iqn is enough to identify a unique block device (in
>> /dev/disk/by-id maybe?) on a host then just use that. Path just needs
>> to be something, anything, to identify the disk on the host. In
>> getPhysicalDisk, identify the local block device matching the info,
>> create a new KVMPhysicalDisk with the local path, size, etc, and
>> return it.
>>
>> >
>> >>
>> >> 2) I thought this access group thing you mention are the grantAccess
>> >> and revokeAccess calls in the storage plugin 2.0 design doc. Was that
>> >> not implemented?
>> >>
>> > [Mike T.] Yeah, as I mentioned in an e-mail way back, those methods were
>> > never implemented in 4.2. I think you said you were going to get around
>> > them not being implemented by keeping c

Re: Libvirt-java 0.5.0 has been released

[Mike Tutkowski]

It collects info like management server IP address, zone id, cluster id,
etc.

The problem appears to be we are trying to invoke a script that does not
exist when I'm doing a sudo apt-get install cloudstack-agent.


On Thu, Sep 26, 2013 at 10:48 PM, Wei ZHOU  wrote:

> Mike,
> What happen if you execute cloudstack-setup-agent?
>
>
> 2013/9/27 Mike Tutkowski 
>
> > Looks like the newly checked in code is looking for
> > /usr/bin/cloudstack-agent-upgrade.
> >
> > I don't see that file in /usr/bin, however.
> >
> > I only see the following cloudstack* in /usr/bin:
> >
> > cloudstack-set-guest-password
> > cloudstack-set-guest-sshkey
> > cloudstack-setup-agent
> > cloudstack-ssh
> >
> >
> > On Thu, Sep 26, 2013 at 3:41 PM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> > > Looks like the new code references cloudstack-agent-upgrade.
> > >
> > > I'm on Ubuntu 12.04, by the way.
> > >
> > > /var/lib/dpkg/info/cloudstack-agent.postinst: line 39:
> > > /usr/bin/cloudstack-agent-upgrade: No such file or directory
> > > dpkg: error processing cloudstack-agent (--configure):
> > >  subprocess installed post-installation script returned error exit
> > status 1
> > > Errors were encountered while processing:
> > >  cloudstack-agent
> > > E: Sub-process /usr/bin/dpkg returned an error code (1)
> > >
> > >
> > >
> > > On Thu, Sep 26, 2013 at 2:57 PM, Mike Tutkowski <
> > > mike.tutkow...@solidfire.com> wrote:
> > >
> > >> OK, thanks!
> > >>
> > >>
> > >> On Thu, Sep 26, 2013 at 2:52 PM, Wei ZHOU 
> > wrote:
> > >>
> > >>> Mike,
> > >>> Sorry my fault. already fixed by commit
> > >>> 522860c03de5d05126f92fc44b6e3f50ed8439f0
> > >>> Please pull the latest code.
> > >>>
> > >>>
> > >>> 2013/9/26 Mike Tutkowski 
> > >>>
> > >>> > Any thoughts on this error message?
> > >>> >
> > >>> > I updated from master today, cleaned, recompiled, then rebuilt and
> > >>> > redeployed the DEBs.
> > >>> >
> > >>> > Thanks
> > >>> >
> > >>> > mtutkowski@ubuntu:~$ sudo apt-get install cloudstack-agent
> > >>> > Reading package lists... Done
> > >>> > Building dependency tree
> > >>> > Reading state information... Done
> > >>> > The following NEW packages will be installed:
> > >>> >   cloudstack-agent
> > >>> > 0 upgraded, 1 newly installed, 0 to remove and 468 not upgraded.
> > >>> > Need to get 39.1 MB of archives.
> > >>> > After this operation, 43.6 MB of additional disk space will be
> used.
> > >>> > WARNING: The following packages cannot be authenticated!
> > >>> >   cloudstack-agent
> > >>> > Install these packages without verification [y/N]? y
> > >>> > Get:1 http://localhost/cloudstack/repo/ binary/ cloudstack-agent
> > 4.3.0
> > >>> > [39.1 MB]
> > >>> > Fetched 39.1 MB in 0s (49.3 MB/s)
> > >>> > Selecting previously unselected package cloudstack-agent.
> > >>> > (Reading database ... 168800 files and directories currently
> > >>> installed.)
> > >>> > Unpacking cloudstack-agent (from
> .../cloudstack-agent_4.3.0_all.deb)
> > >>> ...
> > >>> > Processing triggers for ureadahead ...
> > >>> > Setting up cloudstack-agent (4.3.0) ...
> > >>> > /var/lib/dpkg/info/cloudstack-agent.postinst: line 39:
> > >>> > /usr/bin/cloudstack-agent-upgrade: No such file or directory
> > >>> > dpkg: error processing cloudstack-agent (--configure):
> > >>> >  subprocess installed post-installation script returned error exit
> > >>> status 1
> > >>> > E: Sub-process /usr/bin/dpkg returned an error code (1)
> > >>> >
> > >>> >
> > >>> >
> > >>> > On Thu, Sep 26, 2013 at 8:45 AM, Mike Tutkowski <
> > >>> > mike.tutkow...@solidfire.com> wrote:
> > >>> >
> > >>> > > Let me update and try again and see if that solves the problem.
> > >>> > >
> > >>> > > I am probably a week behind on updating from master.
> > >>> > >
> > >>> > > Thanks
> > >>> > >
> > >>> > >
> > >>> > > On Wed, Sep 25, 2013 at 11:18 PM, Wei ZHOU <
> ustcweiz...@gmail.com>
> > >>> > wrote:
> > >>> > >
> > >>> > >> Mike,
> > >>> > >> Do you test the latest source code?
> > >>> > >>
> > >>> > >>  Pointer.nativeValue  is introduced in jna-3.2.6
> > >>> > >>
> > >>> > >>
> > >>> >
> > >>>
> >
> http://upstream-tracker.org/java/compat_reports/jna/3.2.5_to_3.2.6/bin_compat_report.html
> > >>> > >> and Native.free  is introduced in jna-3.3.0
> > >>> > >>
> > >>> > >>
> > >>> >
> > >>>
> >
> http://upstream-tracker.org/java/compat_reports/jna/3.2.7_to_3.3.0/bin_compat_report.html
> > >>> > >>
> > >>> > >> After commit 3dc4284,  jna-4.0.0.jar is in
> > >>> > /usr/share/cloudstack-agent/lib
> > >>> > >> , then it should be ok.
> > >>> > >>
> > >>> > >> -Wei
> > >>> > >>
> > >>> > >>
> > >>> > >> 2013/9/26 Mike Tutkowski 
> > >>> > >>
> > >>> > >> > Hi,
> > >>> > >> >
> > >>> > >> > I've been having a difficult time getting the KVM agent on
> > master
> > >>> to
> > >>> > >> start
> > >>> > >> > on Ubuntu 12.04.
> > >>> > >> >
> > >>> > >> > The trouble seems to have begun after the Libvirt upgrade.
> > >>> > >> >
> > >>> > >> > Any thoughts on this:
> > >>> > >> >
> > >>> > >> > Tha

cloud-set-guest-password script for ArchLinux?

[Indra Pramana]

Dear all,

I am trying to create CloudStack OS template for ArchLinux. However, I am
not able to find the cloud-set-guest-password password management template
script for ArchLinux. Under the shankerbalan's github site, there are only
scripts for CentOS, Ubuntu, Debian, FreeBSD and SLES:

https://github.com/shankerbalan/cloudstack-scripts

Where can I get the password management template script for ArchLinux?

Looking forward to your reply, thank you.

Cheers.

Re: add connect method on KVM storage code

[Mike Tutkowski]

Hey Marcus,

I agree that CHAP does not fulfill the same role as fencing.

I think we're going to have trouble with HA and live migrations on KVM if
the storage plug-in doesn't have a way of knowing when a host wants to
access a volume and when we want to revoke access to that volume.

We get away without this with XenServer and VMware because - as far as I
know - CS delegates HA and live migration to those clusters and they handle
it most likely with some kind of locking protocol on the SR/datastore.

As far as the path field is concerned, I should be able to populate it with
the IQN of the volume in question.

One problem I do see, however, is in the getPhysicalDisk method.

How are you envisioning I keep track of KVMPhysicalDisks that I create in
my connect method?

Initially I was thinking I'd just keep them in a map. Storage pool UUID to
KVMPhysicalDisks.

The problem is, how do I reconstruct that map if the agent is restarted
(say the host crashes or is restarted).

For storage pools, we get a message (ModifyStoragePoolCommand) from the CS
MS to tell us about all of the relevant storage pools. With this message, I
can reconstruct my cache of storage pools. No problem there.

But how will I know which volumes belong to a given storage pool if I have
to rebuild that map? How will I even know which volumes are in use at all?

Thanks


On Thu, Sep 26, 2013 at 11:37 PM, Marcus Sorensen wrote:

> On Thu, Sep 26, 2013 at 10:23 PM, Mike Tutkowski
>  wrote:
> > My comments are inline:
> >
> >
> > On Thu, Sep 26, 2013 at 9:10 PM, Marcus Sorensen  >wrote:
> >
> >> Ok, let me digest this a bit. I got the github responses but I'd also
> >> like to keep it on-list as well.
> >>
> >>  My initial thoughts are:
> >>
> >> 1) I don't think disk format and size are necessary parameters for
> >> connectPhysicalDisk, as the format can be determined by the adaptor,
> >> and the size is set during the createAsync call in the plugin. We
> >> really just need the disk path and the pool.
> >>
> > [Mike T.] I agree, format is not needed. The only reason I have size
> passed
> > in is because I need to create a KVMPhysicalDisk at the end of the
> connect
> > method. Since this KVMPhysicalDisk is (in the code on GitHub) being used
> to
> > create our XML to attach the disk, I figured we'd need that size. The
> > KVMPhysicalDisk I produce from my implementation of getPhysicalDisk is
> not
> > as good because I don't know the size of the disk at this point (I don't
> > keep that information around). The reason I don't keep that info around
> is
> > because I don't have a good way to reproduce that info if the KVM host is
> > rebooted. We get info about storage pools in the form of a
> > ModifyStoragePoolCommand, but nothing about the volumes inside of the
> > storage pool.
>
> getPhysicalDisk is called in a bunch of places. I'd rely on the
> connectPhysicalDisk to only make the block device appear on the host,
> and then getPhysicalDisk to find that block device and fill out things
> like disk size and path (the real path to the local block device) for
> passing and creating the disk XML. Trust me, unless things have
> changed significantly you need to be able to identify a given device
> as a specific local disk by whatever you are setting the 'path'
> attribute to be.  getPhysicalDisk will be called on your storage pool
> with simply the path attribute, and via your adaptor with the pool and
> path.
>
> So you may set path as some combination of iqn and target/pool info,
> or if iqn is enough to identify a unique block device (in
> /dev/disk/by-id maybe?) on a host then just use that. Path just needs
> to be something, anything, to identify the disk on the host. In
> getPhysicalDisk, identify the local block device matching the info,
> create a new KVMPhysicalDisk with the local path, size, etc, and
> return it.
>
> >
> >>
> >> 2) I thought this access group thing you mention are the grantAccess
> >> and revokeAccess calls in the storage plugin 2.0 design doc. Was that
> >> not implemented?
> >>
> > [Mike T.] Yeah, as I mentioned in an e-mail way back, those methods were
> > never implemented in 4.2. I think you said you were going to get around
> > them not being implemented by keeping certain logic that talks to the SAN
> > in the agent. I don't think we want any SolidFire-specific code in the
> > agent, however, so I can't go that route. If those methods do not get
> > implemented in 4.3, then I will need to use CHAP credentials for KVM
> (just
> > like I did with XenServer and VMware).
>
> I initially figured your StorageAdaptor implementation would be all
> solidfire specific, just like the mgmt server side plugin is. If it
> can be generic to all iscsi storage then that's great. I agree that
> ideally the agent wouldn't be making API calls to your SAN. I don't
> think it should be necessary given that you're not going to use the
> ACL route. I'm not sure CHAP fills the same purpose of fencing.
>
> >
> >>
> >> I see you've  

Re: add connect method on KVM storage code

[Marcus Sorensen]

On Thu, Sep 26, 2013 at 10:23 PM, Mike Tutkowski
 wrote:
> My comments are inline:
>
>
> On Thu, Sep 26, 2013 at 9:10 PM, Marcus Sorensen wrote:
>
>> Ok, let me digest this a bit. I got the github responses but I'd also
>> like to keep it on-list as well.
>>
>>  My initial thoughts are:
>>
>> 1) I don't think disk format and size are necessary parameters for
>> connectPhysicalDisk, as the format can be determined by the adaptor,
>> and the size is set during the createAsync call in the plugin. We
>> really just need the disk path and the pool.
>>
> [Mike T.] I agree, format is not needed. The only reason I have size passed
> in is because I need to create a KVMPhysicalDisk at the end of the connect
> method. Since this KVMPhysicalDisk is (in the code on GitHub) being used to
> create our XML to attach the disk, I figured we'd need that size. The
> KVMPhysicalDisk I produce from my implementation of getPhysicalDisk is not
> as good because I don't know the size of the disk at this point (I don't
> keep that information around). The reason I don't keep that info around is
> because I don't have a good way to reproduce that info if the KVM host is
> rebooted. We get info about storage pools in the form of a
> ModifyStoragePoolCommand, but nothing about the volumes inside of the
> storage pool.

getPhysicalDisk is called in a bunch of places. I'd rely on the
connectPhysicalDisk to only make the block device appear on the host,
and then getPhysicalDisk to find that block device and fill out things
like disk size and path (the real path to the local block device) for
passing and creating the disk XML. Trust me, unless things have
changed significantly you need to be able to identify a given device
as a specific local disk by whatever you are setting the 'path'
attribute to be.  getPhysicalDisk will be called on your storage pool
with simply the path attribute, and via your adaptor with the pool and
path.

So you may set path as some combination of iqn and target/pool info,
or if iqn is enough to identify a unique block device (in
/dev/disk/by-id maybe?) on a host then just use that. Path just needs
to be something, anything, to identify the disk on the host. In
getPhysicalDisk, identify the local block device matching the info,
create a new KVMPhysicalDisk with the local path, size, etc, and
return it.

>
>>
>> 2) I thought this access group thing you mention are the grantAccess
>> and revokeAccess calls in the storage plugin 2.0 design doc. Was that
>> not implemented?
>>
> [Mike T.] Yeah, as I mentioned in an e-mail way back, those methods were
> never implemented in 4.2. I think you said you were going to get around
> them not being implemented by keeping certain logic that talks to the SAN
> in the agent. I don't think we want any SolidFire-specific code in the
> agent, however, so I can't go that route. If those methods do not get
> implemented in 4.3, then I will need to use CHAP credentials for KVM (just
> like I did with XenServer and VMware).

I initially figured your StorageAdaptor implementation would be all
solidfire specific, just like the mgmt server side plugin is. If it
can be generic to all iscsi storage then that's great. I agree that
ideally the agent wouldn't be making API calls to your SAN. I don't
think it should be necessary given that you're not going to use the
ACL route. I'm not sure CHAP fills the same purpose of fencing.

>
>>
>> I see you've  added getters/setters for the attach cmd to pass the
>> iscsi info you need. Would it perhaps be possible to send a details
>> Map instead? Then any plugin implementer could attach
>> arbitrary data they need. So it might be
>> connectPhysicalDisk(StoragePoolType type, String poolUuid, String
>> volPath, Map details)?  I'll have to look and see
>> where those cmd. attributes are set, ideally it would be all the way
>> back in the plugin to avoid custom code for every adaptor that wants
>> to set details.
>>
> [Mike T.] If I'm not using the volumes.path field for anything, I can stick
> the IQN in volumes.path (as well as leaving it in volumes.iscsi_name, which
> is used elsewhere). That way we only have to ask for getPath().

Yeah, whatever it is that you'd need to find the right block device
should go in the path. If you look through LibvirtComputingResource
you'll see stuff like this sprinkled around:

KVMPhysicalDisk volume = primaryPool.getPhysicalDisk(cmd
.getVolumePath());


or:
String volid = cmd.getPath();
 KVMPhysicalDisk vol = pool.getPhysicalDisk(volid);

or:

KVMPhysicalDisk physicalDisk =
_storagePoolMgr.getPhysicalDisk( store.getPoolType(),
store.getUuid(),
data.getPath());

Maybe some of it is short-circuited by the new KVMStorageProcessor,
but I'd still implement a working one, and then attachVolume can call
getPhysicalDisk after connectPhysicalDisk, even on your adaptor/pool.

>
>>
>> On Thu, Sep 26

Re: Problem using DevCloud2 with 4.2

[Mike Tutkowski]

Eh...cancel my query here.

I just repeated the steps and it worked this time.

Odd

Hopefully it was user error and this isn't a timing issue or something.


On Thu, Sep 26, 2013 at 10:38 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hi,
>
> I haven't tried to use DevCloud2 in a while (generally been setting up CS
> manually). I noticed the following problem when running the typical setup
> script today:
>
> mtutkowski-LT:~ mtutkowski$ cd
> documents/cloudstack/src/cloudstack/tools/devcloud ; python
> ../marvin/marvin/deployDataCenter.py -i devcloud.cfg
> Traceback (most recent call last):
>   File "../marvin/marvin/deployDataCenter.py", line 613, in 
> deploy.deploy()
>   File "../marvin/marvin/deployDataCenter.py", line 598, in deploy
> self.createZones(self.config.zones)
>   File "../marvin/marvin/deployDataCenter.py", line 389, in createZones
> zoneresponse = self.apiClient.createZone(createzone)
>   File
> "/Users/mtutkowski/Documents/CloudStack/src/CloudStack/tools/marvin/marvin/cloudstackAPI/cloudstackAPIClient.py",
> line 1242, in createZone
> response = self.connection.marvin_request(command,
> response_type=response, method=method)
>   File
> "/Users/mtutkowski/Documents/CloudStack/src/CloudStack/tools/marvin/marvin/cloudstackConnection.py",
> line 222, in marvin_request
> response = jsonHelper.getResultObj(response.json(), response_type)
>   File
> "/Users/mtutkowski/Documents/CloudStack/src/CloudStack/tools/marvin/marvin/jsonHelper.py",
> line 148, in getResultObj
> raise cloudstackException.cloudstackAPIException(respname, errMsg)
> cloudstackException.cloudstackAPIException: Execute cmd: createzone
> failed, due to: errorCode: 401, errorText:unable to verify user credentials
> and/or request signature
>
> On the management server console side:
>
> INFO  [cloud.api.ApiServer] (1841029180@qtp-1791812015-0:) disabled or
> locked user accessing the api, userid = 2; name = admin; state: disabled;
> accountState: enabled
>
> Has anything changed recently with regards to how we use DevCloud2?
>
> I started with a clean build, cleaned the DB, and had reset DevCloud2 to
> its initial state before running the setup script.
>
> 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
*™*

Re: [DISCUSS] UI: New look and feel

[Shiva Teja]

On Fri, Sep 27, 2013 at 9:28 AM, Ian Duffy  wrote:

> I think so
> implementation of AngularJS like the way Shiva did it for his GSoC
> project would be good.
>

I'm trying to setup a demo for my project. This should give an idea about
the code.

https://github.com/shivateja/cloudstack-ui/blob/angular-rawapi/static/js/common/resources/virtualmachines.js
https://github.com/shivateja/cloudstack-ui/blob/angular-rawapi/static/js/app/instances/instances.js
https://github.com/shivateja/cloudstack-ui/blob/angular-rawapi/static/js/app/instances/instances.tpl.html

Thanks,
Shiva Teja

Re: Libvirt-java 0.5.0 has been released

[Wei ZHOU]

Mike,
What happen if you execute cloudstack-setup-agent?


2013/9/27 Mike Tutkowski 

> Looks like the newly checked in code is looking for
> /usr/bin/cloudstack-agent-upgrade.
>
> I don't see that file in /usr/bin, however.
>
> I only see the following cloudstack* in /usr/bin:
>
> cloudstack-set-guest-password
> cloudstack-set-guest-sshkey
> cloudstack-setup-agent
> cloudstack-ssh
>
>
> On Thu, Sep 26, 2013 at 3:41 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > Looks like the new code references cloudstack-agent-upgrade.
> >
> > I'm on Ubuntu 12.04, by the way.
> >
> > /var/lib/dpkg/info/cloudstack-agent.postinst: line 39:
> > /usr/bin/cloudstack-agent-upgrade: No such file or directory
> > dpkg: error processing cloudstack-agent (--configure):
> >  subprocess installed post-installation script returned error exit
> status 1
> > Errors were encountered while processing:
> >  cloudstack-agent
> > E: Sub-process /usr/bin/dpkg returned an error code (1)
> >
> >
> >
> > On Thu, Sep 26, 2013 at 2:57 PM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> >> OK, thanks!
> >>
> >>
> >> On Thu, Sep 26, 2013 at 2:52 PM, Wei ZHOU 
> wrote:
> >>
> >>> Mike,
> >>> Sorry my fault. already fixed by commit
> >>> 522860c03de5d05126f92fc44b6e3f50ed8439f0
> >>> Please pull the latest code.
> >>>
> >>>
> >>> 2013/9/26 Mike Tutkowski 
> >>>
> >>> > Any thoughts on this error message?
> >>> >
> >>> > I updated from master today, cleaned, recompiled, then rebuilt and
> >>> > redeployed the DEBs.
> >>> >
> >>> > Thanks
> >>> >
> >>> > mtutkowski@ubuntu:~$ sudo apt-get install cloudstack-agent
> >>> > Reading package lists... Done
> >>> > Building dependency tree
> >>> > Reading state information... Done
> >>> > The following NEW packages will be installed:
> >>> >   cloudstack-agent
> >>> > 0 upgraded, 1 newly installed, 0 to remove and 468 not upgraded.
> >>> > Need to get 39.1 MB of archives.
> >>> > After this operation, 43.6 MB of additional disk space will be used.
> >>> > WARNING: The following packages cannot be authenticated!
> >>> >   cloudstack-agent
> >>> > Install these packages without verification [y/N]? y
> >>> > Get:1 http://localhost/cloudstack/repo/ binary/ cloudstack-agent
> 4.3.0
> >>> > [39.1 MB]
> >>> > Fetched 39.1 MB in 0s (49.3 MB/s)
> >>> > Selecting previously unselected package cloudstack-agent.
> >>> > (Reading database ... 168800 files and directories currently
> >>> installed.)
> >>> > Unpacking cloudstack-agent (from .../cloudstack-agent_4.3.0_all.deb)
> >>> ...
> >>> > Processing triggers for ureadahead ...
> >>> > Setting up cloudstack-agent (4.3.0) ...
> >>> > /var/lib/dpkg/info/cloudstack-agent.postinst: line 39:
> >>> > /usr/bin/cloudstack-agent-upgrade: No such file or directory
> >>> > dpkg: error processing cloudstack-agent (--configure):
> >>> >  subprocess installed post-installation script returned error exit
> >>> status 1
> >>> > E: Sub-process /usr/bin/dpkg returned an error code (1)
> >>> >
> >>> >
> >>> >
> >>> > On Thu, Sep 26, 2013 at 8:45 AM, Mike Tutkowski <
> >>> > mike.tutkow...@solidfire.com> wrote:
> >>> >
> >>> > > Let me update and try again and see if that solves the problem.
> >>> > >
> >>> > > I am probably a week behind on updating from master.
> >>> > >
> >>> > > Thanks
> >>> > >
> >>> > >
> >>> > > On Wed, Sep 25, 2013 at 11:18 PM, Wei ZHOU 
> >>> > wrote:
> >>> > >
> >>> > >> Mike,
> >>> > >> Do you test the latest source code?
> >>> > >>
> >>> > >>  Pointer.nativeValue  is introduced in jna-3.2.6
> >>> > >>
> >>> > >>
> >>> >
> >>>
> http://upstream-tracker.org/java/compat_reports/jna/3.2.5_to_3.2.6/bin_compat_report.html
> >>> > >> and Native.free  is introduced in jna-3.3.0
> >>> > >>
> >>> > >>
> >>> >
> >>>
> http://upstream-tracker.org/java/compat_reports/jna/3.2.7_to_3.3.0/bin_compat_report.html
> >>> > >>
> >>> > >> After commit 3dc4284,  jna-4.0.0.jar is in
> >>> > /usr/share/cloudstack-agent/lib
> >>> > >> , then it should be ok.
> >>> > >>
> >>> > >> -Wei
> >>> > >>
> >>> > >>
> >>> > >> 2013/9/26 Mike Tutkowski 
> >>> > >>
> >>> > >> > Hi,
> >>> > >> >
> >>> > >> > I've been having a difficult time getting the KVM agent on
> master
> >>> to
> >>> > >> start
> >>> > >> > on Ubuntu 12.04.
> >>> > >> >
> >>> > >> > The trouble seems to have begun after the Libvirt upgrade.
> >>> > >> >
> >>> > >> > Any thoughts on this:
> >>> > >> >
> >>> > >> > Thanks!
> >>> > >> >
> >>> > >> > 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#noconfigfor
> >>> > >> > more info.
> >>> > >> > java.lang.reflect.InvocationTargetException
> >>> > >> > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>> > >> > at
> >>> > >> >
> >>> > >> >
> >>> > >>
> >>> >
> >>>
> sun.reflect.NativeMethodAccessorImpl.invoke(Nat

Problem using DevCloud2 with 4.2

[Mike Tutkowski]

Hi,

I haven't tried to use DevCloud2 in a while (generally been setting up CS
manually). I noticed the following problem when running the typical setup
script today:

mtutkowski-LT:~ mtutkowski$ cd
documents/cloudstack/src/cloudstack/tools/devcloud ; python
../marvin/marvin/deployDataCenter.py -i devcloud.cfg
Traceback (most recent call last):
  File "../marvin/marvin/deployDataCenter.py", line 613, in 
deploy.deploy()
  File "../marvin/marvin/deployDataCenter.py", line 598, in deploy
self.createZones(self.config.zones)
  File "../marvin/marvin/deployDataCenter.py", line 389, in createZones
zoneresponse = self.apiClient.createZone(createzone)
  File
"/Users/mtutkowski/Documents/CloudStack/src/CloudStack/tools/marvin/marvin/cloudstackAPI/cloudstackAPIClient.py",
line 1242, in createZone
response = self.connection.marvin_request(command,
response_type=response, method=method)
  File
"/Users/mtutkowski/Documents/CloudStack/src/CloudStack/tools/marvin/marvin/cloudstackConnection.py",
line 222, in marvin_request
response = jsonHelper.getResultObj(response.json(), response_type)
  File
"/Users/mtutkowski/Documents/CloudStack/src/CloudStack/tools/marvin/marvin/jsonHelper.py",
line 148, in getResultObj
raise cloudstackException.cloudstackAPIException(respname, errMsg)
cloudstackException.cloudstackAPIException: Execute cmd: createzone failed,
due to: errorCode: 401, errorText:unable to verify user credentials and/or
request signature

On the management server console side:

INFO  [cloud.api.ApiServer] (1841029180@qtp-1791812015-0:) disabled or
locked user accessing the api, userid = 2; name = admin; state: disabled;
accountState: enabled

Has anything changed recently with regards to how we use DevCloud2?

I started with a clean build, cleaned the DB, and had reset DevCloud2 to
its initial state before running the setup script.

Thanks!

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

Re: 4.2 press plan?

[Mike Tutkowski]

Hi Mathias,

I'd be happy to ask our marketing organization to produce outreach
information around the SolidFire plug-in for CS 4.2.

Would you be able to contact me at mike.tutkow...@solidfire.com and I can
send whatever info you might have to the right people?

Thanks!



On Thu, Sep 26, 2013 at 8:55 PM, Mathias Mullins  wrote:

> I've updated the marketing plan based off of all of this. I would also
> like to coordinate some exterior blogs, tweets and social media outputs
> that we can put out on the day of and in the days following the release.
>
> Also I am wondering if we have contacts to our commit partners like Cisco,
> Solidfire (Mike) and others that have new features in the release to brag
> about their work with ACS as well.
>
> Matt
>
>
> On 9/26/13 2:08 PM, "Chip Childers"  wrote:
>
> >On Thu, Sep 26, 2013 at 05:48:09PM +, Karen Vuong wrote:
> >> Hi Mathias,
> >>
> >> I'd be happy to help out with press outreach. I would suggest that we
> >>make the official announcement on Tuesday, October 1st at 12:00pm
> >>Eastern and I will send out the request for briefings on Monday,
> >>September 30th. Any thoughts?
> >
> >Awesome and agreed.
> >
> >>
> >> David and Chip - are you available to take briefings next week? I can
> >>arrange the appointments.
> >
> >Yep - subject to specific timeslot availability.
> >
> >I'm also going to give press@ a heads up that we are announcing and
> >doing our own press outreach.
> >
> >>
> >> Best regards,
> >>
> >> Karen
>
>


-- 
*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: add connect method on KVM storage code

[Mike Tutkowski]

My comments are inline:


On Thu, Sep 26, 2013 at 9:10 PM, Marcus Sorensen wrote:

> Ok, let me digest this a bit. I got the github responses but I'd also
> like to keep it on-list as well.
>
>  My initial thoughts are:
>
> 1) I don't think disk format and size are necessary parameters for
> connectPhysicalDisk, as the format can be determined by the adaptor,
> and the size is set during the createAsync call in the plugin. We
> really just need the disk path and the pool.
>
[Mike T.] I agree, format is not needed. The only reason I have size passed
in is because I need to create a KVMPhysicalDisk at the end of the connect
method. Since this KVMPhysicalDisk is (in the code on GitHub) being used to
create our XML to attach the disk, I figured we'd need that size. The
KVMPhysicalDisk I produce from my implementation of getPhysicalDisk is not
as good because I don't know the size of the disk at this point (I don't
keep that information around). The reason I don't keep that info around is
because I don't have a good way to reproduce that info if the KVM host is
rebooted. We get info about storage pools in the form of a
ModifyStoragePoolCommand, but nothing about the volumes inside of the
storage pool.

>
> 2) I thought this access group thing you mention are the grantAccess
> and revokeAccess calls in the storage plugin 2.0 design doc. Was that
> not implemented?
>
[Mike T.] Yeah, as I mentioned in an e-mail way back, those methods were
never implemented in 4.2. I think you said you were going to get around
them not being implemented by keeping certain logic that talks to the SAN
in the agent. I don't think we want any SolidFire-specific code in the
agent, however, so I can't go that route. If those methods do not get
implemented in 4.3, then I will need to use CHAP credentials for KVM (just
like I did with XenServer and VMware).

>
> I see you've  added getters/setters for the attach cmd to pass the
> iscsi info you need. Would it perhaps be possible to send a details
> Map instead? Then any plugin implementer could attach
> arbitrary data they need. So it might be
> connectPhysicalDisk(StoragePoolType type, String poolUuid, String
> volPath, Map details)?  I'll have to look and see
> where those cmd. attributes are set, ideally it would be all the way
> back in the plugin to avoid custom code for every adaptor that wants
> to set details.
>
[Mike T.] If I'm not using the volumes.path field for anything, I can stick
the IQN in volumes.path (as well as leaving it in volumes.iscsi_name, which
is used elsewhere). That way we only have to ask for getPath().

>
> On Thu, Sep 26, 2013 at 7:35 PM, Mike Tutkowski
>  wrote:
> > Also, if we went the non-CHAP route, before attaching a volume to a VM,
> > we'd have to tell the plug-in to set up a volume access group.
> >
> > When a volume is detached from a VM, we'd have to tell the plug-in to
> > delete the volume access group.
> >
> >
> > On Thu, Sep 26, 2013 at 7:32 PM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> >> I mention this is my comments on GitHub, as well, but CHAP info is
> >> associated with an account - not a storage pool.
> >>
> >> Ideally we could do without CHAP info entirely if we had a reliable way
> to
> >> tell the storage plug-in that a given host wants to access a given
> volume.
> >> In this case, my storage plug-in could create what we call a Volume
> Access
> >> Group on the SAN. It would essentially say, "The host with IQN  can
> >> access the volume with IQN  without using CHAP credentials." Of
> course
> >> we'd need a way to revoke this privilege in the event of a live
> migration
> >> of a VM. Right now, I do not believe such a facility is supported with
> the
> >> storage plug-ins.
> >>
> >>
> >> On Thu, Sep 26, 2013 at 4:56 PM, Marcus Sorensen  >wrote:
> >>
> >>> Looking at your code, is the chap info stored with the pool, so we
> >>> could pass the pool to the adaptor? That would be more agnostic,
> >>> anyone implementing a plugin could pull the specifics they need for
> >>> their stuff out of the pool on the adaptor side, rather than creating
> >>> custom signatures.
> >>>
> >>> Also, I think we may want to consider implementing connect/disconnect
> >>> as just dummy methods in LibvirtStorageAdaptor, so we don't have to be
> >>> picky about which adaptors/types in every single place we may want to
> >>> connect/disconnect (in 4.1 there were several, I'm not sure if
> >>> everything goes through this in 4.2). We can just call
> >>> adaptor.connectPhysicalDisk and the adaptor can decide if it needs to
> >>> do anything.
> >>>
> >>> Comments are attached to your commit, I just wanted to echo them here
> >>> on-list.
> >>>
> >>> On Thu, Sep 26, 2013 at 4:32 PM, Mike Tutkowski
> >>>  wrote:
> >>> > Oh, SnapshotTestWithFakeData is just modified because the code wasn't
> >>> > building until I corrected this. It has nothing really to do with my
> >>> real
> >>> > changes.
> >>> >
> >>> >
> >>> > On Thu, Sep 26, 2013 at 4:3

Re: Review Request 14346: CLOUDSTACK:4647 - Fixed test_snapshot_gc.py and common utility function to check snapshot on NFS

[Gaurav Aradhye]

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

(Updated Sept. 27, 2013, 9:48 a.m.)


Review request for cloudstack and Prasanna Santhanam.


Repository: cloudstack-git


Description
---

1. test_snapshot_gc.py : 
a) Removed the account and vm from cleanup, as we are already deleting account 
in the test case execution itself. Adding it to cleanup was throwing exception 
during cleanup operation.
b) Once account deleted, listAccount API should fail (as against it should give 
None)

2. utils.py
Changes in "is_snapshot_on_nfs" function:

a) Corrected the mount URL, earlier mgt server IP was passed instead of nfs url
b) Removed the extra colon between host and dir, colon is already present in 
the host variable on KVM and VMWare which is correct behaviour. This fails on 
Xen Sever as the colon is not present. Bug filed for Xen Server >>> 
https://issues.apache.org/jira/browse/CLOUDSTACK-4741
b) If snapshot not present in db , then return False as the snapshot is not 
present


Diffs
-

  test/integration/component/test_snapshot_gc.py aec9761 
  tools/marvin/marvin/integration/lib/utils.py a6abe06 

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


Testing (updated)
---

Tested on KVM, VMware, and XenServer.
Fails on XenServer due to above mentioned issue.


Thanks,

Gaurav Aradhye

Re: Libvirt-java 0.5.0 has been released

[Mike Tutkowski]

Looks like the newly checked in code is looking for
/usr/bin/cloudstack-agent-upgrade.

I don't see that file in /usr/bin, however.

I only see the following cloudstack* in /usr/bin:

cloudstack-set-guest-password
cloudstack-set-guest-sshkey
cloudstack-setup-agent
cloudstack-ssh


On Thu, Sep 26, 2013 at 3:41 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Looks like the new code references cloudstack-agent-upgrade.
>
> I'm on Ubuntu 12.04, by the way.
>
> /var/lib/dpkg/info/cloudstack-agent.postinst: line 39:
> /usr/bin/cloudstack-agent-upgrade: No such file or directory
> dpkg: error processing cloudstack-agent (--configure):
>  subprocess installed post-installation script returned error exit status 1
> Errors were encountered while processing:
>  cloudstack-agent
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
>
>
> On Thu, Sep 26, 2013 at 2:57 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> OK, thanks!
>>
>>
>> On Thu, Sep 26, 2013 at 2:52 PM, Wei ZHOU  wrote:
>>
>>> Mike,
>>> Sorry my fault. already fixed by commit
>>> 522860c03de5d05126f92fc44b6e3f50ed8439f0
>>> Please pull the latest code.
>>>
>>>
>>> 2013/9/26 Mike Tutkowski 
>>>
>>> > Any thoughts on this error message?
>>> >
>>> > I updated from master today, cleaned, recompiled, then rebuilt and
>>> > redeployed the DEBs.
>>> >
>>> > Thanks
>>> >
>>> > mtutkowski@ubuntu:~$ sudo apt-get install cloudstack-agent
>>> > Reading package lists... Done
>>> > Building dependency tree
>>> > Reading state information... Done
>>> > The following NEW packages will be installed:
>>> >   cloudstack-agent
>>> > 0 upgraded, 1 newly installed, 0 to remove and 468 not upgraded.
>>> > Need to get 39.1 MB of archives.
>>> > After this operation, 43.6 MB of additional disk space will be used.
>>> > WARNING: The following packages cannot be authenticated!
>>> >   cloudstack-agent
>>> > Install these packages without verification [y/N]? y
>>> > Get:1 http://localhost/cloudstack/repo/ binary/ cloudstack-agent 4.3.0
>>> > [39.1 MB]
>>> > Fetched 39.1 MB in 0s (49.3 MB/s)
>>> > Selecting previously unselected package cloudstack-agent.
>>> > (Reading database ... 168800 files and directories currently
>>> installed.)
>>> > Unpacking cloudstack-agent (from .../cloudstack-agent_4.3.0_all.deb)
>>> ...
>>> > Processing triggers for ureadahead ...
>>> > Setting up cloudstack-agent (4.3.0) ...
>>> > /var/lib/dpkg/info/cloudstack-agent.postinst: line 39:
>>> > /usr/bin/cloudstack-agent-upgrade: No such file or directory
>>> > dpkg: error processing cloudstack-agent (--configure):
>>> >  subprocess installed post-installation script returned error exit
>>> status 1
>>> > E: Sub-process /usr/bin/dpkg returned an error code (1)
>>> >
>>> >
>>> >
>>> > On Thu, Sep 26, 2013 at 8:45 AM, Mike Tutkowski <
>>> > mike.tutkow...@solidfire.com> wrote:
>>> >
>>> > > Let me update and try again and see if that solves the problem.
>>> > >
>>> > > I am probably a week behind on updating from master.
>>> > >
>>> > > Thanks
>>> > >
>>> > >
>>> > > On Wed, Sep 25, 2013 at 11:18 PM, Wei ZHOU 
>>> > wrote:
>>> > >
>>> > >> Mike,
>>> > >> Do you test the latest source code?
>>> > >>
>>> > >>  Pointer.nativeValue  is introduced in jna-3.2.6
>>> > >>
>>> > >>
>>> >
>>> http://upstream-tracker.org/java/compat_reports/jna/3.2.5_to_3.2.6/bin_compat_report.html
>>> > >> and Native.free  is introduced in jna-3.3.0
>>> > >>
>>> > >>
>>> >
>>> http://upstream-tracker.org/java/compat_reports/jna/3.2.7_to_3.3.0/bin_compat_report.html
>>> > >>
>>> > >> After commit 3dc4284,  jna-4.0.0.jar is in
>>> > /usr/share/cloudstack-agent/lib
>>> > >> , then it should be ok.
>>> > >>
>>> > >> -Wei
>>> > >>
>>> > >>
>>> > >> 2013/9/26 Mike Tutkowski 
>>> > >>
>>> > >> > Hi,
>>> > >> >
>>> > >> > I've been having a difficult time getting the KVM agent on master
>>> to
>>> > >> start
>>> > >> > on Ubuntu 12.04.
>>> > >> >
>>> > >> > The trouble seems to have begun after the Libvirt upgrade.
>>> > >> >
>>> > >> > Any thoughts on this:
>>> > >> >
>>> > >> > Thanks!
>>> > >> >
>>> > >> > 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#noconfigfor
>>> > >> > 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.N

buildbot success in ASF Buildbot on cloudstack-site-staging

[buildbot]

The Buildbot has detected a restored build on builder cloudstack-site-staging 
while building ASF Buildbot.
Full details are available at:
 http://ci.apache.org/builders/cloudstack-site-staging/builds/206

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: bb-cms-slave

Build Reason: scheduler
Build Source Stamp: [branch cloudstack/site] 1526776
Blamelist: ke4qqq

Build succeeded!

sincerely,
 -The Buildbot

Re: [DISCUSS] UI: New look and feel

[Ian Duffy]

Looks good.

Moving away from design and more into front-end functionality. Is
there any talks about cleaning up the javascript behind the UI? I
recall it being messy and hard to follow from what I recall of looking
at it. The idea single page app with no URL defining a view and a
broken browser back button is quite annoying. I think so
implementation of AngularJS like the way Shiva did it for his GSoC
project would be good.

On 27 September 2013 02:09, Chip Childers  wrote:
> Looks great Brian!
>
> One request actually.  I'm working on a proposed cloudstack.apache.org
> site redesign right now, and I'd actually love to get the relevant CSS
> you used for the header area (faded blue).
>
> It might be nice to have some relationship between the cs.a.o branding
> and the product itself. ;-)
>
> (watch the marketing list for my site redesign proposal shortly)
>
>
> On Thu, Sep 26, 2013 at 10:11:07PM +, Brian Federle wrote:
>> Hi all,
>>
>> In addition to the CSS code cleanup I'm working on, I am planning a 'reskin' 
>> of the current UI to give a better user experience and look and feel. This 
>> will utilize SASS and a grid system as I have discussed in the previous 
>> thread.
>>
>> I created a task in JIRA and wiki functional spec, which has screenshots of 
>> what I've done so far and what I plan to do:
>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Update+UI+visual+appearance
>>
>> https://issues.apache.org/jira/browse/CLOUDSTACK-4748
>>
>> You can also checkout the ui-restyle branch on git, if you are able to 
>> manually compile the cloudstack.scss file via SASS (that will be automated 
>> in the future). I can send over instructions on how to compile SASS 
>> manually; it's pretty easy to setup.
>>
>> Let me know what you think so far :)  I'll of course up and post more 
>> screenshots as I get more done. This reskin is only changing the CSS mainly, 
>> with minimal changes to actual usage or JS code, so it is basically a 
>> drop-in replacement for the current styling. I'm hoping to get this in by 
>> 4.3, so please give me feedback on anything from the current UI you don't 
>> like or want changed, and I can see about improving it.
>>
>> Thanks!
>> Brian
>>

Re: Upgrade failed because system VM was created using old template?

[Indra Pramana]

Dear all,

Would like to confirm on this:

On Wed, Sep 25, 2013 at 7:40 PM, Indra Pramana  wrote:

> 2. Do I need to delete the old system VM template from the template list,
> prior to the upgrade? If yes, I think this should be inside the
> documentation.
>

Prior to the upgrade from 4.1.1 to 4.2.0, we need to register the new
system VM template for 4.2.0. My question, do we also need to delete the
old system VM template?

Looking forward to your reply, thank you.

Cheers.

Re: add connect method on KVM storage code

[Marcus Sorensen]

Ok, let me digest this a bit. I got the github responses but I'd also
like to keep it on-list as well.

 My initial thoughts are:

1) I don't think disk format and size are necessary parameters for
connectPhysicalDisk, as the format can be determined by the adaptor,
and the size is set during the createAsync call in the plugin. We
really just need the disk path and the pool.

2) I thought this access group thing you mention are the grantAccess
and revokeAccess calls in the storage plugin 2.0 design doc. Was that
not implemented?

I see you've  added getters/setters for the attach cmd to pass the
iscsi info you need. Would it perhaps be possible to send a details
Map instead? Then any plugin implementer could attach
arbitrary data they need. So it might be
connectPhysicalDisk(StoragePoolType type, String poolUuid, String
volPath, Map details)?  I'll have to look and see
where those cmd. attributes are set, ideally it would be all the way
back in the plugin to avoid custom code for every adaptor that wants
to set details.

On Thu, Sep 26, 2013 at 7:35 PM, Mike Tutkowski
 wrote:
> Also, if we went the non-CHAP route, before attaching a volume to a VM,
> we'd have to tell the plug-in to set up a volume access group.
>
> When a volume is detached from a VM, we'd have to tell the plug-in to
> delete the volume access group.
>
>
> On Thu, Sep 26, 2013 at 7:32 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> I mention this is my comments on GitHub, as well, but CHAP info is
>> associated with an account - not a storage pool.
>>
>> Ideally we could do without CHAP info entirely if we had a reliable way to
>> tell the storage plug-in that a given host wants to access a given volume.
>> In this case, my storage plug-in could create what we call a Volume Access
>> Group on the SAN. It would essentially say, "The host with IQN  can
>> access the volume with IQN  without using CHAP credentials." Of course
>> we'd need a way to revoke this privilege in the event of a live migration
>> of a VM. Right now, I do not believe such a facility is supported with the
>> storage plug-ins.
>>
>>
>> On Thu, Sep 26, 2013 at 4:56 PM, Marcus Sorensen wrote:
>>
>>> Looking at your code, is the chap info stored with the pool, so we
>>> could pass the pool to the adaptor? That would be more agnostic,
>>> anyone implementing a plugin could pull the specifics they need for
>>> their stuff out of the pool on the adaptor side, rather than creating
>>> custom signatures.
>>>
>>> Also, I think we may want to consider implementing connect/disconnect
>>> as just dummy methods in LibvirtStorageAdaptor, so we don't have to be
>>> picky about which adaptors/types in every single place we may want to
>>> connect/disconnect (in 4.1 there were several, I'm not sure if
>>> everything goes through this in 4.2). We can just call
>>> adaptor.connectPhysicalDisk and the adaptor can decide if it needs to
>>> do anything.
>>>
>>> Comments are attached to your commit, I just wanted to echo them here
>>> on-list.
>>>
>>> On Thu, Sep 26, 2013 at 4:32 PM, Mike Tutkowski
>>>  wrote:
>>> > Oh, SnapshotTestWithFakeData is just modified because the code wasn't
>>> > building until I corrected this. It has nothing really to do with my
>>> real
>>> > changes.
>>> >
>>> >
>>> > On Thu, Sep 26, 2013 at 4:31 PM, Mike Tutkowski <
>>> > mike.tutkow...@solidfire.com> wrote:
>>> >
>>> >> Hey Marcus,
>>> >>
>>> >> I implemented your recommendations regarding adding connect and
>>> disconnect
>>> >> methods. It is not yet checked in (as you know, having trouble with my
>>> KVM
>>> >> environment), but it is on GitHub here:
>>> >>
>>> >>
>>> >>
>>> https://github.com/mike-tutkowski/incubator-cloudstack/commit/f2897c65689012e6157c0a0c2ed7e5355900c59a
>>> >>
>>> >> Please let me know if you have any more comments.
>>> >>
>>> >> Thanks!
>>> >>
>>> >>
>>> >> On Thu, Sep 26, 2013 at 4:05 PM, Marcus Sorensen >> >wrote:
>>> >>
>>> >>> Mike, everyone,
>>> >>>As I've mentioned on the board, I'm working on getting our own
>>> >>> internal KVM storage plugin working on 4.2. In the interest of making
>>> >>> it forward compatible, I just wanted to confirm what you were doing
>>> >>> with the solidfire plugin as far as attaching your iscsi LUNs. We had
>>> >>> discussed a new connectPhysicalDisk method for the StorageAdaptor
>>> >>> class, something perhaps like:
>>> >>>
>>> >>> public boolean connectPhysicalDisk(String volumeUuid, KVMStoragePool
>>> >>> pool);
>>> >>>
>>> >>> then added to KVMStoragePoolManager:
>>> >>>
>>> >>> public boolean connectPhysicalDisk(StoragePoolType type, String
>>> >>> poolUuid, String volPath) {
>>> >>> StorageAdaptor adaptor = getStorageAdaptor(type);
>>> >>> KVMStoragePool pool = adaptor.getStoragePool(poolUuid);
>>> >>> return adaptor.connectPhysicalDisk(volPath, pool);
>>> >>> }
>>> >>>
>>> >>> Something similar to this for disconnect as well. Then in the
>>> >>> KVMStorageProcessor these can be called as nee

Re: Review Request 14058: Including tests for VPC VM Lifecycle on Tagged hosts

[Ashutosh Kelkar]

> On Sept. 26, 2013, 1:30 a.m., Sheng Yang wrote:
> > Please test it before submit.

The tests have been tested and run correctly. There is a manual step needed in 
setup for these tests - Adding host tags to the hosts which is why the tests 
are skipped when committing.


- Ashutosh


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


On Sept. 18, 2013, 2:28 p.m., Ashutosh Kelkar wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14058/
> ---
> 
> (Updated Sept. 18, 2013, 2:28 p.m.)
> 
> 
> Review request for cloudstack, Girish Shilamkar, venkata swamy babu  
> budumuru, and Sheng Yang.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> Added 10 tests for VPC VM liftcycle on tagged hosts
> 
> New class added  : TestVMLifeCycleDiffHosts
> 
> def test_01_deploy_instance_in_network(self):
> def test_02_stop_instance_in_network(self):
> def test_03_start_instance_in_network(self):
> def test_04_reboot_instance_in_network(self):
> def test_05_destroy_instance_in_network(self):
> def test_06_recover_instance_in_network(self):
> def test_07_migrate_instance_in_network(self):
> def test_08_user_data(self):
> def test_09_meta_data(self):
> def   test_10_expunge_instance_in_network(self):
> 
> This set of tests requires a multi host tagged setup (3 hosts - 2 hosts with 
> tag 'host1' and  1 host with tag 'host2')
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_vpc_vm_life_cycle.py 9844c1f 
> 
> Diff: https://reviews.apache.org/r/14058/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ashutosh Kelkar
> 
>

RE: [DISCUSS] Release Managers for future ACS releases - enhacement

[Sudha Ponnaganti]

Ilya,

I work for Citrix QA so can speak to some of the discussion that you have 
raised around QA. I have expressed my opinion on assigning defects in another 
thread. 

-Like Animesh mentioned, Citrix QA has contributed quite a bit for ACS 4.2, I 
can say as much as 90% + towards any of the  QA activity that has happened.
- Pl note that we have to support several projects within citrix and have other 
$dayjob activities just like rest of community. Even though most activities are 
around similar technology, but deliverables are different and may not always 
align with ACS and still we accommodate as much as possible as ACS is one of 
the primary focus areas. We have to support various code lines and other 
ongoing projects as well.

Some overview of test activity in 4.2:
-All test plans related to ACS 4.2 are posted in Mailing lists and solicited 
feedback from community. Several mail threads are posted in this regard. There 
are too many to list here.
-All test plans are posted on cwiki including test results [1] 
-All defects are posted in Apache JIRA for validation done on ACS 4.2 code 
base. 
-400+ BVT tests and 2000 + automation tests have been run on ACS 4.2 code and 
results have been shared with community and on cwiki [2].  I am thinking of 
posting these daily might help to bring visibility. 

-If there are other means of providing transparency, we can definitely pursue 
that. I would say having weekly IRC meetings would help. We are posting updates 
on mailing lists and with the enormous traffic, not all  community members may 
not have paid attention to some of these.  

[1] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/QA+-+4.2+Test+Execution+Results
[2] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/ACS+4.2+Automation+Results+-+Baseline

Thanks
/Sudha

-Original Message-
From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] 
Sent: Thursday, September 26, 2013 5:58 PM
To: dev@cloudstack.apache.org
Subject: RE: [DISCUSS] Release Managers for future ACS releases - enhacement

I have not thought through it all, but some quick comments for now, I will come 
back and refine tomorrow or later tonight

> -Original Message-
> From: Musayev, Ilya [mailto:imusa...@webmd.net]
> Sent: Thursday, September 26, 2013 4:06 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [DISCUSS] Release Managers for future ACS releases - 
> enhacement
> 
> I can feel your pain, as well as Chip's, Dave's, Joe's and whoever was 
> involved in past.
> 
> Here is a bit of uncharted territory we need to address about bug 
> assignment.
> 
> In past I've seen folks ask - we have X number of bugs that need to be 
> triaged, who can take what? Are we still keeping this framework and do 
> we default to whoever wrote the code/patch initially - if no one 
> volunteers?
[Animesh>] We have list of maintainers by component that may be something to 
start with. This does not mean they have to do it, but they can call back and 
say I do not have time right now can someone else look into it. Or if an 
assigned issue is not worked on for a week it automatically gets unassigned, 
would need to check on JIRA support for the workflow, having  played with JIRA 
at least such reports are easy to generate.
> 
> While Citrix is one of the main supporters of CloudStack project and 
> has people employed to do development, how does one - who has no 
> insight into Citrix - assign bugs to people who are employed by Citrix 
> (and can we even do that without their full consent)?
> 
[Animesh>] We can look up the maintainers list by component and I can 
facilitate within Citrix. Even for the prior release I have received emails 
from nonCitrix community members to follow through with Citrix folks.

> One other part, since Citrix and other companies have QA teams, 
> perhaps we can have a closer collaboration as to what testing was done 
> on Citrix side when it comes to major releases? (i.e. ACS 4.2 release)
> 
[Animesh>] Yes, QA contributors have published test plans and Sudha has called 
out help with QA tasks in community. Alex, Amogh, Frank and Prasanna are 
working on a test infrastructure design that can be replicated across sites to 
make testing simpler for anyone who wants or can contribute. You should see a 
proposal on that soon.


> I know in past Citrix would branch of from ACS or even have a separate 
> codebase, but with future releases, its all going to be one ACS code 
> base. So future actual release testing/qa (not automated as part of 
> built process) should get easier since we have folks dedicated to work 
> on ACS project to do QA or is this an incorrect assumption?
> 
[Animesh>] We are aligned already from code perspective and you would have seen 
huge QA engagement in 4.2 . I wanted to call out like every place there is no 
Elastic human capital available so as a community we have to reduce the 
reliance on just Citrix QA. Citrix QA is a good community citizen but will 
naturally foc

Re: add connect method on KVM storage code

[Mike Tutkowski]

Also, if we went the non-CHAP route, before attaching a volume to a VM,
we'd have to tell the plug-in to set up a volume access group.

When a volume is detached from a VM, we'd have to tell the plug-in to
delete the volume access group.


On Thu, Sep 26, 2013 at 7:32 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> I mention this is my comments on GitHub, as well, but CHAP info is
> associated with an account - not a storage pool.
>
> Ideally we could do without CHAP info entirely if we had a reliable way to
> tell the storage plug-in that a given host wants to access a given volume.
> In this case, my storage plug-in could create what we call a Volume Access
> Group on the SAN. It would essentially say, "The host with IQN  can
> access the volume with IQN  without using CHAP credentials." Of course
> we'd need a way to revoke this privilege in the event of a live migration
> of a VM. Right now, I do not believe such a facility is supported with the
> storage plug-ins.
>
>
> On Thu, Sep 26, 2013 at 4:56 PM, Marcus Sorensen wrote:
>
>> Looking at your code, is the chap info stored with the pool, so we
>> could pass the pool to the adaptor? That would be more agnostic,
>> anyone implementing a plugin could pull the specifics they need for
>> their stuff out of the pool on the adaptor side, rather than creating
>> custom signatures.
>>
>> Also, I think we may want to consider implementing connect/disconnect
>> as just dummy methods in LibvirtStorageAdaptor, so we don't have to be
>> picky about which adaptors/types in every single place we may want to
>> connect/disconnect (in 4.1 there were several, I'm not sure if
>> everything goes through this in 4.2). We can just call
>> adaptor.connectPhysicalDisk and the adaptor can decide if it needs to
>> do anything.
>>
>> Comments are attached to your commit, I just wanted to echo them here
>> on-list.
>>
>> On Thu, Sep 26, 2013 at 4:32 PM, Mike Tutkowski
>>  wrote:
>> > Oh, SnapshotTestWithFakeData is just modified because the code wasn't
>> > building until I corrected this. It has nothing really to do with my
>> real
>> > changes.
>> >
>> >
>> > On Thu, Sep 26, 2013 at 4:31 PM, Mike Tutkowski <
>> > mike.tutkow...@solidfire.com> wrote:
>> >
>> >> Hey Marcus,
>> >>
>> >> I implemented your recommendations regarding adding connect and
>> disconnect
>> >> methods. It is not yet checked in (as you know, having trouble with my
>> KVM
>> >> environment), but it is on GitHub here:
>> >>
>> >>
>> >>
>> https://github.com/mike-tutkowski/incubator-cloudstack/commit/f2897c65689012e6157c0a0c2ed7e5355900c59a
>> >>
>> >> Please let me know if you have any more comments.
>> >>
>> >> Thanks!
>> >>
>> >>
>> >> On Thu, Sep 26, 2013 at 4:05 PM, Marcus Sorensen > >wrote:
>> >>
>> >>> Mike, everyone,
>> >>>As I've mentioned on the board, I'm working on getting our own
>> >>> internal KVM storage plugin working on 4.2. In the interest of making
>> >>> it forward compatible, I just wanted to confirm what you were doing
>> >>> with the solidfire plugin as far as attaching your iscsi LUNs. We had
>> >>> discussed a new connectPhysicalDisk method for the StorageAdaptor
>> >>> class, something perhaps like:
>> >>>
>> >>> public boolean connectPhysicalDisk(String volumeUuid, KVMStoragePool
>> >>> pool);
>> >>>
>> >>> then added to KVMStoragePoolManager:
>> >>>
>> >>> public boolean connectPhysicalDisk(StoragePoolType type, String
>> >>> poolUuid, String volPath) {
>> >>> StorageAdaptor adaptor = getStorageAdaptor(type);
>> >>> KVMStoragePool pool = adaptor.getStoragePool(poolUuid);
>> >>> return adaptor.connectPhysicalDisk(volPath, pool);
>> >>> }
>> >>>
>> >>> Something similar to this for disconnect as well. Then in the
>> >>> KVMStorageProcessor these can be called as needed for attach/detach.
>> >>> We can probably stub out one in LibvirtStorageAdaptor so there's no
>> >>> need to switch or if/else for pool types, for example in
>> >>> KVMStorageProcessor.attachVolume.
>> >>>
>> >>> I have debated on whether or not it should just be rolled into
>> >>> getPhysicalDisk, having it connect the disk if it's not already
>> >>> connected. getPhysicalDisk is called a lot, and I'm not sure it always
>> >>> needs to connect the disk when it does. In past iterations
>> >>> getPhysicalDisk has simply spoken to our SAN api and returned the disk
>> >>> details, nothing more. So it seemed more flexible and granular to do
>> >>> the connectPhysicalDisk (we have one now in our 4.1 version).
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> *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

Re: add connect method on KVM storage code

[Mike Tutkowski]

I mention this is my comments on GitHub, as well, but CHAP info is
associated with an account - not a storage pool.

Ideally we could do without CHAP info entirely if we had a reliable way to
tell the storage plug-in that a given host wants to access a given volume.
In this case, my storage plug-in could create what we call a Volume Access
Group on the SAN. It would essentially say, "The host with IQN  can
access the volume with IQN  without using CHAP credentials." Of course
we'd need a way to revoke this privilege in the event of a live migration
of a VM. Right now, I do not believe such a facility is supported with the
storage plug-ins.


On Thu, Sep 26, 2013 at 4:56 PM, Marcus Sorensen wrote:

> Looking at your code, is the chap info stored with the pool, so we
> could pass the pool to the adaptor? That would be more agnostic,
> anyone implementing a plugin could pull the specifics they need for
> their stuff out of the pool on the adaptor side, rather than creating
> custom signatures.
>
> Also, I think we may want to consider implementing connect/disconnect
> as just dummy methods in LibvirtStorageAdaptor, so we don't have to be
> picky about which adaptors/types in every single place we may want to
> connect/disconnect (in 4.1 there were several, I'm not sure if
> everything goes through this in 4.2). We can just call
> adaptor.connectPhysicalDisk and the adaptor can decide if it needs to
> do anything.
>
> Comments are attached to your commit, I just wanted to echo them here
> on-list.
>
> On Thu, Sep 26, 2013 at 4:32 PM, Mike Tutkowski
>  wrote:
> > Oh, SnapshotTestWithFakeData is just modified because the code wasn't
> > building until I corrected this. It has nothing really to do with my real
> > changes.
> >
> >
> > On Thu, Sep 26, 2013 at 4:31 PM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> >> Hey Marcus,
> >>
> >> I implemented your recommendations regarding adding connect and
> disconnect
> >> methods. It is not yet checked in (as you know, having trouble with my
> KVM
> >> environment), but it is on GitHub here:
> >>
> >>
> >>
> https://github.com/mike-tutkowski/incubator-cloudstack/commit/f2897c65689012e6157c0a0c2ed7e5355900c59a
> >>
> >> Please let me know if you have any more comments.
> >>
> >> Thanks!
> >>
> >>
> >> On Thu, Sep 26, 2013 at 4:05 PM, Marcus Sorensen  >wrote:
> >>
> >>> Mike, everyone,
> >>>As I've mentioned on the board, I'm working on getting our own
> >>> internal KVM storage plugin working on 4.2. In the interest of making
> >>> it forward compatible, I just wanted to confirm what you were doing
> >>> with the solidfire plugin as far as attaching your iscsi LUNs. We had
> >>> discussed a new connectPhysicalDisk method for the StorageAdaptor
> >>> class, something perhaps like:
> >>>
> >>> public boolean connectPhysicalDisk(String volumeUuid, KVMStoragePool
> >>> pool);
> >>>
> >>> then added to KVMStoragePoolManager:
> >>>
> >>> public boolean connectPhysicalDisk(StoragePoolType type, String
> >>> poolUuid, String volPath) {
> >>> StorageAdaptor adaptor = getStorageAdaptor(type);
> >>> KVMStoragePool pool = adaptor.getStoragePool(poolUuid);
> >>> return adaptor.connectPhysicalDisk(volPath, pool);
> >>> }
> >>>
> >>> Something similar to this for disconnect as well. Then in the
> >>> KVMStorageProcessor these can be called as needed for attach/detach.
> >>> We can probably stub out one in LibvirtStorageAdaptor so there's no
> >>> need to switch or if/else for pool types, for example in
> >>> KVMStorageProcessor.attachVolume.
> >>>
> >>> I have debated on whether or not it should just be rolled into
> >>> getPhysicalDisk, having it connect the disk if it's not already
> >>> connected. getPhysicalDisk is called a lot, and I'm not sure it always
> >>> needs to connect the disk when it does. In past iterations
> >>> getPhysicalDisk has simply spoken to our SAN api and returned the disk
> >>> details, nothing more. So it seemed more flexible and granular to do
> >>> the connectPhysicalDisk (we have one now in our 4.1 version).
> >>>
> >>
> >>
> >>
> >> --
> >> *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
> > *™*
>



-- 
*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: add connect method on KVM storage code

[Mike Tutkowski]

Hey Marcus,

Thanks for the comments.

I have added comments of my own.

Please let me know what you think.

Thanks!


On Thu, Sep 26, 2013 at 4:56 PM, Marcus Sorensen wrote:

> Looking at your code, is the chap info stored with the pool, so we
> could pass the pool to the adaptor? That would be more agnostic,
> anyone implementing a plugin could pull the specifics they need for
> their stuff out of the pool on the adaptor side, rather than creating
> custom signatures.
>
> Also, I think we may want to consider implementing connect/disconnect
> as just dummy methods in LibvirtStorageAdaptor, so we don't have to be
> picky about which adaptors/types in every single place we may want to
> connect/disconnect (in 4.1 there were several, I'm not sure if
> everything goes through this in 4.2). We can just call
> adaptor.connectPhysicalDisk and the adaptor can decide if it needs to
> do anything.
>
> Comments are attached to your commit, I just wanted to echo them here
> on-list.
>
> On Thu, Sep 26, 2013 at 4:32 PM, Mike Tutkowski
>  wrote:
> > Oh, SnapshotTestWithFakeData is just modified because the code wasn't
> > building until I corrected this. It has nothing really to do with my real
> > changes.
> >
> >
> > On Thu, Sep 26, 2013 at 4:31 PM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> >> Hey Marcus,
> >>
> >> I implemented your recommendations regarding adding connect and
> disconnect
> >> methods. It is not yet checked in (as you know, having trouble with my
> KVM
> >> environment), but it is on GitHub here:
> >>
> >>
> >>
> https://github.com/mike-tutkowski/incubator-cloudstack/commit/f2897c65689012e6157c0a0c2ed7e5355900c59a
> >>
> >> Please let me know if you have any more comments.
> >>
> >> Thanks!
> >>
> >>
> >> On Thu, Sep 26, 2013 at 4:05 PM, Marcus Sorensen  >wrote:
> >>
> >>> Mike, everyone,
> >>>As I've mentioned on the board, I'm working on getting our own
> >>> internal KVM storage plugin working on 4.2. In the interest of making
> >>> it forward compatible, I just wanted to confirm what you were doing
> >>> with the solidfire plugin as far as attaching your iscsi LUNs. We had
> >>> discussed a new connectPhysicalDisk method for the StorageAdaptor
> >>> class, something perhaps like:
> >>>
> >>> public boolean connectPhysicalDisk(String volumeUuid, KVMStoragePool
> >>> pool);
> >>>
> >>> then added to KVMStoragePoolManager:
> >>>
> >>> public boolean connectPhysicalDisk(StoragePoolType type, String
> >>> poolUuid, String volPath) {
> >>> StorageAdaptor adaptor = getStorageAdaptor(type);
> >>> KVMStoragePool pool = adaptor.getStoragePool(poolUuid);
> >>> return adaptor.connectPhysicalDisk(volPath, pool);
> >>> }
> >>>
> >>> Something similar to this for disconnect as well. Then in the
> >>> KVMStorageProcessor these can be called as needed for attach/detach.
> >>> We can probably stub out one in LibvirtStorageAdaptor so there's no
> >>> need to switch or if/else for pool types, for example in
> >>> KVMStorageProcessor.attachVolume.
> >>>
> >>> I have debated on whether or not it should just be rolled into
> >>> getPhysicalDisk, having it connect the disk if it's not already
> >>> connected. getPhysicalDisk is called a lot, and I'm not sure it always
> >>> needs to connect the disk when it does. In past iterations
> >>> getPhysicalDisk has simply spoken to our SAN api and returned the disk
> >>> details, nothing more. So it seemed more flexible and granular to do
> >>> the connectPhysicalDisk (we have one now in our 4.1 version).
> >>>
> >>
> >>
> >>
> >> --
> >> *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
> > *™*
>



-- 
*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: [DISCUSS] UI: New look and feel

[Chip Childers]

Looks great Brian!

One request actually.  I'm working on a proposed cloudstack.apache.org
site redesign right now, and I'd actually love to get the relevant CSS
you used for the header area (faded blue).

It might be nice to have some relationship between the cs.a.o branding
and the product itself. ;-)

(watch the marketing list for my site redesign proposal shortly)


On Thu, Sep 26, 2013 at 10:11:07PM +, Brian Federle wrote:
> Hi all,
> 
> In addition to the CSS code cleanup I'm working on, I am planning a 'reskin' 
> of the current UI to give a better user experience and look and feel. This 
> will utilize SASS and a grid system as I have discussed in the previous 
> thread.
> 
> I created a task in JIRA and wiki functional spec, which has screenshots of 
> what I've done so far and what I plan to do:
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Update+UI+visual+appearance
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-4748
> 
> You can also checkout the ui-restyle branch on git, if you are able to 
> manually compile the cloudstack.scss file via SASS (that will be automated in 
> the future). I can send over instructions on how to compile SASS manually; 
> it's pretty easy to setup.
> 
> Let me know what you think so far :)  I'll of course up and post more 
> screenshots as I get more done. This reskin is only changing the CSS mainly, 
> with minimal changes to actual usage or JS code, so it is basically a drop-in 
> replacement for the current styling. I'm hoping to get this in by 4.3, so 
> please give me feedback on anything from the current UI you don't like or 
> want changed, and I can see about improving it.
> 
> Thanks!
> Brian
> 

RE: [DISCUSS] Release Managers for future ACS releases - enhacement

[Animesh Chaturvedi]

I have not thought through it all, but some quick comments for now, I will come 
back and refine tomorrow or later tonight

> -Original Message-
> From: Musayev, Ilya [mailto:imusa...@webmd.net]
> Sent: Thursday, September 26, 2013 4:06 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [DISCUSS] Release Managers for future ACS releases -
> enhacement
> 
> I can feel your pain, as well as Chip's, Dave's, Joe's and whoever was
> involved in past.
> 
> Here is a bit of uncharted territory we need to address about bug
> assignment.
> 
> In past I've seen folks ask - we have X number of bugs that need to be
> triaged, who can take what? Are we still keeping this framework and do
> we default to whoever wrote the code/patch initially - if no one
> volunteers?
[Animesh>] We have list of maintainers by component that may be something to 
start with. This does not mean they have to do it, but they can call back and 
say I do not have time right now can someone else look into it. Or if an 
assigned issue is not worked on for a week it automatically gets unassigned, 
would need to check on JIRA support for the workflow, having  played with JIRA 
at least such reports are easy to generate.
> 
> While Citrix is one of the main supporters of CloudStack project and has
> people employed to do development, how does one - who has no insight
> into Citrix - assign bugs to people who are employed by Citrix (and can
> we even do that without their full consent)?
> 
[Animesh>] We can look up the maintainers list by component and I can 
facilitate within Citrix. Even for the prior release I have received emails 
from nonCitrix community members to follow through with Citrix folks.

> One other part, since Citrix and other companies have QA teams, perhaps
> we can have a closer collaboration as to what testing was done on Citrix
> side when it comes to major releases? (i.e. ACS 4.2 release)
> 
[Animesh>] Yes, QA contributors have published test plans and Sudha has called 
out help with QA tasks in community. Alex, Amogh, Frank and Prasanna are 
working on a test infrastructure design that can be replicated across sites to 
make testing simpler for anyone who wants or can contribute. You should see a 
proposal on that soon.


> I know in past Citrix would branch of from ACS or even have a separate
> codebase, but with future releases, its all going to be one ACS code
> base. So future actual release testing/qa (not automated as part of
> built process) should get easier since we have folks dedicated to work
> on ACS project to do QA or is this an incorrect assumption?
> 
[Animesh>] We are aligned already from code perspective and you would have seen 
huge QA engagement in 4.2 . I wanted to call out like every place there is no 
Elastic human capital available so as a community we have to reduce the 
reliance on just Citrix QA. Citrix QA is a good community citizen but will 
naturally focus on Citrix priorities first. If you contribute a code to 
CloudStack ideally you should be prepared to maintain and test as well. 
Community testing is indeed needed for this project.

> I am also under impression it would help to have at least one person
> from Citrix on RM team, helps with communication, as they can tap people
> by other means other than mailing lists.
[Animesh>] Yes I am always there to facilitate with community. Sudha, Abhi and 
Ram Ganesh are also available to help out. 
> 
> There are a lot of assumptions here, I could be wrong on all or some of
> these, please clarify or voice your opinion.
[Animesh>] Thanks for bringing up these issues they are all valid and its best 
to clear out any expectations.
> 
> Thanks
> ilya
> 
> 
> 
> 
> 
> > -Original Message-
> > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> > Sent: Thursday, September 26, 2013 5:25 PM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [DISCUSS] Release Managers for future ACS releases -
> > enhacement
> >
> > +1
> >
> > Ilya I am glad that you brought it up and recognize the challenge. I
> > survived on 3 cups of JetFuel[1] every day for last 3 months. It's
> > like doing two $dayjob$ shifts
> >
> > http://www.keurig.com/coffee/jet-fuel-extra-bold-coffee-k-cup-coffee-
> > people
> >
> >
> >
> > > -Original Message-
> > > From: Musayev, Ilya [mailto:imusa...@webmd.net]
> > > Sent: Thursday, September 26, 2013 9:02 AM
> > > To: dev@cloudstack.apache.org
> > > Subject: [DISCUSS] Release Managers for future ACS releases -
> > > enhacement
> > >
> > > I apologize in advance if this is a repeat of something that was
> > > previously stated.
> > >
> > > As Animesh learned recently with ACS 4.2, RM work for major versions
> > > takes a lot of effort, to lesser extent the 4.2.x minor release may
> > > not be as involved, but still decent amount of work.
> > >
> > > What complicates the matter further, is many of us have $dayjobs$
> > > that don't emphasize heavy involvement on ACS.
> > >
> > > Perhaps we can revisit the str

Re: [DISCUSS] UI: New look and feel

[Chiradeep Vittal]

Not to be a fanboi and all that and hating to divert this topic, but doing
it anyway, I do like 'flat'.

On 9/26/13 5:12 PM, "Musayev, Ilya"  wrote:

>I don't agree.
>
>For the reference,  take a look at OpenStack UI and compare it to ACS
>specifically version 4.2
>
>
>- All mistakes in this message are not mine but Android's.
>
>
> Original message 
>From: Tracy Phillips 
>Date: 09/26/2013 8:06 PM (GMT-05:00)
>To: dev@cloudstack.apache.org
>Subject: Re: [DISCUSS] UI: New look and feel
>
>
>I am a fan of Foundation's look (or Bootstrap even)...
>
>http://foundation.zurb.com/
>
>3d elements make it look dated, kind of like it does now. The less images,
>the better imo.
>
>
>
>
>On Thu, Sep 26, 2013 at 7:11 PM, Kelcey Jamison Damage <
>kel...@backbonetechnology.com> wrote:
>
>> Hmm, maybe cut 2 copies... 1 with icons, and 1 just a clean text look.
>>
>> - Original Message -
>> From: "Ilya Musayev" 
>> To: dev@cloudstack.apache.org
>> Sent: Thursday, September 26, 2013 4:08:50 PM
>> Subject: RE: [DISCUSS] UI: New look and feel
>>
>> Brian,
>>
>> Are we no longer using icons on the left navigation menu or is this a
>> draft?
>>
>> Thanks
>> ilya
>>
>> > -Original Message-
>> > From: Kelcey Jamison Damage [mailto:kel...@backbonetechnology.com]
>> > Sent: Thursday, September 26, 2013 6:28 PM
>> > To: dev@cloudstack.apache.org
>> > Subject: Re: [DISCUSS] UI: New look and feel
>> >
>> > You just made my day, these look great. Most importantly it has a look
>> that
>> > will sell to IT managers, etc.
>> >
>> > I wish you the best of luck with this and hope for rapid progress :)
>> >
>> > Again, it looks awesome!
>> >
>> > - Original Message -
>> > From: "Brian Federle" 
>> > To: dev@cloudstack.apache.org
>> > Cc: "Sonny Chhen" , "Animesh Chaturvedi"
>> > , "Jessica Wang"
>> > 
>> > Sent: Thursday, September 26, 2013 3:11:07 PM
>> > Subject: [DISCUSS] UI: New look and feel
>> >
>> > Hi all,
>> >
>> > In addition to the CSS code cleanup I'm working on, I am planning a
>> 'reskin' of
>> > the current UI to give a better user experience and look and feel.
>>This
>> will
>> > utilize SASS and a grid system as I have discussed in the previous
>> thread.
>> >
>> > I created a task in JIRA and wiki functional spec, which has
>>screenshots
>> of
>> > what I've done so far and what I plan to do:
>> >
>> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Update+UI+visu
>> > al+appearance
>> >
>> > https://issues.apache.org/jira/browse/CLOUDSTACK-4748
>> >
>> > You can also checkout the ui-restyle branch on git, if you are able to
>> manually
>> > compile the cloudstack.scss file via SASS (that will be automated in
>>the
>> > future). I can send over instructions on how to compile SASS manually;
>> it's
>> > pretty easy to setup.
>> >
>> > Let me know what you think so far :)  I'll of course up and post more
>> > screenshots as I get more done. This reskin is only changing the CSS
>> mainly,
>> > with minimal changes to actual usage or JS code, so it is basically a
>> drop-in
>> > replacement for the current styling. I'm hoping to get this in by 4.3,
>> so please
>> > give me feedback on anything from the current UI you don't like or
>>want
>> > changed, and I can see about improving it.
>> >
>> > Thanks!
>> > Brian
>> >
>>
>>

Re: [DISCUSS] UI: New look and feel

[Musayev, Ilya]

I don't agree.

For the reference,  take a look at OpenStack UI and compare it to ACS 
specifically version 4.2


- All mistakes in this message are not mine but Android's.


 Original message 
From: Tracy Phillips 
Date: 09/26/2013 8:06 PM (GMT-05:00)
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] UI: New look and feel


I am a fan of Foundation's look (or Bootstrap even)...

http://foundation.zurb.com/

3d elements make it look dated, kind of like it does now. The less images,
the better imo.




On Thu, Sep 26, 2013 at 7:11 PM, Kelcey Jamison Damage <
kel...@backbonetechnology.com> wrote:

> Hmm, maybe cut 2 copies... 1 with icons, and 1 just a clean text look.
>
> - Original Message -
> From: "Ilya Musayev" 
> To: dev@cloudstack.apache.org
> Sent: Thursday, September 26, 2013 4:08:50 PM
> Subject: RE: [DISCUSS] UI: New look and feel
>
> Brian,
>
> Are we no longer using icons on the left navigation menu or is this a
> draft?
>
> Thanks
> ilya
>
> > -Original Message-
> > From: Kelcey Jamison Damage [mailto:kel...@backbonetechnology.com]
> > Sent: Thursday, September 26, 2013 6:28 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] UI: New look and feel
> >
> > You just made my day, these look great. Most importantly it has a look
> that
> > will sell to IT managers, etc.
> >
> > I wish you the best of luck with this and hope for rapid progress :)
> >
> > Again, it looks awesome!
> >
> > - Original Message -
> > From: "Brian Federle" 
> > To: dev@cloudstack.apache.org
> > Cc: "Sonny Chhen" , "Animesh Chaturvedi"
> > , "Jessica Wang"
> > 
> > Sent: Thursday, September 26, 2013 3:11:07 PM
> > Subject: [DISCUSS] UI: New look and feel
> >
> > Hi all,
> >
> > In addition to the CSS code cleanup I'm working on, I am planning a
> 'reskin' of
> > the current UI to give a better user experience and look and feel. This
> will
> > utilize SASS and a grid system as I have discussed in the previous
> thread.
> >
> > I created a task in JIRA and wiki functional spec, which has screenshots
> of
> > what I've done so far and what I plan to do:
> >
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Update+UI+visu
> > al+appearance
> >
> > https://issues.apache.org/jira/browse/CLOUDSTACK-4748
> >
> > You can also checkout the ui-restyle branch on git, if you are able to
> manually
> > compile the cloudstack.scss file via SASS (that will be automated in the
> > future). I can send over instructions on how to compile SASS manually;
> it's
> > pretty easy to setup.
> >
> > Let me know what you think so far :)  I'll of course up and post more
> > screenshots as I get more done. This reskin is only changing the CSS
> mainly,
> > with minimal changes to actual usage or JS code, so it is basically a
> drop-in
> > replacement for the current styling. I'm hoping to get this in by 4.3,
> so please
> > give me feedback on anything from the current UI you don't like or want
> > changed, and I can see about improving it.
> >
> > Thanks!
> > Brian
> >
>
>

Re: [DISCUSS] UI: New look and feel

[Tracy Phillips]

I am a fan of Foundation's look (or Bootstrap even)...

http://foundation.zurb.com/

3d elements make it look dated, kind of like it does now. The less images,
the better imo.




On Thu, Sep 26, 2013 at 7:11 PM, Kelcey Jamison Damage <
kel...@backbonetechnology.com> wrote:

> Hmm, maybe cut 2 copies... 1 with icons, and 1 just a clean text look.
>
> - Original Message -
> From: "Ilya Musayev" 
> To: dev@cloudstack.apache.org
> Sent: Thursday, September 26, 2013 4:08:50 PM
> Subject: RE: [DISCUSS] UI: New look and feel
>
> Brian,
>
> Are we no longer using icons on the left navigation menu or is this a
> draft?
>
> Thanks
> ilya
>
> > -Original Message-
> > From: Kelcey Jamison Damage [mailto:kel...@backbonetechnology.com]
> > Sent: Thursday, September 26, 2013 6:28 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] UI: New look and feel
> >
> > You just made my day, these look great. Most importantly it has a look
> that
> > will sell to IT managers, etc.
> >
> > I wish you the best of luck with this and hope for rapid progress :)
> >
> > Again, it looks awesome!
> >
> > - Original Message -
> > From: "Brian Federle" 
> > To: dev@cloudstack.apache.org
> > Cc: "Sonny Chhen" , "Animesh Chaturvedi"
> > , "Jessica Wang"
> > 
> > Sent: Thursday, September 26, 2013 3:11:07 PM
> > Subject: [DISCUSS] UI: New look and feel
> >
> > Hi all,
> >
> > In addition to the CSS code cleanup I'm working on, I am planning a
> 'reskin' of
> > the current UI to give a better user experience and look and feel. This
> will
> > utilize SASS and a grid system as I have discussed in the previous
> thread.
> >
> > I created a task in JIRA and wiki functional spec, which has screenshots
> of
> > what I've done so far and what I plan to do:
> >
> > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Update+UI+visu
> > al+appearance
> >
> > https://issues.apache.org/jira/browse/CLOUDSTACK-4748
> >
> > You can also checkout the ui-restyle branch on git, if you are able to
> manually
> > compile the cloudstack.scss file via SASS (that will be automated in the
> > future). I can send over instructions on how to compile SASS manually;
> it's
> > pretty easy to setup.
> >
> > Let me know what you think so far :)  I'll of course up and post more
> > screenshots as I get more done. This reskin is only changing the CSS
> mainly,
> > with minimal changes to actual usage or JS code, so it is basically a
> drop-in
> > replacement for the current styling. I'm hoping to get this in by 4.3,
> so please
> > give me feedback on anything from the current UI you don't like or want
> > changed, and I can see about improving it.
> >
> > Thanks!
> > Brian
> >
>
>

Re: [DISCUSS] Release Managers for future ACS releases - enhacement

[Sheng Yang]

I think one way is, we can just enable the default assigner(maintainer) for
components in Jira. The components can be break down into further smaller
parts, to make sure one guy's work is not big. And the maintainer for the
different components can communicate(just like RM did) to assign the bug(or
resolve by themselves). I think it would be much more efficiency.
CloudStack is so big now that depends on one or two person to triage the
bugs is too much work for them.

One practical issue is, probably too many peoples just set component to
"Management Server", then that guy would have too much work to do(mostly
triage and update the component I believe). But it would be still much
better than all bugs goes to one or two person to triage.

--Sheng


On Thu, Sep 26, 2013 at 4:06 PM, Musayev, Ilya  wrote:

> I can feel your pain, as well as Chip's, Dave's, Joe's and whoever was
> involved in past.
>
> Here is a bit of uncharted territory we need to address about bug
> assignment.
>
> In past I've seen folks ask - we have X number of bugs that need to be
> triaged, who can take what? Are we still keeping this framework and do we
> default to whoever wrote the code/patch initially - if no one volunteers?
>
> While Citrix is one of the main supporters of CloudStack project and has
> people employed to do development, how does one - who has no insight into
> Citrix - assign bugs to people who are employed by Citrix (and can we even
> do that without their full consent)?
>
> One other part, since Citrix and other companies have QA teams, perhaps we
> can have a closer collaboration as to what testing was done on Citrix side
> when it comes to major releases? (i.e. ACS 4.2 release)
>
> I know in past Citrix would branch of from ACS or even have a separate
> codebase, but with future releases, its all going to be one ACS code base.
> So future actual release testing/qa (not automated as part of built
> process) should get easier since we have folks dedicated to work on ACS
> project to do QA or is this an incorrect assumption?
>
> I am also under impression it would help to have at least one person from
> Citrix on RM team, helps with communication, as they can tap people by
> other means other than mailing lists.
>
> There are a lot of assumptions here, I could be wrong on all or some of
> these, please clarify or voice your opinion.
>
> Thanks
> ilya
>
>
>
>
>
> > -Original Message-
> > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> > Sent: Thursday, September 26, 2013 5:25 PM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [DISCUSS] Release Managers for future ACS releases -
> > enhacement
> >
> > +1
> >
> > Ilya I am glad that you brought it up and recognize the challenge. I
> survived
> > on 3 cups of JetFuel[1] every day for last 3 months. It's like doing two
> > $dayjob$ shifts
> >
> > http://www.keurig.com/coffee/jet-fuel-extra-bold-coffee-k-cup-coffee-
> > people
> >
> >
> >
> > > -Original Message-
> > > From: Musayev, Ilya [mailto:imusa...@webmd.net]
> > > Sent: Thursday, September 26, 2013 9:02 AM
> > > To: dev@cloudstack.apache.org
> > > Subject: [DISCUSS] Release Managers for future ACS releases -
> > > enhacement
> > >
> > > I apologize in advance if this is a repeat of something that was
> > > previously stated.
> > >
> > > As Animesh learned recently with ACS 4.2, RM work for major versions
> > > takes a lot of effort, to lesser extent the 4.2.x minor release may
> > > not be as involved, but still decent amount of work.
> > >
> > > What complicates the matter further, is many of us have $dayjobs$ that
> > > don't emphasize heavy involvement on ACS.
> > >
> > > Perhaps we can revisit the strategy and have 2 -3 release managers for
> > > major version and 1-2 for minor.
> > >
> > > Obviously, one is going the be a Lead RM, and others will be secondary
> > > but also involved.
> > >
> > > Any thoughts on this approach?
> > >
> > > Thanks
> > > ilya
> >
>
>
>

Re: Review Request 11981: Adding base support for NVP security groups to the NVP API

[Chiradeep Vittal]

> On June 20, 2013, 6:40 a.m., Prasanna Santhanam wrote:
> > Minor nitpick : our code conventions recommend the method naming to not use 
> > underscore. so it's lowerCaseAndNoUnderscores()
> > 
> > http://cloudstack.apache.org/develop/coding-conventions.html
> 
> Animesh Chaturvedi wrote:
> Hugo can you review this patch

Agree with Prasanna's comment. 


- Chiradeep


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


On June 19, 2013, 9:28 p.m., Adrian Steer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/11981/
> ---
> 
> (Updated June 19, 2013, 9:28 p.m.)
> 
> 
> Review request for cloudstack and Hugo Trippaers.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> This is initial version of API implementation of security groups within the 
> NVP API
> 
> 
> Diffs
> -
> 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/LogicalSwitchPort.java
>  c571458 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraAddressPairs.java
>  PRE-CREATION 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraLogicalPortRule.java
>  PRE-CREATION 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraNvpApi.java
>  12fa6c0 
>   
> plugins/network-elements/nicira-nvp/src/com/cloud/network/nicira/NiciraSecurityProfile.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/11981/diff/
> 
> 
> Testing
> ---
> 
> Compile testing
> 
> 
> Thanks,
> 
> Adrian Steer
> 
>

Re: Review Request 14346: CLOUDSTACK:4647 - Fixed test_snapshot_gc.py and common utility function to check snapshot on NFS

[Rayees Namathponnan]

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


Is it tested on KVM, Xen and vmware ?

Tested or not missing in review

- Rayees Namathponnan


On Sept. 26, 2013, 10 a.m., Gaurav Aradhye wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14346/
> ---
> 
> (Updated Sept. 26, 2013, 10 a.m.)
> 
> 
> Review request for cloudstack and Prasanna Santhanam.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> 1. test_snapshot_gc.py : 
> a) Removed the account and vm from cleanup, as we are already deleting 
> account in the test case execution itself. Adding it to cleanup was throwing 
> exception during cleanup operation.
> b) Once account deleted, listAccount API should fail (as against it should 
> give None)
> 
> 2. utils.py
> Changes in "is_snapshot_on_nfs" function:
> 
> a) Corrected the mount URL, earlier mgt server IP was passed instead of nfs 
> url
> b) Removed the extra colon between host and dir, colon is already present in 
> the host variable on KVM and VMWare which is correct behaviour. This fails on 
> Xen Sever as the colon is not present. Bug filed for Xen Server >>> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-4741
> b) If snapshot not present in db , then return False as the snapshot is not 
> present
> 
> 
> Diffs
> -
> 
>   test/integration/component/test_snapshot_gc.py aec9761 
>   tools/marvin/marvin/integration/lib/utils.py a6abe06 
> 
> Diff: https://reviews.apache.org/r/14346/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gaurav Aradhye
> 
>

Re: [DISCUSS] UI: New look and feel

[Kelcey Jamison Damage]

Hmm, maybe cut 2 copies... 1 with icons, and 1 just a clean text look.

- Original Message -
From: "Ilya Musayev" 
To: dev@cloudstack.apache.org
Sent: Thursday, September 26, 2013 4:08:50 PM
Subject: RE: [DISCUSS] UI: New look and feel

Brian,

Are we no longer using icons on the left navigation menu or is this a draft?

Thanks
ilya

> -Original Message-
> From: Kelcey Jamison Damage [mailto:kel...@backbonetechnology.com]
> Sent: Thursday, September 26, 2013 6:28 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] UI: New look and feel
> 
> You just made my day, these look great. Most importantly it has a look that
> will sell to IT managers, etc.
> 
> I wish you the best of luck with this and hope for rapid progress :)
> 
> Again, it looks awesome!
> 
> - Original Message -
> From: "Brian Federle" 
> To: dev@cloudstack.apache.org
> Cc: "Sonny Chhen" , "Animesh Chaturvedi"
> , "Jessica Wang"
> 
> Sent: Thursday, September 26, 2013 3:11:07 PM
> Subject: [DISCUSS] UI: New look and feel
> 
> Hi all,
> 
> In addition to the CSS code cleanup I'm working on, I am planning a 'reskin' 
> of
> the current UI to give a better user experience and look and feel. This will
> utilize SASS and a grid system as I have discussed in the previous thread.
> 
> I created a task in JIRA and wiki functional spec, which has screenshots of
> what I've done so far and what I plan to do:
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Update+UI+visu
> al+appearance
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-4748
> 
> You can also checkout the ui-restyle branch on git, if you are able to 
> manually
> compile the cloudstack.scss file via SASS (that will be automated in the
> future). I can send over instructions on how to compile SASS manually; it's
> pretty easy to setup.
> 
> Let me know what you think so far :)  I'll of course up and post more
> screenshots as I get more done. This reskin is only changing the CSS mainly,
> with minimal changes to actual usage or JS code, so it is basically a drop-in
> replacement for the current styling. I'm hoping to get this in by 4.3, so 
> please
> give me feedback on anything from the current UI you don't like or want
> changed, and I can see about improving it.
> 
> Thanks!
> Brian
> 

RE: [DISCUSS] UI: New look and feel

[Musayev, Ilya]

Brian,

Are we no longer using icons on the left navigation menu or is this a draft?

Thanks
ilya

> -Original Message-
> From: Kelcey Jamison Damage [mailto:kel...@backbonetechnology.com]
> Sent: Thursday, September 26, 2013 6:28 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] UI: New look and feel
> 
> You just made my day, these look great. Most importantly it has a look that
> will sell to IT managers, etc.
> 
> I wish you the best of luck with this and hope for rapid progress :)
> 
> Again, it looks awesome!
> 
> - Original Message -
> From: "Brian Federle" 
> To: dev@cloudstack.apache.org
> Cc: "Sonny Chhen" , "Animesh Chaturvedi"
> , "Jessica Wang"
> 
> Sent: Thursday, September 26, 2013 3:11:07 PM
> Subject: [DISCUSS] UI: New look and feel
> 
> Hi all,
> 
> In addition to the CSS code cleanup I'm working on, I am planning a 'reskin' 
> of
> the current UI to give a better user experience and look and feel. This will
> utilize SASS and a grid system as I have discussed in the previous thread.
> 
> I created a task in JIRA and wiki functional spec, which has screenshots of
> what I've done so far and what I plan to do:
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Update+UI+visu
> al+appearance
> 
> https://issues.apache.org/jira/browse/CLOUDSTACK-4748
> 
> You can also checkout the ui-restyle branch on git, if you are able to 
> manually
> compile the cloudstack.scss file via SASS (that will be automated in the
> future). I can send over instructions on how to compile SASS manually; it's
> pretty easy to setup.
> 
> Let me know what you think so far :)  I'll of course up and post more
> screenshots as I get more done. This reskin is only changing the CSS mainly,
> with minimal changes to actual usage or JS code, so it is basically a drop-in
> replacement for the current styling. I'm hoping to get this in by 4.3, so 
> please
> give me feedback on anything from the current UI you don't like or want
> changed, and I can see about improving it.
> 
> Thanks!
> Brian
> 

RE: [DISCUSS] Release Managers for future ACS releases - enhacement

[Musayev, Ilya]

I can feel your pain, as well as Chip's, Dave's, Joe's and whoever was involved 
in past.

Here is a bit of uncharted territory we need to address about bug assignment. 

In past I've seen folks ask - we have X number of bugs that need to be triaged, 
who can take what? Are we still keeping this framework and do we default to 
whoever wrote the code/patch initially - if no one volunteers?

While Citrix is one of the main supporters of CloudStack project and has people 
employed to do development, how does one - who has no insight into Citrix - 
assign bugs to people who are employed by Citrix (and can we even do that 
without their full consent)? 

One other part, since Citrix and other companies have QA teams, perhaps we can 
have a closer collaboration as to what testing was done on Citrix side when it 
comes to major releases? (i.e. ACS 4.2 release)

I know in past Citrix would branch of from ACS or even have a separate 
codebase, but with future releases, its all going to be one ACS code base. So 
future actual release testing/qa (not automated as part of built process) 
should get easier since we have folks dedicated to work on ACS project to do QA 
or is this an incorrect assumption? 

I am also under impression it would help to have at least one person from 
Citrix on RM team, helps with communication, as they can tap people by other 
means other than mailing lists.

There are a lot of assumptions here, I could be wrong on all or some of these, 
please clarify or voice your opinion.

Thanks
ilya





> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Thursday, September 26, 2013 5:25 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [DISCUSS] Release Managers for future ACS releases -
> enhacement
> 
> +1
> 
> Ilya I am glad that you brought it up and recognize the challenge. I survived
> on 3 cups of JetFuel[1] every day for last 3 months. It's like doing two
> $dayjob$ shifts
> 
> http://www.keurig.com/coffee/jet-fuel-extra-bold-coffee-k-cup-coffee-
> people
> 
> 
> 
> > -Original Message-
> > From: Musayev, Ilya [mailto:imusa...@webmd.net]
> > Sent: Thursday, September 26, 2013 9:02 AM
> > To: dev@cloudstack.apache.org
> > Subject: [DISCUSS] Release Managers for future ACS releases -
> > enhacement
> >
> > I apologize in advance if this is a repeat of something that was
> > previously stated.
> >
> > As Animesh learned recently with ACS 4.2, RM work for major versions
> > takes a lot of effort, to lesser extent the 4.2.x minor release may
> > not be as involved, but still decent amount of work.
> >
> > What complicates the matter further, is many of us have $dayjobs$ that
> > don't emphasize heavy involvement on ACS.
> >
> > Perhaps we can revisit the strategy and have 2 -3 release managers for
> > major version and 1-2 for minor.
> >
> > Obviously, one is going the be a Lead RM, and others will be secondary
> > but also involved.
> >
> > Any thoughts on this approach?
> >
> > Thanks
> > ilya
> 

RE: [DISCUSS] Release Managers for future ACS releases - enhacement

[Sudha Ponnaganti]

+1 on multiple RMs

+1 on assigning defects by RMs as this gives faster closure on defects esp 
critical ones. This can be done over IRC at regular intervals instead of 
waiting for folks to claim defects which may take time given the priorities 
that each one has. Same with validation as well.  

-Original Message-
From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] 
Sent: Thursday, September 26, 2013 2:59 PM
To: dev@cloudstack.apache.org
Subject: RE: [DISCUSS] Release Managers for future ACS releases - enhacement



> -Original Message-
> From: Alex Huang [mailto:alex.hu...@citrix.com]
> Sent: Thursday, September 26, 2013 10:22 AM
> To: dev@cloudstack.apache.org
> Subject: RE: [DISCUSS] Release Managers for future ACS releases - 
> enhacement
> 
> Agreed.  If you look at what a release manager has to do today
> 
> - triage bugs
> - follow up on reviews and ask people to commit them
> - cherry-pick fixes
> 
> To me it is a lot of work for one person to do for CloudStack.  We can 
> certainly divide up the work.  For example,
> 
>  - One RM is responsible for overall release
>  - One RM is responsible for following up on review board
>  - Two or three RMs is responsible for triaging bugs
>  - One is responsible for cherry-pick
> 
> I also like to propose that we stop the practice of only assigning 
> bugs to yourself.  I know it's there to make sure there's no 
> cookie-licking but really let's not make ourselves less efficient just for 
> the sake of
> appearances.   RMs should be able to assign bugs as part of the process
> to ask for someone to look at the bug rather than having to ask 
> privately and have the person assign to themselves.  Keeping track of 
> such things with the amount of changes CloudStack goes through in a 
> release just makes us less efficient and less enjoyable to work on 
> CloudStack.
> 
> --Alex
[Animesh>] Alex thanks for bringing this up I was going to reopen the "Do not 
assign tickets to people" thread after 4.2 is announced. To set the perspective 
4.2 was a huge release whereas community  fixed 1900+ issues in 7 months. That 
speaks a lot about the vibrancy of our community but as a release manager not 
being able to assign the bugs was a huge hindrance.  I had to export all the 
data out every day in excel run pivots and follow through in private emails and 
keep an inventory on which one did not get responded to in offline 
spreadsheets. It is so much easier to use JIRA and keep the whole context in 
one place and also it makes all the effort towards shipping a release  
transparent and public.

If you look in JIRA we have over 250 unassigned issues that were create over 6 
months ago and over 700 open unassigned issues, without active triage and the 
ability to assign our backlog will continue to grow.


Thanks
Animesh


> 
> > -Original Message-
> > From: Musayev, Ilya [mailto:imusa...@webmd.net]
> > Sent: Thursday, September 26, 2013 9:02 AM
> > To: dev@cloudstack.apache.org
> > Subject: [DISCUSS] Release Managers for future ACS releases - 
> > enhacement
> >
> > I apologize in advance if this is a repeat of something that was 
> > previously stated.
> >
> > As Animesh learned recently with ACS 4.2, RM work for major versions 
> > takes a lot of effort, to lesser extent the 4.2.x minor release may 
> > not be as involved, but still decent amount of work.
> >
> > What complicates the matter further, is many of us have $dayjobs$ 
> > that don't emphasize heavy involvement on ACS.
> >
> > Perhaps we can revisit the strategy and have 2 -3 release managers 
> > for major version and 1-2 for minor.
> >
> > Obviously, one is going the be a Lead RM, and others will be 
> > secondary but also involved.
> >
> > Any thoughts on this approach?
> >
> > Thanks
> > ilya

Re: add connect method on KVM storage code

[Marcus Sorensen]

Looking at your code, is the chap info stored with the pool, so we
could pass the pool to the adaptor? That would be more agnostic,
anyone implementing a plugin could pull the specifics they need for
their stuff out of the pool on the adaptor side, rather than creating
custom signatures.

Also, I think we may want to consider implementing connect/disconnect
as just dummy methods in LibvirtStorageAdaptor, so we don't have to be
picky about which adaptors/types in every single place we may want to
connect/disconnect (in 4.1 there were several, I'm not sure if
everything goes through this in 4.2). We can just call
adaptor.connectPhysicalDisk and the adaptor can decide if it needs to
do anything.

Comments are attached to your commit, I just wanted to echo them here on-list.

On Thu, Sep 26, 2013 at 4:32 PM, Mike Tutkowski
 wrote:
> Oh, SnapshotTestWithFakeData is just modified because the code wasn't
> building until I corrected this. It has nothing really to do with my real
> changes.
>
>
> On Thu, Sep 26, 2013 at 4:31 PM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
>> Hey Marcus,
>>
>> I implemented your recommendations regarding adding connect and disconnect
>> methods. It is not yet checked in (as you know, having trouble with my KVM
>> environment), but it is on GitHub here:
>>
>>
>> https://github.com/mike-tutkowski/incubator-cloudstack/commit/f2897c65689012e6157c0a0c2ed7e5355900c59a
>>
>> Please let me know if you have any more comments.
>>
>> Thanks!
>>
>>
>> On Thu, Sep 26, 2013 at 4:05 PM, Marcus Sorensen wrote:
>>
>>> Mike, everyone,
>>>As I've mentioned on the board, I'm working on getting our own
>>> internal KVM storage plugin working on 4.2. In the interest of making
>>> it forward compatible, I just wanted to confirm what you were doing
>>> with the solidfire plugin as far as attaching your iscsi LUNs. We had
>>> discussed a new connectPhysicalDisk method for the StorageAdaptor
>>> class, something perhaps like:
>>>
>>> public boolean connectPhysicalDisk(String volumeUuid, KVMStoragePool
>>> pool);
>>>
>>> then added to KVMStoragePoolManager:
>>>
>>> public boolean connectPhysicalDisk(StoragePoolType type, String
>>> poolUuid, String volPath) {
>>> StorageAdaptor adaptor = getStorageAdaptor(type);
>>> KVMStoragePool pool = adaptor.getStoragePool(poolUuid);
>>> return adaptor.connectPhysicalDisk(volPath, pool);
>>> }
>>>
>>> Something similar to this for disconnect as well. Then in the
>>> KVMStorageProcessor these can be called as needed for attach/detach.
>>> We can probably stub out one in LibvirtStorageAdaptor so there's no
>>> need to switch or if/else for pool types, for example in
>>> KVMStorageProcessor.attachVolume.
>>>
>>> I have debated on whether or not it should just be rolled into
>>> getPhysicalDisk, having it connect the disk if it's not already
>>> connected. getPhysicalDisk is called a lot, and I'm not sure it always
>>> needs to connect the disk when it does. In past iterations
>>> getPhysicalDisk has simply spoken to our SAN api and returned the disk
>>> details, nothing more. So it seemed more flexible and granular to do
>>> the connectPhysicalDisk (we have one now in our 4.1 version).
>>>
>>
>>
>>
>> --
>> *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: add connect method on KVM storage code

[Mike Tutkowski]

Oh, SnapshotTestWithFakeData is just modified because the code wasn't
building until I corrected this. It has nothing really to do with my real
changes.


On Thu, Sep 26, 2013 at 4:31 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Hey Marcus,
>
> I implemented your recommendations regarding adding connect and disconnect
> methods. It is not yet checked in (as you know, having trouble with my KVM
> environment), but it is on GitHub here:
>
>
> https://github.com/mike-tutkowski/incubator-cloudstack/commit/f2897c65689012e6157c0a0c2ed7e5355900c59a
>
> Please let me know if you have any more comments.
>
> Thanks!
>
>
> On Thu, Sep 26, 2013 at 4:05 PM, Marcus Sorensen wrote:
>
>> Mike, everyone,
>>As I've mentioned on the board, I'm working on getting our own
>> internal KVM storage plugin working on 4.2. In the interest of making
>> it forward compatible, I just wanted to confirm what you were doing
>> with the solidfire plugin as far as attaching your iscsi LUNs. We had
>> discussed a new connectPhysicalDisk method for the StorageAdaptor
>> class, something perhaps like:
>>
>> public boolean connectPhysicalDisk(String volumeUuid, KVMStoragePool
>> pool);
>>
>> then added to KVMStoragePoolManager:
>>
>> public boolean connectPhysicalDisk(StoragePoolType type, String
>> poolUuid, String volPath) {
>> StorageAdaptor adaptor = getStorageAdaptor(type);
>> KVMStoragePool pool = adaptor.getStoragePool(poolUuid);
>> return adaptor.connectPhysicalDisk(volPath, pool);
>> }
>>
>> Something similar to this for disconnect as well. Then in the
>> KVMStorageProcessor these can be called as needed for attach/detach.
>> We can probably stub out one in LibvirtStorageAdaptor so there's no
>> need to switch or if/else for pool types, for example in
>> KVMStorageProcessor.attachVolume.
>>
>> I have debated on whether or not it should just be rolled into
>> getPhysicalDisk, having it connect the disk if it's not already
>> connected. getPhysicalDisk is called a lot, and I'm not sure it always
>> needs to connect the disk when it does. In past iterations
>> getPhysicalDisk has simply spoken to our SAN api and returned the disk
>> details, nothing more. So it seemed more flexible and granular to do
>> the connectPhysicalDisk (we have one now in our 4.1 version).
>>
>
>
>
> --
> *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: add connect method on KVM storage code

[Mike Tutkowski]

Hey Marcus,

I implemented your recommendations regarding adding connect and disconnect
methods. It is not yet checked in (as you know, having trouble with my KVM
environment), but it is on GitHub here:

https://github.com/mike-tutkowski/incubator-cloudstack/commit/f2897c65689012e6157c0a0c2ed7e5355900c59a

Please let me know if you have any more comments.

Thanks!


On Thu, Sep 26, 2013 at 4:05 PM, Marcus Sorensen wrote:

> Mike, everyone,
>As I've mentioned on the board, I'm working on getting our own
> internal KVM storage plugin working on 4.2. In the interest of making
> it forward compatible, I just wanted to confirm what you were doing
> with the solidfire plugin as far as attaching your iscsi LUNs. We had
> discussed a new connectPhysicalDisk method for the StorageAdaptor
> class, something perhaps like:
>
> public boolean connectPhysicalDisk(String volumeUuid, KVMStoragePool pool);
>
> then added to KVMStoragePoolManager:
>
> public boolean connectPhysicalDisk(StoragePoolType type, String
> poolUuid, String volPath) {
> StorageAdaptor adaptor = getStorageAdaptor(type);
> KVMStoragePool pool = adaptor.getStoragePool(poolUuid);
> return adaptor.connectPhysicalDisk(volPath, pool);
> }
>
> Something similar to this for disconnect as well. Then in the
> KVMStorageProcessor these can be called as needed for attach/detach.
> We can probably stub out one in LibvirtStorageAdaptor so there's no
> need to switch or if/else for pool types, for example in
> KVMStorageProcessor.attachVolume.
>
> I have debated on whether or not it should just be rolled into
> getPhysicalDisk, having it connect the disk if it's not already
> connected. getPhysicalDisk is called a lot, and I'm not sure it always
> needs to connect the disk when it does. In past iterations
> getPhysicalDisk has simply spoken to our SAN api and returned the disk
> details, nothing more. So it seemed more flexible and granular to do
> the connectPhysicalDisk (we have one now in our 4.1 version).
>



-- 
*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: [DISCUSS] UI: New look and feel

[Kelcey Jamison Damage]

You just made my day, these look great. Most importantly it has a look that 
will sell to IT managers, etc.

I wish you the best of luck with this and hope for rapid progress :)

Again, it looks awesome!

- Original Message -
From: "Brian Federle" 
To: dev@cloudstack.apache.org
Cc: "Sonny Chhen" , "Animesh Chaturvedi" 
, "Jessica Wang" 
Sent: Thursday, September 26, 2013 3:11:07 PM
Subject: [DISCUSS] UI: New look and feel

Hi all,

In addition to the CSS code cleanup I'm working on, I am planning a 'reskin' of 
the current UI to give a better user experience and look and feel. This will 
utilize SASS and a grid system as I have discussed in the previous thread.

I created a task in JIRA and wiki functional spec, which has screenshots of 
what I've done so far and what I plan to do:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Update+UI+visual+appearance

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

You can also checkout the ui-restyle branch on git, if you are able to manually 
compile the cloudstack.scss file via SASS (that will be automated in the 
future). I can send over instructions on how to compile SASS manually; it's 
pretty easy to setup.

Let me know what you think so far :)  I'll of course up and post more 
screenshots as I get more done. This reskin is only changing the CSS mainly, 
with minimal changes to actual usage or JS code, so it is basically a drop-in 
replacement for the current styling. I'm hoping to get this in by 4.3, so 
please give me feedback on anything from the current UI you don't like or want 
changed, and I can see about improving it.

Thanks!
Brian

[DISCUSS] UI: New look and feel

[Brian Federle]

Hi all,

In addition to the CSS code cleanup I'm working on, I am planning a 'reskin' of 
the current UI to give a better user experience and look and feel. This will 
utilize SASS and a grid system as I have discussed in the previous thread.

I created a task in JIRA and wiki functional spec, which has screenshots of 
what I've done so far and what I plan to do:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Update+UI+visual+appearance

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

You can also checkout the ui-restyle branch on git, if you are able to manually 
compile the cloudstack.scss file via SASS (that will be automated in the 
future). I can send over instructions on how to compile SASS manually; it's 
pretty easy to setup.

Let me know what you think so far :)  I'll of course up and post more 
screenshots as I get more done. This reskin is only changing the CSS mainly, 
with minimal changes to actual usage or JS code, so it is basically a drop-in 
replacement for the current styling. I'm hoping to get this in by 4.3, so 
please give me feedback on anything from the current UI you don't like or want 
changed, and I can see about improving it.

Thanks!
Brian

buildbot failure in ASF Buildbot on cloudstack-site-staging

[buildbot]

The Buildbot has detected a new failure on builder cloudstack-site-staging 
while building ASF Buildbot.
Full details are available at:
 http://ci.apache.org/builders/cloudstack-site-staging/builds/204

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: bb-cms-slave

Build Reason: scheduler
Build Source Stamp: [branch cloudstack/site] 1526718
Blamelist: ke4qqq

BUILD FAILED: failed compile

sincerely,
 -The Buildbot

add connect method on KVM storage code

[Marcus Sorensen]

Mike, everyone,
   As I've mentioned on the board, I'm working on getting our own
internal KVM storage plugin working on 4.2. In the interest of making
it forward compatible, I just wanted to confirm what you were doing
with the solidfire plugin as far as attaching your iscsi LUNs. We had
discussed a new connectPhysicalDisk method for the StorageAdaptor
class, something perhaps like:

public boolean connectPhysicalDisk(String volumeUuid, KVMStoragePool pool);

then added to KVMStoragePoolManager:

public boolean connectPhysicalDisk(StoragePoolType type, String
poolUuid, String volPath) {
StorageAdaptor adaptor = getStorageAdaptor(type);
KVMStoragePool pool = adaptor.getStoragePool(poolUuid);
return adaptor.connectPhysicalDisk(volPath, pool);
}

Something similar to this for disconnect as well. Then in the
KVMStorageProcessor these can be called as needed for attach/detach.
We can probably stub out one in LibvirtStorageAdaptor so there's no
need to switch or if/else for pool types, for example in
KVMStorageProcessor.attachVolume.

I have debated on whether or not it should just be rolled into
getPhysicalDisk, having it connect the disk if it's not already
connected. getPhysicalDisk is called a lot, and I'm not sure it always
needs to connect the disk when it does. In past iterations
getPhysicalDisk has simply spoken to our SAN api and returned the disk
details, nothing more. So it seemed more flexible and granular to do
the connectPhysicalDisk (we have one now in our 4.1 version).

RE: [DISCUSS] Release Managers for future ACS releases - enhacement

[Animesh Chaturvedi]

> -Original Message-
> From: Alex Huang [mailto:alex.hu...@citrix.com]
> Sent: Thursday, September 26, 2013 10:22 AM
> To: dev@cloudstack.apache.org
> Subject: RE: [DISCUSS] Release Managers for future ACS releases -
> enhacement
> 
> Agreed.  If you look at what a release manager has to do today
> 
> - triage bugs
> - follow up on reviews and ask people to commit them
> - cherry-pick fixes
> 
> To me it is a lot of work for one person to do for CloudStack.  We can
> certainly divide up the work.  For example,
> 
>  - One RM is responsible for overall release
>  - One RM is responsible for following up on review board
>  - Two or three RMs is responsible for triaging bugs
>  - One is responsible for cherry-pick
> 
> I also like to propose that we stop the practice of only assigning bugs
> to yourself.  I know it's there to make sure there's no cookie-licking
> but really let's not make ourselves less efficient just for the sake of
> appearances.   RMs should be able to assign bugs as part of the process
> to ask for someone to look at the bug rather than having to ask
> privately and have the person assign to themselves.  Keeping track of
> such things with the amount of changes CloudStack goes through in a
> release just makes us less efficient and less enjoyable to work on
> CloudStack.
> 
> --Alex
[Animesh>] Alex thanks for bringing this up I was going to reopen the "Do not 
assign tickets to people" thread after 4.2 is announced. To set the perspective 
4.2 was a huge release whereas community  fixed 1900+ issues in 7 months. That 
speaks a lot about the vibrancy of our community but as a release manager not 
being able to assign the bugs was a huge hindrance.  I had to export all the 
data out every day in excel run pivots and follow through in private emails and 
keep an inventory on which one did not get responded to in offline 
spreadsheets. It is so much easier to use JIRA and keep the whole context in 
one place and also it makes all the effort towards shipping a release  
transparent and public.

If you look in JIRA we have over 250 unassigned issues that were create over 6 
months ago and over 700 open unassigned issues, without active triage and the 
ability to assign our backlog will continue to grow.


Thanks
Animesh


> 
> > -Original Message-
> > From: Musayev, Ilya [mailto:imusa...@webmd.net]
> > Sent: Thursday, September 26, 2013 9:02 AM
> > To: dev@cloudstack.apache.org
> > Subject: [DISCUSS] Release Managers for future ACS releases -
> > enhacement
> >
> > I apologize in advance if this is a repeat of something that was
> > previously stated.
> >
> > As Animesh learned recently with ACS 4.2, RM work for major versions
> > takes a lot of effort, to lesser extent the 4.2.x minor release may
> > not be as involved, but still decent amount of work.
> >
> > What complicates the matter further, is many of us have $dayjobs$ that
> > don't emphasize heavy involvement on ACS.
> >
> > Perhaps we can revisit the strategy and have 2 -3 release managers for
> > major version and 1-2 for minor.
> >
> > Obviously, one is going the be a Lead RM, and others will be secondary
> > but also involved.
> >
> > Any thoughts on this approach?
> >
> > Thanks
> > ilya

[PROPOSAL] Site-to-site VPN between two virtual routers

[Sheng Yang]

Hi,

I'd like to propose "site-to-site VPN between VRs" as a new feature for
CloudStack 4.3.

Basically the VPC's site-to-site VPN currently only support to access
remote peer which is a hardware VPN gateway. This feature would extend the
support to other CloudStack VRs, which enabled CloudStack networks to
communicate with each other through VPN.

Original requirement at:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Site-to-Site+VPN+2.0
https://issues.apache.org/jira/browse/CLOUDSTACK-730

FS available at:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Site-to-site+VPN+VR-to-VR+functional+spec

--Sheng

Re: Libvirt-java 0.5.0 has been released

[Mike Tutkowski]

Looks like the new code references cloudstack-agent-upgrade.

I'm on Ubuntu 12.04, by the way.

/var/lib/dpkg/info/cloudstack-agent.postinst: line 39:
/usr/bin/cloudstack-agent-upgrade: No such file or directory
dpkg: error processing cloudstack-agent (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 cloudstack-agent
E: Sub-process /usr/bin/dpkg returned an error code (1)



On Thu, Sep 26, 2013 at 2:57 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> OK, thanks!
>
>
> On Thu, Sep 26, 2013 at 2:52 PM, Wei ZHOU  wrote:
>
>> Mike,
>> Sorry my fault. already fixed by commit
>> 522860c03de5d05126f92fc44b6e3f50ed8439f0
>> Please pull the latest code.
>>
>>
>> 2013/9/26 Mike Tutkowski 
>>
>> > Any thoughts on this error message?
>> >
>> > I updated from master today, cleaned, recompiled, then rebuilt and
>> > redeployed the DEBs.
>> >
>> > Thanks
>> >
>> > mtutkowski@ubuntu:~$ sudo apt-get install cloudstack-agent
>> > Reading package lists... Done
>> > Building dependency tree
>> > Reading state information... Done
>> > The following NEW packages will be installed:
>> >   cloudstack-agent
>> > 0 upgraded, 1 newly installed, 0 to remove and 468 not upgraded.
>> > Need to get 39.1 MB of archives.
>> > After this operation, 43.6 MB of additional disk space will be used.
>> > WARNING: The following packages cannot be authenticated!
>> >   cloudstack-agent
>> > Install these packages without verification [y/N]? y
>> > Get:1 http://localhost/cloudstack/repo/ binary/ cloudstack-agent 4.3.0
>> > [39.1 MB]
>> > Fetched 39.1 MB in 0s (49.3 MB/s)
>> > Selecting previously unselected package cloudstack-agent.
>> > (Reading database ... 168800 files and directories currently installed.)
>> > Unpacking cloudstack-agent (from .../cloudstack-agent_4.3.0_all.deb) ...
>> > Processing triggers for ureadahead ...
>> > Setting up cloudstack-agent (4.3.0) ...
>> > /var/lib/dpkg/info/cloudstack-agent.postinst: line 39:
>> > /usr/bin/cloudstack-agent-upgrade: No such file or directory
>> > dpkg: error processing cloudstack-agent (--configure):
>> >  subprocess installed post-installation script returned error exit
>> status 1
>> > E: Sub-process /usr/bin/dpkg returned an error code (1)
>> >
>> >
>> >
>> > On Thu, Sep 26, 2013 at 8:45 AM, Mike Tutkowski <
>> > mike.tutkow...@solidfire.com> wrote:
>> >
>> > > Let me update and try again and see if that solves the problem.
>> > >
>> > > I am probably a week behind on updating from master.
>> > >
>> > > Thanks
>> > >
>> > >
>> > > On Wed, Sep 25, 2013 at 11:18 PM, Wei ZHOU 
>> > wrote:
>> > >
>> > >> Mike,
>> > >> Do you test the latest source code?
>> > >>
>> > >>  Pointer.nativeValue  is introduced in jna-3.2.6
>> > >>
>> > >>
>> >
>> http://upstream-tracker.org/java/compat_reports/jna/3.2.5_to_3.2.6/bin_compat_report.html
>> > >> and Native.free  is introduced in jna-3.3.0
>> > >>
>> > >>
>> >
>> http://upstream-tracker.org/java/compat_reports/jna/3.2.7_to_3.3.0/bin_compat_report.html
>> > >>
>> > >> After commit 3dc4284,  jna-4.0.0.jar is in
>> > /usr/share/cloudstack-agent/lib
>> > >> , then it should be ok.
>> > >>
>> > >> -Wei
>> > >>
>> > >>
>> > >> 2013/9/26 Mike Tutkowski 
>> > >>
>> > >> > Hi,
>> > >> >
>> > >> > I've been having a difficult time getting the KVM agent on master
>> to
>> > >> start
>> > >> > on Ubuntu 12.04.
>> > >> >
>> > >> > The trouble seems to have begun after the Libvirt upgrade.
>> > >> >
>> > >> > Any thoughts on this:
>> > >> >
>> > >> > Thanks!
>> > >> >
>> > >> > 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#noconfigfor
>> > >> > 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.NoSuchMethodError: com.sun.jna.Native.free(J)V
>> > >> > at org.libvirt.Library.free(Unknown Source)
>> > >> > at org.libvirt.Connect.getCapabilities(Unknown Source)
>> > >> > at
>> > >> >
>> > >> >
>> > >>
>> >
>> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.IsHVMEnabled(LibvirtComputingResource.java:4524)
>> > >> > at
>> > >> >
>> > >> >
>> > >>
>> >
>> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.configure(LibvirtComputingResource.java:753)
>> > >> > at com.cloud.agent.Agent.(Agent.java:168)
>> >

RE: [DISCUSS] Release Managers for future ACS releases - enhacement

[Animesh Chaturvedi]

+1

Ilya I am glad that you brought it up and recognize the challenge. I survived 
on 3 cups of JetFuel[1] every day for last 3 months. It's like doing two 
$dayjob$ shifts

http://www.keurig.com/coffee/jet-fuel-extra-bold-coffee-k-cup-coffee-people

 

> -Original Message-
> From: Musayev, Ilya [mailto:imusa...@webmd.net]
> Sent: Thursday, September 26, 2013 9:02 AM
> To: dev@cloudstack.apache.org
> Subject: [DISCUSS] Release Managers for future ACS releases - enhacement
> 
> I apologize in advance if this is a repeat of something that was
> previously stated.
> 
> As Animesh learned recently with ACS 4.2, RM work for major versions
> takes a lot of effort, to lesser extent the 4.2.x minor release may not
> be as involved, but still decent amount of work.
> 
> What complicates the matter further, is many of us have $dayjobs$ that
> don't emphasize heavy involvement on ACS.
> 
> Perhaps we can revisit the strategy and have 2 -3 release managers for
> major version and 1-2 for minor.
> 
> Obviously, one is going the be a Lead RM, and others will be secondary
> but also involved.
> 
> Any thoughts on this approach?
> 
> Thanks
> ilya

Re: com.cloud.exception.InsufficientServerCapacityException what wrong?

[Sheng Yang]

Log is needed to tell what's wrong.

Basically it means you don't have enough resources(host or network or
storage) to deploy the vm.

--Sheng


On Tue, Sep 24, 2013 at 12:27 AM, Jake.liu  wrote:

>DeployDestination dest;
> try {
> dest = _dpMgr.planDeployment(vmProfile, plan, exclude);
> } catch (AffinityConflictException e) {
> throw new CloudRuntimeException("Unable to create deployment,
> affinity rules associted to the VM conflict");
> }
>
>
> if (dest != null) {
>//save destination with VMEntityVO
> VMReservationVO vmReservation = new
> VMReservationVO(vm.getId(), dest.getDataCenter().getId(),
> dest.getPod().getId(), dest.getCluster().getId(), dest.getHost().getId());
> Map volumeReservationMap = new HashMap();
>
>
> if (vm.getHypervisorType() != HypervisorType.BareMetal) {
> for(Volume vo : dest.getStorageForDisks().keySet()){
> volumeReservationMap.put(vo.getId(),
> dest.getStorageForDisks().get(vo).getId());
> }
> vmReservation.setVolumeReservation(volumeReservationMap);
> }
>
>
> vmEntityVO.setVmReservation(vmReservation);
> _vmEntityDao.persist(vmEntityVO);
>
>
> return vmReservation.getUuid();
> } else if (planChangedByReadyVolume) {
> // we could not reserve in the Volume's cluster - let the
> deploy
> // call retry it.
> return UUID.randomUUID().toString();
> }else{
> throw new InsufficientServerCapacityException("Unable to
> create a deployment for " + vmProfile,
> DataCenter.class, plan.getDataCenterId(),
> areAffinityGroupsAssociated(vmProfile));
> }

Re: Review Request 14320: add boolean option httpModeEnabled to the service offering for use in haproxy conf

[Chiradeep Vittal]

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


Not sure if this should be in the API since it is a HAProxy-specific 
configuration. This wouldn't apply to Netscaler or F5. 
After all the end user has no idea if he is using HAProxy of Netscaler or F5.

Likely this flag is of interest to the cloud operator only, so why not put it 
in zone-wide config instead of the network offering.
Do you really see someone creating 2 offerings: one with HttpClose and one 
without HttpClose?

- Chiradeep Vittal


On Sept. 26, 2013, 7:01 p.m., daan Hoogland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/14320/
> ---
> 
> (Updated Sept. 26, 2013, 7:01 p.m.)
> 
> 
> Review request for cloudstack and Wei Zhou.
> 
> 
> Bugs: CLOUDSTACK-4328
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> add boolean option httpModeEnabled to the service offering for use in haproxy 
> conf
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/offering/NetworkOffering.java 6c5573e 
>   api/src/org/apache/cloudstack/api/ApiConstants.java f85784b 
>   
> api/src/org/apache/cloudstack/api/command/admin/network/CreateNetworkOfferingCmd.java
>  bdad904 
>   
> api/src/org/apache/cloudstack/api/command/admin/network/UpdateNetworkOfferingCmd.java
>  c9c4c8a 
>   core/src/com/cloud/agent/api/routing/LoadBalancerConfigCommand.java ee29290 
>   core/src/com/cloud/network/HAProxyConfigurator.java 2309125 
>   core/test/com/cloud/network/HAProxyConfiguratorTest.java PRE-CREATION 
>   engine/components-api/src/com/cloud/configuration/ConfigurationManager.java 
> 5e1b9b5 
>   
> engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
>  53f64fd 
>   engine/schema/src/com/cloud/offerings/NetworkOfferingVO.java eefdc94 
>   
> plugins/network-elements/elastic-loadbalancer/src/com/cloud/network/lb/ElasticLoadBalancerManagerImpl.java
>  ecd6006 
>   
> plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManagerImpl.java
>  587ae99 
>   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 8a0f7a6 
>   server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
> 7c026a4 
>   server/test/com/cloud/vpc/MockConfigurationManagerImpl.java c9a0480 
>   
> server/test/org/apache/cloudstack/networkoffering/CreateNetworkOfferingTest.java
>  1f1fb75 
>   setup/db/db/schema-420to430.sql 44a884d 
> 
> Diff: https://reviews.apache.org/r/14320/diff/
> 
> 
> Testing
> ---
> 
> created unit test.
> instantiated a network with some loadbalancer rule based on a netoffer with 
> the option to true/false and maxconnections to a non default value -> checked 
> haproxy.cfg on the router
> 
> 
> Thanks,
> 
> daan Hoogland
> 
>

Re: Libvirt-java 0.5.0 has been released

[Mike Tutkowski]

OK, thanks!


On Thu, Sep 26, 2013 at 2:52 PM, Wei ZHOU  wrote:

> Mike,
> Sorry my fault. already fixed by commit
> 522860c03de5d05126f92fc44b6e3f50ed8439f0
> Please pull the latest code.
>
>
> 2013/9/26 Mike Tutkowski 
>
> > Any thoughts on this error message?
> >
> > I updated from master today, cleaned, recompiled, then rebuilt and
> > redeployed the DEBs.
> >
> > Thanks
> >
> > mtutkowski@ubuntu:~$ sudo apt-get install cloudstack-agent
> > Reading package lists... Done
> > Building dependency tree
> > Reading state information... Done
> > The following NEW packages will be installed:
> >   cloudstack-agent
> > 0 upgraded, 1 newly installed, 0 to remove and 468 not upgraded.
> > Need to get 39.1 MB of archives.
> > After this operation, 43.6 MB of additional disk space will be used.
> > WARNING: The following packages cannot be authenticated!
> >   cloudstack-agent
> > Install these packages without verification [y/N]? y
> > Get:1 http://localhost/cloudstack/repo/ binary/ cloudstack-agent 4.3.0
> > [39.1 MB]
> > Fetched 39.1 MB in 0s (49.3 MB/s)
> > Selecting previously unselected package cloudstack-agent.
> > (Reading database ... 168800 files and directories currently installed.)
> > Unpacking cloudstack-agent (from .../cloudstack-agent_4.3.0_all.deb) ...
> > Processing triggers for ureadahead ...
> > Setting up cloudstack-agent (4.3.0) ...
> > /var/lib/dpkg/info/cloudstack-agent.postinst: line 39:
> > /usr/bin/cloudstack-agent-upgrade: No such file or directory
> > dpkg: error processing cloudstack-agent (--configure):
> >  subprocess installed post-installation script returned error exit
> status 1
> > E: Sub-process /usr/bin/dpkg returned an error code (1)
> >
> >
> >
> > On Thu, Sep 26, 2013 at 8:45 AM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> > > Let me update and try again and see if that solves the problem.
> > >
> > > I am probably a week behind on updating from master.
> > >
> > > Thanks
> > >
> > >
> > > On Wed, Sep 25, 2013 at 11:18 PM, Wei ZHOU 
> > wrote:
> > >
> > >> Mike,
> > >> Do you test the latest source code?
> > >>
> > >>  Pointer.nativeValue  is introduced in jna-3.2.6
> > >>
> > >>
> >
> http://upstream-tracker.org/java/compat_reports/jna/3.2.5_to_3.2.6/bin_compat_report.html
> > >> and Native.free  is introduced in jna-3.3.0
> > >>
> > >>
> >
> http://upstream-tracker.org/java/compat_reports/jna/3.2.7_to_3.3.0/bin_compat_report.html
> > >>
> > >> After commit 3dc4284,  jna-4.0.0.jar is in
> > /usr/share/cloudstack-agent/lib
> > >> , then it should be ok.
> > >>
> > >> -Wei
> > >>
> > >>
> > >> 2013/9/26 Mike Tutkowski 
> > >>
> > >> > Hi,
> > >> >
> > >> > I've been having a difficult time getting the KVM agent on master to
> > >> start
> > >> > on Ubuntu 12.04.
> > >> >
> > >> > The trouble seems to have begun after the Libvirt upgrade.
> > >> >
> > >> > Any thoughts on this:
> > >> >
> > >> > Thanks!
> > >> >
> > >> > 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#noconfigfor
> > >> > 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.NoSuchMethodError: com.sun.jna.Native.free(J)V
> > >> > at org.libvirt.Library.free(Unknown Source)
> > >> > at org.libvirt.Connect.getCapabilities(Unknown Source)
> > >> > at
> > >> >
> > >> >
> > >>
> >
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.IsHVMEnabled(LibvirtComputingResource.java:4524)
> > >> > at
> > >> >
> > >> >
> > >>
> >
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.configure(LibvirtComputingResource.java:753)
> > >> > at com.cloud.agent.Agent.(Agent.java:168)
> > >> > at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:439)
> > >> > at
> > >>
> com.cloud.agent.AgentShell.launchAgentFromClassInfo(AgentShell.java:386)
> > >> > at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:361)
> > >> > at com.cloud.agent.AgentShell.start(AgentShell.java:473)
> > >> > ... 5 more
> > >> > Cannot start daemon
> > >> > Service exit with a return value of 5
> > >> >
> > >> >
> > >> > On Wed, Sep 25, 2013 at 6:03 PM, Yoshikazu Nojima  >
> > >> > wrote:
> > >> >
> > >> > > Hi Wei,
> > >> > >
> > >> > > Thank you for fix it!
> > >> > >
> > >> > > 2013/9/25 Wei ZHOU :
> > >> > > > fixed by commit 3dc4284
> > >> > > >
> > >> > > >
> > >> > > > commit 3dc4

Re: Libvirt-java 0.5.0 has been released

[Wei ZHOU]

Mike,
Sorry my fault. already fixed by commit
522860c03de5d05126f92fc44b6e3f50ed8439f0
Please pull the latest code.


2013/9/26 Mike Tutkowski 

> Any thoughts on this error message?
>
> I updated from master today, cleaned, recompiled, then rebuilt and
> redeployed the DEBs.
>
> Thanks
>
> mtutkowski@ubuntu:~$ sudo apt-get install cloudstack-agent
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> The following NEW packages will be installed:
>   cloudstack-agent
> 0 upgraded, 1 newly installed, 0 to remove and 468 not upgraded.
> Need to get 39.1 MB of archives.
> After this operation, 43.6 MB of additional disk space will be used.
> WARNING: The following packages cannot be authenticated!
>   cloudstack-agent
> Install these packages without verification [y/N]? y
> Get:1 http://localhost/cloudstack/repo/ binary/ cloudstack-agent 4.3.0
> [39.1 MB]
> Fetched 39.1 MB in 0s (49.3 MB/s)
> Selecting previously unselected package cloudstack-agent.
> (Reading database ... 168800 files and directories currently installed.)
> Unpacking cloudstack-agent (from .../cloudstack-agent_4.3.0_all.deb) ...
> Processing triggers for ureadahead ...
> Setting up cloudstack-agent (4.3.0) ...
> /var/lib/dpkg/info/cloudstack-agent.postinst: line 39:
> /usr/bin/cloudstack-agent-upgrade: No such file or directory
> dpkg: error processing cloudstack-agent (--configure):
>  subprocess installed post-installation script returned error exit status 1
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
>
>
> On Thu, Sep 26, 2013 at 8:45 AM, Mike Tutkowski <
> mike.tutkow...@solidfire.com> wrote:
>
> > Let me update and try again and see if that solves the problem.
> >
> > I am probably a week behind on updating from master.
> >
> > Thanks
> >
> >
> > On Wed, Sep 25, 2013 at 11:18 PM, Wei ZHOU 
> wrote:
> >
> >> Mike,
> >> Do you test the latest source code?
> >>
> >>  Pointer.nativeValue  is introduced in jna-3.2.6
> >>
> >>
> http://upstream-tracker.org/java/compat_reports/jna/3.2.5_to_3.2.6/bin_compat_report.html
> >> and Native.free  is introduced in jna-3.3.0
> >>
> >>
> http://upstream-tracker.org/java/compat_reports/jna/3.2.7_to_3.3.0/bin_compat_report.html
> >>
> >> After commit 3dc4284,  jna-4.0.0.jar is in
> /usr/share/cloudstack-agent/lib
> >> , then it should be ok.
> >>
> >> -Wei
> >>
> >>
> >> 2013/9/26 Mike Tutkowski 
> >>
> >> > Hi,
> >> >
> >> > I've been having a difficult time getting the KVM agent on master to
> >> start
> >> > on Ubuntu 12.04.
> >> >
> >> > The trouble seems to have begun after the Libvirt upgrade.
> >> >
> >> > Any thoughts on this:
> >> >
> >> > Thanks!
> >> >
> >> > 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#noconfigfor
> >> > 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.NoSuchMethodError: com.sun.jna.Native.free(J)V
> >> > at org.libvirt.Library.free(Unknown Source)
> >> > at org.libvirt.Connect.getCapabilities(Unknown Source)
> >> > at
> >> >
> >> >
> >>
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.IsHVMEnabled(LibvirtComputingResource.java:4524)
> >> > at
> >> >
> >> >
> >>
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.configure(LibvirtComputingResource.java:753)
> >> > at com.cloud.agent.Agent.(Agent.java:168)
> >> > at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:439)
> >> > at
> >> com.cloud.agent.AgentShell.launchAgentFromClassInfo(AgentShell.java:386)
> >> > at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:361)
> >> > at com.cloud.agent.AgentShell.start(AgentShell.java:473)
> >> > ... 5 more
> >> > Cannot start daemon
> >> > Service exit with a return value of 5
> >> >
> >> >
> >> > On Wed, Sep 25, 2013 at 6:03 PM, Yoshikazu Nojima 
> >> > wrote:
> >> >
> >> > > Hi Wei,
> >> > >
> >> > > Thank you for fix it!
> >> > >
> >> > > 2013/9/25 Wei ZHOU :
> >> > > > fixed by commit 3dc4284
> >> > > >
> >> > > >
> >> > > > commit 3dc4284a34a1c79970b30288c245a26e8425e811
> >> > > > Author: Wei Zhou 
> >> > > > Date:   Wed Sep 25 11:08:57 2013 +0200
> >> > > > add missing jna-4.0.0.jar to cloudstack-agent library by
> >> changing
> >> > > scope
> >> > > > from provided to default runtime
> >> > > > diff --git a/plugins/hypervisors/kvm/pom.xml
> >> > > > b/plugins/hypervisors/kvm/pom.xml
> >> > > > index

Re: Libvirt-java 0.5.0 has been released

[Mike Tutkowski]

Any thoughts on this error message?

I updated from master today, cleaned, recompiled, then rebuilt and
redeployed the DEBs.

Thanks

mtutkowski@ubuntu:~$ sudo apt-get install cloudstack-agent
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  cloudstack-agent
0 upgraded, 1 newly installed, 0 to remove and 468 not upgraded.
Need to get 39.1 MB of archives.
After this operation, 43.6 MB of additional disk space will be used.
WARNING: The following packages cannot be authenticated!
  cloudstack-agent
Install these packages without verification [y/N]? y
Get:1 http://localhost/cloudstack/repo/ binary/ cloudstack-agent 4.3.0
[39.1 MB]
Fetched 39.1 MB in 0s (49.3 MB/s)
Selecting previously unselected package cloudstack-agent.
(Reading database ... 168800 files and directories currently installed.)
Unpacking cloudstack-agent (from .../cloudstack-agent_4.3.0_all.deb) ...
Processing triggers for ureadahead ...
Setting up cloudstack-agent (4.3.0) ...
/var/lib/dpkg/info/cloudstack-agent.postinst: line 39:
/usr/bin/cloudstack-agent-upgrade: No such file or directory
dpkg: error processing cloudstack-agent (--configure):
 subprocess installed post-installation script returned error exit status 1
E: Sub-process /usr/bin/dpkg returned an error code (1)



On Thu, Sep 26, 2013 at 8:45 AM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Let me update and try again and see if that solves the problem.
>
> I am probably a week behind on updating from master.
>
> Thanks
>
>
> On Wed, Sep 25, 2013 at 11:18 PM, Wei ZHOU  wrote:
>
>> Mike,
>> Do you test the latest source code?
>>
>>  Pointer.nativeValue  is introduced in jna-3.2.6
>>
>> http://upstream-tracker.org/java/compat_reports/jna/3.2.5_to_3.2.6/bin_compat_report.html
>> and Native.free  is introduced in jna-3.3.0
>>
>> http://upstream-tracker.org/java/compat_reports/jna/3.2.7_to_3.3.0/bin_compat_report.html
>>
>> After commit 3dc4284,  jna-4.0.0.jar is in /usr/share/cloudstack-agent/lib
>> , then it should be ok.
>>
>> -Wei
>>
>>
>> 2013/9/26 Mike Tutkowski 
>>
>> > Hi,
>> >
>> > I've been having a difficult time getting the KVM agent on master to
>> start
>> > on Ubuntu 12.04.
>> >
>> > The trouble seems to have begun after the Libvirt upgrade.
>> >
>> > Any thoughts on this:
>> >
>> > Thanks!
>> >
>> > 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#noconfigfor
>> > 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.NoSuchMethodError: com.sun.jna.Native.free(J)V
>> > at org.libvirt.Library.free(Unknown Source)
>> > at org.libvirt.Connect.getCapabilities(Unknown Source)
>> > at
>> >
>> >
>> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.IsHVMEnabled(LibvirtComputingResource.java:4524)
>> > at
>> >
>> >
>> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.configure(LibvirtComputingResource.java:753)
>> > at com.cloud.agent.Agent.(Agent.java:168)
>> > at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:439)
>> > at
>> com.cloud.agent.AgentShell.launchAgentFromClassInfo(AgentShell.java:386)
>> > at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:361)
>> > at com.cloud.agent.AgentShell.start(AgentShell.java:473)
>> > ... 5 more
>> > Cannot start daemon
>> > Service exit with a return value of 5
>> >
>> >
>> > On Wed, Sep 25, 2013 at 6:03 PM, Yoshikazu Nojima 
>> > wrote:
>> >
>> > > Hi Wei,
>> > >
>> > > Thank you for fix it!
>> > >
>> > > 2013/9/25 Wei ZHOU :
>> > > > fixed by commit 3dc4284
>> > > >
>> > > >
>> > > > commit 3dc4284a34a1c79970b30288c245a26e8425e811
>> > > > Author: Wei Zhou 
>> > > > Date:   Wed Sep 25 11:08:57 2013 +0200
>> > > > add missing jna-4.0.0.jar to cloudstack-agent library by
>> changing
>> > > scope
>> > > > from provided to default runtime
>> > > > diff --git a/plugins/hypervisors/kvm/pom.xml
>> > > > b/plugins/hypervisors/kvm/pom.xml
>> > > > index 4c0ec98..024cafe 100644
>> > > > --- a/plugins/hypervisors/kvm/pom.xml
>> > > > +++ b/plugins/hypervisors/kvm/pom.xml
>> > > > @@ -51,7 +51,6 @@
>> > > >  
>> > > >net.java.dev.jna
>> > > > jna
>> > > > -   provided
>> > > > ${cs.jna.version}
>> > > >  
>> > > >
>> > > >
>> > > >
>> > > > 2013/9/25 Wei ZHOU 
>> > > >
>> > > >> I tried both java 6 and java 7.
>> > > >> build and install succes

Re: [PROPOSAL] Service monitoring tool in virtual router

[David Nalley]

For what it's worth we created an ACS-specific MIB (beneath the
org.apache MIB) so really this is just a matter of defining and
publishing it.

But lets think about monit being used to restart services - with HA,
Redundant VR, are we sure that we want to inject yet another point of
control into things? Is it better to just respawn an instance since
they are essentially stateless? I don't know, but management server,
local daemons, and other SysVMs making decisions seems like we are
increasing complexity.

--David

On Thu, Sep 26, 2013 at 10:31 AM, Chiradeep Vittal
 wrote:
> In this case you would have to invent another enterprise MIB. Not too
> hard, but I'd argue that it needs to be proxied through some other service
> anyway and it represents a different integration point with ACS. Depends
> on whether you consider the system vm part of the ACS deployment, or an
> entity like a host.
>
> On 9/26/13 10:27 AM, "Alex Huang"  wrote:
>
>>Using SNMP for alert notification is not a bad idea though.  I don't see
>>why we can't do that instead of posting to the management server.  This
>>is specifically referring to the second part of the proposal.  Why
>>reinvent that part of it?
>>
>>--Alex
>>
>>> -Original Message-
>>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>>> Sent: Wednesday, September 25, 2013 10:28 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: [PROPOSAL] Service monitoring tool in virtual router
>>>
>>> SNMP wouldn't restart a failed process nor would it generate alerts. It
>>>is
>>> simply too generic for the requirements outlined here. The proposal does
>>> not talk about modifying monit, just using it. That wouldn't trigger
>>>the AGPL.
>>> I think the idea is to have a tight monitoring loop that scales: so
>>>executing the
>>> monitoring loop in-situ makes sense.
>>>
>>>
>>> On 9/25/13 9:53 PM, "David Nalley"  wrote:
>>>
>>> >On Wed, Sep 25, 2013 at 9:30 AM, Jayapal Reddy Uradi
>>> > wrote:
>>> >> Hi,
>>> >>
>>> >> Currently in virtual router there is no way to recover and notify if
>>> >>some service goes down unexpectedly.
>>> >>
>>> >> This feature is about monitoring all the services rendered by the
>>> >>virtual router, ensure that the services are running through the life
>>> >>time of the VR.
>>> >>
>>> >> On service failure:
>>> >> 1. Generate an alert and event indicating failure 2. Restart the
>>> >> service
>>> >>
>>> >> Services to be monitored:
>>> >> DHCP, DNS, haproxy, password server etc.
>>> >>
>>> >> As part of monitoring there are two activities
>>> >>
>>> >> 1. One is monitoring the services in VR and log the events. Using
>>> >>monit for monitoring services  2. Second part is pushing alerts from
>>> >>router to  MS server. Thinking on POST the logs to web server in MS.
>>> >>
>>> >> I will be updating more details and FS in this thread.
>>> >>
>>> >> I created enhancement bug for this.
>>> >> https://issues.apache.org/jira/browse/CLOUDSTACK-4736
>>> >>
>>> >> Thanks,
>>> >> Jayapal
>>> >
>>> >So several things - why not make this via SNMP? Query processes, and
>>> >many other things. This should be relatively simple, is well known, can
>>> >be locked down (or could be monitored for many other things by external
>>> >monitoring packages) and is the defacto standard for monitoring hosts.
>>> >Second - monit is Affero GPL licensed - which is a cat-x license.
>>> >While I expect that we would merely use this and not do any hacking on
>>> >it - I think its inclusion might be a surprise (and forbidden in many
>>> >environments) to our users
>>> >
>>> >--David
>>
>

Re: VpcProvider doesn't really seems extensible

[Alena Prokharchyk]

On 9/26/13 11:44 AM, "Darren Shepherd"  wrote:

>Alena,
>
>Additionally, there's a bit of discontinuity between VpcProvider,
>NetworkElement, and Network.Service for me.  Could you help me here.
>This is going to be confusing...
>
>Basically, for each Network.Service there is a corresponding interface
>that extends NetworkElement.  VpcProvider also extends NetworkElement
>and seems as though there should be a corresponding Network.Service
>for Vpc. If you were to add a Network.Service("Vpc") then it would
>seem logical to me that when you are doing
>startVpc/shutdownVpc/applyStaticRoutes/applyVpcPrivateGateway/deleteVpcPri
>vateGateway
>you would look in vpc_service_map for the provider that provides
>"Vpc."  Now if you were to do that, what value is vpc_service_map?
>Sorry, all the provider to service to capability to
>vpc/network/offering mappings are hard to follow and keep in my head.


I can see why is it confusing. At the moment, vpc_service_map is nothing
more than a superset of services that the current VPC supports (populated
using data from VpcOffering). Any network inside the VPC can implement a
subset of these services. Like for example, Web tier in VPC would have a
Dhcp/DNS/UserData/SourceNat/Lb Service, while App tier would have only
Dhcp/DNS/UserData/SourceNat (no LB).

All the services for the VPC networks (PF/LB/StaticNat, etc) are currently
being proxied through NetworkOfferings, so for instance when you add PF
rule for the VPC network, we check ntwk_service_map to see if the PF
service is being provided by this network.

When it comes to services that can be provided just in a context of VPC -
StaticRoutes/PrivateGateway - it would make sense to introduce a separate
service like you've suggested (instead of hardcoded value). Then this
service would become a part of VPC offering (and vpc_service_map), and we
should check for its provider whenever
startVpc/shutdownVpc/applyStaticRoutes/applyVpcPrivateGateway/deleteVpcPriv
ateGateway calls are made.

I've filed a bug for this one:

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



>
>Another weird thing is that for applyStaticRoutes you look for a
>provider of StaticNat but then once you find it you call
>VpcProvider.applyStaticRoutes.  Why the check for StaticNat?


Thats a regression introduced with the commit
836ce6c11ad6a11db2c4564620e46bf5e17f8189. StaticRoute has nothing to do
with StaticNat provider.


>
>Darren
>
>On Thu, Sep 26, 2013 at 11:02 AM, Alena Prokharchyk
> wrote:
>> They should, Darren. "vpcservicemap" was added just in this release, and
>> only shutdown/start use it. We should fix it for
>> applyStaticRoutes/applyVpcPrivateGateway/deleteVpcPrivateGateway. I will
>> file a Jira ticket for myself to fix it.
>>
>> -Alena.
>>
>> From: Darren Shepherd 
>> Reply-To: "dev@cloudstack.apache.org" 
>> Date: Thursday, September 26, 2013 10:52 AM
>> To: "dev@cloudstack.apache.org" 
>> Subject: VpcProvider doesn't really seems extensible
>>
>> I'm looking to add a new VpcProvider, but it seems the code is
>> essentially hard coded to using the Provider.VPCVirtualRouter in
>> getVpcElements().  I could just add a setVpcElements() and inject my
>> own implementation, but I think it will run into some problems
>> (haven't tried, just reading the code)
>>
>> Both shutdownVpc and startVpc both do the intersection of providers
>> supported by the VPC and getVpcElements(), so in theory only the
>> elements/providers applied to the VPC should get executed if you were
>> to have multiple VpcProviders.
>>
>> applyStaticRoutes(), applyVpcPrivateGateway(), and
>> deleteVpcPrivateGateway() don't do the similar check and instead just
>> call of all getVpcElements().  Am I missing something here, shouldn't
>> those methods all check vpc_service_map?
>>
>> Darren
>>
>

Re: CloudStack Server Memory Requirements

[Marcus Sorensen]

If I recall, we were able to start running it in devcloud again with
only 1G of memory allocated to dom0 just a few weeks after the initial
spring merge. I just think the default was never set back.

On Thu, Sep 26, 2013 at 11:29 AM, Chiradeep Vittal
 wrote:
> I believe Darren's proposed Spring refactor will help greatly.
>
> On 9/26/13 7:41 AM, "Marcus Sorensen"  wrote:
>
>>I think its an artifact from the Spring stuff six months ago. We can
>>probably decrease that in the default tomcat conf now.
>>On Sep 26, 2013 6:11 AM, "Geoff Higginbottom" <
>>geoff.higginbot...@shapeblue.com> wrote:
>>
>>>  I¹ve been testing the 4.2 release of CloudStack using Virtual Box and
>>> have noticed a need to allocate significantly more memory to the VM.
>>> Previously I would use a CentOS VM with 1 GB of RAM for the installation
>>> but then drop the memory to 512MB, leaving plenty of RAM on the host
>>> machine to then stand up a XenServer VM or a KVM VM etc.
>>>
>>>
>>>
>>> I initially had problems logging into 4.2 after a clean install, and
>>> discovered that only by increasing the memory to 2GB could I get the
>>>system
>>> to function.
>>>
>>>
>>>
>>> I am quite shocked that the memory footprint has increased 400% between
>>> releases.  Obviously for a real production system, allocating more than
>>>2GB
>>> or RAM to CloudStack is not an issue, but it does make standing up a
>>>simple
>>> test environment in Virtual Box more difficult.
>>>
>>>
>>>
>>> Does anyone have ideas why this has increased and is it something that
>>> should be looked at.
>>>
>>>
>>>
>>> Regards
>>>
>>>
>>>
>>> Geoff Higginbottom
>>>
>>> *CTO / Cloud Architect*
>>>
>>>
>>>
>>> [image: Description: Mail Logo Bottom Align]
>>>
>>>
>>>
>>> D: +44 20 3603 0542 <+442036030542> | S: +44 20 3603 0540
>>><+442036030540>| M:
>>> +447968161581
>>>
>>>
>>>
>>> geoff.higginbot...@shapeblue.com | www.shapeblue.com |
>>>Twitter:@shapeblue
>>>
>>>
>>>
>>> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
>>>
>>>
>>>
>>> Apache CloudStack Bootcamp training courses
>>>
>>> 18/19 September,
>>>Bangalore
>>>
>>> 02/03 October,
>>>London
>>>
>>> 13/14 November,
>>>London
>>>
>>> 27/28 November,
>>>Bangalore
>>>
>>> 08/09 January 2014,
>>>London
>>> **
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>  This email and any attachments to it may be confidential and are
>>>intended
>>> solely for the use of the individual to whom it is addressed. Any views
>>>or
>>> opinions expressed are solely those of the author and do not necessarily
>>> represent those of Shape Blue Ltd or related companies. If you are not
>>>the
>>> intended recipient of this email, you must neither take any action based
>>> upon its contents, nor copy or show it to anyone. Please contact the
>>>sender
>>> if you believe you have received this email in error. Shape Blue Ltd is
>>>a
>>> company incorporated in England & Wales. ShapeBlue Services India LLP
>>>is a
>>> company incorporated in India and is operated under license from Shape
>>>Blue
>>> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in
>>>Brasil
>>> and is operated under license from Shape Blue Ltd. ShapeBlue is a
>>> registered trademark.
>>>
>

Re: Review Request 14320: add boolean option httpModeEnabled to the service offering for use in haproxy conf

[daan Hoogland]

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

(Updated Sept. 26, 2013, 7:01 p.m.)


Review request for cloudstack and Wei Zhou.


Changes
---

added Wei, don't know if he's the guy or who to add, looking for volunteers.


Bugs: CLOUDSTACK-4328


Repository: cloudstack-git


Description
---

add boolean option httpModeEnabled to the service offering for use in haproxy 
conf


Diffs (updated)
-

  api/src/com/cloud/offering/NetworkOffering.java 6c5573e 
  api/src/org/apache/cloudstack/api/ApiConstants.java f85784b 
  
api/src/org/apache/cloudstack/api/command/admin/network/CreateNetworkOfferingCmd.java
 bdad904 
  
api/src/org/apache/cloudstack/api/command/admin/network/UpdateNetworkOfferingCmd.java
 c9c4c8a 
  core/src/com/cloud/agent/api/routing/LoadBalancerConfigCommand.java ee29290 
  core/src/com/cloud/network/HAProxyConfigurator.java 2309125 
  core/test/com/cloud/network/HAProxyConfiguratorTest.java PRE-CREATION 
  engine/components-api/src/com/cloud/configuration/ConfigurationManager.java 
5e1b9b5 
  
engine/orchestration/src/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
 53f64fd 
  engine/schema/src/com/cloud/offerings/NetworkOfferingVO.java eefdc94 
  
plugins/network-elements/elastic-loadbalancer/src/com/cloud/network/lb/ElasticLoadBalancerManagerImpl.java
 ecd6006 
  
plugins/network-elements/internal-loadbalancer/src/org/apache/cloudstack/network/lb/InternalLoadBalancerVMManagerImpl.java
 587ae99 
  server/src/com/cloud/configuration/ConfigurationManagerImpl.java 8a0f7a6 
  server/src/com/cloud/network/router/VirtualNetworkApplianceManagerImpl.java 
7c026a4 
  server/test/com/cloud/vpc/MockConfigurationManagerImpl.java c9a0480 
  
server/test/org/apache/cloudstack/networkoffering/CreateNetworkOfferingTest.java
 1f1fb75 
  setup/db/db/schema-420to430.sql 44a884d 

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


Testing (updated)
---

created unit test.
instantiated a network with some loadbalancer rule based on a netoffer with the 
option to true/false and maxconnections to a non default value -> checked 
haproxy.cfg on the router


Thanks,

daan Hoogland

Re: VpcProvider doesn't really seems extensible

[Darren Shepherd]

Alena,

Additionally, there's a bit of discontinuity between VpcProvider,
NetworkElement, and Network.Service for me.  Could you help me here.
This is going to be confusing...

Basically, for each Network.Service there is a corresponding interface
that extends NetworkElement.  VpcProvider also extends NetworkElement
and seems as though there should be a corresponding Network.Service
for Vpc. If you were to add a Network.Service("Vpc") then it would
seem logical to me that when you are doing
startVpc/shutdownVpc/applyStaticRoutes/applyVpcPrivateGateway/deleteVpcPrivateGateway
you would look in vpc_service_map for the provider that provides
"Vpc."  Now if you were to do that, what value is vpc_service_map?
Sorry, all the provider to service to capability to
vpc/network/offering mappings are hard to follow and keep in my head.

Another weird thing is that for applyStaticRoutes you look for a
provider of StaticNat but then once you find it you call
VpcProvider.applyStaticRoutes.  Why the check for StaticNat?

Darren

On Thu, Sep 26, 2013 at 11:02 AM, Alena Prokharchyk
 wrote:
> They should, Darren. "vpcservicemap" was added just in this release, and
> only shutdown/start use it. We should fix it for
> applyStaticRoutes/applyVpcPrivateGateway/deleteVpcPrivateGateway. I will
> file a Jira ticket for myself to fix it.
>
> -Alena.
>
> From: Darren Shepherd 
> Reply-To: "dev@cloudstack.apache.org" 
> Date: Thursday, September 26, 2013 10:52 AM
> To: "dev@cloudstack.apache.org" 
> Subject: VpcProvider doesn't really seems extensible
>
> I'm looking to add a new VpcProvider, but it seems the code is
> essentially hard coded to using the Provider.VPCVirtualRouter in
> getVpcElements().  I could just add a setVpcElements() and inject my
> own implementation, but I think it will run into some problems
> (haven't tried, just reading the code)
>
> Both shutdownVpc and startVpc both do the intersection of providers
> supported by the VPC and getVpcElements(), so in theory only the
> elements/providers applied to the VPC should get executed if you were
> to have multiple VpcProviders.
>
> applyStaticRoutes(), applyVpcPrivateGateway(), and
> deleteVpcPrivateGateway() don't do the similar check and instead just
> call of all getVpcElements().  Am I missing something here, shouldn't
> those methods all check vpc_service_map?
>
> Darren
>

Re: [RESULTS] [VOTE] Release Apache CloudStack 4.2.0 (sixth round)

[Chip Childers]

On Wed, Sep 25, 2013 at 11:24:24PM +, Animesh Chaturvedi wrote:
> [Animesh>] David, Chip Mathias has incorporated the comments received so far. 
> What is pending here? The feature description is brief should we add more 
> details?

I think (IMO) we are fine as is.  However, folks can chime in on
marketing@.  I just added a last call note, since I want to get the
announcement content over to press@ EOD tomorrow (US ET).

-chip

RE: [PROPOSAL] move away from time-based releases and/or revamp release process

[Musayev, Ilya]

Dan and David,

I see your concerns. Let me explain what I mean by modular and how we can 
address dependency.

Assume you have base ACS 4.2
Then you would have plugins like Nicira 4.2.x, VMware 4.2.x, NetScaler 4.2.x 
etc.. Goes without saying, but you cannot use a plugin from 4.3.x family on ACS 
4.2.x base...
We can aslo introduce dependcy checks, such that if Nicira plugin is enabled, 
we need VMware plugin enabled as well.

Why would we consider this? You can update modules more rapidly that include 
bug fixes (and perhaps minor non impacting enhacements) without waiting for the 
entire release cycle, you testing should be less as well, as you would only be 
testing affected modules, unless they strongly tie with another plugin.

If properly architected, CloudStack wont suffer OpenStack's faith - which is 
what they go through now - of only specific version x.y.z module can work with 
another x.y.z module.

Regards
ilya

> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Thursday, September 26, 2013 4:57 AM
> To: dev
> Subject: Re: [PROPOSAL] move away from time-based releases and/or
> revamp release process
> 
> Some more remarks on this:
> 
> Another model is of keeping quality high is controlling what gets in per
> release. This would go against the opensource model somewhat. You would
> need e release manager like me and I strongly advice against that.
> 
> Giving users more control on what goes into their system is a good thing. it
> must not become a 'university degree required' hurdle though. It would
> allow them to have a narrower view on what is good software, functionality -
> and quality wise. That would lead to better quality of quality control. I 
> know I
> am no good at that aspect right now because of the load of code I need to
> know about.
> 
> 
> hear hear, David. You are pointing at some of the challenges OSGi deals with.
> Ours is a little simpler; As we don't need run-time control, our plugins can
> have a strict hierarchical requirements tree which is somewhat easier to
> handle. Still you might end up with a system with two hypervisor (versions)
> that require a different storage or network version to work. or vice versa. I
> think we should be happy at first if we get a static system where 3rd party
> plugins work with version x till y. Note that then the plugin interface is to 
> be
> stable through a (semantically versioned) major release.
> 
> challenge i like, :)
> 
> 
> On Thu, Sep 26, 2013 at 6:21 AM, David Nalley  wrote:
> > On Wed, Sep 25, 2013 at 11:26 AM, Musayev, Ilya
>  wrote:
> >> We can still use scheduled release as we do now and yet have some
> agility.
> >>
> >> An idea was passed around before if we can modularize ACS in future
> releases VS being it monolithic.
> >>
> >> We can still have a core as is, but additional components/plugins can be
> loaded adhoc pm the need base. As an example, there is no need to bake in
> vmware support into release if a customer has not need for it. You cant just
> upgrade vmware code unless you upgrade from version X.y.1 to X.y.2.
> >>
> >> Same applies to all other "plugins", that are not truly pluggable.
> >>
> >> Splitting components as separate "plugins" (or whatever the proper term
> is) would ease the release cycle and give us flexibility in my opinion.
> >>
> >
> > Can you imagine the complexity of that model? Core version 4.3.x has
> > to work with VMware plugin 7.2.3, 7.1.5, and 7.0.2 and also has to
> > work with Nicira plugin version 3.4.1, 3.5.2, and 3.6.0 - except that
> > both of those plugins interact with each other as well as the core
> > orchestration platform. We struggle to test well now, the additional
> > combinations there boggle the mind.
> >
> > --David

RE: [VOTE] Accept the donation of a Contrail plugin into Apache CloudStack

[Sudha Ponnaganti]

+1 (binding) on donation

-Original Message-
From: Chip Childers [mailto:chipchild...@apache.org] 
Sent: Wednesday, September 25, 2013 10:13 AM
To: dev@cloudstack.apache.org
Subject: [VOTE] Accept the donation of a Contrail plugin into Apache CloudStack

Hi all!

As stated in other threads, Juniper is proposing the donation of a Contrail 
plugin to Apache CloudStack.  The code itself has been posted to reviewboard 
[1].  The design has been documented by Pedro [2].

[1] https://reviews.apache.org/r/14325/
[2] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Contrail+network+plugin

I'm calling a vote here, so that we have a formal consensus on accepting the 
code into the project.  As I've suggested earlier, I'd like us to accept the 
code into a branch, and then work through any technical concerns / reviews / 
changes prior to a master branch merge.

So...  voting will end in ~72 hours.  As this is a technical decision, 
committer and PMC votes are binding.

-chip


Votes please!

[ ] +1 - Accept the donation
[ ] +/-0 - No strong opinion
[ ] -1 - Do not accept the donation

Re: VpcProvider doesn't really seems extensible

[Alena Prokharchyk]

They should, Darren. "vpcservicemap" was added just in this release, and only 
shutdown/start use it. We should fix it for 
applyStaticRoutes/applyVpcPrivateGateway/deleteVpcPrivateGateway. I will file a 
Jira ticket for myself to fix it.

-Alena.

From: Darren Shepherd 
mailto:darren.s.sheph...@gmail.com>>
Reply-To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Date: Thursday, September 26, 2013 10:52 AM
To: "dev@cloudstack.apache.org" 
mailto:dev@cloudstack.apache.org>>
Subject: VpcProvider doesn't really seems extensible

I'm looking to add a new VpcProvider, but it seems the code is
essentially hard coded to using the Provider.VPCVirtualRouter in
getVpcElements().  I could just add a setVpcElements() and inject my
own implementation, but I think it will run into some problems
(haven't tried, just reading the code)

Both shutdownVpc and startVpc both do the intersection of providers
supported by the VPC and getVpcElements(), so in theory only the
elements/providers applied to the VPC should get executed if you were
to have multiple VpcProviders.

applyStaticRoutes(), applyVpcPrivateGateway(), and
deleteVpcPrivateGateway() don't do the similar check and instead just
call of all getVpcElements().  Am I missing something here, shouldn't
those methods all check vpc_service_map?

Darren

VpcProvider doesn't really seems extensible

[Darren Shepherd]

I'm looking to add a new VpcProvider, but it seems the code is
essentially hard coded to using the Provider.VPCVirtualRouter in
getVpcElements().  I could just add a setVpcElements() and inject my
own implementation, but I think it will run into some problems
(haven't tried, just reading the code)

Both shutdownVpc and startVpc both do the intersection of providers
supported by the VPC and getVpcElements(), so in theory only the
elements/providers applied to the VPC should get executed if you were
to have multiple VpcProviders.

applyStaticRoutes(), applyVpcPrivateGateway(), and
deleteVpcPrivateGateway() don't do the similar check and instead just
call of all getVpcElements().  Am I missing something here, shouldn't
those methods all check vpc_service_map?

Darren

RE: [ANNOUNCE] A GCE interface to CloudStack

[Frank Zhang]

> >
> >
> 
> Thanks to all and Darren S for testing.
> 
> I have not looked at the AWS query api in a long time and Frank's comments
> are beyond my understanding of it however if we wanted to do this, we could
> technically use the same framework has this GCE app. mapping the cloudstack
> api response object to the ec2 response can be a headache but not
> unsurmountable.

Oh, if we are talking about AWS query api, then forget my lengthy comments.
I am talking about creating a query framework in declarative way that can 
handle any query for any response object.

AWS response object is tight and high denormalized, my approach is not capable
for it. Then we have to go back imperative way and your flask based framework
is absolutely capable.

> 
> -Sebastien
> 
> >> -Original Message-
> >> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
> >> Sent: Tuesday, September 24, 2013 7:38 PM
> >> To: dev@cloudstack.apache.org
> >> Cc: dev@cloudstack.apache.org; Ian Duffy; Darren Brogan
> >> Subject: Re: [ANNOUNCE] A GCE interface to CloudStack
> >>
> >> I got this running earlier today and was really impressed with it, good 
> >> job!
> >>
> >> Our current AWS is just SOAP right?  How about when we do the query
> >> api we do it as a separate python project just like this.
> >>
> >> Darren
> >>
> >>> On Sep 24, 2013, at 11:40 AM, Frank Zhang 
> wrote:
> >>>
> >>> Take a look at source. Clean and lightweight implementation. Awesome.
> >>> I hope our AWS someday can go this way someday, a separate web
> >>> server in separate repo and using some dynamically language which
> >>> makes smaller code
> >>>
> >>>
>  -Original Message-
>  From: Musayev, Ilya [mailto:imusa...@webmd.net]
>  Sent: Tuesday, September 24, 2013 11:23 AM
>  To: dev@cloudstack.apache.org
>  Cc: Ian Duffy; Darren Brogan
>  Subject: RE: [ANNOUNCE] A GCE interface to CloudStack
> 
>  This looks awesome :)
> 
> > -Original Message-
> > From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
> > Sent: Tuesday, September 24, 2013 12:59 PM
> > To: dev@cloudstack.apache.org
> > Cc: Ian Duffy; Darren Brogan
> > Subject: Re: [ANNOUNCE] A GCE interface to CloudStack
> >
> > Wow. Nice!
> >
> >> On 9/24/13 6:04 AM, "sebgoa"  wrote:
> >>
> >> Hi,
> >>
> >> I am quite pumped to announce a Google Compute Engine (GCE)
> >> interface to CloudStack.
> >>
> >> Ian Duffy, Darren Brogan and myself worked on this on github over
> >> the last month. Our latest branch:
> >>
> >> https://github.com/NOPping/cloudstack-gce/tree/refactor
> >>
> >> Has been uploaded to pypi:
> >>
> >> https://pypi.python.org/pypi/gcloud
> >>
> >> A little virtualenv and a pip install gcloud will give you a
> >> Flask application, with OAuth2 provider and REST routes that map
> >> to the CloudStack API.
> >> The routes are compliant with GCE API, which allows you to use
> >> the Google gcutil cli to talk to your CloudStack cloud.
> >>
> >> Of course there are a few caveats that I will not mention, this
> >> is release 0.0.1, feedback and pr welcome.
> >>
> >> Congrats to our two 20 year olds in ireland who are taking names
> >> up in Dublin !
> >>
> >> Have fun,
> >>
> >> -Sebastien
> >>>

Re: [PROPOSAL] Service monitoring tool in virtual router

[Chiradeep Vittal]

In this case you would have to invent another enterprise MIB. Not too
hard, but I'd argue that it needs to be proxied through some other service
anyway and it represents a different integration point with ACS. Depends
on whether you consider the system vm part of the ACS deployment, or an
entity like a host.

On 9/26/13 10:27 AM, "Alex Huang"  wrote:

>Using SNMP for alert notification is not a bad idea though.  I don't see
>why we can't do that instead of posting to the management server.  This
>is specifically referring to the second part of the proposal.  Why
>reinvent that part of it?
>
>--Alex
>
>> -Original Message-
>> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
>> Sent: Wednesday, September 25, 2013 10:28 PM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [PROPOSAL] Service monitoring tool in virtual router
>> 
>> SNMP wouldn't restart a failed process nor would it generate alerts. It
>>is
>> simply too generic for the requirements outlined here. The proposal does
>> not talk about modifying monit, just using it. That wouldn't trigger
>>the AGPL.
>> I think the idea is to have a tight monitoring loop that scales: so
>>executing the
>> monitoring loop in-situ makes sense.
>> 
>> 
>> On 9/25/13 9:53 PM, "David Nalley"  wrote:
>> 
>> >On Wed, Sep 25, 2013 at 9:30 AM, Jayapal Reddy Uradi
>> > wrote:
>> >> Hi,
>> >>
>> >> Currently in virtual router there is no way to recover and notify if
>> >>some service goes down unexpectedly.
>> >>
>> >> This feature is about monitoring all the services rendered by the
>> >>virtual router, ensure that the services are running through the life
>> >>time of the VR.
>> >>
>> >> On service failure:
>> >> 1. Generate an alert and event indicating failure 2. Restart the
>> >> service
>> >>
>> >> Services to be monitored:
>> >> DHCP, DNS, haproxy, password server etc.
>> >>
>> >> As part of monitoring there are two activities
>> >>
>> >> 1. One is monitoring the services in VR and log the events. Using
>> >>monit for monitoring services  2. Second part is pushing alerts from
>> >>router to  MS server. Thinking on POST the logs to web server in MS.
>> >>
>> >> I will be updating more details and FS in this thread.
>> >>
>> >> I created enhancement bug for this.
>> >> https://issues.apache.org/jira/browse/CLOUDSTACK-4736
>> >>
>> >> Thanks,
>> >> Jayapal
>> >
>> >So several things - why not make this via SNMP? Query processes, and
>> >many other things. This should be relatively simple, is well known, can
>> >be locked down (or could be monitored for many other things by external
>> >monitoring packages) and is the defacto standard for monitoring hosts.
>> >Second - monit is Affero GPL licensed - which is a cat-x license.
>> >While I expect that we would merely use this and not do any hacking on
>> >it - I think its inclusion might be a surprise (and forbidden in many
>> >environments) to our users
>> >
>> >--David
>

Re: ubuntu LTS for system vm? and 64bit?

[Chiradeep Vittal]

That enabled running without a system vm. But you'd still need a VR if you
wanted network services.

On 9/26/13 12:47 AM, "Sebastien Goasguen"  wrote:

>
>On Sep 26, 2013, at 3:27 AM, Wido den Hollander  wrote:
>
>> 
>> 
>> On 09/26/2013 01:38 AM, Darren Shepherd wrote:
>>> Is there any technical reason why we couldn't use ubuntu LTS (12.04
>>> and soon to be 14.04) for the system VM.  Additionally is there any
>>> technical reason we couldn't switch to 64bit.  I don't necesarily want
>>> to get into "fight for you favorite distro" discussion, just curious.
>>> 
>> 
>> This still underlines the problem with the SystemVM, it isn't flexible
>>enough.
>> 
>> I'm not saying we should change overnight, but the SystemVM should be
>>abstracted a lot more so people can throw in their own SystemVM more
>>easily.
>> 
>> I created a issue about this last year:
>>https://issues.apache.org/jira/browse/CLOUDSTACK-451
>> 
>> I'd like to see this abstracted more so you can drop in any Linux or
>>BSD distro you like as long as it talks the API and does what it's asked
>>to do.
>> 
>> For Debian based we should be able to create some .deb packages which
>>you can simple install and for Redhat some .rpms.
>> 
>> The SystemVMs aren't rocket-science, as a matter of fact, I think the
>>are a big mess internally when you see all the scripts.
>> 
>> Wido
>
>Didn't Chiradeep work on quick cloud to solve some of those issues:
>
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/QuickCloud
>
>
>
>> 
>>> Darren
>>> 
>

Re: CloudStack Server Memory Requirements

[Chiradeep Vittal]

I believe Darren's proposed Spring refactor will help greatly.

On 9/26/13 7:41 AM, "Marcus Sorensen"  wrote:

>I think its an artifact from the Spring stuff six months ago. We can
>probably decrease that in the default tomcat conf now.
>On Sep 26, 2013 6:11 AM, "Geoff Higginbottom" <
>geoff.higginbot...@shapeblue.com> wrote:
>
>>  I¹ve been testing the 4.2 release of CloudStack using Virtual Box and
>> have noticed a need to allocate significantly more memory to the VM.
>> Previously I would use a CentOS VM with 1 GB of RAM for the installation
>> but then drop the memory to 512MB, leaving plenty of RAM on the host
>> machine to then stand up a XenServer VM or a KVM VM etc.
>>
>>
>>
>> I initially had problems logging into 4.2 after a clean install, and
>> discovered that only by increasing the memory to 2GB could I get the
>>system
>> to function.
>>
>>
>>
>> I am quite shocked that the memory footprint has increased 400% between
>> releases.  Obviously for a real production system, allocating more than
>>2GB
>> or RAM to CloudStack is not an issue, but it does make standing up a
>>simple
>> test environment in Virtual Box more difficult.
>>
>>
>>
>> Does anyone have ideas why this has increased and is it something that
>> should be looked at.
>>
>>
>>
>> Regards
>>
>>
>>
>> Geoff Higginbottom
>>
>> *CTO / Cloud Architect*
>>
>>
>>
>> [image: Description: Mail Logo Bottom Align]
>>
>>
>>
>> D: +44 20 3603 0542 <+442036030542> | S: +44 20 3603 0540
>><+442036030540>| M:
>> +447968161581
>>
>>
>>
>> geoff.higginbot...@shapeblue.com | www.shapeblue.com |
>>Twitter:@shapeblue
>>
>>
>>
>> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
>>
>>
>>
>> Apache CloudStack Bootcamp training courses
>>
>> 18/19 September,
>>Bangalore
>>
>> 02/03 October, 
>>London
>>
>> 13/14 November, 
>>London
>>
>> 27/28 November, 
>>Bangalore
>>
>> 08/09 January 2014,
>>London
>> **
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  This email and any attachments to it may be confidential and are
>>intended
>> solely for the use of the individual to whom it is addressed. Any views
>>or
>> opinions expressed are solely those of the author and do not necessarily
>> represent those of Shape Blue Ltd or related companies. If you are not
>>the
>> intended recipient of this email, you must neither take any action based
>> upon its contents, nor copy or show it to anyone. Please contact the
>>sender
>> if you believe you have received this email in error. Shape Blue Ltd is
>>a
>> company incorporated in England & Wales. ShapeBlue Services India LLP
>>is a
>> company incorporated in India and is operated under license from Shape
>>Blue
>> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in
>>Brasil
>> and is operated under license from Shape Blue Ltd. ShapeBlue is a
>> registered trademark.
>>

RE: [PROPOSAL] Service monitoring tool in virtual router

[Alex Huang]

Using SNMP for alert notification is not a bad idea though.  I don't see why we 
can't do that instead of posting to the management server.  This is 
specifically referring to the second part of the proposal.  Why reinvent that 
part of it?

--Alex

> -Original Message-
> From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
> Sent: Wednesday, September 25, 2013 10:28 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] Service monitoring tool in virtual router
> 
> SNMP wouldn't restart a failed process nor would it generate alerts. It is
> simply too generic for the requirements outlined here. The proposal does
> not talk about modifying monit, just using it. That wouldn't trigger the AGPL.
> I think the idea is to have a tight monitoring loop that scales: so executing 
> the
> monitoring loop in-situ makes sense.
> 
> 
> On 9/25/13 9:53 PM, "David Nalley"  wrote:
> 
> >On Wed, Sep 25, 2013 at 9:30 AM, Jayapal Reddy Uradi
> > wrote:
> >> Hi,
> >>
> >> Currently in virtual router there is no way to recover and notify if
> >>some service goes down unexpectedly.
> >>
> >> This feature is about monitoring all the services rendered by the
> >>virtual router, ensure that the services are running through the life
> >>time of the VR.
> >>
> >> On service failure:
> >> 1. Generate an alert and event indicating failure 2. Restart the
> >> service
> >>
> >> Services to be monitored:
> >> DHCP, DNS, haproxy, password server etc.
> >>
> >> As part of monitoring there are two activities
> >>
> >> 1. One is monitoring the services in VR and log the events. Using
> >>monit for monitoring services  2. Second part is pushing alerts from
> >>router to  MS server. Thinking on POST the logs to web server in MS.
> >>
> >> I will be updating more details and FS in this thread.
> >>
> >> I created enhancement bug for this.
> >> https://issues.apache.org/jira/browse/CLOUDSTACK-4736
> >>
> >> Thanks,
> >> Jayapal
> >
> >So several things - why not make this via SNMP? Query processes, and
> >many other things. This should be relatively simple, is well known, can
> >be locked down (or could be monitored for many other things by external
> >monitoring packages) and is the defacto standard for monitoring hosts.
> >Second - monit is Affero GPL licensed - which is a cat-x license.
> >While I expect that we would merely use this and not do any hacking on
> >it - I think its inclusion might be a surprise (and forbidden in many
> >environments) to our users
> >
> >--David

Re: ubuntu LTS for system vm? and 64bit?

[Chiradeep Vittal]

Yes. 4.2 has Wheezy with the 3.2 kernel. Theoretically with RPS/RFS we
could use multiple cores effectively, but it may be harder in practice.

On 9/25/13 10:53 PM, "Darren Shepherd"  wrote:

>Yeah, for sure 32bit PV is faster.  Do we require a specific minimum
>kernel version?  I though I heard something about upgrading the template
>for multicore networking or something like that.
>
>Darren
>
>> On Sep 25, 2013, at 10:38 PM, Chiradeep Vittal
>> wrote:
>> 
>> 32-bit theoretically performs better on Xen.
>> Debian is just more stable than Ubuntu, hence the preference.
>> 
>>> On 9/25/13 4:38 PM, "Darren Shepherd" 
>>>wrote:
>>> 
>>> Is there any technical reason why we couldn't use ubuntu LTS (12.04
>>> and soon to be 14.04) for the system VM.  Additionally is there any
>>> technical reason we couldn't switch to 64bit.  I don't necesarily want
>>> to get into "fight for you favorite distro" discussion, just curious.
>>> 
>>> Darren
>> 

RE: [DISCUSS] Release Managers for future ACS releases - enhacement

[Alex Huang]

Agreed.  If you look at what a release manager has to do today

- triage bugs
- follow up on reviews and ask people to commit them
- cherry-pick fixes

To me it is a lot of work for one person to do for CloudStack.  We can 
certainly divide up the work.  For example,

 - One RM is responsible for overall release 
 - One RM is responsible for following up on review board
 - Two or three RMs is responsible for triaging bugs
 - One is responsible for cherry-pick

I also like to propose that we stop the practice of only assigning bugs to 
yourself.  I know it's there to make sure there's no cookie-licking but really 
let's not make ourselves less efficient just for the sake of appearances.   RMs 
should be able to assign bugs as part of the process to ask for someone to look 
at the bug rather than having to ask privately and have the person assign to 
themselves.  Keeping track of such things with the amount of changes CloudStack 
goes through in a release just makes us less efficient and less enjoyable to 
work on CloudStack.
 
--Alex

> -Original Message-
> From: Musayev, Ilya [mailto:imusa...@webmd.net]
> Sent: Thursday, September 26, 2013 9:02 AM
> To: dev@cloudstack.apache.org
> Subject: [DISCUSS] Release Managers for future ACS releases - enhacement
> 
> I apologize in advance if this is a repeat of something that was previously
> stated.
> 
> As Animesh learned recently with ACS 4.2, RM work for major versions takes
> a lot of effort, to lesser extent the 4.2.x minor release may not be as 
> involved,
> but still decent amount of work.
> 
> What complicates the matter further, is many of us have $dayjobs$ that
> don't emphasize heavy involvement on ACS.
> 
> Perhaps we can revisit the strategy and have 2 -3 release managers for major
> version and 1-2 for minor.
> 
> Obviously, one is going the be a Lead RM, and others will be secondary but
> also involved.
> 
> Any thoughts on this approach?
> 
> Thanks
> ilya

Re: Lines of contributed code

[La Motta, David]

The chart that I saw on OpenStack was taken from the same site Chip
pointed out, so I have an apples-to-apples comparison to make.

Regardless, thanks Animesh.



David La Motta
Technical Marketing Engineer - Citrix Solutions | NetApp
Direct: 1.919.476.5042
Mobile: 1.919.413.5600



On 9/26/13 12:53 PM, "Animesh Chaturvedi" 
wrote:

>I used sloccount and it reports roughly 1.35 million lines of code
>without comments.
>
>
>SLOCDirectory   SLOC-by-Language (Sorted)
>651515  awsapi  java=651509,sh=6
>142854  client  javascript=121639,python=11230,sh=6951,jsp=3007,
>perl=27
>127014  server  java=127009,sh=5
>97243   plugins java=94186,python=2928,sh=129
>75653   engine  java=75648,jsp=5
>73218   testpython=65414,java=6910,sh=894
>52898   api java=52869,python=29
>28910   depsjava=28905,sh=5
>17697   utils   java=17678,python=19
>14923   corejava=14923
>14730   ui  javascript=14730
>11171   tools   python=9323,sh=1569,ruby=182,java=97
>10949   servicesjava=8488,javascript=1611,sh=690,python=160
>8572vmware-base java=8572
>7085patches sh=6878,python=207
>3761usage   java=3589,sh=172
>3136agent   java=2533,sh=326,python=277
>2921framework   java=2921
>2877python  python=2601,sh=276
>815 cloud-cli   python=815
>755 packaging   sh=755
>697 setup   python=697
>592 awsapi-setupsh=530,python=62
>56  debian  sh=56
>11  docssh=11
>0   agent-simulator (none)
>0   build   (none)
>0   developer   (none)
>0   scripts (none)
>0   target  (none)
>0   top_dir (none)
>
>
>Totals grouped by language (dominant language first):
>java:   1095837 (81.17%)
>javascript:137980 (10.22%)
>python:   93762 (6.95%)
>sh:   19253 (1.43%)
>jsp:   3012 (0.22%)
>ruby:   182 (0.01%)
>perl:27 (0.00%)
>
>
>
>
>Total Physical Source Lines of Code (SLOC)= 1,350,053
>Development Effort Estimate, Person-Years (Person-Months) = 387.17
>(4,646.00)
>(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
>Schedule Estimate, Years (Months) = 5.16 (61.86)
>(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
>Estimated Average Number of Developers (Effort/Schedule)  = 75.10
>Total Estimated Cost to Develop   = $ 52,300,999
>(average salary = $56,286/year, overhead = 2.40).
>SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
>SLOCCount is Open Source Software/Free Software, licensed under the GNU
>GPL.
>SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
>redistribute it under certain conditions as specified by the GNU GPL
>license;
>see the documentation for details.
>Please credit this data as "generated using David A. Wheeler's
>'SLOCCount'."
>
>
>
>> -Original Message-
>> From: La Motta, David [mailto:david.lamo...@netapp.com]
>> Sent: Thursday, September 26, 2013 9:39 AM
>> To: dev@cloudstack.apache.org
>> Subject: Lines of contributed code
>> 
>> Hey everybody, as an advocate of CloudStack for NetApp and our
>> customers, I am often times asked to compare and contrast ACS with
>> OpenStack.  One interesting metric that I am looking at right now is
>> that OpenStack has about 1.7 million lines of contributed code.
>> 
>> How many can we say about CloudStack??
>> 
>> Thanks!
>> 
>> 
>> David La Motta
>> Technical Marketing Engineer - Citrix Solutions | NetApp
>> Direct: 1.919.476.5042
>> Mobile: 1.919.413.5600
>> 
>> [NetApp] [@virtualcrusader]
>>   [LinkedIn]
>> 
>> [@virtualcrusader] 
>> [dlamo...@netapp.com] 
>> 
>

RE: Lines of contributed code

[Animesh Chaturvedi]

Looking at Chip's email, sloccount did not report HTML and CSS

Thanks
Animesh

> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Thursday, September 26, 2013 9:53 AM
> To: dev@cloudstack.apache.org
> Subject: RE: Lines of contributed code
> 
> I used sloccount and it reports roughly 1.35 million lines of code
> without comments.
> 
> 
> SLOCDirectory   SLOC-by-Language (Sorted)
> 651515  awsapi  java=651509,sh=6
> 142854  client  javascript=121639,python=11230,sh=6951,jsp=3007,
> perl=27
> 127014  server  java=127009,sh=5
> 97243   plugins java=94186,python=2928,sh=129
> 75653   engine  java=75648,jsp=5
> 73218   testpython=65414,java=6910,sh=894
> 52898   api java=52869,python=29
> 28910   depsjava=28905,sh=5
> 17697   utils   java=17678,python=19
> 14923   corejava=14923
> 14730   ui  javascript=14730
> 11171   tools   python=9323,sh=1569,ruby=182,java=97
> 10949   servicesjava=8488,javascript=1611,sh=690,python=160
> 8572vmware-base java=8572
> 7085patches sh=6878,python=207
> 3761usage   java=3589,sh=172
> 3136agent   java=2533,sh=326,python=277
> 2921framework   java=2921
> 2877python  python=2601,sh=276
> 815 cloud-cli   python=815
> 755 packaging   sh=755
> 697 setup   python=697
> 592 awsapi-setupsh=530,python=62
> 56  debian  sh=56
> 11  docssh=11
> 0   agent-simulator (none)
> 0   build   (none)
> 0   developer   (none)
> 0   scripts (none)
> 0   target  (none)
> 0   top_dir (none)
> 
> 
> Totals grouped by language (dominant language first):
> java:   1095837 (81.17%)
> javascript:137980 (10.22%)
> python:   93762 (6.95%)
> sh:   19253 (1.43%)
> jsp:   3012 (0.22%)
> ruby:   182 (0.01%)
> perl:27 (0.00%)
> 
> 
> 
> 
> Total Physical Source Lines of Code (SLOC)= 1,350,053
> Development Effort Estimate, Person-Years (Person-Months) = 387.17
> (4,646.00) (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
> Schedule Estimate, Years (Months) = 5.16 (61.86)
> (Basic COCOMO model, Months = 2.5 * (person-months**0.38)) Estimated
> Average Number of Developers (Effort/Schedule)  = 75.10
> Total Estimated Cost to Develop   = $ 52,300,999
> (average salary = $56,286/year, overhead = 2.40).
> SLOCCount, Copyright (C) 2001-2004 David A. Wheeler SLOCCount is Open
> Source Software/Free Software, licensed under the GNU GPL.
> SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
> redistribute it under certain conditions as specified by the GNU GPL
> license; see the documentation for details.
> Please credit this data as "generated using David A. Wheeler's
> 'SLOCCount'."
> 
> 
> 
> > -Original Message-
> > From: La Motta, David [mailto:david.lamo...@netapp.com]
> > Sent: Thursday, September 26, 2013 9:39 AM
> > To: dev@cloudstack.apache.org
> > Subject: Lines of contributed code
> >
> > Hey everybody, as an advocate of CloudStack for NetApp and our
> > customers, I am often times asked to compare and contrast ACS with
> > OpenStack.  One interesting metric that I am looking at right now is
> > that OpenStack has about 1.7 million lines of contributed code.
> >
> > How many can we say about CloudStack??
> >
> > Thanks!
> >
> >
> > David La Motta
> > Technical Marketing Engineer - Citrix Solutions | NetApp
> > Direct: 1.919.476.5042
> > Mobile: 1.919.413.5600
> >
> > [NetApp] [@virtualcrusader]
> >   [LinkedIn]
> > 
> > [@virtualcrusader] 
> > [dlamo...@netapp.com] 
> >

RE: Lines of contributed code

[Animesh Chaturvedi]

I used sloccount and it reports roughly 1.35 million lines of code without 
comments.


SLOCDirectory   SLOC-by-Language (Sorted)
651515  awsapi  java=651509,sh=6
142854  client  javascript=121639,python=11230,sh=6951,jsp=3007,
perl=27
127014  server  java=127009,sh=5
97243   plugins java=94186,python=2928,sh=129
75653   engine  java=75648,jsp=5
73218   testpython=65414,java=6910,sh=894
52898   api java=52869,python=29
28910   depsjava=28905,sh=5
17697   utils   java=17678,python=19
14923   corejava=14923
14730   ui  javascript=14730
11171   tools   python=9323,sh=1569,ruby=182,java=97
10949   servicesjava=8488,javascript=1611,sh=690,python=160
8572vmware-base java=8572
7085patches sh=6878,python=207
3761usage   java=3589,sh=172
3136agent   java=2533,sh=326,python=277
2921framework   java=2921
2877python  python=2601,sh=276
815 cloud-cli   python=815
755 packaging   sh=755
697 setup   python=697
592 awsapi-setupsh=530,python=62
56  debian  sh=56
11  docssh=11
0   agent-simulator (none)
0   build   (none)
0   developer   (none)
0   scripts (none)
0   target  (none)
0   top_dir (none)


Totals grouped by language (dominant language first):
java:   1095837 (81.17%)
javascript:137980 (10.22%)
python:   93762 (6.95%)
sh:   19253 (1.43%)
jsp:   3012 (0.22%)
ruby:   182 (0.01%)
perl:27 (0.00%)




Total Physical Source Lines of Code (SLOC)= 1,350,053
Development Effort Estimate, Person-Years (Person-Months) = 387.17 (4,646.00)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 5.16 (61.86)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 75.10
Total Estimated Cost to Develop   = $ 52,300,999
(average salary = $56,286/year, overhead = 2.40).
SLOCCount, Copyright (C) 2001-2004 David A. Wheeler
SLOCCount is Open Source Software/Free Software, licensed under the GNU GPL.
SLOCCount comes with ABSOLUTELY NO WARRANTY, and you are welcome to
redistribute it under certain conditions as specified by the GNU GPL license;
see the documentation for details.
Please credit this data as "generated using David A. Wheeler's 'SLOCCount'."



> -Original Message-
> From: La Motta, David [mailto:david.lamo...@netapp.com]
> Sent: Thursday, September 26, 2013 9:39 AM
> To: dev@cloudstack.apache.org
> Subject: Lines of contributed code
> 
> Hey everybody, as an advocate of CloudStack for NetApp and our
> customers, I am often times asked to compare and contrast ACS with
> OpenStack.  One interesting metric that I am looking at right now is
> that OpenStack has about 1.7 million lines of contributed code.
> 
> How many can we say about CloudStack??
> 
> Thanks!
> 
> 
> David La Motta
> Technical Marketing Engineer - Citrix Solutions | NetApp
> Direct: 1.919.476.5042
> Mobile: 1.919.413.5600
> 
> [NetApp] [@virtualcrusader]
>   [LinkedIn]
> 
> [@virtualcrusader] 
> [dlamo...@netapp.com] 
> 

Re: Lines of contributed code

[La Motta, David]

Awesome, thanks!


David La Motta
Technical Marketing Engineer - Citrix Solutions | NetApp
Direct: 1.919.476.5042
Mobile: 1.919.413.5600




On 9/26/13 12:44 PM, "Chip Childers"  wrote:

>This is a good tool:
>
>http://www.ohloh.net/p/CloudStack
>
>
>On Thu, Sep 26, 2013 at 12:38 PM, La Motta, David
>wrote:
>
>> Hey everybody, as an advocate of CloudStack for NetApp and our
>>customers,
>> I am often times asked to compare and contrast ACS with OpenStack.  One
>> interesting metric that I am looking at right now is that OpenStack has
>> about 1.7 million lines of contributed code.
>>
>> How many can we say about CloudStack??
>>
>> Thanks!
>>
>>
>> David La Motta
>> Technical Marketing Engineer - Citrix Solutions | NetApp
>> Direct: 1.919.476.5042
>> Mobile: 1.919.413.5600

Re: Lines of contributed code

[Chip Childers]

This is a good tool:

http://www.ohloh.net/p/CloudStack


On Thu, Sep 26, 2013 at 12:38 PM, La Motta, David
wrote:

> Hey everybody, as an advocate of CloudStack for NetApp and our customers,
> I am often times asked to compare and contrast ACS with OpenStack.  One
> interesting metric that I am looking at right now is that OpenStack has
> about 1.7 million lines of contributed code.
>
> How many can we say about CloudStack??
>
> Thanks!
>
>
> David La Motta
> Technical Marketing Engineer - Citrix Solutions | NetApp
> Direct: 1.919.476.5042
> Mobile: 1.919.413.5600
>
> [NetApp] [@virtualcrusader] <
> http://twitter.com/virtualcrusader>  [LinkedIn] <
> https://www.linkedin.com/profile/view?id=4658253&trk>  [@virtualcrusader]
>   [dlamo...@netapp.com]
> 
>
>
>

Lines of contributed code

[La Motta, David]

Hey everybody, as an advocate of CloudStack for NetApp and our customers, I am 
often times asked to compare and contrast ACS with OpenStack.  One interesting 
metric that I am looking at right now is that OpenStack has about 1.7 million 
lines of contributed code.

How many can we say about CloudStack??

Thanks!


David La Motta
Technical Marketing Engineer - Citrix Solutions | NetApp
Direct: 1.919.476.5042
Mobile: 1.919.413.5600

[NetApp] [@virtualcrusader] 
  [LinkedIn] 
  [@virtualcrusader] 
  [dlamo...@netapp.com] 

Re: LocalHostEndPoint seems to get called

[Daan Hoogland]

The state is 'RUNNING' not 'Up' . Maybe it is me out racing the
computer. so don't deepdive. I just thought it was weird I got this
message while the ssvm was up.

once again, no hinder, Min. Thanks

On Thu, Sep 26, 2013 at 6:27 PM, Min Chen  wrote:
> I am only aware that before ssvm is up, you will see such message in
> StatCollector, but that is no hurt. I don't understand why you encountered
> this even if your ssvm is up? Is your s-1-VM entry in host db table is in
> Up state? Are you using devcloud or real hypervisor in your setup? We may
> need detailed log to figure out what is going on here in your case.
>
> Thanks
> -min
>
> On 9/26/13 6:39 AM, "Daan Hoogland"  wrote:
>
>>I get "No running ssvm is found, so command will be sent to
>>LocalHostEndPoint" while I can see and log into a machine called
>>s-1-VM which has state 'RUNNING' in the database. Is there some
>>relation? I never though much of it as it does not seem to be the
>>first thing stopping me usually.
>>
>>On Wed, Sep 25, 2013 at 11:20 PM, Edison Su  wrote:
>>>
>>>
 -Original Message-
 From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
 Sent: Wednesday, September 25, 2013 12:38 PM
 To: dev@cloudstack.apache.org
 Subject: LocalHostEndPoint seems to get called

 While I'm doing development and restarting things and what not, it
seems
 often storage commands get routed to LocalHostEndPoint.  This seems
bad.  I
 don't have sudo setup for my user on my laptop, so things like "Unable
to
 create local folder for:
 /mnt/secStorage/64d6e26f-e656-3ba3-908f-ce6610ede011 in order to mount
 nfs://192.168.3.134:/exports/secondary1" fail.  But the bigger problem
is,
 shouldn't that not happen at all.  It seems like in a normal setup it
should
 never try to use LocalHostEndpoint.  Do I have some setting flipped
that is
 enabling that?
>>>
>>> The current code has bug if ssvm agent is not in the up state, then
>>>template downloading will likely choose localhostendpoint to download
>>>template.
>>> Localhostendpoint should only be used to download system vm template.
>>>

 Seems like with the current code you might accidentally mount
secondary to
 the management server if the conditions are right...

 Darren
>

Re: LocalHostEndPoint seems to get called

[Min Chen]

I am only aware that before ssvm is up, you will see such message in
StatCollector, but that is no hurt. I don't understand why you encountered
this even if your ssvm is up? Is your s-1-VM entry in host db table is in
Up state? Are you using devcloud or real hypervisor in your setup? We may
need detailed log to figure out what is going on here in your case.

Thanks
-min

On 9/26/13 6:39 AM, "Daan Hoogland"  wrote:

>I get "No running ssvm is found, so command will be sent to
>LocalHostEndPoint" while I can see and log into a machine called
>s-1-VM which has state 'RUNNING' in the database. Is there some
>relation? I never though much of it as it does not seem to be the
>first thing stopping me usually.
>
>On Wed, Sep 25, 2013 at 11:20 PM, Edison Su  wrote:
>>
>>
>>> -Original Message-
>>> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
>>> Sent: Wednesday, September 25, 2013 12:38 PM
>>> To: dev@cloudstack.apache.org
>>> Subject: LocalHostEndPoint seems to get called
>>>
>>> While I'm doing development and restarting things and what not, it
>>>seems
>>> often storage commands get routed to LocalHostEndPoint.  This seems
>>>bad.  I
>>> don't have sudo setup for my user on my laptop, so things like "Unable
>>>to
>>> create local folder for:
>>> /mnt/secStorage/64d6e26f-e656-3ba3-908f-ce6610ede011 in order to mount
>>> nfs://192.168.3.134:/exports/secondary1" fail.  But the bigger problem
>>>is,
>>> shouldn't that not happen at all.  It seems like in a normal setup it
>>>should
>>> never try to use LocalHostEndpoint.  Do I have some setting flipped
>>>that is
>>> enabling that?
>>
>> The current code has bug if ssvm agent is not in the up state, then
>>template downloading will likely choose localhostendpoint to download
>>template.
>> Localhostendpoint should only be used to download system vm template.
>>
>>>
>>> Seems like with the current code you might accidentally mount
>>>secondary to
>>> the management server if the conditions are right...
>>>
>>> Darren

[DISCUSS] Release Managers for future ACS releases - enhacement

[Musayev, Ilya]

I apologize in advance if this is a repeat of something that was previously 
stated.

As Animesh learned recently with ACS 4.2, RM work for major versions takes a 
lot of effort, to lesser extent the 4.2.x minor release may not be as involved, 
but still decent amount of work.

What complicates the matter further, is many of us have $dayjobs$ that don't 
emphasize heavy involvement on ACS.

Perhaps we can revisit the strategy and have 2 -3 release managers for major 
version and 1-2 for minor.

Obviously, one is going the be a Lead RM, and others will be secondary but also 
involved.

Any thoughts on this approach?

Thanks
ilya

RE: [MAJOR][BUG] ACS powers off some VMs in vSphere - when MS service is restarted

[Musayev, Ilya]

++Koushik

Thanks Sowmya

Koushik 

Any reason why this is cannot be applied to ACS 4.1?  Since I'm Release Manager 
for 4.1.x branch, I will work on testing and releasing 4.1.2

Thanks
ilya

> -Original Message-
> From: Sowmya Krishnan [mailto:sowmya.krish...@citrix.com]
> Sent: Thursday, September 26, 2013 3:03 AM
> To: dev@cloudstack.apache.org
> Subject: RE: [MAJOR][BUG] ACS powers off some VMs in vSphere - when MS
> service is restarted
> 
> Ilya,
> Is this similar to this issue:
> https://issues.apache.org/jira/browse/CLOUDSTACK-4636
> Fix for this has gone in 4.2-forward and master. As stated in the bug, this
> could happen if more than one thread tries to process the same host post
> MS restart.
> 
> > -Original Message-
> > From: Musayev, Ilya [mailto:imusa...@webmd.net]
> > Sent: Thursday, September 26, 2013 3:43 AM
> > To: dev@cloudstack.apache.org
> > Subject: RE: [MAJOR][BUG] ACS powers off some VMs in vSphere - when
> MS
> > service is restarted
> >
> > Sorry if the error log is abit hard to read, as an example, please
> > track the vmname i-2-262-acs-docs-fc17.
> >
> > 2013-09-25 14:35:49,928 DEBUG [vmware.resource.VmwareResource]
> > (AgentTaskPool-1:null) Detecting a new state but couldn't find a old
> > state so adding it to the changes: i-2-262-acs-docs-fc17
> > 2013-09-25 14:35:53,614 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > (AgentTaskPool-1:null) VM i-2-262-acs-docs-fc17: cs state = Running
> > and realState = Stopped
> > 2013-09-25 14:35:53,614 DEBUG [cloud.vm.VirtualMachineManagerImpl]
> > (AgentTaskPool-1:null) VM i-2-262-acs-docs-fc17: cs state = Running
> > and realState = Stopped
> > 2013-09-25 14:35:53,614 INFO  [cloud.ha.HighAvailabilityManagerImpl]
> > (AgentTaskPool-1:null) Skip HA for VMware VM i-2-262-acs-docs-fc17
> > 2013-09-25 14:35:53,694 DEBUG [agent.transport.Request]
> > (AgentTaskPool-
> > 1:null) Seq 11-1418264581: Sending  { Cmd , MgmtId: 345049078181, via:
> > 11,
> > Ver: v1, Flags: 100101,
> > [{"StopCommand":{"isProxy":false,"vmName":"i-2-262-
> > acs-docs-fc17","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-
> > 2-
> > 278-demo01t-ops-
> > 08","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-2-281-acs-
> > appliance","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-2-28
> > 3-
> > vmbld01l-ops-
> 08","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"
> > i-2-
> > 285-ossec01l-ops-08","wait":0}}] }
> > 2013-09-25 14:35:53,695 DEBUG [agent.transport.Request]
> > (AgentTaskPool-
> > 1:null) Seq 11-1418264581: Executing:  { Cmd , MgmtId: 345049078181,
> > via: 11,
> > Ver: v1, Flags: 100101,
> > [{"StopCommand":{"isProxy":false,"vmName":"i-2-262-
> > acs-docs-fc17","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-
> > 2-
> > 278-demo01t-ops-
> > 08","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-2-281-acs-
> > appliance","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"i-2-28
> > 3-
> > vmbld01l-ops-
> 08","wait":0}},{"StopCommand":{"isProxy":false,"vmName":"
> > i-2-
> > 285-ossec01l-ops-08","wait":0}}] }
> > 2013-09-25 14:35:53,702 INFO  [vmware.resource.VmwareResource]
> > (DirectAgent-3:vmha62d-ops-08.portal.webmd.com) Executing resource
> > StopCommand:
> > {"isProxy":false,"vmName":"i-2-262-acs-docs-fc17","wait":0}
> > 2013-09-25 14:35:53,703 DEBUG [vmware.mo.HostMO] (DirectAgent-
> > 3:vmha62d-ops-08.portal.webmd.com) find VM i-2-262-acs-docs-fc17 on
> > host
> > 2013-09-25 14:35:54,753 INFO  [vmware.resource.VmwareResource]
> > (DirectAgent-3:vmha62d-ops-08.portal.webmd.com) VM
> > i-2-262-acs-docs-fc17 is already in stopped state
> >
> > > -Original Message-
> > > From: Musayev, Ilya [mailto:imusa...@webmd.net]
> > > Sent: Wednesday, September 25, 2013 6:08 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: [MAJOR][BUG] ACS powers off some VMs in vSphere - when MS
> > > service is restarted
> > >
> > > Hi All,
> > >
> > > I'd like to raise an awareness on the issue with ACS 4.1.1 (I assume
> > > other versions are affected - since I could not find any changes in
> > > the latest code that would state otherwise).
> > >
> > > On MS server start/restart, it checks all the VMs for their state,
> > > if some reason state is either not found or comes as stopped - which
> > > is inaccurate, the vms will *power off*.
> > >
> > > On todays occurrence, half of my plant  went down because ACS
> > > invoked StopCommand on the vms that either had no state or for some
> > > reason agentState == Stopped.
> > >
> > > The details of this issue is in
> > > https://issues.apache.org/jira/browse/CLOUDSTACK-4740
> > >
> > > The error in the logs is:
> > >
> > > 2013-09-25 14:35:49,928 DEBUG [vmware.resource.VmwareResource]
> > > (AgentTaskPool-1:null) Detecting a new state but couldn't find a old
> > > state so adding it to the changes: i-2-262-acs-docs-fc17
> > > 2013-09-25 14:35:51,213 DEBUG [agent.transport.Request]
> > > (AgentTaskPool-
> > > 1:null) Seq -1--1: Startup request from directly connect

Re: Libvirt-java 0.5.0 has been released

[Mike Tutkowski]

Let me update and try again and see if that solves the problem.

I am probably a week behind on updating from master.

Thanks


On Wed, Sep 25, 2013 at 11:18 PM, Wei ZHOU  wrote:

> Mike,
> Do you test the latest source code?
>
>  Pointer.nativeValue  is introduced in jna-3.2.6
>
> http://upstream-tracker.org/java/compat_reports/jna/3.2.5_to_3.2.6/bin_compat_report.html
> and Native.free  is introduced in jna-3.3.0
>
> http://upstream-tracker.org/java/compat_reports/jna/3.2.7_to_3.3.0/bin_compat_report.html
>
> After commit 3dc4284,  jna-4.0.0.jar is in /usr/share/cloudstack-agent/lib
> , then it should be ok.
>
> -Wei
>
>
> 2013/9/26 Mike Tutkowski 
>
> > Hi,
> >
> > I've been having a difficult time getting the KVM agent on master to
> start
> > on Ubuntu 12.04.
> >
> > The trouble seems to have begun after the Libvirt upgrade.
> >
> > Any thoughts on this:
> >
> > Thanks!
> >
> > 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.NoSuchMethodError: com.sun.jna.Native.free(J)V
> > at org.libvirt.Library.free(Unknown Source)
> > at org.libvirt.Connect.getCapabilities(Unknown Source)
> > at
> >
> >
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.IsHVMEnabled(LibvirtComputingResource.java:4524)
> > at
> >
> >
> com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.configure(LibvirtComputingResource.java:753)
> > at com.cloud.agent.Agent.(Agent.java:168)
> > at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:439)
> > at
> com.cloud.agent.AgentShell.launchAgentFromClassInfo(AgentShell.java:386)
> > at com.cloud.agent.AgentShell.launchAgent(AgentShell.java:361)
> > at com.cloud.agent.AgentShell.start(AgentShell.java:473)
> > ... 5 more
> > Cannot start daemon
> > Service exit with a return value of 5
> >
> >
> > On Wed, Sep 25, 2013 at 6:03 PM, Yoshikazu Nojima 
> > wrote:
> >
> > > Hi Wei,
> > >
> > > Thank you for fix it!
> > >
> > > 2013/9/25 Wei ZHOU :
> > > > fixed by commit 3dc4284
> > > >
> > > >
> > > > commit 3dc4284a34a1c79970b30288c245a26e8425e811
> > > > Author: Wei Zhou 
> > > > Date:   Wed Sep 25 11:08:57 2013 +0200
> > > > add missing jna-4.0.0.jar to cloudstack-agent library by changing
> > > scope
> > > > from provided to default runtime
> > > > diff --git a/plugins/hypervisors/kvm/pom.xml
> > > > b/plugins/hypervisors/kvm/pom.xml
> > > > index 4c0ec98..024cafe 100644
> > > > --- a/plugins/hypervisors/kvm/pom.xml
> > > > +++ b/plugins/hypervisors/kvm/pom.xml
> > > > @@ -51,7 +51,6 @@
> > > >  
> > > >net.java.dev.jna
> > > > jna
> > > > -   provided
> > > > ${cs.jna.version}
> > > >  
> > > >
> > > >
> > > >
> > > > 2013/9/25 Wei ZHOU 
> > > >
> > > >> I tried both java 6 and java 7.
> > > >> build and install successfully
> > > >> agent can not restart.
> > > >> I will try after jna.version change .
> > > >>
> > >
> >
> >
> >
> > --
> > *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: CloudStack Server Memory Requirements

[Marcus Sorensen]

I think its an artifact from the Spring stuff six months ago. We can
probably decrease that in the default tomcat conf now.
On Sep 26, 2013 6:11 AM, "Geoff Higginbottom" <
geoff.higginbot...@shapeblue.com> wrote:

>  I’ve been testing the 4.2 release of CloudStack using Virtual Box and
> have noticed a need to allocate significantly more memory to the VM.
> Previously I would use a CentOS VM with 1 GB of RAM for the installation
> but then drop the memory to 512MB, leaving plenty of RAM on the host
> machine to then stand up a XenServer VM or a KVM VM etc.
>
>
>
> I initially had problems logging into 4.2 after a clean install, and
> discovered that only by increasing the memory to 2GB could I get the system
> to function.
>
>
>
> I am quite shocked that the memory footprint has increased 400% between
> releases.  Obviously for a real production system, allocating more than 2GB
> or RAM to CloudStack is not an issue, but it does make standing up a simple
> test environment in Virtual Box more difficult.
>
>
>
> Does anyone have ideas why this has increased and is it something that
> should be looked at.
>
>
>
> Regards
>
>
>
> Geoff Higginbottom
>
> *CTO / Cloud Architect*
>
>
>
> [image: Description: Mail Logo Bottom Align]
>
>
>
> D: +44 20 3603 0542 <+442036030542> | S: +44 20 3603 0540 <+442036030540>| M:
> +447968161581
>
>
>
> geoff.higginbot...@shapeblue.com | www.shapeblue.com | 
> Twitter:@shapeblue
>
>
>
> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
>
>
>
> Apache CloudStack Bootcamp training courses
>
> 18/19 September, 
> Bangalore
>
> 02/03 October, 
> London
>
> 13/14 November, 
> London
>
> 27/28 November, 
> Bangalore
>
> 08/09 January 2014, 
> London
> **
>
>
>
>
>
>
>
>
>
>
>
>
>  This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. Shape Blue Ltd is a
> company incorporated in England & Wales. ShapeBlue Services India LLP is a
> company incorporated in India and is operated under license from Shape Blue
> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
> and is operated under license from Shape Blue Ltd. ShapeBlue is a
> registered trademark.
>

marvin over https

[Daan Hoogland]

H,

I have some trouble getting marvin to connect to cloudstack over https.
I am supposing the following should work
conn = cloudConnection(mgmtip, apiKey=apikey,
securityKey=secretkey, logging=log, port=443, scheme="https")
lz = listZones.listZonesCmd()
conn.marvin_request(lz)

is this a valid assumption?

I can browse to the https:///client/ and login to retrieve the
keys used, but on running the code above i get

requests.exceptions.ConnectionError:
HTTPSConnectionPool(host='10.200.23.16', port=443): Max retries
exceeded with url:
/client/api?apiKey=JGvIQPeIVsbgEhVC3shZ51r9buYwClB4ToJZX9Cxs9e3NZbRoJLNyANnWEKgsmgt1uoF_eLdL31GHMwcss6Zyw&command=listZones&signature=KL93r9GYIr6%2FRcbNHuaOj3jUF6o%3D&response=json
(Caused by : [Errno 111] Connection refused)

I am not sure where to look. at marvin, httprequest or the setup of my
env. Hints?

thanks,
Daan

Re: LocalHostEndPoint seems to get called

[Daan Hoogland]

I get "No running ssvm is found, so command will be sent to
LocalHostEndPoint" while I can see and log into a machine called
s-1-VM which has state 'RUNNING' in the database. Is there some
relation? I never though much of it as it does not seem to be the
first thing stopping me usually.

On Wed, Sep 25, 2013 at 11:20 PM, Edison Su  wrote:
>
>
>> -Original Message-
>> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
>> Sent: Wednesday, September 25, 2013 12:38 PM
>> To: dev@cloudstack.apache.org
>> Subject: LocalHostEndPoint seems to get called
>>
>> While I'm doing development and restarting things and what not, it seems
>> often storage commands get routed to LocalHostEndPoint.  This seems bad.  I
>> don't have sudo setup for my user on my laptop, so things like "Unable to
>> create local folder for:
>> /mnt/secStorage/64d6e26f-e656-3ba3-908f-ce6610ede011 in order to mount
>> nfs://192.168.3.134:/exports/secondary1" fail.  But the bigger problem is,
>> shouldn't that not happen at all.  It seems like in a normal setup it should
>> never try to use LocalHostEndpoint.  Do I have some setting flipped that is
>> enabling that?
>
> The current code has bug if ssvm agent is not in the up state, then template 
> downloading will likely choose localhostendpoint to download template.
> Localhostendpoint should only be used to download system vm template.
>
>>
>> Seems like with the current code you might accidentally mount secondary to
>> the management server if the conditions are right...
>>
>> Darren

RE: [VOTE] Accept the donation of a Contrail plugin into Apache CloudStack

[Alex Huang]

+1 (binding)

--Alex

> -Original Message-
> From: Chip Childers [mailto:chipchild...@apache.org]
> Sent: Wednesday, September 25, 2013 10:13 AM
> To: dev@cloudstack.apache.org
> Subject: [VOTE] Accept the donation of a Contrail plugin into Apache
> CloudStack
> 
> Hi all!
> 
> As stated in other threads, Juniper is proposing the donation of a Contrail
> plugin to Apache CloudStack.  The code itself has been posted to
> reviewboard [1].  The design has been documented by Pedro [2].
> 
> [1] https://reviews.apache.org/r/14325/
> [2]
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Contrail+networ
> k+plugin
> 
> I'm calling a vote here, so that we have a formal consensus on accepting the
> code into the project.  As I've suggested earlier, I'd like us to accept the 
> code
> into a branch, and then work through any technical concerns / reviews /
> changes prior to a master branch merge.
> 
> So...  voting will end in ~72 hours.  As this is a technical decision, 
> committer
> and PMC votes are binding.
> 
> -chip
> 
> 
> Votes please!
> 
> [ ] +1 - Accept the donation
> [ ] +/-0 - No strong opinion
> [ ] -1 - Do not accept the donation

Re: [VOTE] Accept the donation of a Contrail plugin into Apache CloudStack

[Simon Weller]

+1. 

- Original Message -

From: "Chip Childers"  
To: dev@cloudstack.apache.org 
Sent: Wednesday, September 25, 2013 12:13:07 PM 
Subject: [VOTE] Accept the donation of a Contrail plugin into Apache CloudStack 

Hi all! 

As stated in other threads, Juniper is proposing the donation of a 
Contrail plugin to Apache CloudStack. The code itself has been posted 
to reviewboard [1]. The design has been documented by Pedro [2]. 

[1] https://reviews.apache.org/r/14325/ 
[2] 
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Contrail+network+plugin 

I'm calling a vote here, so that we have a formal consensus on accepting 
the code into the project. As I've suggested earlier, I'd like us to 
accept the code into a branch, and then work through any technical 
concerns / reviews / changes prior to a master branch merge. 

So... voting will end in ~72 hours. As this is a technical decision, 
committer and PMC votes are binding. 

-chip 


Votes please! 

[ ] +1 - Accept the donation 
[ ] +/-0 - No strong opinion 
[ ] -1 - Do not accept the donation 

CloudStack Server Memory Requirements

[Geoff Higginbottom]

I've been testing the 4.2 release of CloudStack using Virtual Box and have 
noticed a need to allocate significantly more memory to the VM.  Previously I 
would use a CentOS VM with 1 GB of RAM for the installation but then drop the 
memory to 512MB, leaving plenty of RAM on the host machine to then stand up a 
XenServer VM or a KVM VM etc.

I initially had problems logging into 4.2 after a clean install, and discovered 
that only by increasing the memory to 2GB could I get the system to function.

I am quite shocked that the memory footprint has increased 400% between 
releases.  Obviously for a real production system, allocating more than 2GB or 
RAM to CloudStack is not an issue, but it does make standing up a simple test 
environment in Virtual Box more difficult.

Does anyone have ideas why this has increased and is it something that should 
be looked at.

Regards

Geoff Higginbottom
CTO / Cloud Architect

[Description: Mail Logo Bottom Align]

D: +44 20 3603 0542 | S: +44 20 3603 0540 
| M: +447968161581

geoff.higginbot...@shapeblue.com | 
www.shapeblue.com | Twitter:@shapeblue

ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS

Apache CloudStack Bootcamp training courses
18/19 September, 
Bangalore
02/03 October, 
London
13/14 November, 
London
27/28 November, 
Bangalore
08/09 January 2014, 
London






This email and any attachments to it may be confidential and are intended 
solely for the use of the individual to whom it is addressed. Any views or 
opinions expressed are solely those of the author and do not necessarily 
represent those of Shape Blue Ltd or related companies. If you are not the 
intended recipient of this email, you must neither take any action based upon 
its contents, nor copy or show it to anyone. Please contact the sender if you 
believe you have received this email in error. Shape Blue Ltd is a company 
incorporated in England & Wales. ShapeBlue Services India LLP is a company 
incorporated in India and is operated under license from Shape Blue Ltd. Shape 
Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is 
operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.