date:20130411

On 11 April 2013 15:52, Abhinandan Prateek
abhinandan.prat...@citrix.com wrote:


I will start with an example: A critical bug (CLOUDSTACK-1941) that is
blocking a release (4.1) is not picked up by any community member for 5
days !
The reason being that it is a UI issue but not that clear from the desc,
the nature of the bug is known after someone spends time on it.

Now is it wrong to ask the community members who have expertise on UI to
fix it, in a bid to help Chip get the release out ?

A set of guidelines are necessary so that this whole confusion about bugs
getting assigned is cleared up. I will start by proposing some simple
rules:

1. Never assign bugs that are not critical or blocker unless they meet
any
of the below condition.

Never would be too lenient. Maybe assign it after 7-8 days since they
don't need immediate attention.

 7-8 days is a huge time lost. I was suggesting that this to be 3 days. Let
 other community members chime in too.


Just to note: contributors will enter anytime. They don't necessarily
know of our release roadmap when they come in looking to contribute.
And typically they'd be looking at low hanging fruit - ie not blocker,
criticals. If you're saying 'x days are lost' then that doesn't make
much sense to an external contributor, x days based on what? If a bug
is blocking someone else's progress then the person who is blocked
should make noise on this list so the appropriate person can fix it.
I think the issue this thread is trying to address is assignment of
bugs in the background without community participation and/or
knowledge.

Also I don't think bugs are getting fixed immediately after assignment
as you indicate. Bugs go between Triager 1 to Triager 2 to Developer 3
and then Developer 3 assigns it to the Developer 4 who fixes the bug.
Instead - Developer 4 should have got to it first or explained the
nature of the fix if he hasn't the time to fix it. Which doesn't
happen either. As Alex proposed, when someone takes up a bug they
should mark it in progress so that we know work is on going. Instead
if Triagers are just assigning bugs based on some kind of weird
LRU-cache in their head of who's (usually $dayjob stakeholder) the
rightful owner I find it exclusionary to community participation.

There is no contest on the bugs being assigned by the RM that are
essential to be fixed for a release. So I agree with you on that.

Re: Review Request: Storage motion changes for xenserver

2013-04-11 Thread Devdeep Singh

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

(Updated April 11, 2013, 11:02 a.m.)

Review request for cloudstack, Abhinandan Prateek, edison su, Alex Huang, and
anthony xu.

Changes
---

Updated the patch to incorporate the review comments.
1. Created new response objects for listing hosts and storage pools available
for migration.
2. Renamed the listHostsForMigration api and listStoragePoolsForMigration api
to findHostsForMigration and findStoragePoolsForMigration respectively.
3. Introduced a new XenServerStorageMotionStrategy for migrating volumes of a
vm. When a vm is being migrated with its volumes, the vm is put in migrating
state and a request is send to the volume manager to migrate the vm and its
volumes. Volume manager calls into the volume service which forwards the
request to data motion service after moving all the volumes to migrating state.
Data motion service enumerates the strategies and the request reaches the
XenServerStorageMotionStrategy. It calls in to the resource to complete the
operation.
4. Removed migrateAsync from data motion service. The work of migrating a
volume of a running vm is also done in copyAsync.
5. Fixed the marvin tests to work with the updated/renamed apis.

Description (updated)
---

Storage motion for Xenserver. FS for the feature
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Enabling+Storage+XenMotion+for+XenServer
1. Implemented Api findStoragePoolsForMigration. Added a new response
objects to list storage pools available for migration.
2. Updated migrateVolume api for allowing migrating volumes of running vms.
These changes are integrated into the latest storage refactoring changes.
3. Added the implementation for findHostsForMigration api. It lists the
hosts to which an instance can be migrated, including hosts from within and
across clusters to which an instance may be migrated with storage motion. The
work of migrating a volume of a running vm is also done in copyAsync.
4. Updated the listHosts api for backward compatibility.
5. Added the implementation for migrateVirtualMachineWithVolume api. It
migrates an instance with its volumes within a cluster and also across
clusters. Also introduced a new XenServerStorageMotionStrategy for migrating
volumes of a vm. When a vm is being migrated with its volumes, the vm is put in
migrating state and a request is send to the volume manager to migrate the vm
and its volumes. Volume manager calls into the volume service which forwards
the request to data motion service after moving all the volumes to migrating
state. Data motion service enumerates the strategies and the request reaches
the XenServerStorageMotionStrategy. It calls in to the resource to complete the
operation.
6. Resolved an issue where storage xenmotion of 2nd VM created from the
same template to a host was failing with duplicate_vm exception. Made changes
to remove the mac_seed key value pair from other_config when vms are created.
This is was storage motion to fail.
7. Updated the db upgrade schema script.
8. Added the right permissions in commands.properties
9. Marvin tests for testing storage motion. Following scenarios are tested.
9.1. A virtual machine is migrated to another host. Its volumes are also
migrated to another storage pool.
9.2. Just the volumes of a vm are migrated to another storage pool while
the vm continues to run on the same host.
10. Unit tests for testing migration of a vm with its volumes.

This addresses bug https://issues.apache.org/jira/browse/CLOUDSTACK-659.

Diffs (updated)
-

api/src/com/cloud/agent/api/MigrateWithStorageAnswer.java PRE-CREATION
api/src/com/cloud/agent/api/MigrateWithStorageCommand.java PRE-CREATION
api/src/com/cloud/agent/api/MigrateWithStorageCompleteAnswer.java
PRE-CREATION
api/src/com/cloud/agent/api/MigrateWithStorageCompleteCommand.java
PRE-CREATION
api/src/com/cloud/agent/api/MigrateWithStorageReceiveAnswer.java PRE-CREATION
api/src/com/cloud/agent/api/MigrateWithStorageReceiveCommand.java
PRE-CREATION
api/src/com/cloud/agent/api/MigrateWithStorageSendAnswer.java PRE-CREATION
api/src/com/cloud/agent/api/MigrateWithStorageSendCommand.java PRE-CREATION
api/src/com/cloud/agent/api/storage/MigrateVolumeAnswer.java PRE-CREATION
api/src/com/cloud/agent/api/storage/MigrateVolumeCommand.java PRE-CREATION
api/src/com/cloud/hypervisor/HypervisorCapabilities.java aff81b0
api/src/com/cloud/server/ManagementService.java 1e6ca8d
api/src/com/cloud/vm/UserVmService.java 2c33d41
api/src/org/apache/cloudstack/api/ApiConstants.java c518830
api/src/org/apache/cloudstack/api/ResponseGenerator.java d1e1302

api/src/org/apache/cloudstack/api/command/admin/host/FindHostsForMigrationCmd.java

Re: Associate IP feature request (RE: CLOUDSTACK-1942)

On 11 April 2013 01:08, Ryan Dietrich r...@betterservers.com wrote:
 RE: https://issues.apache.org/jira/browse/CLOUDSTACK-1942

 I added this feature this morning, but before I present the diff to review 
 board, I'd like to have some feedback on the approach.  I just want to make 
 sure how I did it is ok from the maintainers perspective so I'm not wasting 
 anyones time.

 1. Add an optional parameter to 
 api/src/org/apache/cloudstack/api/command/user/address/AssociateIPAddrCmd.java
  allowing you to pass in a UUID of the specific IP you want to add.
 2. Make AssociateIPAddrCmd either use the provided IP or use the existing 
 getEntity() call it is using now.
 3. Update allocateIP to have a new optional argument, the Long (id) of 
 IpAddress.
 4. Update the NetworkManager and NetworkService interfaces to include the new 
 parameter
 5. Update the MockNetworkManager and MockNetworkService implementations to 
 include the new parameter.
 6. Update the NetworkServiceImplementation to include the new parameter and 
 pass it through.
 7. Update NetworkManagerImpl: Use the existing functionality of 
 fetchNewPublicIp and pass in the String requestedIp based on the Long id 
 of IpAddress (I used ApiDBUtils to fetch the object out and transform it into 
 a string).

I don't see any problem with the approach.

Re: [DISCUSS] Don't assign tickets to people when triaging

On 11 April 2013 04:08, Abhinandan Prateek abhinandan.prat...@citrix.comwrote:


 Now is it wrong to ask the community members who have expertise on UI to
 fix it, in a bid to help Chip get the release out ?


It is certainly not wrong to co-ordinate with people in an effort to ship a
release. (I would point out, however, that it is not Chip getting the
release out. It is the community. But maybe I am misinterpreting your
remark here...)

2. Assign a bug that is open for more than 3 days and none of the
 community member has shown interest in picking it up. This period can vary
 depending on how close a branch where bug is noted is close to a release.


Three days?

That is a very short period of time, when you consider the size of our JIRA
queue, and the average timespan of a ticket.

I really don't see why bugs that are not on the critical path of a release
should be assigned at all. As has already been pointed out several times in
this thread, this is an exclusionary practice which is likely to put off
new contributions to the project. It will calcify the existing structure
and roles, and will hamper CloudStack's ability to grow as a project.

I don't understand why non-critical bugs cannot be categorised into
components. And then engineers can pick up items of the component backlogs
as they become free or want to work on CloudStack. This sort of approach is
inclusionary. Anybody can go to JIRA and click on one of the component
reports, and just take a ticket, and start working on it. (Without having
to contact the person it is assigned to to ask if they may start on it.
Which, in reality, nobody is going to to do.)

I also reject the idea that engineers need tickets assigned to them as
either a) some sort of communication method, or b) some way to spur them
into action. Firstly, we have the mailing list as a communication method.
If you want a particular set of bugs to be worked on, or whatever, then
post a message to the list, and ask for participation. Secondly, we should
not be spurring anybody into action. This is a volunteer project, and
people contribute as and when they can. They should not be managed like an
employee would be managed. Which is why it's so important that we build
structures that are open to chaotic volunteer efforts.

If $company is employing people to work on CloudStack, and wants to spur
its employees into action around a certain feature or component, then that
is fine. But this activity must be kept away from the lists. Perhaps have
$company internal email threads where you ask people to focus on things.
Any time that activity leaks on to the list, it sends the wrong message
about how to participate in the project, and sends the wrong message about
$company's relationship to the project.


 3. Assign or request to community for picking up a bug if it is blocking
 the work that a community member may be working on.


Again, this is presumptuous. There is no minimum level of participation. So
saying Bob, this is your bug, so fix it, because it is blocking me is the
wrong attitude to take. Instead, we should be using every opportunity we
have, every construct we build, as a way to invite further participation
from the community. A better approach would be to mark the bug as blocking
some other work, and then post a note to the list saying this bug is
blocking me, can I have some help with it please? In an email like that,
feel free to CC the engineers you expect might want to / be able to help
out, or mention them by name. But don't make a habit of saying Bob, this
bug is blocking me, can you fix it when you could say this bug is
blocking me, can someone fix it? /cc Bob


-- 
NS

RE: Review request for storage motion on xenserver

2013-04-11 Thread Devdeep Singh

Hi Edison,

I have updated the patch [1] after incorporating your review comments. It also 
includes the changes to address the review comments given by Alex. Kindly take 
a look at the changes and let me know your comments.

[1] https://reviews.apache.org/r/10196/

Regards,
Devdeep

 -Original Message-
 From: Devdeep Singh [mailto:devdeep.si...@citrix.com]
 Sent: Friday, April 05, 2013 3:37 PM
 To: dev@cloudstack.apache.org
 Subject: RE: Review request for storage motion on xenserver
 
 Hi Edison,
 
 Thanks a lot for looking at the changes. I am going through your feedback and
 working on a patch which addresses your review comments. I'll get back to
 you if I have any queries.
 
 Regards,
 Devdeep
 
  -Original Message-
  From: Edison Su [mailto:edison...@citrix.com]
  Sent: Thursday, April 04, 2013 3:21 AM
  To: dev@cloudstack.apache.org
  Subject: RE: Review request for storage motion on xenserver
 
  Sorry for the late. Following is my comments on storage motion:
  1. We shouldn't touch volume state in virutalmachinemanager. I spend a
  lot of time trying to move volume related operations from
  virtualmachinemanager to storage subsystem, better to follow the same
 pattern.
  2. The current storage subsystem apis, can only operate on one data
  object (volume/snapshot or template) at one time. In storage migration
  case, it has to deal with multiple volumes at one time.
  My suggestion is that add a new method, like,
  migrateVolumes(MapvolumeInfo, DataStore volumeMaps), which can
  migrate a group of volumes at one time.
  3. The code follow will look like:
  virtualmachineManagerImpl:migrateWithStorage(change vm state) -
  volumemanager: migrateVolumes{do basic check} -
  volumeService:migrateVolumes{which will change volume state} -
  datamotionservice:copyAsync(which will find a data motion strategy
  which can handle storage migration for xenserver) -
  xenserverstoragemigrationstategy:copyAsync(send commands to xenserver
  resource )
 
  You need to write a datamotion strategy for xenserver storage
  migration, and need to add a method on both datamotionservice,
  volumeservice, volumemanager and DataMotionStrategy, so that they can
  operate on multiple volumes at one time.
 
  4. Don't need to add a new api called migrateasync, copyasync has the
  same meaning.
 
  Does it make sense?
 
   -Original Message-
   From: Devdeep Singh [mailto:devdeep.si...@citrix.com]
   Sent: Friday, March 29, 2013 8:21 AM
   To: dev@cloudstack.apache.org
   Subject: Review request for storage motion on xenserver
  
   I have put the feature proposed [1] and developed in the feature
   branch [2] up for review. Code for this feature conforms to what was
  proposed in FS [3].
   The patch available at [4]. It includes marvin tests and unit tests
   for verifying the functionality. Please take a look at it and let me
   know your
  comments.
  
   [1] http://markmail.org/message/numdk6pdab2hekdp
   [2] https://github.com/devdeep/cloudstack/commits/sm3
   [3]
   https://cwiki.apache.org/confluence/display/CLOUDSTACK/Enabling+Stor
   ag
   e+XenMotion+for+XenServer
   [4] https://reviews.apache.org/r/10196/
  
   Regards,
   Devdeep

Re: [DISCUSS] Don't assign tickets to people when triaging

Of course releases are important.

But if our current cadence is putting too much pressure on the community,
one option might be to do our releases further apart from each other. Or,
we get strict about the principal of time based releases: i.e. if your
feature is not ready for the freeze, then it doesn't make it in. No big
deal. If it's ready for the next freeze, then we'll ship it then.

Also, I may be reading your message wrong, but there's no need for this to
be a divisive argument. There are no sides to this. As a community, it is
up to us all to identify our problems, and figure out solutions.

So what problems do you think we'll run in to if we stop assigning the
majority of bugs, and how do you think we can mitigate those problems? Or
do you have another idea in mind altogether?




On 11 April 2013 12:40, Abhinandan Prateek abhinandan.prat...@citrix.comwrote:

 I think it will be good if we also find out a process so that the release
 cycle is not affected by unclaimed bugs sitting out there. Here I am
 assuming the releases are important.

 I guess the discussion has turned into keeping things free without
 offering solutions to problems that that system will create.


 On 11/04/13 5:04 PM, John Burwell jburw...@basho.com wrote:

 +1
 
 On Apr 11, 2013, at 7:22 AM, Noah Slater nsla...@apache.org wrote:
 
  On 11 April 2013 11:22, Abhinandan Prateek
 abhinandan.prat...@citrix.comwrote:
 
 
  7-8 days is a huge time lost. I was suggesting that this to be 3 days.
 Let
  other community members chime in too.
 
 
  I should have replied to this in my previous missive. But I want to
  reenforce how unhealthy I believe this practice is. 7-8 days, or even 3
  days being a huge time loss makes absolutely no sense to me at all.
  Assigning a bug should not mean it gets fixed any faster. If it does,
 then
  we need to change the way we are working. (And if this means changing
 the
  JIRA ticket workflow, then so be it. If something isn't working for us,
 we
  change it.)
 
  In fact, I would go so far as to say that we should think of assigning
 bugs
  as an exclusionary practice. Every time you assign a bug, you're
 shutting
  out the community. That's how we should think about it. Assign the bug,
  shut out the community. And so, I would say we should try to avoid doing
  it, unless it is absolutely necessary. (Such as when you're
 co-ordinating
  some release critical work, or when you, yourself, are about to start
 work
  on something. Of course, it's perfectly fine to shut out the community,
 if
  you're doing that at the same time as starting work on something!)
 
 
  --
  NS
 




-- 
NS

Re: Access to Jira system

2013-04-11 Thread David Nalley

On Thu, Apr 11, 2013 at 5:59 AM, Isaac Chiang isaacchi...@gmail.com wrote:
 Dear CloudStack-dev :
   May I have the access to the jira system(To be the assignee)?
  I'd like to take some unassigned tasks/issues. Many thanks.


 Regards
 Isaac

Done

Thanks!

--David

[DOCS] Documentation focused committers, and review processes

Hi all,

I've observed Radhika struggling to get reviews of her feature docs, and
having to work to provide patch after patch for reviewboard submissions.

I have a proposal (which I think Joe hinted at in another thread):

Doc writers with commit rights shouldn't use reviewboard to elicit
reviews from feature developers.  They have access to the repo directly.
Instead, commit away anything that would have previously been posted to
reviewboard.  There's a reason that we try to move folks from
contributor to committer on the project, right? ;-)

Radhika, perhaps you just commit what you have for review if you feel
that it's close enough to publish.  Point people to jenkins.cs.o jobs to
review the content if required.  Questions that block even the initial
doc authoring process obviously continue to be raised on this list.

Would this make life easier for you Radhika?

-chip

Re: Share: SystemVM template for VMWare which has open-vm-tools

2013-04-11 Thread Rohit Yadav

Alright, both of them are uploaded:

SystemVM template for VMWare + open-vm-tools:
http://people.apache.org/~bhaisaab/cloudstack/systemvmtemplates/systemvmtemplate-openvmtools-vmware.ova

SystemVM template for VMWare + vmware-tools:
http://people.apache.org/~bhaisaab/cloudstack/systemvmtemplates/systemvmtemplate-vmwaretools-vmware.ova

Both of are based on/around rev a0b5ebc.

Cheers.

On Thu, Apr 11, 2013 at 2:20 PM, Rohit Yadav bhais...@apache.org wrote:

Hey community!

The systemvm build job [1] fails to create VMWare compatible ova, I could
not find a solution that would completely use opensource tools so I went
ahead to use ovftool. First I import the vmdk produced by this buildjob [1]
in a new VMWare Fusion/Workstation VM, fix it's compatibility and settings.
Next I use ovftool to export the ova. (ovftool vmx output ova).

I've updated this workaround on the wiki:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Build+Your+Own+SystemVM+Templates

So, far I've only uploaded vmware systemvm template (master, rev:
a0b5ebccb814cbb12c5f40aa0c8894ebb3b322d6) which install only open-vm-tools:

http://people.apache.org/~bhaisaab/cloudstack/systemvmtemplates/systemvmtemplate-openvmtools-vmware.ova
MD5 (systemvmtemplate-openvmtools-vmware.ova) =
406e9b3dae3ff2e8ee06cf461828cb06

To install vmware-tools (I'm told they are needed for certain VPC features
on VMWare), it requires:

0. Packages: build-essential, linux-headers and gcc for building modules
1. Bigger space in /usr (so the current partition scheme of systemvms does
not work for me)
2. Running on VMWare Fusion/Workstation, I tried to automate this on the
vbox/veewee buildjob it failed complaining: this configuration program
is to be executed in a virtual machine.

Pl. share if there is a workaround that can be automated. I'll try to
build my own systemvm with vmware-tools from Fusion, upload the template
with 'em soon.

[1] http://jenkins.cloudstack.org/view/master/job/build-systemvm-master

Cheers.

Re: Review Request: Typos fixed

2013-04-11 Thread Pascal Borreli



 On April 11, 2013, 1:26 p.m., Joe Brockmeier wrote:
  Hi - the content looks good, but the actual patch looks wonky. Doesn't 
  apply. Can you reformat and make sure that it applies against master? 
  (Actually try applying it to master as a patch, if you haven't.) Thanks!

my original plan was to target 4.1 branch, are you sure you want me to rebase 
to master ?


- Pascal


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


On April 10, 2013, 11:06 p.m., Pascal Borreli wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/10411/
 ---
 
 (Updated April 10, 2013, 11:06 p.m.)
 
 
 Review request for cloudstack, Joe Brockmeier and Sebastien Goasguen.
 
 
 Description
 ---
 
 Few typo fixed
 
 
 Diffs
 -
 
   docs/it-IT/hypervisor-host-install-libvirt.po a04f6c2 
   docs/ja-JP/hypervisor-host-install-libvirt.po a0b587d 
   docs/pot/hypervisor-host-install-libvirt.pot 6df34bb 
   docs/pt-BR/hypervisor-host-install-libvirt.po 6aad9b7 
   docs/zh-CN/hypervisor-host-install-libvirt.po 189be92 
   docs/zh-TW/hypervisor-host-install-libvirt.po 3e4ae93 
   
 engine/api/src/org/apache/cloudstack/engine/subsystem/api/network/NetworkSubsystem.java
  53254cc 
   
 engine/api/src/org/apache/cloudstack/engine/subsystem/api/storage/TemplateProfile.java
  e05e7db 
   
 engine/storage/image/src/org/apache/cloudstack/storage/image/store/TemplateObject.java
  1b0661c 
   
 engine/storage/volume/src/org/apache/cloudstack/storage/volume/VolumeObject.java
  9e04909 
   
 plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java
  8d01eb7 
   server/src/com/cloud/configuration/ConfigurationManagerImpl.java 52ea8e2 
   server/src/com/cloud/storage/TemplateProfile.java 1d8b6bf 
 
 Diff: https://reviews.apache.org/r/10411/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Pascal Borreli

Re: [DISCUSS] Don't assign tickets to people when triaging

I believe it is possible to mention someone in a JIRA ticket in such a
way that they get notified. Might this be an effective way of CCing someone
into the conversation, without prescribing who should fix it? Might there
be some room for exploration here?


On Thursday, 11 April 2013, Abhinandan Prateek wrote:

 Yes, I think we need to space our releases further apart.
 I had big trouble when master was unstable for a while and specially on
 VMware it was difficult to deploy and test features. Yes for each issue I
 could have shouted on mail list I saw people doing that but the fact is
 that instability was around for a while. Doesn't it make sense that in such
 scenarios we could do things in a more pro active manner. Again I donot see
 much difference in asking someone on Jira to pick a issue vs sending a
 email, but will agree to whatever the community decides here.

 Also community members should volunteer to own some part so that in above
 circumstances a person looking for some fix can approach that member, once
 again a suggestion.



 On 11-Apr-2013, at 5:17 PM, Noah Slater nsla...@apache.orgjavascript:;
 wrote:

  Of course releases are important.
 
  But if our current cadence is putting too much pressure on the community,
  one option might be to do our releases further apart from each other. Or,
  we get strict about the principal of time based releases: i.e. if your
  feature is not ready for the freeze, then it doesn't make it in. No big
  deal. If it's ready for the next freeze, then we'll ship it then.
 
  Also, I may be reading your message wrong, but there's no need for this
 to
  be a divisive argument. There are no sides to this. As a community, it
 is
  up to us all to identify our problems, and figure out solutions.
 
  So what problems do you think we'll run in to if we stop assigning the
  majority of bugs, and how do you think we can mitigate those problems? Or
  do you have another idea in mind altogether?
 
 
 
 
  On 11 April 2013 12:40, Abhinandan Prateek 
 abhinandan.prat...@citrix.com javascript:;wrote:
 
  I think it will be good if we also find out a process so that the
 release
  cycle is not affected by unclaimed bugs sitting out there. Here I am
  assuming the releases are important.
 
  I guess the discussion has turned into keeping things free without
  offering solutions to problems that that system will create.
 
 
  On 11/04/13 5:04 PM, John Burwell jburw...@basho.com javascript:;
 wrote:
 
  +1
 
  On Apr 11, 2013, at 7:22 AM, Noah Slater 
  nsla...@apache.orgjavascript:;
 wrote:
 
  On 11 April 2013 11:22, Abhinandan Prateek
  abhinandan.prat...@citrix.com javascript:;wrote:
 
 
  7-8 days is a huge time lost. I was suggesting that this to be 3
 days.
  Let
  other community members chime in too.
 
 
  I should have replied to this in my previous missive. But I want to
  reenforce how unhealthy I believe this practice is. 7-8 days, or even
 3
  days being a huge time loss makes absolutely no sense to me at all.
  Assigning a bug should not mean it gets fixed any faster. If it does,
  then
  we need to change the way we are working. (And if this means changing
  the
  JIRA ticket workflow, then so be it. If something isn't working for
 us,
  we
  change it.)
 
  In fact, I would go so far as to say that we should think of assigning
  bugs
  as an exclusionary practice. Every time you assign a bug, you're
  shutting
  out the community. That's how we should think about it. Assign the
 bug,
  shut out the community. And so, I would say we should try to avoid
 doing
  it, unless it is absolutely necessary. (Such as when you're
  co-ordinating
  some release critical work, or when you, yourself, are about to start
  work
  on something. Of course, it's perfectly fine to shut out the
 community,
  if
  you're doing that at the same time as starting work on something!)
 
 
  --
  NS
 
 
  --
  NS



-- 
NS

Re: Access to Jira system

2013-04-11 Thread Isaac Chiang

Thanks!:)


On Thu, Apr 11, 2013 at 8:18 PM, David Nalley da...@gnsa.us wrote:

 On Thu, Apr 11, 2013 at 5:59 AM, Isaac Chiang isaacchi...@gmail.com
 wrote:
  Dear CloudStack-dev :
May I have the access to the jira system(To be the
 assignee)?
   I'd like to take some unassigned tasks/issues. Many thanks.
 
 
  Regards
  Isaac

 Done

 Thanks!

 --David

Re: [DOCS] Documentation focused committers, and review processes

On Thu, Apr 11, 2013, at 08:04 AM, Chip Childers wrote:
 I've observed Radhika struggling to get reviews of her feature docs, and
 having to work to provide patch after patch for reviewboard submissions.
 
 I have a proposal (which I think Joe hinted at in another thread):

Indeed. 
 
 Doc writers with commit rights shouldn't use reviewboard to elicit
 reviews from feature developers.  They have access to the repo directly.
 Instead, commit away anything that would have previously been posted to
 reviewboard.  There's a reason that we try to move folks from
 contributor to committer on the project, right? ;-)

That's my thinking. +1

 Radhika, perhaps you just commit what you have for review if you feel
 that it's close enough to publish.  Point people to jenkins.cs.o jobs to
 review the content if required.  Questions that block even the initial
 doc authoring process obviously continue to be raised on this list.
 
 Would this make life easier for you Radhika?
 
 -chip


Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: [DOCS][ACS41] Release notes are failing the build

On Thu, Apr 11, 2013, at 07:31 AM, Chip Childers wrote:
 Hi all,
 
 Release notes are failing the build in jenkins.cs.o:
 
 http://jenkins.cloudstack.org/job/docs-4.1-releasenotes/372/console
 
 Release_Notes.xml:32: validity error : IDREF attribute linkend
 references an unknown ID feedback
 
 I created CLOUDSTACK-2007 for this.  Joe, I think that you may be the
 only person working on this document, so do you mind taking a look (and
 grabbing the bug)?

This is weird. Looking into this now. 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: [DISCUSS] Don't assign tickets to people when triaging

On 11 April 2013 15:11, Joe Brockmeier j...@zonker.net wrote:


 I'm against a policy of never assigning tickets, but it shouldn't be the
 norm for one set of folks to triage tickets and assign them to another
 set of folks.



Me too.

We should establish:

 a) A rule that we avoid ticket assignment by default, and
 b) A clear set of exceptions to that rule...


-- 
NS

Re: [DISCUSS] Don't assign tickets to people when triaging

2013-04-11 Thread Abhinandan Prateek



On the Jira notification my suggestion will be to have a goto list of
people for various domains of expertise. Anyone can register for these
domains. When a bug is filed, the filer selects one of the domains he
thinks that is right for getting the bug to be resolved. This alerts the
people who have volunteered for that domain. We may take this one step
future in that for each domain we can have a designated contact person who
may once in a while take a look at the list of open issues in that domain
and may further take action for quicker resolution.

I think I had enough inputs for the day :-), Moreover the day is ending in
my timezone.
I guess that did bring some issues to the notice of community, I will
expect other community members to think of solutions.
With so many passionate members in this community I think we will arrive
at a good solution that works.


Kudos to the community !


On 11/04/13 7:17 PM, Noah Slater nsla...@apache.org wrote:

I believe it is possible to mention someone in a JIRA ticket in such a
way that they get notified. Might this be an effective way of CCing
someone
into the conversation, without prescribing who should fix it? Might there
be some room for exploration here?


On Thursday, 11 April 2013, Abhinandan Prateek wrote:

 Yes, I think we need to space our releases further apart.
 I had big trouble when master was unstable for a while and specially on
 VMware it was difficult to deploy and test features. Yes for each issue
I
 could have shouted on mail list I saw people doing that but the fact is
 that instability was around for a while. Doesn't it make sense that in
such
 scenarios we could do things in a more pro active manner. Again I donot
see
 much difference in asking someone on Jira to pick a issue vs sending a
 email, but will agree to whatever the community decides here.

 Also community members should volunteer to own some part so that in
above
 circumstances a person looking for some fix can approach that member,
once
 again a suggestion.



 On 11-Apr-2013, at 5:17 PM, Noah Slater
nsla...@apache.orgjavascript:;
 wrote:

  Of course releases are important.
 
  But if our current cadence is putting too much pressure on the
community,
  one option might be to do our releases further apart from each other.
Or,
  we get strict about the principal of time based releases: i.e. if your
  feature is not ready for the freeze, then it doesn't make it in. No
big
  deal. If it's ready for the next freeze, then we'll ship it then.
 
  Also, I may be reading your message wrong, but there's no need for
this
 to
  be a divisive argument. There are no sides to this. As a community,
it
 is
  up to us all to identify our problems, and figure out solutions.
 
  So what problems do you think we'll run in to if we stop assigning the
  majority of bugs, and how do you think we can mitigate those
problems? Or
  do you have another idea in mind altogether?
 
 
 
 
  On 11 April 2013 12:40, Abhinandan Prateek 
 abhinandan.prat...@citrix.com javascript:;wrote:
 
  I think it will be good if we also find out a process so that the
 release
  cycle is not affected by unclaimed bugs sitting out there. Here I am
  assuming the releases are important.
 
  I guess the discussion has turned into keeping things free without
  offering solutions to problems that that system will create.
 
 
  On 11/04/13 5:04 PM, John Burwell jburw...@basho.com
javascript:;
 wrote:
 
  +1
 
  On Apr 11, 2013, at 7:22 AM, Noah Slater
nsla...@apache.orgjavascript:;
 wrote:
 
  On 11 April 2013 11:22, Abhinandan Prateek
  abhinandan.prat...@citrix.com javascript:;wrote:
 
 
  7-8 days is a huge time lost. I was suggesting that this to be 3
 days.
  Let
  other community members chime in too.
 
 
  I should have replied to this in my previous missive. But I want to
  reenforce how unhealthy I believe this practice is. 7-8 days, or
even
 3
  days being a huge time loss makes absolutely no sense to me at
all.
  Assigning a bug should not mean it gets fixed any faster. If it
does,
  then
  we need to change the way we are working. (And if this means
changing
  the
  JIRA ticket workflow, then so be it. If something isn't working for
 us,
  we
  change it.)
 
  In fact, I would go so far as to say that we should think of
assigning
  bugs
  as an exclusionary practice. Every time you assign a bug, you're
  shutting
  out the community. That's how we should think about it. Assign the
 bug,
  shut out the community. And so, I would say we should try to avoid
 doing
  it, unless it is absolutely necessary. (Such as when you're
  co-ordinating
  some release critical work, or when you, yourself, are about to
start
  work
  on something. Of course, it's perfectly fine to shut out the
 community,
  if
  you're doing that at the same time as starting work on something!)
 
 
  --
  NS
 
 
  --
  NS



-- 
NS

Re: [DISCUSS] Don't assign tickets to people when triaging

To me, it seems like what you're describing are components. You assign or
sort the ticket into a component. Then I guess, people who are interested
can watch that component for new issues. I am not sure if there's a way to
watch a component in JIRA so that you get email notifications for it. I
took a look, but couldn't find anything. Perhaps Infra would install a
plugin for us. (I noticed that at least one such plugin exists.) At the
very least, you could save a report as a favourite...


On 11 April 2013 15:20, Abhinandan Prateek abhinandan.prat...@citrix.comwrote:



 On the Jira notification my suggestion will be to have a goto list of
 people for various domains of expertise. Anyone can register for these
 domains. When a bug is filed, the filer selects one of the domains he
 thinks that is right for getting the bug to be resolved. This alerts the
 people who have volunteered for that domain. We may take this one step
 future in that for each domain we can have a designated contact person who
 may once in a while take a look at the list of open issues in that domain
 and may further take action for quicker resolution.

 I think I had enough inputs for the day :-), Moreover the day is ending in
 my timezone.
 I guess that did bring some issues to the notice of community, I will
 expect other community members to think of solutions.
 With so many passionate members in this community I think we will arrive
 at a good solution that works.


 Kudos to the community !


 On 11/04/13 7:17 PM, Noah Slater nsla...@apache.org wrote:

 I believe it is possible to mention someone in a JIRA ticket in such a
 way that they get notified. Might this be an effective way of CCing
 someone
 into the conversation, without prescribing who should fix it? Might there
 be some room for exploration here?
 
 
 On Thursday, 11 April 2013, Abhinandan Prateek wrote:
 
  Yes, I think we need to space our releases further apart.
  I had big trouble when master was unstable for a while and specially on
  VMware it was difficult to deploy and test features. Yes for each issue
 I
  could have shouted on mail list I saw people doing that but the fact is
  that instability was around for a while. Doesn't it make sense that in
 such
  scenarios we could do things in a more pro active manner. Again I donot
 see
  much difference in asking someone on Jira to pick a issue vs sending a
  email, but will agree to whatever the community decides here.
 
  Also community members should volunteer to own some part so that in
 above
  circumstances a person looking for some fix can approach that member,
 once
  again a suggestion.
 
 
 
  On 11-Apr-2013, at 5:17 PM, Noah Slater
 nsla...@apache.orgjavascript:;
  wrote:
 
   Of course releases are important.
  
   But if our current cadence is putting too much pressure on the
 community,
   one option might be to do our releases further apart from each other.
 Or,
   we get strict about the principal of time based releases: i.e. if your
   feature is not ready for the freeze, then it doesn't make it in. No
 big
   deal. If it's ready for the next freeze, then we'll ship it then.
  
   Also, I may be reading your message wrong, but there's no need for
 this
  to
   be a divisive argument. There are no sides to this. As a community,
 it
  is
   up to us all to identify our problems, and figure out solutions.
  
   So what problems do you think we'll run in to if we stop assigning the
   majority of bugs, and how do you think we can mitigate those
 problems? Or
   do you have another idea in mind altogether?
  
  
  
  
   On 11 April 2013 12:40, Abhinandan Prateek 
  abhinandan.prat...@citrix.com javascript:;wrote:
  
   I think it will be good if we also find out a process so that the
  release
   cycle is not affected by unclaimed bugs sitting out there. Here I am
   assuming the releases are important.
  
   I guess the discussion has turned into keeping things free without
   offering solutions to problems that that system will create.
  
  
   On 11/04/13 5:04 PM, John Burwell jburw...@basho.com
 javascript:;
  wrote:
  
   +1
  
   On Apr 11, 2013, at 7:22 AM, Noah Slater
 nsla...@apache.orgjavascript:;
  wrote:
  
   On 11 April 2013 11:22, Abhinandan Prateek
   abhinandan.prat...@citrix.com javascript:;wrote:
  
  
   7-8 days is a huge time lost. I was suggesting that this to be 3
  days.
   Let
   other community members chime in too.
  
  
   I should have replied to this in my previous missive. But I want to
   reenforce how unhealthy I believe this practice is. 7-8 days, or
 even
  3
   days being a huge time loss makes absolutely no sense to me at
 all.
   Assigning a bug should not mean it gets fixed any faster. If it
 does,
   then
   we need to change the way we are working. (And if this means
 changing
   the
   JIRA ticket workflow, then so be it. If something isn't working for
  us,
   we
   change it.)
  
   In fact, I would go so far as to say that we should think of
 assigning

Re: [DISCUSS] Don't assign tickets to people when triaging

On Thu, Apr 11, 2013, at 09:28 AM, Noah Slater wrote:
 To me, it seems like what you're describing are components. You assign or
 sort the ticket into a component. Then I guess, people who are interested
 can watch that component for new issues. I am not sure if there's a way
 to
 watch a component in JIRA so that you get email notifications for it. I
 took a look, but couldn't find anything. Perhaps Infra would install a
 plugin for us. (I noticed that at least one such plugin exists.) At the
 very least, you could save a report as a favourite...

Triaging tickets into components, and making sure that new tickets are
appropriately categorized, should be fine. 

I don't know if there's specifically a watch feature for a component,
but it's easy enough to bookmark a search for a specific component and
look through the tickets. 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: [DOCS][ACS41] Release notes are failing the build

On Thu, Apr 11, 2013, at 07:31 AM, Chip Childers wrote:
 Hi all,
 
 Release notes are failing the build in jenkins.cs.o:
 
 http://jenkins.cloudstack.org/job/docs-4.1-releasenotes/372/console
 
 Release_Notes.xml:32: validity error : IDREF attribute linkend
 references an unknown ID feedback
 
 I created CLOUDSTACK-2007 for this.  Joe, I think that you may be the
 only person working on this document, so do you mind taking a look (and
 grabbing the bug)?

So, having looked at this... (also updated the ticket)

Tested building the release notes on two systems, a Fedora 18 and a
Fedora 17 system, with slightly different versions of Publican.

Both systems build the release notes successfully. I think the problem
is in the common content, which I modified a few days ago to include
Feedback.xml. If you're building the docs locally, this requires you to
redo the publican-cloudstack RPM. Perhaps this isn't reflected in the
Jenkins job? 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: [DISCUSS] Don't assign tickets to people when triaging

On Thu, Apr 11, 2013 at 12:51:34PM +, Abhinandan Prateek wrote:
 Yes, I think we need to space our releases further apart.

That's a different discussion, which you are free to raise if you'd like.

 Also community members should volunteer to own some part so that in above 
 circumstances a person looking for some fix can approach that member, once 
 again a suggestion.

I've been reading through this thread, and I'll pick the owner comment
above as a starting point for my personal opinions.  This is a reaction
to the whole thread really, so take a minute to read to the end please.

Owning some part is antithetical to a healthy community approach.
Certainly people will gravitate to certain areas, and by all means
everyone should feel free to work on areas of the code-base that they
feel like they want to improve or support.  This may lead to people
effectively being the primary do-er for certain areas (examples: Wido
has been working on DEB packaging, Rohit has been working on
CloudMonkey), but we shouldn't ever consider this ownership. I feel
personally welcome to make a change in CloudMonkey, and would certainly
consider it important to collaborate with anyone (especially Rohit) that
may have input and insights.

The idea of ownership if a part of the software is something I'm strongly
against.

Even the idea of maintainers seems like it is problematic in
implementation.  How do we decide who the official maintainer is?  How
do we decide when someone else should do that... And frankly, doesn't a
maintainer model really discourage others from working in named areas?

All of these attempts to structure the community appear to be natural
responses when you have a background in corporate development (product
or otherwise), which is my background as well.  It doesn't work here,
and you have to fight the urge to apply the same solutions (WRT
structure and process) in this environment.  If you haven't read
Producing OSS [1], go do that.

What we really need is for those individuals that are interested in
participating in this community to actively participate.  Read the ML,
take on bugs, focus on the shared community release goals.  If you
consider yourself interested in this project, then don't wait for
assignments from someone else.  Watch the lists, notice areas where you
can help, discuss if you disagree with proposed community goals as they
are being formed.

Personal responsibility and interest in contributing to the shared
community goals is what we should all expect of each other. We should
not expect that others in the community will spoon feed tasks out. If
that happens within someone's $dayjob, that's not a community concern.

You'll notice that I have rarely assigned a bug.  In a couple of
instances, I've pushed something to someone that I know is *actively*
working in an area of the code.  I've also assigned a bug as purely an
administrative step, when I know someone is already working on the issue,
but may not have had the time to assign the bug to themselves.  Release
blockers that I don't easily associated with some ongoing and known work
are highlighted in emails, with a request for someone to grab them.

Releases are the shared goals of the community, but building a strong
community is more important than any specific release.  That's why this
conversation started really.

So yes, I want blockers to be addressed.  Yes, I want us to get our
releases out.  Yes, I'd like us to be close to our proposed schedules.
No, I'm not willing to have a release take priority over the more
important goal of building a stronger and stronger community.

-chip

[1] http://www.producingoss.com/

Re: [DISCUSS] Don't assign tickets to people when triaging

+1


On 11 April 2013 15:39, Chip Childers chip.child...@sungard.com wrote:

 On Thu, Apr 11, 2013 at 12:51:34PM +, Abhinandan Prateek wrote:
  Yes, I think we need to space our releases further apart.

 That's a different discussion, which you are free to raise if you'd like.

  Also community members should volunteer to own some part so that in
 above circumstances a person looking for some fix can approach that member,
 once again a suggestion.

 I've been reading through this thread, and I'll pick the owner comment
 above as a starting point for my personal opinions.  This is a reaction
 to the whole thread really, so take a minute to read to the end please.

 Owning some part is antithetical to a healthy community approach.
 Certainly people will gravitate to certain areas, and by all means
 everyone should feel free to work on areas of the code-base that they
 feel like they want to improve or support.  This may lead to people
 effectively being the primary do-er for certain areas (examples: Wido
 has been working on DEB packaging, Rohit has been working on
 CloudMonkey), but we shouldn't ever consider this ownership. I feel
 personally welcome to make a change in CloudMonkey, and would certainly
 consider it important to collaborate with anyone (especially Rohit) that
 may have input and insights.

 The idea of ownership if a part of the software is something I'm strongly
 against.

 Even the idea of maintainers seems like it is problematic in
 implementation.  How do we decide who the official maintainer is?  How
 do we decide when someone else should do that... And frankly, doesn't a
 maintainer model really discourage others from working in named areas?

 All of these attempts to structure the community appear to be natural
 responses when you have a background in corporate development (product
 or otherwise), which is my background as well.  It doesn't work here,
 and you have to fight the urge to apply the same solutions (WRT
 structure and process) in this environment.  If you haven't read
 Producing OSS [1], go do that.

 What we really need is for those individuals that are interested in
 participating in this community to actively participate.  Read the ML,
 take on bugs, focus on the shared community release goals.  If you
 consider yourself interested in this project, then don't wait for
 assignments from someone else.  Watch the lists, notice areas where you
 can help, discuss if you disagree with proposed community goals as they
 are being formed.

 Personal responsibility and interest in contributing to the shared
 community goals is what we should all expect of each other. We should
 not expect that others in the community will spoon feed tasks out. If
 that happens within someone's $dayjob, that's not a community concern.

 You'll notice that I have rarely assigned a bug.  In a couple of
 instances, I've pushed something to someone that I know is *actively*
 working in an area of the code.  I've also assigned a bug as purely an
 administrative step, when I know someone is already working on the issue,
 but may not have had the time to assign the bug to themselves.  Release
 blockers that I don't easily associated with some ongoing and known work
 are highlighted in emails, with a request for someone to grab them.

 Releases are the shared goals of the community, but building a strong
 community is more important than any specific release.  That's why this
 conversation started really.

 So yes, I want blockers to be addressed.  Yes, I want us to get our
 releases out.  Yes, I'd like us to be close to our proposed schedules.
 No, I'm not willing to have a release take priority over the more
 important goal of building a stronger and stronger community.

 -chip

 [1] http://www.producingoss.com/




-- 
NS

Re: [jira] [Created] (CLOUDSTACK-2008) guest network vlan tag chain issue

I'll take a look at this when I get a moment, I'll wait until I have time
before assigning it to myself.  I'm thinking this has to do with the 'bond'
device, since it's normally supposed to look in /proc/net/vlan, to see if
the parent interface is tagged, and then look up the parent of THAT
interface.


On Thu, Apr 11, 2013 at 9:01 AM, danny webb (JIRA) j...@apache.org wrote:

 danny webb created CLOUDSTACK-2008:
 --

  Summary: guest network vlan tag chain issue
  Key: CLOUDSTACK-2008
  URL:
 https://issues.apache.org/jira/browse/CLOUDSTACK-2008
  Project: CloudStack
   Issue Type: Bug
   Security Level: Public (Anyone can view this level - this is the
 default.)
   Components: Network Controller
 Affects Versions: 4.0.1
  Environment: centos 6.4
 HP BL460 G1
 Reporter: danny webb
 Priority: Minor


 Hi,

 I have setup a cloudstack instance where my root eth device is a vlan
 tagged bond0.60 (as the network I am on has a different default VLAN id
 than my test vlans).

 so I am setup like this:

 bond0.60 / cloudbr0 == management network / ip of box (bond0 ==
 nothing)

 bond0.60  Link encap:Ethernet  HWaddr 00:17:A4:77:48:3C
   inet6 addr: fe80::217:a4ff:fe77:483c/64 Scope:Link
   UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
   RX packets:37189 errors:0 dropped:0 overruns:0 frame:0
   TX packets:34030 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0
   RX bytes:4476334 (4.2 MiB)  TX bytes:31055747 (29.6 MiB)
 cloudbr0  Link encap:Ethernet  HWaddr 00:17:A4:77:48:3C
   inet addr:172.18.102.8  Bcast:172.18.102.255
  Mask:255.255.255.0
   inet6 addr: fe80::217:a4ff:fe77:483c/64 Scope:Link
   UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
   RX packets:36531 errors:0 dropped:0 overruns:0 frame:0
   TX packets:32606 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0
   RX bytes:4435824 (4.2 MiB)  TX bytes:30976056 (29.5 MiB)

 when it went to setup a new guest network (with a vlan id of 80) it
 created it ontop of the bond0.60 like:

 bond0.60.80 Link encap:Ethernet  HWaddr 00:17:A4:77:48:3C
   inet6 addr: fe80::217:a4ff:fe77:483c/64 Scope:Link
   UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
   TX packets:70 errors:0 dropped:0 overruns:0 carrier:0
   collisions:0 txqueuelen:0
   RX bytes:0 (0.0 b)  TX bytes:13777 (13.4 KiB)

 [root@slo-cnkvm004 ~]# brctl show
 bridge name bridge id   STP enabled interfaces
 cloud0  8000.   no
 cloudVirBr808000.0017a477483c   no
  bond0.60.80

 which doesn't seem to work and I am pretty sure is syntactically wrong.  I
 can't ping any guests that come up on that network.  When creating new
 devices it should I believe be creating them off of the base eth device (ie
 eth0, or bond0).


 --
 This message is automatically generated by JIRA.
 If you think it was sent incorrectly, please contact your JIRA
 administrators
 For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] [Commented] (CLOUDSTACK-2008) guest network vlan tag chain issue

Just a few quick things...  cloudbr0 is being set as your guest bridge,
right? See /etc/cloud/agent/agent.properties

Is there a /proc/net/vlan/bond0.60? If so, can you send the contents? It
should be building guest bridges off of whatever is listed in the Device:
line in this file.

There should also be some logs in the /var/log/cloud/agent/agent.log file
that might indicate what's going on.


On Thu, Apr 11, 2013 at 9:31 AM, Marcus Sorensen (JIRA) j...@apache.orgwrote:


 [
 https://issues.apache.org/jira/browse/CLOUDSTACK-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13629015#comment-13629015]

 Marcus Sorensen commented on CLOUDSTACK-2008:
 -

 I'll take a look at this when I get a moment, I'll wait until I have time
 before assigning it to myself.  I'm thinking this has to do with the 'bond'
 device, since it's normally supposed to look in /proc/net/vlan, to see if
 the parent interface is tagged, and then look up the parent of THAT
 interface.





  guest network vlan tag chain issue
  --
 
  Key: CLOUDSTACK-2008
  URL:
 https://issues.apache.org/jira/browse/CLOUDSTACK-2008
  Project: CloudStack
   Issue Type: Bug
   Security Level: Public(Anyone can view this level - this is the
 default.)
   Components: Network Controller
 Affects Versions: 4.0.1
  Environment: centos 6.4
  HP BL460 G1
 Reporter: danny webb
 Priority: Minor
 
  Hi,
  I have setup a cloudstack instance where my root eth device is a vlan
 tagged bond0.60 (as the network I am on has a different default VLAN id
 than my test vlans).
  so I am setup like this:
  bond0.60 / cloudbr0 == management network / ip of box (bond0 ==
 nothing)
 
  bond0.60  Link encap:Ethernet  HWaddr 00:17:A4:77:48:3C
inet6 addr: fe80::217:a4ff:fe77:483c/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
RX packets:37189 errors:0 dropped:0 overruns:0 frame:0
TX packets:34030 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4476334 (4.2 MiB)  TX bytes:31055747 (29.6 MiB)
  cloudbr0  Link encap:Ethernet  HWaddr 00:17:A4:77:48:3C
inet addr:172.18.102.8  Bcast:172.18.102.255
  Mask:255.255.255.0
inet6 addr: fe80::217:a4ff:fe77:483c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:36531 errors:0 dropped:0 overruns:0 frame:0
TX packets:32606 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4435824 (4.2 MiB)  TX bytes:30976056 (29.5 MiB)
 
  when it went to setup a new guest network (with a vlan id of 80) it
 created it ontop of the bond0.60 like:
 
  bond0.60.80 Link encap:Ethernet  HWaddr 00:17:A4:77:48:3C
inet6 addr: fe80::217:a4ff:fe77:483c/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:70 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b)  TX bytes:13777 (13.4 KiB)
 
  [root@slo-cnkvm004 ~]# brctl show
  bridge name bridge id   STP enabled interfaces
  cloud0  8000.   no
  cloudVirBr808000.0017a477483c   no
  bond0.60.80
 
  which doesn't seem to work and I am pretty sure is syntactically wrong.
  I can't ping any guests that come up on that network.  When creating new
 devices it should I believe be creating them off of the base eth device (ie
 eth0, or bond0).

 --
 This message is automatically generated by JIRA.
 If you think it was sent incorrectly, please contact your JIRA
 administrators
 For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [DISCUSS] Don't assign tickets to people when triaging

2013-04-11 Thread Rohit Yadav

On Thu, Apr 11, 2013 at 8:09 PM, Chip Childers chip.child...@sungard.comwrote:

 On Thu, Apr 11, 2013 at 12:51:34PM +, Abhinandan Prateek wrote:
  Yes, I think we need to space our releases further apart.

 That's a different discussion, which you are free to raise if you'd like.

  Also community members should volunteer to own some part so that in
 above circumstances a person looking for some fix can approach that member,
 once again a suggestion.

 I've been reading through this thread, and I'll pick the owner comment
 above as a starting point for my personal opinions.  This is a reaction
 to the whole thread really, so take a minute to read to the end please.

 Owning some part is antithetical to a healthy community approach.
 Certainly people will gravitate to certain areas, and by all means
 everyone should feel free to work on areas of the code-base that they
 feel like they want to improve or support.  This may lead to people
 effectively being the primary do-er for certain areas (examples: Wido
 has been working on DEB packaging, Rohit has been working on
 CloudMonkey), but we shouldn't ever consider this ownership. I feel
 personally welcome to make a change in CloudMonkey, and would certainly
 consider it important to collaborate with anyone (especially Rohit) that
 may have input and insights.


Super duper +1.

I see the *feature owner/maintainer* only as person of interest around that
area and encourage contributions in whatever way and any area.

Instead of labelling things as mine or yours, being in community means we
own the whole CloudStack it as a team. So, for example I preferred to write
author as The Apache CloudStack Team [1] but name myself as the current
maintainer for the CLI as I've interest around that area and would like to
participate/help review/checkin any feedback/contributions and everyone is
welcome to administrate the pypi channel [1].

[1] https://pypi.python.org/pypi/cloudmonkey/4.1.0-snapshot

Cheers.
You should listen to Chip, read http://www.producingoss.com and follow his
tweets when he shares such awesome stuff ;)




 The idea of ownership if a part of the software is something I'm strongly
 against.

 Even the idea of maintainers seems like it is problematic in
 implementation.  How do we decide who the official maintainer is?  How
 do we decide when someone else should do that... And frankly, doesn't a
 maintainer model really discourage others from working in named areas?

 All of these attempts to structure the community appear to be natural
 responses when you have a background in corporate development (product
 or otherwise), which is my background as well.  It doesn't work here,
 and you have to fight the urge to apply the same solutions (WRT
 structure and process) in this environment.  If you haven't read
 Producing OSS [1], go do that.

 What we really need is for those individuals that are interested in
 participating in this community to actively participate.  Read the ML,
 take on bugs, focus on the shared community release goals.  If you
 consider yourself interested in this project, then don't wait for
 assignments from someone else.  Watch the lists, notice areas where you
 can help, discuss if you disagree with proposed community goals as they
 are being formed.

 Personal responsibility and interest in contributing to the shared
 community goals is what we should all expect of each other. We should
 not expect that others in the community will spoon feed tasks out. If
 that happens within someone's $dayjob, that's not a community concern.

 You'll notice that I have rarely assigned a bug.  In a couple of
 instances, I've pushed something to someone that I know is *actively*
 working in an area of the code.  I've also assigned a bug as purely an
 administrative step, when I know someone is already working on the issue,
 but may not have had the time to assign the bug to themselves.  Release
 blockers that I don't easily associated with some ongoing and known work
 are highlighted in emails, with a request for someone to grab them.

 Releases are the shared goals of the community, but building a strong
 community is more important than any specific release.  That's why this
 conversation started really.

 So yes, I want blockers to be addressed.  Yes, I want us to get our
 releases out.  Yes, I'd like us to be close to our proposed schedules.
 No, I'm not willing to have a release take priority over the more
 important goal of building a stronger and stronger community.

 -chip

 [1] http://www.producingoss.com/

[ACS41][Patch Request]

commit ca8ac08cf37cd9ea8a50d323ac596da16319e7ab
Author: Marcus Sorensen mar...@betterservers.com
Date:   Thu Apr 11 09:50:48 2013 -0600

CLOUDSTACK-2003: When accounts and domains are deleted, cleanup can
fail,
leaving instances in eternal expunged state. This happens when a domain
is
deleted while a deleted account is cleaning up. The cleanup looks for
the domain
of the account and we hit a null pointer. Adding null pointer check.

[ACS40][Patch Request]

commit ca8ac08cf37cd9ea8a50d323ac596da16319e7ab
Author: Marcus Sorensen mar...@betterservers.com
Date:   Thu Apr 11 09:50:48 2013 -0600

CLOUDSTACK-2003: When accounts and domains are deleted, cleanup can
fail,
leaving instances in eternal expunged state. This happens when a domain
is
deleted while a deleted account is cleaning up. The cleanup looks for
the domain
of the account and we hit a null pointer. Adding null pointer check.

Re: [ACS40][Patch Request]


On 04/11/2013 10:55 AM, Marcus Sorensen wrote:

commit ca8ac08cf37cd9ea8a50d323ac596da16319e7ab
Author: Marcus Sorensen mar...@betterservers.com
Date:   Thu Apr 11 09:50:48 2013 -0600

 CLOUDSTACK-2003: When accounts and domains are deleted, cleanup can
fail,
 leaving instances in eternal expunged state. This happens when a domain
is
 deleted while a deleted account is cleaning up. The cleanup looks for
the domain
 of the account and we hit a null pointer. Adding null pointer check.



ACK. Applied, and thanks!

Best,

Joe

Re: [DISCUSS] Don't assign tickets to people when triaging

On 11 April 2013 20:09, Chip Childers chip.child...@sungard.com wrote:
 On Thu, Apr 11, 2013 at 12:51:34PM +, Abhinandan Prateek wrote:
 Yes, I think we need to space our releases further apart.

 That's a different discussion, which you are free to raise if you'd like.

 Also community members should volunteer to own some part so that in above 
 circumstances a person looking for some fix can approach that member, once 
 again a suggestion.

 I've been reading through this thread, and I'll pick the owner comment
 above as a starting point for my personal opinions.  This is a reaction
 to the whole thread really, so take a minute to read to the end please.

 Owning some part is antithetical to a healthy community approach.
 Certainly people will gravitate to certain areas, and by all means
 everyone should feel free to work on areas of the code-base that they
 feel like they want to improve or support.  This may lead to people
 effectively being the primary do-er for certain areas (examples: Wido
 has been working on DEB packaging, Rohit has been working on
 CloudMonkey), but we shouldn't ever consider this ownership. I feel
 personally welcome to make a change in CloudMonkey, and would certainly
 consider it important to collaborate with anyone (especially Rohit) that
 may have input and insights.

 The idea of ownership if a part of the software is something I'm strongly
 against.

 Even the idea of maintainers seems like it is problematic in
 implementation.  How do we decide who the official maintainer is?  How
 do we decide when someone else should do that... And frankly, doesn't a
 maintainer model really discourage others from working in named areas?

 All of these attempts to structure the community appear to be natural
 responses when you have a background in corporate development (product
 or otherwise), which is my background as well.  It doesn't work here,
 and you have to fight the urge to apply the same solutions (WRT
 structure and process) in this environment.  If you haven't read
 Producing OSS [1], go do that.


And if you don't have the patience, here's the appropriate extract:
http://www.producingoss.com/en/managing-volunteers.html#delegation-assignment

Re: [DOC] Opening vncextras firewall ports in ESXi 5.1


On 04/10/2013 04:23 PM, Jason Cadmus wrote:

I have some documentation on how to accomplish this task and would like to
contribute it to the ACS documentation for CS 4.1.


Awesome!


I am going through the following link below, trying to comprehend how to
accomplish this. I have downloaded the source for 4.1, compiled to
documentation with publican, and see what section the information needs to
added to.
https://cwiki.apache.org/CLOUDSTACK/cloudstack-documentation-contributors-overview.html

I do not have a developer background what so every so please
have patience with my questions.


Ask away, we're very happy to help folks who want to contribute. 
Speaking as a non-developer who's also working on docs, I understand 
that it involves a bit of a learning curve.



Should create a new xml doc or do I edit and existing xml doc?


It depends on whether what you want to add fits with an existing 
section, or whether it needs its own section.


Another option would be to write the docs on the wiki and create a doc 
task to port the documentation into the appropriate guide. For a 
first-time docs contribution, that might be an easy way to go. Then 
you'd have an template to work off of for the next time.


We're usually on IRC during the day as well if you have questions about 
how to work in Publican, or anything else.



Is there a easier way for someone to contribute with having a Sys Admin
background?


We can use a lot of help getting the wiki in shape and if you have 
experience with CloudStack and want to add to the wiki information, 
that'd be awesome as well.


I'm sure other folks have ideas too.

Thanks!

Joe

Re: deployDataCenter.py doesn't work for me on master

Is this the same as
https://issues.apache.org/jira/browse/CLOUDSTACK-183

Check SMLog on the XenServer (I think it is /var/log/SMLog)


On 4/10/13 11:00 PM, Soheil Eizadi seiz...@infoblox.com wrote:

I debugged this further looks like there is problem in my XenServer
creating the VDI, the template vhd that is in the NFS secondary storage is
good I verified it with vhd-util.

I was using a PreSetup LVM on the XenServer and had this problem, I
switched to using an NFS primary volume and that behaves the same. If I
look at the Primary NFS volume I see the vhd files copied there.
Any ideas what I should look at next to debug this XenServer Storage
Resource problem? My next step would be to stop the MS when the VM is
spawned on the XenServer and figure out why it is not able to run. It does
not stay around for long, before it is deleted and the MS loops trying to
create it over and over again :(
-Soheil

 System VM state when it fails

[root@xenserver-devcloud ~]# xe vm-list
uuid ( RO) : f45d51c7-9a4f-9c23-7caa-35fc720ac185
name-label ( RW): v-2-VM
power-state ( RO): halted

 MS Exception
2013-04-10 16:19:57,355 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-9:null) can not create vdi in sr
f95f52d1-5c00-17ea-a7e5-973ba7b6c0de
2013-04-10 16:19:57,356 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-9:null) Catch Exception
com.cloud.utils.exception.CloudRuntimeException on
host:f4bc16a9-291c-4d2e-b9f2-d018cabd1a4b for template:
nfs://172.16.197.131/opt/storage/secondary/template/tmpl/1/1/ due to
com.cloud.utils.exception.CloudRuntimeException: can not create vdi in sr
f95f52d1-5c00-17ea-a7e5-973ba7b6c0de
com.cloud.utils.exception.CloudRuntimeException: can not create vdi in sr
f95f52d1-5c00-17ea-a7e5-973ba7b6c0de
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.copy_vhd_from_seconda
r
ystorage(CitrixResourceBase.java:2914)


 LVM volume when I set it up for primary storage
[root@xenserver-devcloud ~]# xe sr-list
….
uuid ( RO): f95f52d1-5c00-17ea-a7e5-973ba7b6c0de
  name-label ( RW): f95f52d1-5c00-17ea-a7e5-973ba7b6c0de
name-description ( RW): Cloud Stack Local LVM Storage Pool for
f4bc16a9-291c-4d2e-b9f2-d018cabd1a4b
host ( RO): xenserver-devcloud
type ( RO): lvm
content-type ( RO): user
….

 Content of NFS Primary Storage when I started using it instead of
PreSetup/LVM
root@devcloud:/opt/storage/primary# ls
1d780a71-890f-43b1-9786-b5db98e510da.vhd
43c00e22-0001-4d76-9962-f39257494695.vhd
hb-f4bc16a9-291c-4d2e-b9f2-d018cabd1a4b




On 4/10/13 5:02 PM, Soheil Eizadi seiz...@infoblox.com wrote:

I am using the devcloud appliance as my NFS Server, for now I am using a
separate XenServer 6.0.2 host, but would like to use the built in
XenServer in devcloud appliance if that works for development.
-Soheil

Here is what is on that NFS drive right now:
root@devcloud:~# find /opt/storage/secondary/template/
/opt/storage/secondary/template/
/opt/storage/secondary/template/tmpl
/opt/storage/secondary/template/tmpl/1
/opt/storage/secondary/template/tmpl/1/1
/opt/storage/secondary/template/tmpl/1/1/template.properties
/opt/storage/secondary/template/tmpl/1/1/dc68eb4c-228c-4a78-84fa-b80ae178
f
b
fd.vhd
/opt/storage/secondary/template/tmpl/1/5
/opt/storage/secondary/template/tmpl/1/5/template.properties
/opt/storage/secondary/template/tmpl/1/5/ce5b212e-215a-3461-94fb-814a635b
2
2
15.vhd




On 4/10/13 4:51 PM, Edison Su edison...@citrix.com wrote:

Have you pre-install xenserver template on
nfs://172.16.197.131/opt/storage/secondary/template/tmpl/1/1/?

 -Original Message-
 From: Soheil Eizadi [mailto:seiz...@infoblox.com]
 Sent: Wednesday, April 10, 2013 4:48 PM
 To: dev@cloudstack.apache.org
 Subject: Re: deployDataCenter.py doesn't work for me on master

 I created a zone my host is added but system VM fails to come up, it
looks
 like a previous problem:
 https://issues.apache.org/jira/browse/CLOUDSTACK-1462


 Is this a known problem or a different issue:

 Log:
 INFO  [cloud.configuration.ConfigurationManagerImpl]
 (1887041580@qtp-567506852-8:) No storage traffic type was specified by
 admin, create default storage traffic on physical network 200 with
same
 configure of management traffic type INFO
 [cloud.secstorage.PremiumSecondaryStorageManagerImpl]
 (secstorage-1:) No running secondary storage vms found in datacenter
id=1,
 starting one INFO  [storage.secondary.SecondaryStorageManagerImpl]
 (secstorage-1:) No stopped secondary storage vm is available, need to
 allocate a new secondary storage vm INFO
 [cloud.consoleproxy.ConsoleProxyManagerImpl] (consoleproxy-1:) No
 stopped console proxy is available, need to allocate a new console
proxy
 WARN  [xen.resource.CitrixResourceBase] (DirectAgent-9:)
 destoryVDIbyNameLabel failed due to there are 0 VDIs with name
 cloud-3a35ffe6-7c5c-44ba-98c7-d7f5d6e0f028
 WARN  [xen.resource.CitrixResourceBase] (DirectAgent-9:) can not
create
 vdi in sr f95f52d1-5c00-17ea-a7e5-973ba7b6c0de
 WARN

Re: Associate IP feature request (RE: CLOUDSTACK-1942)

Well, listPublicIpAddress would only return Ip addresses already acquired
via associateIpAddress (unless you are the admin, in which case it will
return all public ips).

On 4/11/13 4:13 AM, prasanna t...@apache.org wrote:

On 11 April 2013 01:08, Ryan Dietrich r...@betterservers.com wrote:
 RE: https://issues.apache.org/jira/browse/CLOUDSTACK-1942

 I added this feature this morning, but before I present the diff to
review board, I'd like to have some feedback on the approach.  I just
want to make sure how I did it is ok from the maintainers perspective so
I'm not wasting anyones time.

 1. Add an optional parameter to
api/src/org/apache/cloudstack/api/command/user/address/AssociateIPAddrCmd
.java allowing you to pass in a UUID of the specific IP you want to add.
 2. Make AssociateIPAddrCmd either use the provided IP or use the
existing getEntity() call it is using now.
 3. Update allocateIP to have a new optional argument, the Long (id)
of IpAddress.
 4. Update the NetworkManager and NetworkService interfaces to include
the new parameter
 5. Update the MockNetworkManager and MockNetworkService implementations
to include the new parameter.
 6. Update the NetworkServiceImplementation to include the new parameter
and pass it through.
 7. Update NetworkManagerImpl: Use the existing functionality of
fetchNewPublicIp and pass in the String requestedIp based on the
Long id of IpAddress (I used ApiDBUtils to fetch the object out and
transform it into a string).

I don't see any problem with the approach.

Re: System VMs Failover

2013-04-11 Thread Kelven Yang

System VMs are tend to be running in stateless mode, instead of fail-over
of same VM, we are launching new instance of them, this behave is done for
storage and console proxy system VM, for virtual router system VM, there
is a redundant configuration, automatic HA would make the redundant
configuration unstable. so in general, system VMs don't use HA offering
purposely.

Kelven

On 4/11/13 7:54 AM, Jeronimo Garcia garciaj...@gmail.com wrote:

Anyone ever bumped into this yet?

Thanks!


On Wed, Apr 10, 2013 at 11:27 AM, Jeronimo Garcia
garciaj...@gmail.comwrote:

 Hi List.

 Based on documentation and what I'm actually seeing now ,  system vms
can
 only failover to other hosts in the same cluster and therefore pod.

 I'm guessing this is because the system vm is using a management ip
 assigned to that specific pod.

 Is there any HA offering that could make system VMs to failover to
 different pods/clusters?

 Thanks!

systemvm.iso does not get copied with mvn jetty:run

Hi Hugo,

With the change 4a7d392f1, the systemvm.iso no longer appears in
cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/classes/vms/systemvm.iso

For 'clean' hypervisors this means that during a developer build and test,
the systemvm.iso is no longer copied over.

I'd like to revert this. I do not understand the intent of the commit, so
I can't fix both issues.


On 4/3/13 5:56 AM, h...@apache.org h...@apache.org wrote:

Updated Branches:
  refs/heads/master 44567453e - 4a7d392f1


Summary: Small changes to the maven phases.

Moved the copy of the systemvm to the package phase as the systemiso is
made during this phase. So in the original config the old systemvm.zip
would be copied to the server.

Add a cleanup to the console-proxy to clean the dist dir during the
clean phase.

Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/4a7d392f
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/4a7d392f
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/4a7d392f

Branch: refs/heads/master
Commit: 4a7d392f18d5720676cbb22174f2a1a3566cd163
Parents: 4456745
Author: Hugo Trippaers htrippa...@schubergphilis.com
Authored: Wed Apr 3 14:55:50 2013 +0200
Committer: Hugo Trippaers htrippa...@schubergphilis.com
Committed: Wed Apr 3 14:55:50 2013 +0200

--
 client/pom.xml|   26 --
 services/console-proxy/server/pom.xml |   12 
 2 files changed, 32 insertions(+), 6 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/cloudstack/blob/4a7d392f/client/pom
.xml
--
diff --git a/client/pom.xml b/client/pom.xml
index ff861b7..9323d0f 100644
--- a/client/pom.xml
+++ b/client/pom.xml
@@ -279,6 +279,26 @@
 artifactIdmaven-antrun-plugin/artifactId
 version1.7/version
 executions
+  !-- Copy the systemvm in the package phase as it is generated
+   by console-proxy in the package phase.
+  --
+  execution
+idcopy-systemvm/id
+phasepackage/phase
+goals
+  goalrun/goal
+/goals
+configuration
+  target
+copy
todir=${basedir}/target/generated-webapp/WEB-INF/classes/vms
+  fileset
dir=${basedir}/../services/console-proxy/server/dist
+include name=systemvm.zip /
+include name=systemvm.iso /
+  /fileset
+/copy
+  /target
+/configuration
+  /execution
   execution
 idgenerate-resource/id
 phasegenerate-resources/phase
@@ -306,12 +326,6 @@
 include name=resources/**/* /
   /fileset
 /copy
-copy
todir=${basedir}/target/generated-webapp/WEB-INF/classes/vms
-  fileset
dir=${basedir}/../services/console-proxy/server/dist
-include name=systemvm.zip /
-include name=systemvm.iso /
-  /fileset
-/copy
 copy todir=${basedir}/target/generated-webapp
   fileset dir=${basedir}/../ui /
 /copy

http://git-wip-us.apache.org/repos/asf/cloudstack/blob/4a7d392f/services/c
onsole-proxy/server/pom.xml
--
diff --git a/services/console-proxy/server/pom.xml
b/services/console-proxy/server/pom.xml
index 0df7559..f57b4ca 100644
--- a/services/console-proxy/server/pom.xml
+++ b/services/console-proxy/server/pom.xml
@@ -139,6 +139,18 @@
   /execution
 /executions
   /plugin
+  plugin
+artifactIdmaven-clean-plugin/artifactId
+version2.5/version
+configuration
+filesets
+fileset
+directorydist/directory
+followSymlinksfalse/followSymlinks
+/fileset
+/filesets
+/configuration
+/plugin
 !-- Leave this to the systemvm profile
  Enable using the -P systemvm flag
   plugin

Re: [ACS41][Patch Request]

On Thu, Apr 11, 2013 at 09:55:38AM -0600, Marcus Sorensen wrote:
 commit ca8ac08cf37cd9ea8a50d323ac596da16319e7ab
 Author: Marcus Sorensen mar...@betterservers.com
 Date:   Thu Apr 11 09:50:48 2013 -0600
 
 CLOUDSTACK-2003: When accounts and domains are deleted, cleanup can
 fail,
 leaving instances in eternal expunged state. This happens when a domain
 is
 deleted while a deleted account is cleaning up. The cleanup looks for
 the domain
 of the account and we hit a null pointer. Adding null pointer check.

Done.  Thanks.

Re: [ACS41][Patch Request]

On Wed, Apr 10, 2013 at 12:28:57PM -0600, Marcus Sorensen wrote:
 This is a follow-up to previous patch request for CLOUDSTACK-1565 that we
 though should go into 4.1
 
 commit 9670553ea85d6593046425f2c040cc08d2e61733
 Author: Marcus Sorensen mar...@betterservers.com
 Date:   Wed Apr 10 12:17:31 2013 -0600
 
 In system vm, wait for interface to be available before configuring
 gateway.
 Previous patch to this only did so for system vms with a $3 interface,
 usually
 eth2. System VMs that only provide DNS wouldn't get a gateway, for
 example.
 
 BUG-ID: CLOUDSTACK-1565
 Signed-off-by: Marcus Sorensen mar...@betterservers.com 1365617851
 -0600

Done

Re: [ACS41][Patch Request]

On Wed, Apr 10, 2013 at 12:39:24PM -0600, Marcus Sorensen wrote:
 commit be55c5b3a58376eb2048a8add155ff09f14e65eb
 Author: Marcus Sorensen mar...@betterservers.com
 Date:   Tue Apr 9 16:26:08 2013 -0600
 
 VPC - new system vm doesn't bring up eth0 reliably, and we don't set
 eth0 to
 auto start like we should.  cloud-early-config sets 'auto lo $1', but
 we don't
 pass $1 in vpc router scenario like we do in others for some reason.
 eth0 is
 always link local in vpc router, so setting it to that.
 
 Signed-off-by: Marcus Sorensen mar...@betterservers.com 1365546368
 -0600

Done.  I noticed some threading problems with these requested, so please
do a quick review of your requested cherry-picks to make sure I got them
all.

Re: [ACS41][Patch Request]

On Wed, Apr 10, 2013 at 11:11:21PM +, Likitha Shetty wrote:
 Branch: refs/heads/master
 Commit: a0b5ebccb814cbb12c5f40aa0c8894ebb3b322d6
 Author: Likitha Shetty likitha.she...@citrix.com
 Date:   Thu Apr 11 04:25:31 2013 +0530
 
 CLOUDSTACK-1988. Attempting to register a AWS API user fails with error code 
 401.
 Fix the code to refer to 
 /usr/share/cloudstack-management/webapps7080/awsapi/WEB-INF/classes.


Done:

commit ac221262c3168d61aec2020c0c4df89f2dbf9509
Author: Likitha Shetty likitha.she...@citrix.com
Date:   Thu Apr 11 04:25:31 2013 +0530

CLOUDSTACK-1988. Attempting to register a AWS API user fails with error 
code 401.
Fix the code to refer to 
/usr/share/cloudstack-management/webapps7080/awsapi/WEB-INF/classes.

Re: [MERGE] ASA 1000v as external firewall in isolated guest networks

On Mon, Apr 08, 2013 at 01:08:42PM +, Koushik Das wrote:
 I would like to merge the feature ASA 1000v as external firewall in isolated 
 guest networks to master. Please find the details here:
 
 Proposal: 
 http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-users/201301.mbox/%3ccd0b6bea.167bb%25manan.s...@citrix.com%3E
 FS: 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cisco+VNMC+integration.
  The supported use cases are the ones mentioned under Use cases - For 4.2.
 Jira: https://issues.apache.org/jira/browse/CLOUDSTACK-742
 Branch: 
 https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=shortlog;h=refs/heads/cisco-vnmc-api-integration
 Unit tests: Added unit tests for relevant network element interfaces (see 
 under plugins/network-elements/cisco-vnmc/test)
 RAT: ran the rat check and all newly added files are clean
 Open issues: Currently there is an issue with source NAT configuration. 
 Following up with Cisco engineers on a private thread to resolve it. I will 
 open a separate ticket to track it.
 
 Thanks,
 Koushik

Any functional tests?

Otherwise LGTM.

Re: deployDataCenter.py doesn't work for me on master

Can you revert 4a7d392f1 in your workspace and rebuild?

On 4/11/13 9:55 AM, Chiradeep Vittal chiradeep.vit...@citrix.com wrote:

Is this the same as
https://issues.apache.org/jira/browse/CLOUDSTACK-183

Check SMLog on the XenServer (I think it is /var/log/SMLog)


On 4/10/13 11:00 PM, Soheil Eizadi seiz...@infoblox.com wrote:

I debugged this further looks like there is problem in my XenServer
creating the VDI, the template vhd that is in the NFS secondary storage
is
good I verified it with vhd-util.

I was using a PreSetup LVM on the XenServer and had this problem, I
switched to using an NFS primary volume and that behaves the same. If I
look at the Primary NFS volume I see the vhd files copied there.
Any ideas what I should look at next to debug this XenServer Storage
Resource problem? My next step would be to stop the MS when the VM is
spawned on the XenServer and figure out why it is not able to run. It
does
not stay around for long, before it is deleted and the MS loops trying to
create it over and over again :(
-Soheil

 System VM state when it fails

[root@xenserver-devcloud ~]# xe vm-list
uuid ( RO) : f45d51c7-9a4f-9c23-7caa-35fc720ac185
name-label ( RW): v-2-VM
power-state ( RO): halted

 MS Exception
2013-04-10 16:19:57,355 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-9:null) can not create vdi in sr
f95f52d1-5c00-17ea-a7e5-973ba7b6c0de
2013-04-10 16:19:57,356 WARN [xen.resource.CitrixResourceBase]
(DirectAgent-9:null) Catch Exception
com.cloud.utils.exception.CloudRuntimeException on
host:f4bc16a9-291c-4d2e-b9f2-d018cabd1a4b for template:
nfs://172.16.197.131/opt/storage/secondary/template/tmpl/1/1/ due to
com.cloud.utils.exception.CloudRuntimeException: can not create vdi in sr
f95f52d1-5c00-17ea-a7e5-973ba7b6c0de
com.cloud.utils.exception.CloudRuntimeException: can not create vdi in sr
f95f52d1-5c00-17ea-a7e5-973ba7b6c0de
at
com.cloud.hypervisor.xen.resource.CitrixResourceBase.copy_vhd_from_second
a
r
ystorage(CitrixResourceBase.java:2914)


 LVM volume when I set it up for primary storage
[root@xenserver-devcloud ~]# xe sr-list
….
uuid ( RO): f95f52d1-5c00-17ea-a7e5-973ba7b6c0de
  name-label ( RW): f95f52d1-5c00-17ea-a7e5-973ba7b6c0de
name-description ( RW): Cloud Stack Local LVM Storage Pool for
f4bc16a9-291c-4d2e-b9f2-d018cabd1a4b
host ( RO): xenserver-devcloud
type ( RO): lvm
content-type ( RO): user
….

 Content of NFS Primary Storage when I started using it instead of
PreSetup/LVM
root@devcloud:/opt/storage/primary# ls
1d780a71-890f-43b1-9786-b5db98e510da.vhd
43c00e22-0001-4d76-9962-f39257494695.vhd
hb-f4bc16a9-291c-4d2e-b9f2-d018cabd1a4b




On 4/10/13 5:02 PM, Soheil Eizadi seiz...@infoblox.com wrote:

I am using the devcloud appliance as my NFS Server, for now I am using a
separate XenServer 6.0.2 host, but would like to use the built in
XenServer in devcloud appliance if that works for development.
-Soheil

Here is what is on that NFS drive right now:
root@devcloud:~# find /opt/storage/secondary/template/
/opt/storage/secondary/template/
/opt/storage/secondary/template/tmpl
/opt/storage/secondary/template/tmpl/1
/opt/storage/secondary/template/tmpl/1/1
/opt/storage/secondary/template/tmpl/1/1/template.properties
/opt/storage/secondary/template/tmpl/1/1/dc68eb4c-228c-4a78-84fa-b80ae17
8
f
b
fd.vhd
/opt/storage/secondary/template/tmpl/1/5
/opt/storage/secondary/template/tmpl/1/5/template.properties
/opt/storage/secondary/template/tmpl/1/5/ce5b212e-215a-3461-94fb-814a635
b
2
2
15.vhd




On 4/10/13 4:51 PM, Edison Su edison...@citrix.com wrote:

Have you pre-install xenserver template on
nfs://172.16.197.131/opt/storage/secondary/template/tmpl/1/1/?

 -Original Message-
 From: Soheil Eizadi [mailto:seiz...@infoblox.com]
 Sent: Wednesday, April 10, 2013 4:48 PM
 To: dev@cloudstack.apache.org
 Subject: Re: deployDataCenter.py doesn't work for me on master

 I created a zone my host is added but system VM fails to come up, it
looks
 like a previous problem:
 https://issues.apache.org/jira/browse/CLOUDSTACK-1462


 Is this a known problem or a different issue:

 Log:
 INFO  [cloud.configuration.ConfigurationManagerImpl]
 (1887041580@qtp-567506852-8:) No storage traffic type was specified
by
 admin, create default storage traffic on physical network 200 with
same
 configure of management traffic type INFO
 [cloud.secstorage.PremiumSecondaryStorageManagerImpl]
 (secstorage-1:) No running secondary storage vms found in datacenter
id=1,
 starting one INFO  [storage.secondary.SecondaryStorageManagerImpl]
 (secstorage-1:) No stopped secondary storage vm is available, need to
 allocate a new secondary storage vm INFO
 [cloud.consoleproxy.ConsoleProxyManagerImpl] (consoleproxy-1:) No
 stopped console proxy is available, need to allocate a new console
proxy
 WARN  [xen.resource.CitrixResourceBase] (DirectAgent-9:)
 destoryVDIbyNameLabel failed due to there are 0 VDIs with name

Re: [MERGE] Dedicate Public IP Addresses

On Tue, Apr 09, 2013 at 05:23:05PM +, Likitha Shetty wrote:
 Hi all,
 
 I would like to merge the feature Dedicate Public IP ranges to master.
 
 Jira ticket - https://issues.apache.org/jira/browse/CLOUDSTACK-704 
 Proposal discussion - 
 http://mail-archives.apache.org/mod_mbox/incubator-cloudstack-users/201303.mbox/%3C64FB1554ABC9B44FAA773FBD6CB889C2010D9C03119B%40BANPMAILBOX01.citrite.net%3E
  
 FS - 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS-+Dedicate+Public+IP+Addresses+per+tenant
  
 Branch - dedicate_public_ip_range_2
 Unit tests -  Unit tests for the new API's can be found at 
 cloudstack/server/test/com/cloud/configuration/ConfigurationManagerTest.java
 Integration tests - Python tests can be found be found at 
 test/integration/component/test_public_ip_range.py
 Rebased the branch with master - Commit id: 
 d5d167cb97b95f5622c0e34fe4546642484016f6
 RAT report - Attached
 Patch is available at - https://reviews.apache.org/r/10377/ 
 
 Thanks,
 Likitha

+1 - this is a great merge

RE: [DISCUSS] Don't assign tickets to people when triaging

 -Original Message-
 From: Chip Childers [mailto:chip.child...@sungard.com]
 Sent: Thursday, April 11, 2013 7:40 AM
 To: dev@cloudstack.apache.org
 Subject: Re: [DISCUSS] Don't assign tickets to people when triaging

 On Thu, Apr 11, 2013 at 12:51:34PM +, Abhinandan Prateek wrote:
  Yes, I think we need to space our releases further apart.

 That's a different discussion, which you are free to raise if you'd like.

  Also community members should volunteer to own some part so that in
 above circumstances a person looking for some fix can approach that
 member, once again a suggestion.

 I've been reading through this thread, and I'll pick the owner comment
 above as a starting point for my personal opinions.  This is a reaction to the
 whole thread really, so take a minute to read to the end please.

 Owning some part is antithetical to a healthy community approach.
 Certainly people will gravitate to certain areas, and by all means everyone
 should feel free to work on areas of the code-base that they feel like they
 want to improve or support.  This may lead to people effectively being the
 primary do-er for certain areas (examples: Wido has been working on DEB
 packaging, Rohit has been working on CloudMonkey), but we shouldn't ever
 consider this ownership. I feel personally welcome to make a change in
 CloudMonkey, and would certainly consider it important to collaborate with
 anyone (especially Rohit) that may have input and insights.

 The idea of ownership if a part of the software is something I'm strongly
 against.

 Even the idea of maintainers seems like it is problematic in implementation.
 How do we decide who the official maintainer is?  How do we decide when
 someone else should do that... And frankly, doesn't a maintainer model
 really discourage others from working in named areas?

 [Animesh] +1,  that is the reason Apache projects do not use @author tag. I 
take back my original argument of auto-assigning based on maintainers list. I 
did a search but did not find any community using auto-assignment. The 
community argument  wins.

 All of these attempts to structure the community appear to be natural
 responses when you have a background in corporate development (product
 or otherwise), which is my background as well.  It doesn't work here, and you
 have to fight the urge to apply the same solutions (WRT structure and
 process) in this environment.  If you haven't read Producing OSS [1], go do
 that.

 What we really need is for those individuals that are interested in
 participating in this community to actively participate.  Read the ML, take on
 bugs, focus on the shared community release goals.  If you consider yourself
 interested in this project, then don't wait for assignments from someone
 else.  Watch the lists, notice areas where you can help, discuss if you 
 disagree
 with proposed community goals as they are being formed.

 Personal responsibility and interest in contributing to the shared community
 goals is what we should all expect of each other. We should not expect that
 others in the community will spoon feed tasks out. If that happens within
 someone's $dayjob, that's not a community concern.

 You'll notice that I have rarely assigned a bug.  In a couple of instances, 
 I've
 pushed something to someone that I know is *actively* working in an area of
 the code.  I've also assigned a bug as purely an administrative step, when I
 know someone is already working on the issue, but may not have had the
 time to assign the bug to themselves.  Release blockers that I don't easily
 associated with some ongoing and known work are highlighted in emails,
 with a request for someone to grab them.

 Releases are the shared goals of the community, but building a strong
 community is more important than any specific release.  That's why this
 conversation started really.

 So yes, I want blockers to be addressed.  Yes, I want us to get our releases
 out.  Yes, I'd like us to be close to our proposed schedules.
 No, I'm not willing to have a release take priority over the more important
 goal of building a stronger and stronger community.

[Animesh] +1 I have read [1] cover to cover a few times already but looks like 
it is taking in longer to sink in but I think I will get there.

 -chip

 [1] http://www.producingoss.com/

RE: [DISCUSS] Don't assign tickets to people when triaging

 -Original Message-
 From: Joe Brockmeier [mailto:j...@zonker.net]
 Sent: Thursday, April 11, 2013 7:34 AM
 To: dev@cloudstack.apache.org
 Subject: Re: [DISCUSS] Don't assign tickets to people when triaging

 On Thu, Apr 11, 2013, at 09:28 AM, Noah Slater wrote:
  To me, it seems like what you're describing are components. You assign
  or sort the ticket into a component. Then I guess, people who are
  interested can watch that component for new issues. I am not sure if
  there's a way to watch a component in JIRA so that you get email
  notifications for it. I took a look, but couldn't find anything.
  Perhaps Infra would install a plugin for us. (I noticed that at least
  one such plugin exists.) At the very least, you could save a report as
  a favourite...

 Triaging tickets into components, and making sure that new tickets are
 appropriately categorized, should be fine.

 I don't know if there's specifically a watch feature for a component, but 
 it's
 easy enough to bookmark a search for a specific component and look
 through the tickets.

 Best,

 jzb
[Animesh] We can create shared filters based on components. Folks can 
subscribe to the filters to be notified by email as per their schedule [1]. By 
default one can only create Personal Subscriptions but folks with 'Manage Group 
Filter Subscriptions'  privilege can set up the subscription be sent to  a 
group as well. I have requested INFRA to grant me the privilege, I will try it 
once I get the privilege and update the community on findings.

[1[]https://confluence.atlassian.com/display/JIRA/Receiving+Search+Results+via+Email

Re: System VMs Failover

2013-04-11 Thread Jeronimo Garcia

Hi.

Thanks for your answer .
System vms images are normally in secondary storage ,  and currently i have
3 pods and one and only secondary storage nfs system,

When i shut down all the servers on POD1 ,  the system vms refused to
launch in pod2 ,  would it be cause Pod2 has to have it's own secondary
storage.

Thanks!


On Thu, Apr 11, 2013 at 12:08 PM, Kelven Yang kelven.y...@citrix.comwrote:

 System VMs are tend to be running in stateless mode, instead of fail-over
 of same VM, we are launching new instance of them, this behave is done for
 storage and console proxy system VM, for virtual router system VM, there
 is a redundant configuration, automatic HA would make the redundant
 configuration unstable. so in general, system VMs don't use HA offering
 purposely.

 Kelven

 On 4/11/13 7:54 AM, Jeronimo Garcia garciaj...@gmail.com wrote:

 Anyone ever bumped into this yet?
 
 Thanks!
 
 
 On Wed, Apr 10, 2013 at 11:27 AM, Jeronimo Garcia
 garciaj...@gmail.comwrote:
 
  Hi List.
 
  Based on documentation and what I'm actually seeing now ,  system vms
 can
  only failover to other hosts in the same cluster and therefore pod.
 
  I'm guessing this is because the system vm is using a management ip
  assigned to that specific pod.
 
  Is there any HA offering that could make system VMs to failover to
  different pods/clusters?
 
  Thanks!

[JENKINS] Possible problem with Release Notes build setup

Chip pointed out that the Jenkins process for the release notes in 4.1
was failing, but it looks like a problem with the job rather than the
actual docs being busted. 

See ticket CLOUDSTACK-2007
(https://issues.apache.org/jira/browse/CLOUDSTACK-2007). 

Can someone with Jenkins access/wizardry take a look at this? 

The build works locally, but it looks like it may be a problem with the
update to common_content recently. 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: systemvm.iso does not get copied with mvn jetty:run

Yes!

From: Hugo h...@trippaers.nlmailto:h...@trippaers.nl
Date: Thursday, April 11, 2013 11:52 AM
To: Chiradeep Vittal 
chiradeep.vit...@citrix.commailto:chiradeep.vit...@citrix.com
Cc: dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org 
dev@cloudstack.apache.orgmailto:dev@cloudstack.apache.org, 
h...@apache.orgmailto:h...@apache.org 
h...@apache.orgmailto:h...@apache.org
Subject: Re: systemvm.iso does not get copied with mvn jetty:run

Just noticed Kelvens commit f35272b6c585f85c5c0f1e92f99b8224feceb29e

That fixed it right?

Cheers,

Hugo


On Thu, Apr 11, 2013 at 8:46 PM, Hugo Trippaers 
trip...@gmail.commailto:trip...@gmail.com wrote:
Ouch. I'll try and fix that. Without this commit it would use the systemvm.iso 
from the previous compile, which is also bad.

Probably some tweaking in the phases should be ok.

Cheers,

Hugo

Sent from my iPhone

On 11 apr. 2013, at 19:33, Chiradeep Vittal 
chiradeep.vit...@citrix.commailto:chiradeep.vit...@citrix.com wrote:

 Hi Hugo,

 With the change 4a7d392f1, the systemvm.iso no longer appears in
 cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/classes/vms/systemvm.iso

 For 'clean' hypervisors this means that during a developer build and test,
 the systemvm.iso is no longer copied over.

 I'd like to revert this. I do not understand the intent of the commit, so
 I can't fix both issues.


 On 4/3/13 5:56 AM, h...@apache.orgmailto:h...@apache.org 
 h...@apache.orgmailto:h...@apache.org wrote:

 Updated Branches:
 refs/heads/master 44567453e - 4a7d392f1


 Summary: Small changes to the maven phases.

 Moved the copy of the systemvm to the package phase as the systemiso is
 made during this phase. So in the original config the old systemvm.zip
 would be copied to the server.

 Add a cleanup to the console-proxy to clean the dist dir during the
 clean phase.

 Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
 Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/4a7d392f
 Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/4a7d392f
 Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/4a7d392f

 Branch: refs/heads/master
 Commit: 4a7d392f18d5720676cbb22174f2a1a3566cd163
 Parents: 4456745
 Author: Hugo Trippaers 
 htrippa...@schubergphilis.commailto:htrippa...@schubergphilis.com
 Authored: Wed Apr 3 14:55:50 2013 +0200
 Committer: Hugo Trippaers 
 htrippa...@schubergphilis.commailto:htrippa...@schubergphilis.com
 Committed: Wed Apr 3 14:55:50 2013 +0200

 --
 client/pom.xml|   26 --
 services/console-proxy/server/pom.xml |   12 
 2 files changed, 32 insertions(+), 6 deletions(-)
 --


 http://git-wip-us.apache.org/repos/asf/cloudstack/blob/4a7d392f/client/pom
 .xml
 --
 diff --git a/client/pom.xml b/client/pom.xml
 index ff861b7..9323d0f 100644
 --- a/client/pom.xml
 +++ b/client/pom.xml
 @@ -279,6 +279,26 @@
artifactIdmaven-antrun-plugin/artifactId
version1.7/version
executions
 +  !-- Copy the systemvm in the package phase as it is generated
 +   by console-proxy in the package phase.
 +  --
 +  execution
 +idcopy-systemvm/id
 +phasepackage/phase
 +goals
 +  goalrun/goal
 +/goals
 +configuration
 +  target
 +copy
 todir=${basedir}/target/generated-webapp/WEB-INF/classes/vms
 +  fileset
 dir=${basedir}/../services/console-proxy/server/dist
 +include name=systemvm.zip /
 +include name=systemvm.iso /
 +  /fileset
 +/copy
 +  /target
 +/configuration
 +  /execution
  execution
idgenerate-resource/id
phasegenerate-resources/phase
 @@ -306,12 +326,6 @@
include name=resources/**/* /
  /fileset
/copy
 -copy
 todir=${basedir}/target/generated-webapp/WEB-INF/classes/vms
 -  fileset
 dir=${basedir}/../services/console-proxy/server/dist
 -include name=systemvm.zip /
 -include name=systemvm.iso /
 -  /fileset
 -/copy
copy todir=${basedir}/target/generated-webapp
  fileset dir=${basedir}/../ui /
/copy

 http://git-wip-us.apache.org/repos/asf/cloudstack/blob/4a7d392f/services/c
 onsole-proxy/server/pom.xml
 --
 diff --git a/services/console-proxy/server/pom.xml
 b/services/console-proxy/server/pom.xml
 index 0df7559..f57b4ca 100644
 --- a/services/console-proxy/server/pom.xml
 +++

Re: systemvm.iso does not get copied with mvn jetty:run

2013-04-11 Thread Hugo

Just noticed Kelvens commit f35272b6c585f85c5c0f1e92f99b8224feceb29e

That fixed it right?

Cheers,

Hugo


On Thu, Apr 11, 2013 at 8:46 PM, Hugo Trippaers trip...@gmail.com wrote:

 Ouch. I'll try and fix that. Without this commit it would use the
 systemvm.iso from the previous compile, which is also bad.

 Probably some tweaking in the phases should be ok.

 Cheers,

 Hugo

 Sent from my iPhone

 On 11 apr. 2013, at 19:33, Chiradeep Vittal chiradeep.vit...@citrix.com
 wrote:

  Hi Hugo,
 
  With the change 4a7d392f1, the systemvm.iso no longer appears in
  cloud-client-ui-4.2.0-SNAPSHOT/WEB-INF/classes/vms/systemvm.iso
 
  For 'clean' hypervisors this means that during a developer build and
 test,
  the systemvm.iso is no longer copied over.
 
  I'd like to revert this. I do not understand the intent of the commit, so
  I can't fix both issues.
 
 
  On 4/3/13 5:56 AM, h...@apache.org h...@apache.org wrote:
 
  Updated Branches:
  refs/heads/master 44567453e - 4a7d392f1
 
 
  Summary: Small changes to the maven phases.
 
  Moved the copy of the systemvm to the package phase as the systemiso is
  made during this phase. So in the original config the old systemvm.zip
  would be copied to the server.
 
  Add a cleanup to the console-proxy to clean the dist dir during the
  clean phase.
 
  Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo
  Commit:
 http://git-wip-us.apache.org/repos/asf/cloudstack/commit/4a7d392f
  Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/4a7d392f
  Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/4a7d392f
 
  Branch: refs/heads/master
  Commit: 4a7d392f18d5720676cbb22174f2a1a3566cd163
  Parents: 4456745
  Author: Hugo Trippaers htrippa...@schubergphilis.com
  Authored: Wed Apr 3 14:55:50 2013 +0200
  Committer: Hugo Trippaers htrippa...@schubergphilis.com
  Committed: Wed Apr 3 14:55:50 2013 +0200
 
  --
  client/pom.xml|   26 --
  services/console-proxy/server/pom.xml |   12 
  2 files changed, 32 insertions(+), 6 deletions(-)
  --
 
 
 
 http://git-wip-us.apache.org/repos/asf/cloudstack/blob/4a7d392f/client/pom
  .xml
  --
  diff --git a/client/pom.xml b/client/pom.xml
  index ff861b7..9323d0f 100644
  --- a/client/pom.xml
  +++ b/client/pom.xml
  @@ -279,6 +279,26 @@
 artifactIdmaven-antrun-plugin/artifactId
 version1.7/version
 executions
  +  !-- Copy the systemvm in the package phase as it is
 generated
  +   by console-proxy in the package phase.
  +  --
  +  execution
  +idcopy-systemvm/id
  +phasepackage/phase
  +goals
  +  goalrun/goal
  +/goals
  +configuration
  +  target
  +copy
  todir=${basedir}/target/generated-webapp/WEB-INF/classes/vms
  +  fileset
  dir=${basedir}/../services/console-proxy/server/dist
  +include name=systemvm.zip /
  +include name=systemvm.iso /
  +  /fileset
  +/copy
  +  /target
  +/configuration
  +  /execution
   execution
 idgenerate-resource/id
 phasegenerate-resources/phase
  @@ -306,12 +326,6 @@
 include name=resources/**/* /
   /fileset
 /copy
  -copy
  todir=${basedir}/target/generated-webapp/WEB-INF/classes/vms
  -  fileset
  dir=${basedir}/../services/console-proxy/server/dist
  -include name=systemvm.zip /
  -include name=systemvm.iso /
  -  /fileset
  -/copy
 copy todir=${basedir}/target/generated-webapp
   fileset dir=${basedir}/../ui /
 /copy
 
 
 http://git-wip-us.apache.org/repos/asf/cloudstack/blob/4a7d392f/services/c
  onsole-proxy/server/pom.xml
  --
  diff --git a/services/console-proxy/server/pom.xml
  b/services/console-proxy/server/pom.xml
  index 0df7559..f57b4ca 100644
  --- a/services/console-proxy/server/pom.xml
  +++ b/services/console-proxy/server/pom.xml
  @@ -139,6 +139,18 @@
   /execution
 /executions
   /plugin
  +  plugin
  +artifactIdmaven-clean-plugin/artifactId
  +version2.5/version
  +configuration
  +filesets
  +fileset
  +directorydist/directory
  +followSymlinksfalse/followSymlinks
  +/fileset
  +/filesets
  +/configuration
  +/plugin
  !-- Leave this to the systemvm profile

Re: Review Request: Remove 2k limitation for user data on a deployVMCmd issued as an HTTP POST request


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



server/src/com/cloud/vm/UserVmManagerImpl.java
https://reviews.apache.org/r/10294/#comment39551

Based on your comment, for GET, maxBytes = 4K, for POST, maxBytes = 32K. 
Why not define these constants instead of an intermediate 
MAX_USER_DATA_LENGTH_BYTES and do some math calculation here? This code is hard 
to maintain later in case that http length standard changes later.



server/test/com/cloud/vm/dao/UserVmDaoImplTest.java
https://reviews.apache.org/r/10294/#comment39553

This test only tests database persistence. We may need another automated 
test to issue a POST request.



server/test/com/cloud/vm/dao/UserVmDaoTestConfiguration.java
https://reviews.apache.org/r/10294/#comment39552

Where are UserVmDaoTestConfiguration used in your test? You are missing 
some Spring Junit annotation in your UserVmDaoImplTest.


- Min Chen


On April 10, 2013, 9:59 p.m., Venkata Siva Vijayendra Bhamidipati wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/10294/
 ---
 
 (Updated April 10, 2013, 9:59 p.m.)
 
 
 Review request for cloudstack, Chip Childers, Hugo Trippaers, Kelven Yang, 
 and Min Chen.
 
 
 Description
 ---
 
 Please refer to 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/DeployVirtualMachine+userdata+enhancements
  for a background on the requirements driving this patch.
 
 This patch hasn't been extensively tested yet, and I will update this request 
 with more info. I am uploading a first diff for initial review/comments.
 
 
 This addresses bug CLOUDSTACK-1086.
 
 
 Diffs
 -
 
   api/src/com/cloud/vm/UserVmService.java 2c33d41 
   api/src/org/apache/cloudstack/api/BaseCmd.java 8fef422 
   api/src/org/apache/cloudstack/api/command/user/vm/DeployVMCmd.java 21a45f8 
   core/src/com/cloud/vm/UserVmVO.java a16eaf9 
   server/src/com/cloud/api/ApiDispatcher.java 925d90a 
   server/src/com/cloud/api/ApiServer.java d842819 
   server/src/com/cloud/api/ApiServerService.java 12d8b52 
   server/src/com/cloud/api/ApiServlet.java 03bfb5f 
   server/src/com/cloud/vm/UserVmManagerImpl.java 1c3764a 
   server/test/com/cloud/vm/MockUserVmManagerImpl.java dd8dd83 
   server/test/com/cloud/vm/dao/UserVmDaoImplTest.java 0936180 
   server/test/com/cloud/vm/dao/UserVmDaoTestConfiguration.java PRE-CREATION 
   server/test/resources/UserVMDaoTestContext.xml PRE-CREATION 
   setup/db/db/schema-410to420.sql c7c8b5b 
 
 Diff: https://reviews.apache.org/r/10294/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Venkata Siva Vijayendra Bhamidipati

Re: Review Request: Remove 2k limitation for user data on a deployVMCmd issued as an HTTP POST request


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


In your description, you mentioned that it is not extensively tested yet. Is 
this still true? If not, please revise your description to avoid confusing 
people.

- Min Chen


On April 10, 2013, 9:59 p.m., Venkata Siva Vijayendra Bhamidipati wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/10294/
 ---
 
 (Updated April 10, 2013, 9:59 p.m.)
 
 
 Review request for cloudstack, Chip Childers, Hugo Trippaers, Kelven Yang, 
 and Min Chen.
 
 
 Description
 ---
 
 Please refer to 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/DeployVirtualMachine+userdata+enhancements
  for a background on the requirements driving this patch.
 
 This patch hasn't been extensively tested yet, and I will update this request 
 with more info. I am uploading a first diff for initial review/comments.
 
 
 This addresses bug CLOUDSTACK-1086.
 
 
 Diffs
 -
 
   api/src/com/cloud/vm/UserVmService.java 2c33d41 
   api/src/org/apache/cloudstack/api/BaseCmd.java 8fef422 
   api/src/org/apache/cloudstack/api/command/user/vm/DeployVMCmd.java 21a45f8 
   core/src/com/cloud/vm/UserVmVO.java a16eaf9 
   server/src/com/cloud/api/ApiDispatcher.java 925d90a 
   server/src/com/cloud/api/ApiServer.java d842819 
   server/src/com/cloud/api/ApiServerService.java 12d8b52 
   server/src/com/cloud/api/ApiServlet.java 03bfb5f 
   server/src/com/cloud/vm/UserVmManagerImpl.java 1c3764a 
   server/test/com/cloud/vm/MockUserVmManagerImpl.java dd8dd83 
   server/test/com/cloud/vm/dao/UserVmDaoImplTest.java 0936180 
   server/test/com/cloud/vm/dao/UserVmDaoTestConfiguration.java PRE-CREATION 
   server/test/resources/UserVMDaoTestContext.xml PRE-CREATION 
   setup/db/db/schema-410to420.sql c7c8b5b 
 
 Diff: https://reviews.apache.org/r/10294/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Venkata Siva Vijayendra Bhamidipati

Re: [HA][ACS]Running Multiple CS Management hosts under LB

2013-04-11 Thread Ahmad Emneina

this is outlined in the installation guide under section: 4.5.6. Prepare
and Start Additional Management Servers. usually fronted by a load balancer
with a session/sticky policy.


On Thu, Apr 11, 2013 at 1:00 PM, Musayev, Ilya imusa...@webmd.net wrote:

 I recall watching one of the videos on youtube where Chiradeep mentioned
 that CS Management service is stateless and you can run multiple CS MS
 connected to MySQL DB.

 We need to setup High Availability hopefully Active/Active for CloudStack
 Management hosts.

 With that in mind, I'm curious if anyone has it working in active/active
 setup.

 Thanks
 ilya

RE: [MERGE] affinity_groups branch to master

2013-04-11 Thread Prachi Damle

This is now merged to master.

Thanks,
Prachi

-Original Message-
From: Chip Childers [mailto:chip.child...@sungard.com] 
Sent: Wednesday, April 10, 2013 10:54 AM
To: dev@cloudstack.apache.org
Subject: Re: [MERGE] affinity_groups branch to master

On Fri, Apr 05, 2013 at 05:26:15PM -0700, Prachi Damle wrote:
 Hi all,
 
 I would like to merge the Affinity/Anti-Affinity feature developed in 
 affinity_groups branch to master.
 
 
 -  Functional Specs for this feature can be found here: 
 https://cwiki.apache.org/confluence/display/CLOUDSTACK/FS+-+Affinity-Anti-affinity+groups
 
 
 
 -  How to use this feature? FS has a 'Use cases' section that 
 outlines this.
 
 
 
 -  Jira ticket for the same is: 
 https://issues.apache.org/jira/browse/CLOUDSTACK-739
 
 
 
 -  Unit tests:  For the new APIs and Service, added a unit test under 
 cloud-server/test/org/apache/loudstack/affinity/AffinityApiUnitTest.java
 
 
 
 -  Integration tests: Added python test using marvin here:  
 cloud-tools/marvin/marvin/sandbox/demo/live/ testDeployVMWithAffinityGroup.py
 
 
 
 -  I have rebased the branch with master Commit hash: 
 1274d8f68a7d5961d8fc363d8a4952dd6835c252
 
 
 
 -  Attached is the RAT report.
 
 Thanks,
 -Prachi

+1 to this merge.  Thanks for all the specifics!

Re: [ACS41] Help needed clearing bugs!

2013-04-11 Thread Kelven Yang

about CLOUDSTACK-1978, it looks like the problem at hypervsor host side,
the hypervisor host is either failed to setup the VNC listening interface
or failed to configure firewall properly, could KVM developer pick this
up(I assume it is KVM hypervisor)?

Kelven

On 4/11/13 2:11 PM, Chip Childers chip.child...@sungard.com wrote:

Hi all,

I need your help clearing out the following bugs...  if you have one
assigned to you, please see if you can get it completed.  If you have
any time available, and think you can help resolve one of the unassigned
ones, please jump in!  We're obviously behind the schedule that we set
for ourselves, so I'd love to see the community come together for a
final push to get 4.1.0 out the door.

CLOUDSTACK-2007 Release Notes failing to build on jenkins.cs.o
Currently unassigned - Joe looked into it, and he thinks this is a
build server issue.  Can someone please take a look?

CLOUDSTACK-1934 NPE with listSupportedNetworkServices after upgrade from
4.0 to 4.1 (Ubuntu MS)
Unassigned

CLOUDSTACK-1978 openvswitch - unable to start console session for SSVM
CPVM user VMs
Unassigned

CLOUDSTACK-1987 Deleted service offerings owned by a domain show up to
domain users
Unassigned

CLOUDSTACK-1997 Upload and Document IPV6 specific system templates.
Unassigned - Who wants to host the template (wido?), and then we need to
add it to the IPv6 docs.

Last but not least, we still need to wrap up any final docs (including
Release Notes, which I consider a blocker right now).  Joe, do you want
/ need help with the Release Notes?  Other doc folks, anything that's in
progress that we can get over the line would be appreciated.  The same
goes for translations that may be outstanding...

Let's get 4.1.0 out!

-chip

[ASFCS42] Proposed schedule for our next release

Based on the community discussions of having 4 month cadence I am proposing the 
following schedule:

=
 4.2 detailed schedule proposal:
 =


 2013-05-31
   Feature Freeze
   All new feature need to have been merged into master by this date.
   Release branch will be cut on this date.
   Jenkins updated to include new release branch builds.
 
 2013-06-01 through 2013-06-30
   Testing/Bug Fixes (testing against jenkins artifacts)
   Documentation Finalization
 
 2013-06-30
   Docs Freeze (except release notes and translations)
   Release Branch moves to limited updates only (only commits allowed
 in would be release blockers fixes, translation updates, etc...)
 
 2013-07-01 through 2013-07-22
   Translation Development and Integration (should be ongoing, but
 focused effort)
   Final regression testing / bug fixes / doc fixes
 
 2013-07-22
   4.2.0-RC1 is created, and project level VOTE is called


I want to call out my concern on technical debt we have accumulated so far.

 I did an analysis on JIRA bugs yesterday night PST on Affects Version = 4.1 
and created since Dec 2012 

Total records : 429
Resolution Type (Invalid, Duplicate, Cannot reproduce etc.) : 87 (30 Blockers, 
27 Critical, 27 Major, 4 Minor)
Valid Defects  : 429-87= 342
Fixed : 246 (60 Blockers, 70 Critical, 99 Majors) out of which 217 were fixed 
since Feb
Unresolved : 96 (1 Blocker, 8 Critical, 64 Major)

With this data it looks like we have fixed 2/3 of valid defects in little over 
2 months and pretty much deferring around 1/3 rd of issues for future release.

I also looked at overall backlog of bugs (Critical, Major and Blockers only)  
as of 4/10/2013 - 10:0PM PST. 

284 open (18 Blocker, 38 Critical, 228 Major) ; 
By Fix version
-  Release 4.0.x and prior: 13
-  4.1: 70
-  4.2 : 97
-  Future: 8
-  No version: 107

Looking at that we fixed 217 bugs in roughly 2 months during 4.1 cycle,  fixing 
the backlog of bug  will probably take us 2 months.  Should we extend the 4.2 
test cycle by 2 months [Original Schedule: 6/1 - 7/22, Extended Schedule: 
6/1-9/22] to reduce the technical debt significantly? I would like to hear how 
community wants to address technical debt. Based on the input and consensus I 
will publish the agreed schedule next week.


Thanks
Animesh

Re: [ACS41] Help needed clearing bugs!

2013-04-11 Thread Ryan Dietrich

I believe I have a fix for CLOUDSTACK-1987.

https://reviews.apache.org/r/10426/

On Apr 11, 2013, at 3:40 PM, Kelven Yang kelven.y...@citrix.com wrote:

 about CLOUDSTACK-1978, it looks like the problem at hypervsor host side,
 the hypervisor host is either failed to setup the VNC listening interface
 or failed to configure firewall properly, could KVM developer pick this
 up(I assume it is KVM hypervisor)?
 
 Kelven
 
 On 4/11/13 2:11 PM, Chip Childers chip.child...@sungard.com wrote:
 
 Hi all,
 
 I need your help clearing out the following bugs...  if you have one
 assigned to you, please see if you can get it completed.  If you have
 any time available, and think you can help resolve one of the unassigned
 ones, please jump in!  We're obviously behind the schedule that we set
 for ourselves, so I'd love to see the community come together for a
 final push to get 4.1.0 out the door.
 
 CLOUDSTACK-2007 Release Notes failing to build on jenkins.cs.o
 Currently unassigned - Joe looked into it, and he thinks this is a
 build server issue.  Can someone please take a look?
 
 CLOUDSTACK-1934 NPE with listSupportedNetworkServices after upgrade from
 4.0 to 4.1 (Ubuntu MS)
 Unassigned
 
 CLOUDSTACK-1978 openvswitch - unable to start console session for SSVM
 CPVM user VMs
 Unassigned
 
 CLOUDSTACK-1987 Deleted service offerings owned by a domain show up to
 domain users
 Unassigned
 
 CLOUDSTACK-1997 Upload and Document IPV6 specific system templates.
 Unassigned - Who wants to host the template (wido?), and then we need to
 add it to the IPv6 docs.
 
 Last but not least, we still need to wrap up any final docs (including
 Release Notes, which I consider a blocker right now).  Joe, do you want
 / need help with the Release Notes?  Other doc folks, anything that's in
 progress that we can get over the line would be appreciated.  The same
 goes for translations that may be outstanding...
 
 Let's get 4.1.0 out!
 
 -chip

Re: [ACS41] Help needed clearing bugs!

I haven't even touched openvswitch, or I'd take a look at 1978. Is that a
prerequisite for duplicating the issue?
On Apr 11, 2013 3:41 PM, Kelven Yang kelven.y...@citrix.com wrote:

 about CLOUDSTACK-1978, it looks like the problem at hypervsor host side,
 the hypervisor host is either failed to setup the VNC listening interface
 or failed to configure firewall properly, could KVM developer pick this
 up(I assume it is KVM hypervisor)?

 Kelven

 On 4/11/13 2:11 PM, Chip Childers chip.child...@sungard.com wrote:

 Hi all,
 
 I need your help clearing out the following bugs...  if you have one
 assigned to you, please see if you can get it completed.  If you have
 any time available, and think you can help resolve one of the unassigned
 ones, please jump in!  We're obviously behind the schedule that we set
 for ourselves, so I'd love to see the community come together for a
 final push to get 4.1.0 out the door.
 
 CLOUDSTACK-2007 Release Notes failing to build on jenkins.cs.o
 Currently unassigned - Joe looked into it, and he thinks this is a
 build server issue.  Can someone please take a look?
 
 CLOUDSTACK-1934 NPE with listSupportedNetworkServices after upgrade from
 4.0 to 4.1 (Ubuntu MS)
 Unassigned
 
 CLOUDSTACK-1978 openvswitch - unable to start console session for SSVM
 CPVM user VMs
 Unassigned
 
 CLOUDSTACK-1987 Deleted service offerings owned by a domain show up to
 domain users
 Unassigned
 
 CLOUDSTACK-1997 Upload and Document IPV6 specific system templates.
 Unassigned - Who wants to host the template (wido?), and then we need to
 add it to the IPv6 docs.
 
 Last but not least, we still need to wrap up any final docs (including
 Release Notes, which I consider a blocker right now).  Joe, do you want
 / need help with the Release Notes?  Other doc folks, anything that's in
 progress that we can get over the line would be appreciated.  The same
 goes for translations that may be outstanding...
 
 Let's get 4.1.0 out!
 
 -chip

RE: [ACS41] Help needed clearing bugs!

2013-04-11 Thread Edison Su

Probably, it's a setup issue, e.g openvswitch doesn't work. I'll take a look 
QA's environment, if it's still there.

 -Original Message-
 From: Marcus Sorensen [mailto:shadow...@gmail.com]
 Sent: Thursday, April 11, 2013 5:12 PM
 To: dev@cloudstack.apache.org
 Subject: Re: [ACS41] Help needed clearing bugs!

 I haven't even touched openvswitch, or I'd take a look at 1978. Is that a
 prerequisite for duplicating the issue?
 On Apr 11, 2013 3:41 PM, Kelven Yang kelven.y...@citrix.com wrote:

  about CLOUDSTACK-1978, it looks like the problem at hypervsor host
  side, the hypervisor host is either failed to setup the VNC listening
  interface or failed to configure firewall properly, could KVM
  developer pick this up(I assume it is KVM hypervisor)?

  Kelven

  On 4/11/13 2:11 PM, Chip Childers chip.child...@sungard.com wrote:

  Hi all,

  I need your help clearing out the following bugs...  if you have one
  assigned to you, please see if you can get it completed.  If you have
  any time available, and think you can help resolve one of the
  unassigned ones, please jump in!  We're obviously behind the schedule
  that we set for ourselves, so I'd love to see the community come
  together for a final push to get 4.1.0 out the door.

  CLOUDSTACK-2007 Release Notes failing to build on jenkins.cs.o
  Currently unassigned - Joe looked into it, and he thinks this is a
  build server issue.  Can someone please take a look?

  CLOUDSTACK-1934 NPE with listSupportedNetworkServices after upgrade
  from
  4.0 to 4.1 (Ubuntu MS)
  Unassigned

  CLOUDSTACK-1978 openvswitch - unable to start console session for
  SSVM CPVM user VMs Unassigned

  CLOUDSTACK-1987 Deleted service offerings owned by a domain show up
  to domain users Unassigned

  CLOUDSTACK-1997 Upload and Document IPV6 specific system templates.
  Unassigned - Who wants to host the template (wido?), and then we need
  to add it to the IPv6 docs.

  Last but not least, we still need to wrap up any final docs
  (including Release Notes, which I consider a blocker right now).
  Joe, do you want / need help with the Release Notes?  Other doc
  folks, anything that's in progress that we can get over the line
  would be appreciated.  The same goes for translations that may be
 outstanding...

  Let's get 4.1.0 out!

  -chip

RE: [ACS41] Help needed clearing bugs!

2013-04-11 Thread Prachi Damle

I will take a look at CLOUDSTACK-1987.

-Prachi

-Original Message-
From: Edison Su [mailto:edison...@citrix.com] 
Sent: Thursday, April 11, 2013 5:17 PM
To: dev@cloudstack.apache.org
Subject: RE: [ACS41] Help needed clearing bugs!

Probably, it's a setup issue, e.g openvswitch doesn't work. I'll take a look 
QA's environment, if it's still there.

 -Original Message-
 From: Marcus Sorensen [mailto:shadow...@gmail.com]
 Sent: Thursday, April 11, 2013 5:12 PM
 To: dev@cloudstack.apache.org
 Subject: Re: [ACS41] Help needed clearing bugs!

 I haven't even touched openvswitch, or I'd take a look at 1978. Is 
 that a prerequisite for duplicating the issue?
 On Apr 11, 2013 3:41 PM, Kelven Yang kelven.y...@citrix.com wrote:

  about CLOUDSTACK-1978, it looks like the problem at hypervsor host 
  side, the hypervisor host is either failed to setup the VNC 
  listening interface or failed to configure firewall properly, could 
  KVM developer pick this up(I assume it is KVM hypervisor)?

  Kelven

  On 4/11/13 2:11 PM, Chip Childers chip.child...@sungard.com wrote:

  Hi all,

  I need your help clearing out the following bugs...  if you have 
  one assigned to you, please see if you can get it completed.  If 
  you have any time available, and think you can help resolve one of 
  the unassigned ones, please jump in!  We're obviously behind the 
  schedule that we set for ourselves, so I'd love to see the 
  community come together for a final push to get 4.1.0 out the door.

  CLOUDSTACK-2007 Release Notes failing to build on jenkins.cs.o 
  Currently unassigned - Joe looked into it, and he thinks this is a 
  build server issue.  Can someone please take a look?

  CLOUDSTACK-1934 NPE with listSupportedNetworkServices after upgrade 
  from
  4.0 to 4.1 (Ubuntu MS)
  Unassigned

  CLOUDSTACK-1978 openvswitch - unable to start console session for 
  SSVM CPVM user VMs Unassigned

  CLOUDSTACK-1987 Deleted service offerings owned by a domain show up 
  to domain users Unassigned

  CLOUDSTACK-1997 Upload and Document IPV6 specific system templates.
  Unassigned - Who wants to host the template (wido?), and then we 
  need to add it to the IPv6 docs.

  Last but not least, we still need to wrap up any final docs 
  (including Release Notes, which I consider a blocker right now).
  Joe, do you want / need help with the Release Notes?  Other doc 
  folks, anything that's in progress that we can get over the line 
  would be appreciated.  The same goes for translations that may be
 outstanding...

  Let's get 4.1.0 out!

  -chip

Re: [ACS41] Help needed clearing bugs!

2013-04-11 Thread Ryan Dietrich

Could you look at this first?

https://reviews.apache.org/r/10426/

On Apr 11, 2013, at 6:25 PM, Prachi Damle prachi.da...@citrix.com wrote:

 I will take a look at CLOUDSTACK-1987.
 
 -Prachi
 
 -Original Message-
 From: Edison Su [mailto:edison...@citrix.com] 
 Sent: Thursday, April 11, 2013 5:17 PM
 To: dev@cloudstack.apache.org
 Subject: RE: [ACS41] Help needed clearing bugs!
 
 Probably, it's a setup issue, e.g openvswitch doesn't work. I'll take a look 
 QA's environment, if it's still there.
 
 -Original Message-
 From: Marcus Sorensen [mailto:shadow...@gmail.com]
 Sent: Thursday, April 11, 2013 5:12 PM
 To: dev@cloudstack.apache.org
 Subject: Re: [ACS41] Help needed clearing bugs!
 
 I haven't even touched openvswitch, or I'd take a look at 1978. Is 
 that a prerequisite for duplicating the issue?
 On Apr 11, 2013 3:41 PM, Kelven Yang kelven.y...@citrix.com wrote:
 
 about CLOUDSTACK-1978, it looks like the problem at hypervsor host 
 side, the hypervisor host is either failed to setup the VNC 
 listening interface or failed to configure firewall properly, could 
 KVM developer pick this up(I assume it is KVM hypervisor)?
 
 Kelven
 
 On 4/11/13 2:11 PM, Chip Childers chip.child...@sungard.com wrote:
 
 Hi all,
 
 I need your help clearing out the following bugs...  if you have 
 one assigned to you, please see if you can get it completed.  If 
 you have any time available, and think you can help resolve one of 
 the unassigned ones, please jump in!  We're obviously behind the 
 schedule that we set for ourselves, so I'd love to see the 
 community come together for a final push to get 4.1.0 out the door.
 
 CLOUDSTACK-2007 Release Notes failing to build on jenkins.cs.o 
 Currently unassigned - Joe looked into it, and he thinks this is a 
 build server issue.  Can someone please take a look?
 
 CLOUDSTACK-1934 NPE with listSupportedNetworkServices after upgrade 
 from
 4.0 to 4.1 (Ubuntu MS)
 Unassigned
 
 CLOUDSTACK-1978 openvswitch - unable to start console session for 
 SSVM CPVM user VMs Unassigned
 
 CLOUDSTACK-1987 Deleted service offerings owned by a domain show up 
 to domain users Unassigned
 
 CLOUDSTACK-1997 Upload and Document IPV6 specific system templates.
 Unassigned - Who wants to host the template (wido?), and then we 
 need to add it to the IPv6 docs.
 
 Last but not least, we still need to wrap up any final docs 
 (including Release Notes, which I consider a blocker right now).
 Joe, do you want / need help with the Release Notes?  Other doc 
 folks, anything that's in progress that we can get over the line 
 would be appreciated.  The same goes for translations that may be
 outstanding...
 
 Let's get 4.1.0 out!
 
 -chip

RE: [ACS41] Help needed clearing bugs!

2013-04-11 Thread Prachi Damle

Hi Ryan,

Yes Sure, my bad,  will look at the patch first.

Thanks,
Prachi

-Original Message-
From: Ryan Dietrich [mailto:r...@betterservers.com] 
Sent: Thursday, April 11, 2013 5:46 PM
To: dev@cloudstack.apache.org
Subject: Re: [ACS41] Help needed clearing bugs!

Could you look at this first?

https://reviews.apache.org/r/10426/

On Apr 11, 2013, at 6:25 PM, Prachi Damle prachi.da...@citrix.com wrote:

 I will take a look at CLOUDSTACK-1987.
 
 -Prachi
 
 -Original Message-
 From: Edison Su [mailto:edison...@citrix.com]
 Sent: Thursday, April 11, 2013 5:17 PM
 To: dev@cloudstack.apache.org
 Subject: RE: [ACS41] Help needed clearing bugs!
 
 Probably, it's a setup issue, e.g openvswitch doesn't work. I'll take a look 
 QA's environment, if it's still there.
 
 -Original Message-
 From: Marcus Sorensen [mailto:shadow...@gmail.com]
 Sent: Thursday, April 11, 2013 5:12 PM
 To: dev@cloudstack.apache.org
 Subject: Re: [ACS41] Help needed clearing bugs!
 
 I haven't even touched openvswitch, or I'd take a look at 1978. Is 
 that a prerequisite for duplicating the issue?
 On Apr 11, 2013 3:41 PM, Kelven Yang kelven.y...@citrix.com wrote:
 
 about CLOUDSTACK-1978, it looks like the problem at hypervsor host 
 side, the hypervisor host is either failed to setup the VNC 
 listening interface or failed to configure firewall properly, could 
 KVM developer pick this up(I assume it is KVM hypervisor)?
 
 Kelven
 
 On 4/11/13 2:11 PM, Chip Childers chip.child...@sungard.com wrote:
 
 Hi all,
 
 I need your help clearing out the following bugs...  if you have 
 one assigned to you, please see if you can get it completed.  If 
 you have any time available, and think you can help resolve one of 
 the unassigned ones, please jump in!  We're obviously behind the 
 schedule that we set for ourselves, so I'd love to see the 
 community come together for a final push to get 4.1.0 out the door.
 
 CLOUDSTACK-2007 Release Notes failing to build on jenkins.cs.o 
 Currently unassigned - Joe looked into it, and he thinks this is a 
 build server issue.  Can someone please take a look?
 
 CLOUDSTACK-1934 NPE with listSupportedNetworkServices after upgrade 
 from
 4.0 to 4.1 (Ubuntu MS)
 Unassigned
 
 CLOUDSTACK-1978 openvswitch - unable to start console session for 
 SSVM CPVM user VMs Unassigned
 
 CLOUDSTACK-1987 Deleted service offerings owned by a domain show up 
 to domain users Unassigned
 
 CLOUDSTACK-1997 Upload and Document IPV6 specific system templates.
 Unassigned - Who wants to host the template (wido?), and then we 
 need to add it to the IPv6 docs.
 
 Last but not least, we still need to wrap up any final docs 
 (including Release Notes, which I consider a blocker right now).
 Joe, do you want / need help with the Release Notes?  Other doc 
 folks, anything that's in progress that we can get over the line 
 would be appreciated.  The same goes for translations that may be
 outstanding...
 
 Let's get 4.1.0 out!
 
 -chip

Re: Master broken

2013-04-11 Thread Kelven Yang

These issues are caused by that some of components are not really mocked,
instead, they are loaded directly main source.

One of the benefits from Spring is that it integrates with Mokito nicely,
all we need is to probably have a base test configuration that returns all
mocked DAOs or other common components and then have all unit test purely
written against mocked components.

We need to finalize the way to write Java unit test so that everyone can
follow to reduce the frequency/prevent these from happening. I'll find
some time to update the Unit-test guideline document in wiki, cleanup
things in this area and re-enable all unit tests in the build.

Kelven


On 4/9/13 1:57 AM, Hugo Trippaers htrippa...@schubergphilis.com wrote:



 -Original Message-
 From: Chip Childers [mailto:chip.child...@sungard.com]
 Sent: Monday, April 08, 2013 3:51 PM
 To: dev@cloudstack.apache.org
 Subject: Re: Master broken
 
 On Mon, Apr 08, 2013 at 07:44:41AM +, Hugo Trippaers wrote:
 
 
   -Original Message-
   From: Chip Childers [mailto:chip.child...@sungard.com]
   Sent: Saturday, April 06, 2013 7:16 PM
   To: dev@cloudstack.apache.org
   Subject: Re: Master broken
  
   On Sat, Apr 06, 2013 at 05:27:11AM +, Prasanna Santhanam wrote:
Ah - misunderstood. Like Hugo said, a test that fails on presence
of db
   connection should solve this. But I hope ppl will turn mysql on (as
   an additional step) to run the bvt. Or better yet, I can look into
   those db tests and port them as marvin tests.
   
  
   Perhaps I'm confused, but having a unit test that fails the build if
   MySQL is running on the local machine seems like a really bad idea.
  
   I think the problem to solve is just that we want to avoid unit
   tests that require a DB.  As long as we all know this, and that we
   have build jobs that fail on the CI side of things, isn't that
enough?
  
   Am I confused?
 
  No :-)
 
  The idea is to avoid unit tests that rely on the DB. However this is
rather
 difficult to do in some cases. We have a lot of autoloading going on,
so in
 some cases a simple fix to components could suddenly result in having a
 component that requires a database connection. If the developer in
question
 has an active database, he/she will never notice until the tests hit
the master
 branch and Jenkins starts complaining.
 
  My idea was to solve this by adding a negative test (break if you have
 database) to give people a reminder (by breaking their build) if they
have an
 active database. That could help developers remember to shut it down
 before compiling.
 
 I'm against this.  It shouldn't be a build requirement to *not* have a
DB
 running.  That would be exceptionally complicated for people to deal
with all
 the time, just to avoid inappropriate unit tests.

That's a good point :-)  I was also having mixed feelings about this,
just trying to help people remember that they should build unittests that
don't rely on the db.

I'm dropping this suggestion :-)

Master api-docs build

Raising this again. Jenkins seems to not be cleaning up properly. The
dedicatePublicIpRange patch was reverted a few days ago and the build
should be successful.

On 4/11/13 3:05 PM, Apache Jenkins Server jenk...@builds.apache.org
wrote:

See https://builds.apache.org/job/cloudstack-apidocs-master/451/changes

Changes:

[jessica.wang] CLOUDSTACK-1910: cloudstack UI - Regions menu - implement
create GSLB action.

[kelveny] Fix the systemvm packaging issue

[brian.federle] List view: Fix broken add row action

[brian.federle] VM NICs list view: Fix 'VM name' field for VMs without
name

[jessica.wang] CLOUDSTACK-1910: cloudstack UI - Regions menu - create
GSLB - (1) pass gslbstickysessionmethodname parameter to
createGlobalLoadBalancerRule API. (2) Take async Job response.

[prachi] API changes for createAffinityGroup

[prachi] More API changes

[prachi] DeleteAffinityGroup API changes

[prachi] ListAffinityGroups API changes

[prachi] Changes to add AffinityGroupprocessor, deployVM changes

[prachi] Separated out host anti-affinity as a plugin.

[prachi] Added apache license header

[prachi] Schema changes to create affinity group tables

[prachi] DAO constructor should be lightweight to make Spring DI faster.

[prachi] Not using entity factory

[prachi] API to list planners and set the planner in Service offering

[prachi] API changes to expose the commands

[prachi] Changes to make affinity group types configurable.

[prachi] Fixes after functional tests

[prachi] Adding the missing header!

[prachi] Build failure fixes after rebase.

[prachi] Adding a unit test for the new affinity groups API

[prachi] Integration testcase and the config file needed,  that runs with
marvin.

[prachi] Correcting the rebase merge issues.

[prachi] Added cleanup of affinitygroups when a VM is expunging and when
the account is deleted.

[prachi] Changes to return affinity groups information during listVMsCmd

[prachi] Added AffinityGroup View in order to include VM details while
listing AffinityGroups.

[prachi] Fixes to de-couple the AffinityGroupResponse from
UserVmResponse, since ApiDiscoveryService breaks, if we nest two response
objects into each other.

[prachi] More log statements to debug

[prachi] affinity group tests moved into the test folder

[prachi] bvt: marvin test for the affinity groups feature

[prachi] marvin bvt: getting rid of unused keys in the test

[prachi] CLOUDSTACK-1968: affinity_groups: Column 'deployment planner'
cannot be null when creating a service offering

[prachi] affinitygroup bvt: changes to the bvt for affinity groups

[prachi] ACl on affinity group

[prachi] Adding pretty toString() to AffinityGroup

[prachi] Fixes for issues found while testing after the merge

[prachi] Fixes to unit-test dues to changes in master

[prachi] Fixing rat. Merge with master missed the header change

[jessica.wang] CLOUDSTACK-1065: cloudstack UI - AWS Style Regions - set
autocomplete off.

[jessica.wang] CLOUDSTACK-1065: cloudstack UI - AWS Style Regions - make
loginCmdText local.

[prachi]  Excluding this unit test for a while, since it fails because
ComponentContext.initComponentsLifeCycle(); is failing when DB is
unavailable

--
[...truncated 3749 lines...]

---
 T E S T S
---

[INFO] --- maven-surefire-plugin:2.12:test (default-test) @
cloud-client-ui ---

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[JENKINS] Recording test results
[INFO]
[INFO] --- maven-war-plugin:2.3:war (default-war) @ cloud-client-ui ---
[INFO] Packaging webapp
[INFO] Assembling webapp [cloud-client-ui] in
[https://builds.apache.org/job/cloudstack-apidocs-master/ws/client/target
/cloud-client-ui-4.2.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Copying webapp resources
[https://builds.apache.org/job/cloudstack-apidocs-master/ws/client/target
/generated-webapp]
[INFO] Webapp assembled in [522 msecs]
[INFO] Building war:
https://builds.apache.org/job/cloudstack-apidocs-master/ws/client/target/
cloud-client-ui-4.2.0-SNAPSHOT.war
[INFO]
[INFO] --- maven-site-plugin:3.1:attach-descriptor (attach-descriptor) @
cloud-client-ui ---
[INFO] Configured Artifact: org.jasypt:jasypt:1.9.0:jar
[INFO] [INFO] Configured Artifact: org.jasypt:jasypt:1.8:jar
[INFO] Copying jasypt-1.9.0.jar to
https://builds.apache.org/job/cloudstack-apidocs-master/ws/client/target/
pythonlibs/jasypt-1.9.0.jar
[INFO] Copying jasypt-1.8.jar to
https://builds.apache.org/job/cloudstack-apidocs-master/ws/client/target/
pythonlibs/jasypt-1.8.jar

[INFO] --- maven-dependency-plugin:2.5.1:copy (copy) @ cloud-client-ui ---
[INFO] [INFO] Installing
https://builds.apache.org/job/cloudstack-apidocs-master/ws/client/target/
cloud-client-ui-4.2.0-SNAPSHOT.war to
/home/jenkins/jenkins-slave/maven-repositories/1/org/apache/cloudstack/clo
ud-client-ui/4.2.0-SNAPSHOT/cloud-client-ui-4.2.0-SNAPSHOT.war

[INFO] ---

Re: Master api-docs build

2013-04-11 Thread Prasanna Santhanam

452 has actually passed the build.

--
Prasanna.,

- Original Message -
From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
Sent: Friday, April 12, 2013 09:41 AM
To: dev@cloudstack.apache.org dev@cloudstack.apache.org
Subject: Master api-docs build

Raising this again. Jenkins seems to not be cleaning up properly. The
dedicatePublicIpRange patch was reverted a few days ago and the build
should be successful.

On 4/11/13 3:05 PM, Apache Jenkins Server jenk...@builds.apache.org
wrote:

See https://builds.apache.org/job/cloudstack-apidocs-master/451/changes

Changes:

[jessica.wang] CLOUDSTACK-1910: cloudstack UI - Regions menu - implement
create GSLB action.

[kelveny] Fix the systemvm packaging issue

[brian.federle] List view: Fix broken add row action

[brian.federle] VM NICs list view: Fix 'VM name' field for VMs without
name

[jessica.wang] CLOUDSTACK-1910: cloudstack UI - Regions menu - create
GSLB - (1) pass gslbstickysessionmethodname parameter to
createGlobalLoadBalancerRule API. (2) Take async Job response.

[prachi] API changes for createAffinityGroup

[prachi] More API changes

[prachi] DeleteAffinityGroup API changes

[prachi] ListAffinityGroups API changes

[prachi] Changes to add AffinityGroupprocessor, deployVM changes

[prachi] Separated out host anti-affinity as a plugin.

[prachi] Added apache license header

[prachi] Schema changes to create affinity group tables

[prachi] DAO constructor should be lightweight to make Spring DI faster.

[prachi] Not using entity factory

[prachi] API to list planners and set the planner in Service offering

[prachi] API changes to expose the commands

[prachi] Changes to make affinity group types configurable.

[prachi] Fixes after functional tests

[prachi] Adding the missing header!

[prachi] Build failure fixes after rebase.

[prachi] Adding a unit test for the new affinity groups API

[prachi] Integration testcase and the config file needed,  that runs with
marvin.

[prachi] Correcting the rebase merge issues.

[prachi] Added cleanup of affinitygroups when a VM is expunging and when
the account is deleted.

[prachi] Changes to return affinity groups information during listVMsCmd

[prachi] Added AffinityGroup View in order to include VM details while
listing AffinityGroups.

[prachi] Fixes to de-couple the AffinityGroupResponse from
UserVmResponse, since ApiDiscoveryService breaks, if we nest two response
objects into each other.

[prachi] More log statements to debug

[prachi] affinity group tests moved into the test folder

[prachi] bvt: marvin test for the affinity groups feature

[prachi] marvin bvt: getting rid of unused keys in the test

[prachi] CLOUDSTACK-1968: affinity_groups: Column 'deployment planner'
cannot be null when creating a service offering

[prachi] affinitygroup bvt: changes to the bvt for affinity groups

[prachi] ACl on affinity group

[prachi] Adding pretty toString() to AffinityGroup

[prachi] Fixes for issues found while testing after the merge

[prachi] Fixes to unit-test dues to changes in master

[prachi] Fixing rat. Merge with master missed the header change

[jessica.wang] CLOUDSTACK-1065: cloudstack UI - AWS Style Regions - set
autocomplete off.

[jessica.wang] CLOUDSTACK-1065: cloudstack UI - AWS Style Regions - make
loginCmdText local.

[prachi]  Excluding this unit test for a while, since it fails because
ComponentContext.initComponentsLifeCycle(); is failing when DB is
unavailable

--
[...truncated 3749 lines...]

---
 T E S T S
---

[INFO] --- maven-surefire-plugin:2.12:test (default-test) @
cloud-client-ui ---

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[JENKINS] Recording test results
[INFO]
[INFO] --- maven-war-plugin:2.3:war (default-war) @ cloud-client-ui ---
[INFO] Packaging webapp
[INFO] Assembling webapp [cloud-client-ui] in
[https://builds.apache.org/job/cloudstack-apidocs-master/ws/client/target
/cloud-client-ui-4.2.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Copying webapp resources
[https://builds.apache.org/job/cloudstack-apidocs-master/ws/client/target
/generated-webapp]
[INFO] Webapp assembled in [522 msecs]
[INFO] Building war:
https://builds.apache.org/job/cloudstack-apidocs-master/ws/client/target/
cloud-client-ui-4.2.0-SNAPSHOT.war
[INFO]
[INFO] --- maven-site-plugin:3.1:attach-descriptor (attach-descriptor) @
cloud-client-ui ---
[INFO] Configured Artifact: org.jasypt:jasypt:1.9.0:jar
[INFO] [INFO] Configured Artifact: org.jasypt:jasypt:1.8:jar
[INFO] Copying jasypt-1.9.0.jar to
https://builds.apache.org/job/cloudstack-apidocs-master/ws/client/target/
pythonlibs/jasypt-1.9.0.jar
[INFO] Copying jasypt-1.8.jar to
https://builds.apache.org/job/cloudstack-apidocs-master/ws/client/target/
pythonlibs/jasypt-1.8.jar

[INFO] --- maven-dependency-plugin:2.5.1:copy (copy) @ cloud-client-ui ---
[INFO] [INFO] Installing

Re: [JENKINS] Possible problem with Release Notes build setup

2013-04-11 Thread Prasanna Santhanam

I'll look into this today. Assuming this is on jenkins.cs.o.

--
Prasanna.,

- Original Message -
From: Joe Brockmeier [mailto:j...@zonker.net]
Sent: Friday, April 12, 2013 03:38 AM
To: dev@cloudstack.apache.org dev@cloudstack.apache.org
Subject: [JENKINS] Possible problem with Release Notes build setup

Chip pointed out that the Jenkins process for the release notes in 4.1
was failing, but it looks like a problem with the job rather than the
actual docs being busted. 

See ticket CLOUDSTACK-2007
(https://issues.apache.org/jira/browse/CLOUDSTACK-2007). 

Can someone with Jenkins access/wizardry take a look at this? 

The build works locally, but it looks like it may be a problem with the
update to common_content recently. 

Best,

jzb
-- 
Joe Brockmeier
j...@zonker.net
Twitter: @jzb
http://www.dissociatedpress.net/

Re: System VMs Failover

2013-04-11 Thread Jeronimo Garcia

just to clarify I'm using KVM.

Thanks!


On Thu, Apr 11, 2013 at 1:26 PM, Jeronimo Garcia garciaj...@gmail.comwrote:

 Hi.

 Thanks for your answer .
 System vms images are normally in secondary storage ,  and currently i
 have 3 pods and one and only secondary storage nfs system,

 When i shut down all the servers on POD1 ,  the system vms refused to
 launch in pod2 ,  would it be cause Pod2 has to have it's own secondary
 storage.

 Thanks!


 On Thu, Apr 11, 2013 at 12:08 PM, Kelven Yang kelven.y...@citrix.comwrote:

 System VMs are tend to be running in stateless mode, instead of fail-over
 of same VM, we are launching new instance of them, this behave is done for
 storage and console proxy system VM, for virtual router system VM, there
 is a redundant configuration, automatic HA would make the redundant
 configuration unstable. so in general, system VMs don't use HA offering
 purposely.

 Kelven

 On 4/11/13 7:54 AM, Jeronimo Garcia garciaj...@gmail.com wrote:

 Anyone ever bumped into this yet?
 
 Thanks!
 
 
 On Wed, Apr 10, 2013 at 11:27 AM, Jeronimo Garcia
 garciaj...@gmail.comwrote:
 
  Hi List.
 
  Based on documentation and what I'm actually seeing now ,  system vms
 can
  only failover to other hosts in the same cluster and therefore pod.
 
  I'm guessing this is because the system vm is using a management ip
  assigned to that specific pod.
 
  Is there any HA offering that could make system VMs to failover to
  different pods/clusters?
 
  Thanks!

Re: System VMs Failover

Secondary storage is zone wide not pod-specific.
Pod2 probably has some problems (enough shared storage perhaps?). The MS
logs should indicate the problem.

On 4/11/13 7:03 PM, Jeronimo Garcia garciaj...@gmail.com wrote:

just to clarify I'm using KVM.

Thanks!


On Thu, Apr 11, 2013 at 1:26 PM, Jeronimo Garcia
garciaj...@gmail.comwrote:

 Hi.

 Thanks for your answer .
 System vms images are normally in secondary storage ,  and currently i
 have 3 pods and one and only secondary storage nfs system,

 When i shut down all the servers on POD1 ,  the system vms refused to
 launch in pod2 ,  would it be cause Pod2 has to have it's own secondary
 storage.

 Thanks!


 On Thu, Apr 11, 2013 at 12:08 PM, Kelven Yang
kelven.y...@citrix.comwrote:

 System VMs are tend to be running in stateless mode, instead of
fail-over
 of same VM, we are launching new instance of them, this behave is done
for
 storage and console proxy system VM, for virtual router system VM,
there
 is a redundant configuration, automatic HA would make the redundant
 configuration unstable. so in general, system VMs don't use HA offering
 purposely.

 Kelven

 On 4/11/13 7:54 AM, Jeronimo Garcia garciaj...@gmail.com wrote:

 Anyone ever bumped into this yet?
 
 Thanks!
 
 
 On Wed, Apr 10, 2013 at 11:27 AM, Jeronimo Garcia
 garciaj...@gmail.comwrote:
 
  Hi List.
 
  Based on documentation and what I'm actually seeing now ,  system
vms
 can
  only failover to other hosts in the same cluster and therefore pod.
 
  I'm guessing this is because the system vm is using a management ip
  assigned to that specific pod.
 
  Is there any HA offering that could make system VMs to failover to
  different pods/clusters?
 
  Thanks!

Re: Review Request: Remove 2k limitation for user data on a deployVMCmd issued as an HTTP POST request

2013-04-11 Thread Venkata Siva Vijayendra Bhamidipati

On April 11, 2013, 8:54 p.m., Min Chen wrote:
server/src/com/cloud/vm/UserVmManagerImpl.java, line 2581
https://reviews.apache.org/r/10294/diff/3/?file=280319#file280319line2581

Based on your comment, for GET, maxBytes = 4K, for POST, maxBytes =
32K. Why not define these constants instead of an intermediate
MAX_USER_DATA_LENGTH_BYTES and do some math calculation here? This code is
hard to maintain later in case that http length standard changes later.

I just used the existing constant value, but yes, defining explicit constants
for userdata length for different http methods will be cleaner. Will do that.

On April 11, 2013, 8:54 p.m., Min Chen wrote:
server/test/com/cloud/vm/dao/UserVmDaoImplTest.java, line 61
https://reviews.apache.org/r/10294/diff/3/?file=280321#file280321line61

This test only tests database persistence. We may need another
automated test to issue a POST request.

Will add a marvin test for that.

On April 11, 2013, 8:54 p.m., Min Chen wrote:
server/test/com/cloud/vm/dao/UserVmDaoTestConfiguration.java, line 1
https://reviews.apache.org/r/10294/diff/3/?file=280322#file280322line1

Where are UserVmDaoTestConfiguration used in your test? You are missing
some Spring Junit annotation in your UserVmDaoImplTest.

Thanks for catching this - looks like the Testconfiguration.java and
textcontext.xml files slipped out of the diffs - when uploading the new diffs,
I'll ensure that they're present.

- Venkata Siva Vijayendra

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

On April 10, 2013, 9:59 p.m., Venkata Siva Vijayendra Bhamidipati wrote:

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

(Updated April 10, 2013, 9:59 p.m.)

Review request for cloudstack, Chip Childers, Hugo Trippaers, Kelven Yang,
and Min Chen.

Description
---

Please refer to
https://cwiki.apache.org/confluence/display/CLOUDSTACK/DeployVirtualMachine+userdata+enhancements
for a background on the requirements driving this patch.

This patch hasn't been extensively tested yet, and I will update this request
with more info. I am uploading a first diff for initial review/comments.

This addresses bug CLOUDSTACK-1086.

Diffs
-

api/src/com/cloud/vm/UserVmService.java 2c33d41
api/src/org/apache/cloudstack/api/BaseCmd.java 8fef422
api/src/org/apache/cloudstack/api/command/user/vm/DeployVMCmd.java 21a45f8
core/src/com/cloud/vm/UserVmVO.java a16eaf9
server/src/com/cloud/api/ApiDispatcher.java 925d90a
server/src/com/cloud/api/ApiServer.java d842819
server/src/com/cloud/api/ApiServerService.java 12d8b52
server/src/com/cloud/api/ApiServlet.java 03bfb5f
server/src/com/cloud/vm/UserVmManagerImpl.java 1c3764a
server/test/com/cloud/vm/MockUserVmManagerImpl.java dd8dd83
server/test/com/cloud/vm/dao/UserVmDaoImplTest.java 0936180
server/test/com/cloud/vm/dao/UserVmDaoTestConfiguration.java PRE-CREATION
server/test/resources/UserVMDaoTestContext.xml PRE-CREATION
setup/db/db/schema-410to420.sql c7c8b5b

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

Testing
---

Thanks,

Venkata Siva Vijayendra Bhamidipati

Re: System VMs Failover

2013-04-11 Thread Jeronimo Garcia

Thanks.

Is primary storage zone wide too?



On Thu, Apr 11, 2013 at 9:06 PM, Chiradeep Vittal 
chiradeep.vit...@citrix.com wrote:

 Secondary storage is zone wide not pod-specific.
 Pod2 probably has some problems (enough shared storage perhaps?). The MS
 logs should indicate the problem.

 On 4/11/13 7:03 PM, Jeronimo Garcia garciaj...@gmail.com wrote:

 just to clarify I'm using KVM.
 
 Thanks!
 
 
 On Thu, Apr 11, 2013 at 1:26 PM, Jeronimo Garcia
 garciaj...@gmail.comwrote:
 
  Hi.
 
  Thanks for your answer .
  System vms images are normally in secondary storage ,  and currently i
  have 3 pods and one and only secondary storage nfs system,
 
  When i shut down all the servers on POD1 ,  the system vms refused to
  launch in pod2 ,  would it be cause Pod2 has to have it's own secondary
  storage.
 
  Thanks!
 
 
  On Thu, Apr 11, 2013 at 12:08 PM, Kelven Yang
 kelven.y...@citrix.comwrote:
 
  System VMs are tend to be running in stateless mode, instead of
 fail-over
  of same VM, we are launching new instance of them, this behave is done
 for
  storage and console proxy system VM, for virtual router system VM,
 there
  is a redundant configuration, automatic HA would make the redundant
  configuration unstable. so in general, system VMs don't use HA offering
  purposely.
 
  Kelven
 
  On 4/11/13 7:54 AM, Jeronimo Garcia garciaj...@gmail.com wrote:
 
  Anyone ever bumped into this yet?
  
  Thanks!
  
  
  On Wed, Apr 10, 2013 at 11:27 AM, Jeronimo Garcia
  garciaj...@gmail.comwrote:
  
   Hi List.
  
   Based on documentation and what I'm actually seeing now ,  system
 vms
  can
   only failover to other hosts in the same cluster and therefore pod.
  
   I'm guessing this is because the system vm is using a management ip
   assigned to that specific pod.
  
   Is there any HA offering that could make system VMs to failover to
   different pods/clusters?
  
   Thanks!

[QA][PROPOSAL][ACS4.2] Test plan review: GSLB (Global Server Load Balancing)

2013-04-11 Thread Venkata SwamyBabu Budumuru


Hi Murali,

Please review the test plan [1] for feature  GSLB (Global Server Load 
Balancing) and let me know the review comments. The test cases are mentioned 
in an excel sheet attached to the page.

[1] Test Plan  :   
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=31817730
[2] Functional Spec:
https://cwiki.apache.org/CLOUDSTACK/gslb-global-server-load-balancing-functional-specification-and-design-document.html
[3] Bug Id   :   
https://issues.apache.org/jira/browse/CLOUDSTACK-894


Thanks,
SWAMY

Re: System VMs Failover

2013-04-11 Thread Ahmad Emneina

it could be per cluster or per host (local storage) at the moment. I
believe after the storage refactor work happens is when support for zone
wide primary *might* become a reality.


On Thu, Apr 11, 2013 at 7:28 PM, Jeronimo Garcia garciaj...@gmail.comwrote:

 Thanks.

 Is primary storage zone wide too?



 On Thu, Apr 11, 2013 at 9:06 PM, Chiradeep Vittal 
 chiradeep.vit...@citrix.com wrote:

  Secondary storage is zone wide not pod-specific.
  Pod2 probably has some problems (enough shared storage perhaps?). The MS
  logs should indicate the problem.
 
  On 4/11/13 7:03 PM, Jeronimo Garcia garciaj...@gmail.com wrote:
 
  just to clarify I'm using KVM.
  
  Thanks!
  
  
  On Thu, Apr 11, 2013 at 1:26 PM, Jeronimo Garcia
  garciaj...@gmail.comwrote:
  
   Hi.
  
   Thanks for your answer .
   System vms images are normally in secondary storage ,  and currently i
   have 3 pods and one and only secondary storage nfs system,
  
   When i shut down all the servers on POD1 ,  the system vms refused to
   launch in pod2 ,  would it be cause Pod2 has to have it's own
 secondary
   storage.
  
   Thanks!
  
  
   On Thu, Apr 11, 2013 at 12:08 PM, Kelven Yang
  kelven.y...@citrix.comwrote:
  
   System VMs are tend to be running in stateless mode, instead of
  fail-over
   of same VM, we are launching new instance of them, this behave is
 done
  for
   storage and console proxy system VM, for virtual router system VM,
  there
   is a redundant configuration, automatic HA would make the redundant
   configuration unstable. so in general, system VMs don't use HA
 offering
   purposely.
  
   Kelven
  
   On 4/11/13 7:54 AM, Jeronimo Garcia garciaj...@gmail.com wrote:
  
   Anyone ever bumped into this yet?
   
   Thanks!
   
   
   On Wed, Apr 10, 2013 at 11:27 AM, Jeronimo Garcia
   garciaj...@gmail.comwrote:
   
Hi List.
   
Based on documentation and what I'm actually seeing now ,  system
  vms
   can
only failover to other hosts in the same cluster and therefore
 pod.
   
I'm guessing this is because the system vm is using a management
 ip
assigned to that specific pod.
   
Is there any HA offering that could make system VMs to failover to
different pods/clusters?
   
Thanks!

Re: [DISCUSS] Don't assign tickets to people when triaging

2013-04-11 Thread Abhinandan Prateek

+1 To what Chip had to say on this thread. My use of ownership was wrong
and I actually meant interest. I have also started on the
producingoss.com as suggested by Rohit, looks like a good way to
understand the working of a voluntary community.

So now that I am positive on the community feedback, I realise some of
these may not work in the $dayjob but a good understanding can benefit
both worlds.


On 11/04/13 9:35 PM, prasanna t...@apache.org wrote:

Abhi - not to gang up on you and I'm glad to see you share your
opinions, concerns about release management and such.

I see the problem you might be facing though. I think it would be
better to have your internal JIRA mirror the ASF JIRA. That way you
can triage as you please corporate style ;) in your internal JIRA and
not let that spill over into the Apache JIRA which should be left to
work community style. If a bug is assigned to someone on your internal
JIRA, then that person will come and assign the bug to themselves in
the community ASF JIRA when they have time to fix it. That, I think,
works well for both the community and corporates invested in the
project.

HTH,

On 11 April 2013 19:17, Noah Slater nsla...@apache.org wrote:
 I believe it is possible to mention someone in a JIRA ticket in such a
 way that they get notified. Might this be an effective way of CCing
someone
 into the conversation, without prescribing who should fix it? Might
there
 be some room for exploration here?


 On Thursday, 11 April 2013, Abhinandan Prateek wrote:

 Yes, I think we need to space our releases further apart.
 I had big trouble when master was unstable for a while and specially on
 VMware it was difficult to deploy and test features. Yes for each
issue I
 could have shouted on mail list I saw people doing that but the fact is
 that instability was around for a while. Doesn't it make sense that in
such
 scenarios we could do things in a more pro active manner. Again I
donot see
 much difference in asking someone on Jira to pick a issue vs sending a
 email, but will agree to whatever the community decides here.

 Also community members should volunteer to own some part so that in
above
 circumstances a person looking for some fix can approach that member,
once
 again a suggestion.



 On 11-Apr-2013, at 5:17 PM, Noah Slater
nsla...@apache.orgjavascript:;
 wrote:

  Of course releases are important.
 
  But if our current cadence is putting too much pressure on the
community,
  one option might be to do our releases further apart from each
other. Or,
  we get strict about the principal of time based releases: i.e. if
your
  feature is not ready for the freeze, then it doesn't make it in. No
big
  deal. If it's ready for the next freeze, then we'll ship it then.
 
  Also, I may be reading your message wrong, but there's no need for
this
 to
  be a divisive argument. There are no sides to this. As a
community, it
 is
  up to us all to identify our problems, and figure out solutions.
 
  So what problems do you think we'll run in to if we stop assigning
the
  majority of bugs, and how do you think we can mitigate those
problems? Or
  do you have another idea in mind altogether?
 
 
 
 
  On 11 April 2013 12:40, Abhinandan Prateek 
 abhinandan.prat...@citrix.com javascript:;wrote:
 
  I think it will be good if we also find out a process so that the
 release
  cycle is not affected by unclaimed bugs sitting out there. Here I am
  assuming the releases are important.
 
  I guess the discussion has turned into keeping things free without
  offering solutions to problems that that system will create.
 
 
  On 11/04/13 5:04 PM, John Burwell jburw...@basho.com
javascript:;
 wrote:
 
  +1
 
  On Apr 11, 2013, at 7:22 AM, Noah Slater
nsla...@apache.orgjavascript:;
 wrote:
 
  On 11 April 2013 11:22, Abhinandan Prateek
  abhinandan.prat...@citrix.com javascript:;wrote:
 
 
  7-8 days is a huge time lost. I was suggesting that this to be 3
 days.
  Let
  other community members chime in too.
 
 
  I should have replied to this in my previous missive. But I want
to
  reenforce how unhealthy I believe this practice is. 7-8 days, or
even
 3
  days being a huge time loss makes absolutely no sense to me at
all.
  Assigning a bug should not mean it gets fixed any faster. If it
does,
  then
  we need to change the way we are working. (And if this means
changing
  the
  JIRA ticket workflow, then so be it. If something isn't working
for
 us,
  we
  change it.)
 
  In fact, I would go so far as to say that we should think of
assigning
  bugs
  as an exclusionary practice. Every time you assign a bug, you're
  shutting
  out the community. That's how we should think about it. Assign the
 bug,
  shut out the community. And so, I would say we should try to avoid
 doing
  it, unless it is absolutely necessary. (Such as when you're
  co-ordinating
  some release critical work, or when you, yourself, are about to
start
  work
  on something. Of course, it's perfectly fine to shut out the

Review Request: Fixed typo in public class

2013-04-11 Thread Pascal Borreli


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

Review request for cloudstack.


Description
---

Fixed typo in public class, made a Review Board with only that as it could be 
problematic (BC, external class using it)


Diffs
-

  client/WEB-INF/classes/resources/messages_de_DE.properties 5c7fc63 
  
engine/storage/integration-test/test/org/apache/cloudstack/storage/test/DirectAgentTest.java
 2d6b94f 
  
engine/storage/src/org/apache/cloudstack/storage/command/CreateVolumeFromBaseImageCommand.java
 f4be067 
  
engine/storage/src/org/apache/cloudstack/storage/to/ImageOnPrimayDataStoreTO.java
 18743d7 
  
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServerStorageResource.java
 70660d2 

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


Testing
---


Thanks,

Pascal Borreli

Re: Review Request: Fixed typo in public class

2013-04-11 Thread Rohit Yadav


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

(Updated April 12, 2013, 4:11 a.m.)


Review request for cloudstack, Chip Childers, Joe Brockmeier, and Sebastien 
Goasguen.


Description
---

Fixed typo in public class, made a Review Board with only that as it could be 
problematic (BC, external class using it)


Diffs
-

  client/WEB-INF/classes/resources/messages_de_DE.properties 5c7fc63 
  
engine/storage/integration-test/test/org/apache/cloudstack/storage/test/DirectAgentTest.java
 2d6b94f 
  
engine/storage/src/org/apache/cloudstack/storage/command/CreateVolumeFromBaseImageCommand.java
 f4be067 
  
engine/storage/src/org/apache/cloudstack/storage/to/ImageOnPrimayDataStoreTO.java
 18743d7 
  
plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/XenServerStorageResource.java
 70660d2 

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


Testing
---


Thanks,

Pascal Borreli

Re: [ACS41][Patch Request]

Ok. I also noticed that for me gmail picked up the subjects of
[ACS40][Patch Request] and [ACS41][Patch Request] and stuffed them in the
same thread for some reason, even though they were sent as two distinct
messages.


On Thu, Apr 11, 2013 at 11:40 AM, Chip Childers
chip.child...@sungard.comwrote:

 On Wed, Apr 10, 2013 at 12:39:24PM -0600, Marcus Sorensen wrote:
  commit be55c5b3a58376eb2048a8add155ff09f14e65eb
  Author: Marcus Sorensen mar...@betterservers.com
  Date:   Tue Apr 9 16:26:08 2013 -0600
 
  VPC - new system vm doesn't bring up eth0 reliably, and we don't set
  eth0 to
  auto start like we should.  cloud-early-config sets 'auto lo $1', but
  we don't
  pass $1 in vpc router scenario like we do in others for some reason.
  eth0 is
  always link local in vpc router, so setting it to that.
 
  Signed-off-by: Marcus Sorensen mar...@betterservers.com 1365546368
  -0600

 Done.  I noticed some threading problems with these requested, so please
 do a quick review of your requested cherry-picks to make sure I got them
 all.

Re: Review Request: Fix for CLOUDSTACK-1987

Adding list, it looks like reviews.apache.org left it off (due to the group
field being empty?).

On Thu, Apr 11, 2013 at 10:53 PM, Marcus Sorensen shadow...@gmail.comwrote:

There were two issues, one is that service offerings that have been
deleted show up as available from a domain user's perspective (but not as
root admin), that's CLOUDSTACK-1987. The other (CLOUDSTACK-1989) is that
users can't provide an offering id to get the list info of a particular
offering, they can query all, but if they provide an offering ID they get
an empty list.

On Thu, Apr 11, 2013 at 10:44 PM, Ryan Dietrich r...@betterservers.comwrote:

This fix solves a related problem. (Marcus, I thought this was Scott's
issue)

Right now, domain users cannot query service offerings by ID's.
Should I file a different bug then?

It's pretty simple to replicate. As a domain user, call
listServiceOfferings, then make the same call with an ID of a system wide
offering.

On Apr 11, 2013, at 7:06 PM, Min Chen min.c...@citrix.com wrote:

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

server/src/com/cloud/api/query/QueryManagerImpl.javahttps://reviews.apache.org/r/10426/diff/1/?file=280571#file280571line2110
(Diff
revision 1)

{'text': 'public class QueryManagerImpl extends ManagerBase implements
QueryService {', 'line': 153, 'expand_offset': 1950}

2110

spc.addOr(domainId, SearchCriteria.Op.IN, domainIds.toArray());

Somehow I could not understand how this addresses CLOUDSTACK-1987? Are you
saying that if a service offering is deleted, its domain id is set to NULL?
Did I overlook something here?

- Min

On April 11th, 2013, 11:43 p.m., Ryan Dietrich wrote:
Review request for Chip Childers and Marcus Sorensen.
By Ryan Dietrich.

*Updated April 11, 2013, 11:43 p.m.*
Description

So, without this fix you can't query service offerings that don't have a
domain id set (null).

Testing

Called listServiceOfferings using a simple perl script, once with an ID,
and once without an ID specified.

Diffs

- server/src/com/cloud/api/query/QueryManagerImpl.java (951d09e)

View Diff https://reviews.apache.org/r/10426/diff/

Re: Review Request: Fix for CLOUDSTACK-1987

2013-04-11 Thread Prasanna Santhanam


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

(Updated April 12, 2013, 4:57 a.m.)


Review request for cloudstack, Chip Childers and Marcus Sorensen.


Changes
---

adding group


Description
---

So, without this fix you can't query service offerings that don't have a domain 
id set (null).


Diffs
-

  server/src/com/cloud/api/query/QueryManagerImpl.java 951d09e 

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


Testing
---

Called listServiceOfferings using a simple perl script, once with an ID, and 
once without an ID specified.


Thanks,

Ryan Dietrich

Re: [ASFCS42] Proposed schedule for our next release

2013-04-11 Thread David Nalley


 Looking at that we fixed 217 bugs in roughly 2 months during 4.1 cycle,  
 fixing the backlog of bug  will probably take us 2 months.  Should we extend 
 the 4.2 test cycle by 2 months [Original Schedule: 6/1 - 7/22, Extended 
 Schedule: 6/1-9/22] to reduce the technical debt significantly? I would like 
 to hear how community wants to address technical debt. Based on the input and 
 consensus I will publish the agreed schedule next week.



So it's a bit confusing, you just proposed a schedule for keeping us
on the 4-month cycle, and then ask this question about extending it by
two months.
IMO changing the release cycle needs to be it's own thread though.

--David

Re: Master api-docs build

Oddly 453 failed again. They build on different nodes ubuntu4 and
ubuntu3 and ubuntu4 seems to fail the build.

On 12 April 2013 07:14, Prasanna Santhanam
prasanna.santha...@citrix.com wrote:
 452 has actually passed the build.

 --
 Prasanna.,

 - Original Message -
 From: Chiradeep Vittal [mailto:chiradeep.vit...@citrix.com]
 Sent: Friday, April 12, 2013 09:41 AM
 To: dev@cloudstack.apache.org dev@cloudstack.apache.org
 Subject: Master api-docs build

 Raising this again. Jenkins seems to not be cleaning up properly. The
 dedicatePublicIpRange patch was reverted a few days ago and the build
 should be successful.

 On 4/11/13 3:05 PM, Apache Jenkins Server jenk...@builds.apache.org
 wrote:

See https://builds.apache.org/job/cloudstack-apidocs-master/451/changes

Changes:

[jessica.wang] CLOUDSTACK-1910: cloudstack UI - Regions menu - implement
create GSLB action.

[kelveny] Fix the systemvm packaging issue

[brian.federle] List view: Fix broken add row action

[brian.federle] VM NICs list view: Fix 'VM name' field for VMs without
name

[jessica.wang] CLOUDSTACK-1910: cloudstack UI - Regions menu - create
GSLB - (1) pass gslbstickysessionmethodname parameter to
createGlobalLoadBalancerRule API. (2) Take async Job response.

[prachi] API changes for createAffinityGroup

[prachi] More API changes

[prachi] DeleteAffinityGroup API changes

[prachi] ListAffinityGroups API changes

[prachi] Changes to add AffinityGroupprocessor, deployVM changes

[prachi] Separated out host anti-affinity as a plugin.

[prachi] Added apache license header

[prachi] Schema changes to create affinity group tables

[prachi] DAO constructor should be lightweight to make Spring DI faster.

[prachi] Not using entity factory

[prachi] API to list planners and set the planner in Service offering

[prachi] API changes to expose the commands

[prachi] Changes to make affinity group types configurable.

[prachi] Fixes after functional tests

[prachi] Adding the missing header!

[prachi] Build failure fixes after rebase.

[prachi] Adding a unit test for the new affinity groups API

[prachi] Integration testcase and the config file needed,  that runs with
marvin.

[prachi] Correcting the rebase merge issues.

[prachi] Added cleanup of affinitygroups when a VM is expunging and when
the account is deleted.

[prachi] Changes to return affinity groups information during listVMsCmd

[prachi] Added AffinityGroup View in order to include VM details while
listing AffinityGroups.

[prachi] Fixes to de-couple the AffinityGroupResponse from
UserVmResponse, since ApiDiscoveryService breaks, if we nest two response
objects into each other.

[prachi] More log statements to debug

[prachi] affinity group tests moved into the test folder

[prachi] bvt: marvin test for the affinity groups feature

[prachi] marvin bvt: getting rid of unused keys in the test

[prachi] CLOUDSTACK-1968: affinity_groups: Column 'deployment planner'
cannot be null when creating a service offering

[prachi] affinitygroup bvt: changes to the bvt for affinity groups

[prachi] ACl on affinity group

[prachi] Adding pretty toString() to AffinityGroup

[prachi] Fixes for issues found while testing after the merge

[prachi] Fixes to unit-test dues to changes in master

[prachi] Fixing rat. Merge with master missed the header change

[jessica.wang] CLOUDSTACK-1065: cloudstack UI - AWS Style Regions - set
autocomplete off.

[jessica.wang] CLOUDSTACK-1065: cloudstack UI - AWS Style Regions - make
loginCmdText local.

[prachi]  Excluding this unit test for a while, since it fails because
ComponentContext.initComponentsLifeCycle(); is failing when DB is
unavailable

--
[...truncated 3749 lines...]

---
 T E S T S
---

[INFO] --- maven-surefire-plugin:2.12:test (default-test) @
cloud-client-ui ---

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[JENKINS] Recording test results
[INFO]
[INFO] --- maven-war-plugin:2.3:war (default-war) @ cloud-client-ui ---
[INFO] Packaging webapp
[INFO] Assembling webapp [cloud-client-ui] in
[https://builds.apache.org/job/cloudstack-apidocs-master/ws/client/target
/cloud-client-ui-4.2.0-SNAPSHOT]
[INFO] Processing war project
[INFO] Copying webapp resources
[https://builds.apache.org/job/cloudstack-apidocs-master/ws/client/target
/generated-webapp]
[INFO] Webapp assembled in [522 msecs]
[INFO] Building war:
https://builds.apache.org/job/cloudstack-apidocs-master/ws/client/target/
cloud-client-ui-4.2.0-SNAPSHOT.war
[INFO]
[INFO] --- maven-site-plugin:3.1:attach-descriptor (attach-descriptor) @
cloud-client-ui ---
[INFO] Configured Artifact: org.jasypt:jasypt:1.9.0:jar
[INFO] [INFO] Configured Artifact: org.jasypt:jasypt:1.8:jar
[INFO] Copying jasypt-1.9.0.jar to
https://builds.apache.org/job/cloudstack-apidocs-master/ws/client/target/
pythonlibs/jasypt-1.9.0.jar
[INFO] Copying jasypt-1.8.jar to

Re: Review Request: Fix for CLOUDSTACK-1987


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



server/src/com/cloud/api/query/QueryManagerImpl.java
https://reviews.apache.org/r/10426/#comment39602

For domain users, they should not be able to query system offerings. This 
fix didn't guard that case.


- Min Chen


On April 12, 2013, 4:57 a.m., Ryan Dietrich wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/10426/
 ---
 
 (Updated April 12, 2013, 4:57 a.m.)
 
 
 Review request for cloudstack, Chip Childers and Marcus Sorensen.
 
 
 Description
 ---
 
 So, without this fix you can't query service offerings that don't have a 
 domain id set (null).
 
 
 Diffs
 -
 
   server/src/com/cloud/api/query/QueryManagerImpl.java 951d09e 
 
 Diff: https://reviews.apache.org/r/10426/diff/
 
 
 Testing
 ---
 
 Called listServiceOfferings using a simple perl script, once with an ID, 
 and once without an ID specified.
 
 
 Thanks,
 
 Ryan Dietrich

Re: [ASFCS42] Proposed schedule for our next release

One thing I'd like to point out, and perhaps its merely subjective, but it
seemed like from initial 4.1 feature freeze to a week or two before the rc
was supposed to be cut there wasn't much action on bug fixing. It wasn't
until the deadlines started becoming imminent that people came back to work
on 4.1. Just something to keep in mind when discussing extending deadlines.
On Apr 11, 2013 11:12 PM, David Nalley da...@gnsa.us wrote:

 
  Looking at that we fixed 217 bugs in roughly 2 months during 4.1 cycle,
  fixing the backlog of bug  will probably take us 2 months.  Should we
 extend the 4.2 test cycle by 2 months [Original Schedule: 6/1 - 7/22,
 Extended Schedule: 6/1-9/22] to reduce the technical debt significantly? I
 would like to hear how community wants to address technical debt. Based on
 the input and consensus I will publish the agreed schedule next week.
 
 

 So it's a bit confusing, you just proposed a schedule for keeping us
 on the 4-month cycle, and then ask this question about extending it by
 two months.
 IMO changing the release cycle needs to be it's own thread though.

 --David

Re: [ACS41] Help needed clearing bugs!

It seems to me that this patch will fix 1989, not 1987.
Thanks
-min

On 4/11/13 6:24 PM, Marcus Sorensen shadow...@gmail.com wrote:

Does it fix 1989, or perhaps both?

https://issues.apache.org/jira/browse/CLOUDSTACK-1989
On Apr 11, 2013 7:08 PM, Min Chen min.c...@citrix.com wrote:

 Hi Ryan,

 Maybe I overlooked something, but I could not understand how
your
 patch
 is fixing CLOUDSTACK-1987. It would be appreciated if you can address my
 comment in that patch.

 Thanks
 -min

 On 4/11/13 5:52 PM, Prachi Damle prachi.da...@citrix.com wrote:

 Hi Ryan,
 
 Yes Sure, my bad,  will look at the patch first.
 
 Thanks,
 Prachi
 
 -Original Message-
 From: Ryan Dietrich [mailto:r...@betterservers.com]
 Sent: Thursday, April 11, 2013 5:46 PM
 To: dev@cloudstack.apache.org
 Subject: Re: [ACS41] Help needed clearing bugs!
 
 Could you look at this first?
 
 https://reviews.apache.org/r/10426/
 
 On Apr 11, 2013, at 6:25 PM, Prachi Damle prachi.da...@citrix.com
 wrote:
 
  I will take a look at CLOUDSTACK-1987.
 
  -Prachi
 
  -Original Message-
  From: Edison Su [mailto:edison...@citrix.com]
  Sent: Thursday, April 11, 2013 5:17 PM
  To: dev@cloudstack.apache.org
  Subject: RE: [ACS41] Help needed clearing bugs!
 
  Probably, it's a setup issue, e.g openvswitch doesn't work. I'll
take a
 look QA's environment, if it's still there.
 
  -Original Message-
  From: Marcus Sorensen [mailto:shadow...@gmail.com]
  Sent: Thursday, April 11, 2013 5:12 PM
  To: dev@cloudstack.apache.org
  Subject: Re: [ACS41] Help needed clearing bugs!
 
  I haven't even touched openvswitch, or I'd take a look at 1978. Is
  that a prerequisite for duplicating the issue?
  On Apr 11, 2013 3:41 PM, Kelven Yang kelven.y...@citrix.com
wrote:
 
  about CLOUDSTACK-1978, it looks like the problem at hypervsor host
  side, the hypervisor host is either failed to setup the VNC
  listening interface or failed to configure firewall properly, could
  KVM developer pick this up(I assume it is KVM hypervisor)?
 
  Kelven
 
  On 4/11/13 2:11 PM, Chip Childers chip.child...@sungard.com
 wrote:
 
  Hi all,
 
  I need your help clearing out the following bugs...  if you have
  one assigned to you, please see if you can get it completed.  If
  you have any time available, and think you can help resolve one of
  the unassigned ones, please jump in!  We're obviously behind the
  schedule that we set for ourselves, so I'd love to see the
  community come together for a final push to get 4.1.0 out the
door.
 
  CLOUDSTACK-2007 Release Notes failing to build on jenkins.cs.o
  Currently unassigned - Joe looked into it, and he thinks this is a
  build server issue.  Can someone please take a look?
 
  CLOUDSTACK-1934 NPE with listSupportedNetworkServices after
upgrade
  from
  4.0 to 4.1 (Ubuntu MS)
  Unassigned
 
  CLOUDSTACK-1978 openvswitch - unable to start console session for
  SSVM CPVM user VMs Unassigned
 
  CLOUDSTACK-1987 Deleted service offerings owned by a domain show
up
  to domain users Unassigned
 
  CLOUDSTACK-1997 Upload and Document IPV6 specific system
templates.
  Unassigned - Who wants to host the template (wido?), and then we
  need to add it to the IPv6 docs.
 
  Last but not least, we still need to wrap up any final docs
  (including Release Notes, which I consider a blocker right now).
  Joe, do you want / need help with the Release Notes?  Other doc
  folks, anything that's in progress that we can get over the line
  would be appreciated.  The same goes for translations that may be
  outstanding...
 
  Let's get 4.1.0 out!
 
  -chip

Re: Review Request: Fix for CLOUDSTACK-1987



 On April 12, 2013, 5:28 a.m., Min Chen wrote:
  server/src/com/cloud/api/query/QueryManagerImpl.java, line 2111
  https://reviews.apache.org/r/10426/diff/1/?file=280571#file280571line2111
 
  For domain users, they should not be able to query system offerings. 
  This fix didn't guard that case.

If this patch is to fix 1989 (instead of 1987), then the patch looks fine to 
me. Based on ML discussion, it seems that we need to update this review summary 
to clarify that it is to fix CLOUDSTACK-1989.


- Min


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


On April 12, 2013, 4:57 a.m., Ryan Dietrich wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/10426/
 ---
 
 (Updated April 12, 2013, 4:57 a.m.)
 
 
 Review request for cloudstack, Chip Childers and Marcus Sorensen.
 
 
 Description
 ---
 
 So, without this fix you can't query service offerings that don't have a 
 domain id set (null).
 
 
 Diffs
 -
 
   server/src/com/cloud/api/query/QueryManagerImpl.java 951d09e 
 
 Diff: https://reviews.apache.org/r/10426/diff/
 
 
 Testing
 ---
 
 Called listServiceOfferings using a simple perl script, once with an ID, 
 and once without an ID specified.
 
 
 Thanks,
 
 Ryan Dietrich

Re: [ASFCS42] Proposed schedule for our next release