RE: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU support for XenServer.
I see that the change has been pushed already, but I'm a bit concerned about there being a hard-coded list of vGPU types in the class GPU. I anticipate that Nvidia or other vendors will add more vGPU types later, and this will require us to keep up with the list. Is there a way we can use the list of vGPU types returned from the servers instead? -- Stephen Turner -Original Message- From: ASF Subversion and Git Services [mailto:nore...@reviews.apache.org] On Behalf Of ASF Subversion and Git Services Sent: 11 March 2014 10:10 To: Koushik Das; Devdeep Singh; Alex Huang Cc: Sanjay Tripathi; ASF Subversion and Git Services; cloudstack Subject: Re: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU support for XenServer. --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17889/#review36769 --- Commit c7d31fe288b13ff4f0f046f83f9eb4a9c2bf06c5 in cloudstack's branch refs/heads/master from Sanjay Tripathi [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c7d31fe ] CLOUDSTACK-4760 : Enabling GPU support for XenServer. CLOUDSTACK-4762 : Enabling VGPU support for XenServer. This feature is to enable the GPU-passthrough and vGPU functionality, with the help of this feature, admins/users will be able to leverage the GPU graphics unit power by deploying a virtul machine with GPU or vGPU support or by changing the service offering of an existing VM at any later point of time. There GPU/vGPU enabled VMs are able to run graphical applications. For now, this feature is only supported with XenServer hypervisor but can be extended to add the support of other hypervisors. - ASF Subversion and Git Services On Feb. 27, 2014, 12:35 p.m., Sanjay Tripathi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/17889/ > --- > > (Updated Feb. 27, 2014, 12:35 p.m.) > > > Review request for cloudstack, Alex Huang, Devdeep Singh, and Koushik Das. > > > Bugs: CLOUDSTACK-4760 and CLOUDSTACK-4762 > https://issues.apache.org/jira/browse/CLOUDSTACK-4760 > https://issues.apache.org/jira/browse/CLOUDSTACK-4762 > > > Repository: cloudstack-git > > > Description > --- > > CLOUDSTACK-4760 : Enabling GPU support for XenServer. > CLOUDSTACK-4762 : Enabling VGPU support for XenServer. > > This feature is to enable the GPU-passthrough and vGPU functionality, > with the help of this feature, admins/users will be able to leverage > the GPU graphics unit power by deploying a virtul machine with GPU or > vGPU support or by changing the service offering of an existing VM at > any later point of time. There GPU/vGPU enabled VMs are able to run > graphical applications. > For now, this feature is only supported with XenServer hypervisor but > can be extended to add the support of other hypervisors. > > > Diffs > - > > api/src/com/cloud/agent/api/to/GPUDeviceTO.java PRE-CREATION > api/src/com/cloud/agent/api/to/VirtualMachineTO.java bed3e1d > api/src/com/cloud/gpu/GPU.java PRE-CREATION > api/src/org/apache/cloudstack/api/ApiConstants.java 7b7f9ca > > api/src/org/apache/cloudstack/api/command/admin/offering/CreateServiceOfferingCmd.java > 1d8cbff > api/src/org/apache/cloudstack/api/response/GpuResponse.java PRE-CREATION > api/src/org/apache/cloudstack/api/response/HostResponse.java e2d8eb5 > api/src/org/apache/cloudstack/api/response/UserVmResponse.java 84d532b > api/src/org/apache/cloudstack/api/response/VgpuResponse.java PRE-CREATION > core/src/com/cloud/agent/api/GetGPUStatsAnswer.java PRE-CREATION > core/src/com/cloud/agent/api/GetGPUStatsCommand.java PRE-CREATION > core/src/com/cloud/agent/api/StartupRoutingCommand.java 626c87f > core/src/com/cloud/agent/api/StopCommand.java 6a29aa6 > engine/components-api/src/com/cloud/resource/ResourceManager.java 95fb385 > engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java > d19fc38 > > engine/schema/resources/META-INF/cloudstack/core/spring-engine-schema-core-daos-context.xml > 08efb83 > engine/schema/src/com/cloud/gpu/HostGpuGroupsVO.java PRE-CREATION > engine/schema/src/com/cloud/gpu/VGPUTypesVO.java PRE-CREATION > engine/schema/src/com/cloud/gpu/dao/HostGpuGroupsDao.java PRE-CREATION > engine/schema/src/com/cloud/gpu/dao/HostGpuGroupsDaoImpl.java PRE-CREATION > engine/schema/src/com/cloud/gpu/dao/VGPUTypesDao.java PRE-CREATION > engine/schema/src/com/cloud/gpu/dao/VGPUTypesDaoImpl.java PRE-CREATION > engine/schema/s
RE: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU support for XenServer.
Thanks for your reply, Sanjay. I understand that it's only K1 and K2 cards at the moment, but when they add more, do we really want to have to edit the code to match? What is the notification process by which we know there are new types? Does the user have to upgrade CloudStack to get access to the new types? In contrast, if we could use the current list from the server, we don't have to worry about it: it will just keep itself up to date. -- Stephen Turner -Original Message- From: Sanjay Tripathi Sent: 11 March 2014 16:05 To: Stephen Turner; dev@cloudstack.apache.org Subject: RE: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU support for XenServer. Hi Stephen, As of now, there are 2 GPU cards available in market i.e. NVIDIA GRID K1 and K2 cards. These card supports 5 different configurations of vGPUs which we call as vGPU types (for details: http://www.nvidia.com/object/virtual-gpus.html). In future, if this list grows, then we'll add a separate table similar to guest_os table, which will have the list of supported vGPU types. Also, the table "vgpu_types" has the entries of different vGPU types supported in hosts managed by CloudStack. --Sanjay -Original Message- From: Stephen Turner Sent: Tuesday, March 11, 2014 5:54 PM To: dev@cloudstack.apache.org Cc: Sanjay Tripathi Subject: RE: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU support for XenServer. I see that the change has been pushed already, but I'm a bit concerned about there being a hard-coded list of vGPU types in the class GPU. I anticipate that Nvidia or other vendors will add more vGPU types later, and this will require us to keep up with the list. Is there a way we can use the list of vGPU types returned from the servers instead? -- Stephen Turner -Original Message- From: ASF Subversion and Git Services [mailto:nore...@reviews.apache.org] On Behalf Of ASF Subversion and Git Services Sent: 11 March 2014 10:10 To: Koushik Das; Devdeep Singh; Alex Huang Cc: Sanjay Tripathi; ASF Subversion and Git Services; cloudstack Subject: Re: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU support for XenServer. --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17889/#review36769 --- Commit c7d31fe288b13ff4f0f046f83f9eb4a9c2bf06c5 in cloudstack's branch refs/heads/master from Sanjay Tripathi [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c7d31fe ] CLOUDSTACK-4760 : Enabling GPU support for XenServer. CLOUDSTACK-4762 : Enabling VGPU support for XenServer. This feature is to enable the GPU-passthrough and vGPU functionality, with the help of this feature, admins/users will be able to leverage the GPU graphics unit power by deploying a virtul machine with GPU or vGPU support or by changing the service offering of an existing VM at any later point of time. There GPU/vGPU enabled VMs are able to run graphical applications. For now, this feature is only supported with XenServer hypervisor but can be extended to add the support of other hypervisors. - ASF Subversion and Git Services On Feb. 27, 2014, 12:35 p.m., Sanjay Tripathi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/17889/ > --- > > (Updated Feb. 27, 2014, 12:35 p.m.) > > > Review request for cloudstack, Alex Huang, Devdeep Singh, and Koushik Das. > > > Bugs: CLOUDSTACK-4760 and CLOUDSTACK-4762 > https://issues.apache.org/jira/browse/CLOUDSTACK-4760 > https://issues.apache.org/jira/browse/CLOUDSTACK-4762 > > > Repository: cloudstack-git > > > Description > --- > > CLOUDSTACK-4760 : Enabling GPU support for XenServer. > CLOUDSTACK-4762 : Enabling VGPU support for XenServer. > > This feature is to enable the GPU-passthrough and vGPU functionality, > with the help of this feature, admins/users will be able to leverage > the GPU graphics unit power by deploying a virtul machine with GPU or > vGPU support or by changing the service offering of an existing VM at > any later point of time. There GPU/vGPU enabled VMs are able to run > graphical applications. > For now, this feature is only supported with XenServer hypervisor but > can be extended to add the support of other hypervisors. > > > Diffs > - > > api/src/com/cloud/agent/api/to/GPUDeviceTO.java PRE-CREATION > api/src/com/cloud/agent/api/to/VirtualMachineTO.java bed3e1d > api/src/com/cloud/gpu/GPU.java PRE-CREATION > api/src/org/apache/cloudstack/api/ApiConstants.java 7b7f9ca > > api/src/org/apache/clo
RE: How writing a new api of Pause VirtualMachine
Not answering your question, but note that XenServer has two different concepts: pause/unpause and suspend/resume. Normally you want suspend, which suspends to disk; with pause, the VM will continue using memory. In fact, the XenServer UI (XenCenter) doesn't even expose pause. -- Stephen Turner -Original Message- From: Yitao Jiang [mailto:willier...@gmail.com] Sent: 12 March 2014 04:55 To: dev@cloudstack.apache.org Subject: How writing a new api of Pause VirtualMachine Hi, I wanna pause a vm and resume it in cloudstack4.2.1 with xenserver 6.2 hypervisor, but CS did not implement this feature, so i wondered if you experienced guys can do something for this.Or give me some useful informations about how doing this. Thanks, Yitao
Developer access to JIRA please
I have three developers on my team who have started to work on CloudStack, mostly in the UI and API area. Could somebody kindly give our JIRA accounts developer rights, so that we can assign and resolve bugs? Our ids are: stephen.tur...@citrix.com<mailto:stephen.tur...@citrix.com> (Yes, my id is the same as my email address) gabora (Gabor Apati-Nagy) mihaelas (Mihaela Stoica) kc284 (Konstantina Chremmou, known as Tina) Thank you very much, -- Stephen Turner
RE: Developer access to JIRA please
Thanks, Dan, but we all have accounts already. We're talking about issues.apache.org, right? -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 12 March 2014 13:35 To: dev Subject: Re: Developer access to JIRA please On Wed, Mar 12, 2014 at 11:57 AM, Stephen Turner wrote: > kc284 added, the other accounts don't exist in jira. Please create and I will give you all rights. -- Daan
RE: Developer access to JIRA please
Oops, sorry for mis-spelling your name, Daan. https://issues.apache.org/jira/secure/ViewProfile.jspa?name=mihaelas https://issues.apache.org/jira/secure/ViewProfile.jspa?name=gabora https://issues.apache.org/jira/secure/ViewProfile.jspa?name=stephen.tur...@citrix.com all exist. -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 12 March 2014 13:45 To: Stephen Turner Cc: dev@cloudstack.apache.org Subject: Re: Developer access to JIRA please ../jira yes (even when not being called Dan) I looked at stephen.t gabora and mihaelas and got no matches found on each search. kc284 was matched with no delay. please triple check. On Wed, Mar 12, 2014 at 2:40 PM, Stephen Turner wrote: > Thanks, Dan, but we all have accounts already. We're talking about > issues.apache.org, right? > > -- > Stephen Turner > > > -Original Message- > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > Sent: 12 March 2014 13:35 > To: dev > Subject: Re: Developer access to JIRA please > > On Wed, Mar 12, 2014 at 11:57 AM, Stephen Turner > wrote: >> kc284 > > > added, the other accounts don't exist in jira. Please create and I will give > you all rights. > > -- > Daan -- Daan
RE: Developer access to JIRA please
Thank you very much, Daan. -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 12 March 2014 15:09 To: Stephen Turner Cc: dev@cloudstack.apache.org Subject: Re: Developer access to JIRA please now we are a bit better off. after retrying stubbornly, you are all in. cheers, On Wed, Mar 12, 2014 at 4:03 PM, Daan Hoogland wrote: > hm, I have been trying to add you guys to confluence, sorry > > On Wed, Mar 12, 2014 at 3:58 PM, Stephen Turner > wrote: >> Oops, sorry for mis-spelling your name, Daan. >> >> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=mihaelas >> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=gabora >> https://issues.apache.org/jira/secure/ViewProfile.jspa?name=stephen.t >> ur...@citrix.com >> >> all exist. >> >> -- >> Stephen Turner >> >> >> -Original Message----- >> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] >> Sent: 12 March 2014 13:45 >> To: Stephen Turner >> Cc: dev@cloudstack.apache.org >> Subject: Re: Developer access to JIRA please >> >> ../jira yes (even when not being called Dan) >> >> I looked at >> stephen.t >> gabora >> >> and >> >> mihaelas >> >> and got no matches found on each search. kc284 was matched with no delay. >> please triple check. >> >> On Wed, Mar 12, 2014 at 2:40 PM, Stephen Turner >> wrote: >>> Thanks, Dan, but we all have accounts already. We're talking about >>> issues.apache.org, right? >>> >>> -- >>> Stephen Turner >>> >>> >>> -Original Message- >>> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] >>> Sent: 12 March 2014 13:35 >>> To: dev >>> Subject: Re: Developer access to JIRA please >>> >>> On Wed, Mar 12, 2014 at 11:57 AM, Stephen Turner >>> wrote: >>>> kc284 >>> >>> >>> added, the other accounts don't exist in jira. Please create and I will >>> give you all rights. >>> >>> -- >>> Daan >> >> >> >> -- >> Daan > > > > -- > Daan -- Daan
RE: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU support for XenServer.
Does anyone else have a view on this? I'm not familiar with the code base yet, so am I worrying about nothing? -- Stephen Turner -Original Message- From: Stephen Turner [mailto:stephen.tur...@citrix.com] Sent: 11 March 2014 16:13 To: dev@cloudstack.apache.org Cc: Sanjay Tripathi Subject: RE: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU support for XenServer. Thanks for your reply, Sanjay. I understand that it's only K1 and K2 cards at the moment, but when they add more, do we really want to have to edit the code to match? What is the notification process by which we know there are new types? Does the user have to upgrade CloudStack to get access to the new types? In contrast, if we could use the current list from the server, we don't have to worry about it: it will just keep itself up to date. -- Stephen Turner -Original Message- From: Sanjay Tripathi Sent: 11 March 2014 16:05 To: Stephen Turner; dev@cloudstack.apache.org Subject: RE: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU support for XenServer. Hi Stephen, As of now, there are 2 GPU cards available in market i.e. NVIDIA GRID K1 and K2 cards. These card supports 5 different configurations of vGPUs which we call as vGPU types (for details: http://www.nvidia.com/object/virtual-gpus.html). In future, if this list grows, then we'll add a separate table similar to guest_os table, which will have the list of supported vGPU types. Also, the table "vgpu_types" has the entries of different vGPU types supported in hosts managed by CloudStack. --Sanjay -----Original Message- From: Stephen Turner Sent: Tuesday, March 11, 2014 5:54 PM To: dev@cloudstack.apache.org Cc: Sanjay Tripathi Subject: RE: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU support for XenServer. I see that the change has been pushed already, but I'm a bit concerned about there being a hard-coded list of vGPU types in the class GPU. I anticipate that Nvidia or other vendors will add more vGPU types later, and this will require us to keep up with the list. Is there a way we can use the list of vGPU types returned from the servers instead? -- Stephen Turner -Original Message- From: ASF Subversion and Git Services [mailto:nore...@reviews.apache.org] On Behalf Of ASF Subversion and Git Services Sent: 11 March 2014 10:10 To: Koushik Das; Devdeep Singh; Alex Huang Cc: Sanjay Tripathi; ASF Subversion and Git Services; cloudstack Subject: Re: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU support for XenServer. --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/17889/#review36769 --- Commit c7d31fe288b13ff4f0f046f83f9eb4a9c2bf06c5 in cloudstack's branch refs/heads/master from Sanjay Tripathi [ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c7d31fe ] CLOUDSTACK-4760 : Enabling GPU support for XenServer. CLOUDSTACK-4762 : Enabling VGPU support for XenServer. This feature is to enable the GPU-passthrough and vGPU functionality, with the help of this feature, admins/users will be able to leverage the GPU graphics unit power by deploying a virtul machine with GPU or vGPU support or by changing the service offering of an existing VM at any later point of time. There GPU/vGPU enabled VMs are able to run graphical applications. For now, this feature is only supported with XenServer hypervisor but can be extended to add the support of other hypervisors. - ASF Subversion and Git Services On Feb. 27, 2014, 12:35 p.m., Sanjay Tripathi wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/17889/ > --- > > (Updated Feb. 27, 2014, 12:35 p.m.) > > > Review request for cloudstack, Alex Huang, Devdeep Singh, and Koushik Das. > > > Bugs: CLOUDSTACK-4760 and CLOUDSTACK-4762 > https://issues.apache.org/jira/browse/CLOUDSTACK-4760 > https://issues.apache.org/jira/browse/CLOUDSTACK-4762 > > > Repository: cloudstack-git > > > Description > --- > > CLOUDSTACK-4760 : Enabling GPU support for XenServer. > CLOUDSTACK-4762 : Enabling VGPU support for XenServer. > > This feature is to enable the GPU-passthrough and vGPU functionality, > with the help of this feature, admins/users will be able to leverage > the GPU graphics unit power by deploying a virtul machine with GPU or > vGPU support or by changing the service offering of an existing VM at > any later point of time. There GPU/vGPU enabled VMs are able to run > graphical applications. > For now, this feature is only supported with XenServer hypervisor but > can
RE: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU support for XenServer.
I believe XenServer exposes everything you need in the VGPU_type class: # xe vgpu-type-list params=all uuid ( RO) : 6e175f2c-e8f1-2dce-aadf-8a8962b6f0e8 vendor-name ( RO): NVIDIA Corporation model-name ( RO): GRID K260Q framebuffer-size ( RO): 2013265920 max-heads ( RO): 4 max-resolution ( RO): 2560x1600 supported-on-PGPUs ( RO): b3fcca33-5fd6-9c44-70ac-c873f967d152; 8a436468-546b-ae69-2ab5-4e1d66d1a0eb; 37fbb55a-edf6-1aff-b80c-4f45ad46fc58; 6be9966b-f8bd-157a-5274-e927e57c28dd enabled-on-PGPUs ( RO): b3fcca33-5fd6-9c44-70ac-c873f967d152; 8a436468-546b-ae69-2ab5-4e1d66d1a0eb; 37fbb55a-edf6-1aff-b80c-4f45ad46fc58; 6be9966b-f8bd-157a-5274-e927e57c28dd supported-on-GPU-groups ( RO): 41c93ffe-23fe-2c50-674e-a8640e53b64f enabled-on-GPU-groups ( RO): 41c93ffe-23fe-2c50-674e-a8640e53b64f VGPU-uuids ( RO): framebuffer-size is the video RAM. The number of vGPUs of a particularly type that can be supported on a pGPU (the fraction of the GPU you get, if you like to think of it that way), is in the GPU class as supported_VGPU_max_capacities. XenCenter has none of this knowledge hard coded, so anything visible in XenCenter comes from XenServer over the XenAPI. -- Stephen Turner -Original Message- From: Ram Ganesh [mailto:ram.gan...@citrix.com] Sent: 13 March 2014 09:55 To: dev@cloudstack.apache.org Cc: Sanjay Tripathi; Sateesh Chodapuneedi Subject: RE: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU support for XenServer. If we look at [1] section "Interoperability and compatibility requirements" each of the cards supports certain profiles which has underpinning to Video RAM it supports, no of vGPUs that can be supported on one physical GPU. These mapping are maintained in CS. This mapping is required for the planner to pick a host which has the required resources to deploy a VM. Currently XenServer does not expose the Video RAM that each profile supports. Once we have that and all other loose ends around resources available vs used are taken care of then we can try to dynamically learn the lists from the hosts. [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/GPU+and+vGPU+support+for+CloudStack+Guest+VMs
RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
I see that there are a bunch of similar-looking changes in the original
changeset. Maybe someone with awk-fu should check that the others are sound?
--
Stephen Turner
-Original Message-
From: Edison Su [mailto:edison...@citrix.com]
Sent: 14 March 2014 20:59
To: dev@cloudstack.apache.org
Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
The following change will the be root cause:
-refs = execute("iptables -n -L " + brfw + " |grep " + brfw + " | cut
-d \( -f2 | awk '{print $1}'").strip()
+refs = execute("""iptables -n -L " + brfw + " | awk
+ '/%s(.*)references/ {gsub(/\(/, "") ;print $3}'""" % brfw).strip()
In commit: 052bff15c6603877e7a0767993eb4675e9bd9ca8
The code should be
+refs = execute("""iptables -n -L " + %s + " | awk
+ '/%s(.*)references/ {gsub(/\(/, "") ;print $3}'""" % (brfw,
+ brfw)).strip()
> -Original Message-
> From: Nux! [mailto:n...@li.nux.ro]
> Sent: Friday, March 14, 2014 1:13 PM
> To: dev@cloudstack.apache.org
> Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
>
> On 14.03.2014 19:36, Edison Su wrote:
> >> -Original Message-
> >> From: Nux! [mailto:n...@li.nux.ro]
> >> Sent: Friday, March 14, 2014 12:19 PM
> >> To: dev@cloudstack.apache.org
> >> Subject: RE: [VOTE] Apache CloudStack 4.3.0 (eighth round)
> >>
> >> On 14.03.2014 19:14, Edison Su wrote:
> >>> Hi Nux,
> >>>Could you post security group log file on your 4.3 kvm host?
> >>> The file is @/var/log/cloudstack/agent/security_group.log
> >>
> >> Thanks Edison, but the problem went away once I replaced that
> >> python script with
> >> https://git-wip-
> >> us.apache.org/repos/asf?p=cloudstack.git;a=blob_plain;f=scripts/vm/
> >> ne
> >> two
> >>
> rk/security_group.py;h=0ac8b74a872d46b5def69be8df35e4fc49eb52b3;hb=0
> >> 898a264a5463b85c4cab3033f9c3161c5ef83f8
> >
> > But the code is not for 4.3, right?
> > I want to figure out, why 4.3 security group is broken.
>
> I think this is the key difference:
>
> -A FORWARD -o brbond0-540 -m physdev --physdev-is-bridged -j
> BF-brbond0-540
> -A FORWARD -i brbond0-540 -m physdev --physdev-is-bridged -j
> BF-brbond0-540
> -A FORWARD -o brbond0-540 -j DROP
> -A FORWARD -i brbond0-540 -j DROP
>
> It's missing in the 4.3 and since FORWARD chain defaults to ACCEPT ...
> I'll try to rollback to old script and send you the logs.
>
> Lucian
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
RE: [PROPOSAL] Support pure Xen as a hypervisor
+1. I find it confusing that "Xen" is used for XenServer rather than XenProject, and I think it would be good to be explicit about which we mean in each case. -- Stephen Turner -Original Message- From: Tim Mackey [mailto:tmac...@gmail.com] Sent: 18 March 2014 15:40 To: dev@cloudstack.apache.org; us...@cloudstack.apache.org Subject: [PROPOSAL] Support pure Xen as a hypervisor Historically CloudStack has used Xen and XenServer interchangeably to refer to any XenAPI based implementation. With the recent release of Xen Project 4.4 (http://blog.xen.org/index.php/2014/03/10/xen-4-4-released/), and interest in alternate architectures like ARM, the loose definition of our Xen support could be confusing. In this two part effort I propose that CloudStack 4.4 be cleansed to ensure that all Xen references become XenServer references, and second that an alternate hypervisor type of "XenProject" be introduced for pure Xen which could either support libvirt or libxl (preference for libvirt given the 4.4 work to improve the interface and broader support for libvirt in general). Cross posted to users to for broader comment. -tim
RE: RealHostIp
GLENDOWER I can call spirits from the vasty deep. HOTSPUR Why, so can I, or so can any man; But will they come when you do call for them? -- Stephen Turner -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: 19 March 2014 18:40 To: dev@cloudstack.apache.org Subject: Re: RealHostIp AFAIK they've never been pingable. Or rather never responded to pings. --David On Wed, Mar 19, 2014 at 2:04 PM, John Kinsella wrote: > I can't ping the NS servers, but they do respond to queries... > > On Mar 19, 2014, at 2:37 AM, Alex Hitchins > wrote: > >> I can't ping RealHostIp, has the service been properly taken down? An >> NSLOOKUP didn't resolve any nameservers at all. >> >> Alex >> >> . >> >> Need Enterprise Grade Support for Apache CloudStack? >> Our CloudStack Infrastructure >> Support<http://shapeblue.com/cloudstack-infrastructure-support/> offers the >> best 24/7 SLA for CloudStack Environments. >> >> Apache CloudStack Bootcamp training courses >> >> **NEW!** CloudStack 4.2.1 training<http://shapeblue.com/cloudstack-training/> >> 18th-19th February 2014, Brazil. >> Classroom<http://shapeblue.com/cloudstack-training/> >> 17th-23rd March 2014, Region A. Instructor led, >> On-line<http://shapeblue.com/cloudstack-training/> >> 24th-28th March 2014, Region B. Instructor led, >> On-line<http://shapeblue.com/cloudstack-training/> >> 16th-20th June 2014, Region A. Instructor led, >> On-line<http://shapeblue.com/cloudstack-training/> >> 23rd-27th June 2014, Region B. Instructor led, >> On-line<http://shapeblue.com/cloudstack-training/> >> >> This email and any attachments to it may be confidential and are intended >> solely for the use of the individual to whom it is addressed. Any views or >> opinions expressed are solely those of the author and do not necessarily >> represent those of Shape Blue Ltd or related companies. If you are not the >> intended recipient of this email, you must neither take any action based >> upon its contents, nor copy or show it to anyone. Please contact the sender >> if you believe you have received this email in error. Shape Blue Ltd is a >> company incorporated in England & Wales. ShapeBlue Services India LLP is a >> company incorporated in India and is operated under license from Shape Blue >> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil >> and is operated under license from Shape Blue Ltd. ShapeBlue is a registered >> trademark. > >
RE: Guidelines for new or changed APIs?
Actually, Alena has recently started a document: https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+API+Coding+Guidelines I don't know how complete it is yet though. -- Stephen Turner -Original Message- From: Alex Hitchins [mailto:alex.hitch...@shapeblue.com] Sent: 29 March 2014 15:15 To: dev@cloudstack.apache.org Subject: RE: Guidelines for new or changed APIs? I don't know of any documentation, however we must ensure backwards compatibility, so that rather rules out changing existing api method signatures (adding/removing parameters). Regards Alex Hitchins D: +44 1892 523 587 | S: +44 2036 030 540 | M: +44 7788 423 969 alex.hitch...@shapeblue.com -Original Message- From: Demetrius Tsitrelis [mailto:demetrius.tsitre...@citrix.com] Sent: 29 March 2014 15:06 To: dev@cloudstack.apache.org Subject: Guidelines for new or changed APIs? I'd like to propose a few changes. Some adding a parameter to an existing API and some adding a new API altogether. Is there a document describing ASF or ACS policies for doing so? Sent from my Windows Phone Need Enterprise Grade Support for Apache CloudStack? Our CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> offers the best 24/7 SLA for CloudStack Environments. Apache CloudStack Bootcamp training courses **NEW!** CloudStack 4.2.1 training<http://shapeblue.com/cloudstack-training/> 18th-19th February 2014, Brazil. Classroom<http://shapeblue.com/cloudstack-training/> 17th-23rd March 2014, Region A. Instructor led, On-line<http://shapeblue.com/cloudstack-training/> 24th-28th March 2014, Region B. Instructor led, On-line<http://shapeblue.com/cloudstack-training/> 16th-20th June 2014, Region A. Instructor led, On-line<http://shapeblue.com/cloudstack-training/> 23rd-27th June 2014, Region B. Instructor led, On-line<http://shapeblue.com/cloudstack-training/> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
RE: Coding Standards Questions
I agree that pulling the return value out into a variable and returning it at
the end can be clearer, but I wouldn't want to make an absolute rule about it.
Sometimes returning early can reduce the number of nested if/else statements
and increase clarity. For example, I would rather see:
public int getNumberOfWidgets(Foo input) {
if (input == null)
return -1;
int ret;
// 30 lines of computation
return ret;
}
than put the bulk of the function in an else block. But maybe others disagree?
--
Stephen Turner
-Original Message-
From: Alex Hitchins [mailto:a...@alexhitchins.com]
Sent: 11 April 2014 21:45
To: dev@cloudstack.apache.org
Subject: RE: Coding Standards Questions
Daan,
Are you referring to keeping line lengths up to 80 characters? Sorry - tired
eyes.
My thoughts were more that in a function there should only be one "return"
statement rather than many, all nested in layers of if/else statements.
Alex Hitchins | 07788 423 969 | 01892 523 587
-
-Original Message-
From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
Sent: 11 April 2014 18:30
To: dev
Subject: Re: Coding Standards Questions
H Alex,
I agree with you that would be nicer if your function fits in a screen.
Another coding convention we should adhere to. As it is I think it not so much
'not a major concern' as too much to ask for.
Feel free to refactor and submit patches;)
Daan
On Fri, Apr 11, 2014 at 9:54 AM, Alex Hitchins
wrote:
> All,
>
>
>
> As I've been looking through the code, I've seen a fair number of
> places where return statements are called within if statements and the
> like. I've always found that having one place to return is easier to
> debug and follow the code flow.
>
>
>
> Are there any guidelines on this? Or is it not a major concern?
>
>
>
> Thanks,
>
>
>
> Alex
>
>
>
>
>
>
>
> Alex Hitchins
>
> --
>
> E: a...@alexhitchins.com
>
> W: alexhitchins.com
>
> M: 07788 423 969
>
> T: 01892 523 587
>
>
>
--
Daan
RE: [ACS4.5] move from xen 2 xenserver
As I said in the previous threaed, I'm +1 on the principle. It will avoid confusion between straight Xen and XenServer. It will also allow us to offer a non-XenServer Xen implementation. Sebastien, as all the filenames have changed, it's not clear from the diff whether this is just a straight renaming with no other changes. Could you confirm that? Also, are there any backwards compatibility implications for the API? Or did we already use "XenServer" instead of "Xen" there? -- Stephen Turner -Original Message- From: Sebastien Goasguen [mailto:run...@gmail.com] Sent: 15 April 2014 08:36 To: dev@cloudstack.apache.org Subject: [ACS4.5] move from xen 2 xenserver Folks, I just applied a patch from Tim Mackey: https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=748b575af8a66c58b0d52e7457e4d4e1e875231f commit: 748b575af8a66c58b0d52e7457e4d4e1e875231f This followed a [PROPOSAL] thread [1] This was pushed into a separate branch: xen2server This is a significant change that we should get consensus on and merge to master relatively quickly to avoid any conflicts later on. Basically, we have been treating xen and xenserver the same so far, since the integration with Xen (i.e Xen Project) was/is done via xapi. There has been discussion to integrate with Xen using straight up libvirt, by creating a new Xen agent probably based on the KVM agent and there was some discussion to that effect in the Denver Hackathon. Making a clear split between Xen and Xenserver type of hypervisors will help support different integration methods. I have asked Tim (in the review message) to create a wiki page, discussing all of this, but I wanted to give a heads up that this just hit the repo and that we should see a [MERGE] thread quickly. thoughts, flames ? [1] http://markmail.org/thread/yrl3ii7gqlaaexij -Sebastien
RE: [ACS4.5] move from xen 2 xenserver
Thanks, Tim, that's helpful. My question about API backwards compatibility was also whether any API arguments or return values are of the form "Xen" currently and would become "XenServer" after this change, for example because of changes in some parsing code. -- Stephen Turner -Original Message- From: Tim Mackey [mailto:tmac...@gmail.com] Sent: 16 April 2014 01:31 To: dev@cloudstack.apache.org Subject: Re: [ACS4.5] move from xen 2 xenserver This was a little more than a straight renaming, and I'll post all the changes to the wiki for review in the morning. At a high level this patch did the following: - Move the old plugins/hypervisors/xen to /plugins/hypervisors/xenserver and change all namespaces to reflect the move (bulk of the work) - Change any DDL/DML containing "xen"/"Xen" to become "XenServer" (took care of both create and upgrade paths) - Change any display areas containing "Xen" to become "XenServer" iirc there was one API change in the network label. It was xennetworklabel, and I updated it to become xenservernetworklabel. Since I don't want to break backwards compatibility either, I'm open to how best to handle the situation. Also would like to understand a test case I can use to validate. -tim On Tue, Apr 15, 2014 at 6:27 AM, Sebastien Goasguen wrote: > > On Apr 15, 2014, at 4:46 AM, Stephen Turner > > wrote: > > > As I said in the previous threaed, I'm +1 on the principle. It will > avoid confusion between straight Xen and XenServer. It will also allow > us to offer a non-XenServer Xen implementation. > > > > Sebastien, as all the filenames have changed, it's not clear from > > the > diff whether this is just a straight renaming with no other changes. > Could you confirm that? > > > > That's what it looks like, basically it creates a 'xenserver' plugin I > know Tim has a prototype of Xen support as well, but it was not in > this commit it seems. > > > > Also, are there any backwards compatibility implications for the > > API? Or > did we already use "XenServer" instead of "Xen" there? > > > > In the CloudStack API ? > > We are probably using Xen as value in several api calls…so we will > need to check this carefully before any merge, we definitely don't > want to break backward compatibility, or if we do we will need to move > to 5.0 > > > -- > > Stephen Turner > > > > > > -Original Message- > > From: Sebastien Goasguen [mailto:run...@gmail.com] > > Sent: 15 April 2014 08:36 > > To: dev@cloudstack.apache.org > > Subject: [ACS4.5] move from xen 2 xenserver > > > > Folks, > > > > I just applied a patch from Tim Mackey: > > > > > https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=74 > 8b575af8a66c58b0d52e7457e4d4e1e875231f > > > > commit: 748b575af8a66c58b0d52e7457e4d4e1e875231f > > > > This followed a [PROPOSAL] thread [1] > > > > This was pushed into a separate branch: xen2server > > > > This is a significant change that we should get consensus on and > > merge > to master relatively quickly to avoid any conflicts later on. > > > > Basically, we have been treating xen and xenserver the same so far, > since the integration with Xen (i.e Xen Project) was/is done via xapi. > > > > There has been discussion to integrate with Xen using straight up > libvirt, by creating a new Xen agent probably based on the KVM agent > and there was some discussion to that effect in the Denver Hackathon. > > > > Making a clear split between Xen and Xenserver type of hypervisors > > will > help support different integration methods. > > > > I have asked Tim (in the review message) to create a wiki page, > discussing all of this, but I wanted to give a heads up that this just > hit the repo and that we should see a [MERGE] thread quickly. > > > > thoughts, flames ? > > > > > > [1] http://markmail.org/thread/yrl3ii7gqlaaexij > > > > -Sebastien > > > >
RE: Best practice: Do not use innerHtml() property or it's equivalent jQuery .html() method
Brian, didn't you fix most of these already? -- Stephen Turner -Original Message- From: Demetrius Tsitrelis [mailto:demetrius.tsitre...@citrix.com] Sent: 17 April 2014 00:07 To: dev@cloudstack.apache.org Subject: Best practice: Do not use innerHtml() property or it's equivalent jQuery .html() method This property is used to dynamically insert HTML into the UI. Unfortunately, it is easily abused because it accepts input such as
RE: [XenServer] 6.2.5?
There is no XenServer 6.2.5. This resource refers to XenServer with some CloudStack-requested patches that were included in a recent XenServer hotfix. Specifically, it's XenServer 6.2 + SP1 + XS62ESP1004 (see Alex Huang's email at http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201404.mbox/%3C20CF38CB4385CE4D9D1558D52A0FC0582745D5%40SJCPEX01CL03.citrite.net%3E for more details). -- Stephen Turner -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: 23 April 2014 16:32 To: dev@cloudstack.apache.org Subject: [XenServer] 6.2.5? Hi, I see that we have a Xenserver625Resource class, which implies, of course, that there is a 6.2.5 version of XenServer. When I go to Citrix's site, though, and look for it, all I see is 6.2.0 (with regards to 6.2.x). Does anyone know where I can download this update from? Thanks! Mike -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *(tm)*
RE: [XenServer] 6.2.5?
Tina's work was just the xen-api.jar piece of that, so I think the 625 resource is still relevant for the other changes. -- Stephen Turner -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: 23 April 2014 16:54 To: dev@cloudstack.apache.org Subject: Re: [XenServer] 6.2.5? Interesting...if memory serves, that work with XAPI was reverted from CS 4.4. Does that mean this 625 resource no longer applies in 4.4? Thanks! On Wed, Apr 23, 2014 at 9:50 AM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Thanks, Stephen! > > > On Wed, Apr 23, 2014 at 9:46 AM, Stephen Turner > > wrote: > >> There is no XenServer 6.2.5. This resource refers to XenServer with >> some CloudStack-requested patches that were included in a recent >> XenServer hotfix. Specifically, it's XenServer 6.2 + SP1 + >> XS62ESP1004 (see Alex Huang's email at >> http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201404.mbox/%3C20CF38CB4385CE4D9D1558D52A0FC0582745D5%40SJCPEX01CL03.citrite.net%3Efor >> more details). >> >> -- >> Stephen Turner >> >> >> -Original Message- >> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] >> Sent: 23 April 2014 16:32 >> To: dev@cloudstack.apache.org >> Subject: [XenServer] 6.2.5? >> >> Hi, >> >> I see that we have a Xenserver625Resource class, which implies, of >> course, that there is a 6.2.5 version of XenServer. >> >> When I go to Citrix's site, though, and look for it, all I see is >> 6.2.0 (with regards to 6.2.x). >> >> Does anyone know where I can download this update from? >> >> Thanks! >> Mike >> >> -- >> *Mike Tutkowski* >> *Senior CloudStack Developer, SolidFire Inc.* >> e: mike.tutkow...@solidfire.com >> o: 303.746.7302 >> Advancing the way the world uses the >> cloud<http://solidfire.com/solution/overview/?video=play> >> *(tm)* >> > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *(tm)* > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *(tm)*
RE: Review Request 21624: Mouseover to click for quickview
You didn't assign any reviewers, but I suggest Brian Federle would be the best person, so cc:ing him. -- Stephen Turner -Original Message- From: Axel Delahaye [mailto:nore...@reviews.apache.org] On Behalf Of Axel Delahaye Sent: 19 May 2014 10:54 To: Axel Delahaye; cloudstack Subject: Review Request 21624: Mouseover to click for quickview --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21624/ --- Review request for cloudstack. Repository: cloudstack-git Description --- To avoid undesired opening of the quickview or mistake. Ex: destroy an instance and it was the top instance quickview which was open. For the quickview '+' button, I change the mouseover to the click handler. Diffs - ui/scripts/ui/widgets/listView.js d5ba2fe Diff: https://reviews.apache.org/r/21624/diff/ Testing --- Thanks, Axel Delahaye
Re: Review Request 21498: CLOUDSTACK-6009: listHosts API fixed to return all "memory" stats in Bytes instead of a mix of Bytes and Kilobytes
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21498/#review43345 --- Is it possible that someone is relying on the existing behaviour? I realise that you've made a new method to mimic the existing behaviour, but that will still break people's scripts unless they update them to call the new method. My bias tends to be to preserve the API until the next official revision, and work around the problem on the client side. - Stephen Turner On May 15, 2014, 7:54 p.m., Sam Schmit wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/21498/ > --- > > (Updated May 15, 2014, 7:54 p.m.) > > > Review request for cloudstack. > > > Bugs: CLOUDSTACK-6009 > https://issues.apache.org/jira/browse/CLOUDSTACK-6009 > > > Repository: cloudstack-git > > > Description > --- > > CLOUDSTACK-6009: listHosts API call is returning memoryAvailable and > memoryTotal in Bytes, and memoryUsed in Kilobytes. This fix changes the > memoryUsed value to return in Bytes as well, and includes a new method to > return memoryUsed in Kilobytes if needed. > > > Diffs > - > > api/src/com/cloud/host/HostStats.java 4eb7b1a > core/src/com/cloud/agent/api/GetHostStatsAnswer.java 6a52e76 > core/src/com/cloud/agent/api/HostStatsEntry.java c9d25a0 > > Diff: https://reviews.apache.org/r/21498/diff/ > > > Testing > --- > > Pre-change: > 1) Called "listHosts" API call with no arguments. > 2) Validated that memoryAvailable and memoryTotal were in Bytes, while > memoryUsed was in Kilobytes (factor of 1000 times smaller than it should be) > > Post-change: > 1) Called "listHosts" API call with no arguments. > 2) Validated that memoryAvailable, memoryTotal, and memoryUsed are all in > Bytes, and memoryAvailable + memoryUsed = memoryTotal > > > Thanks, > > Sam Schmit > >
RE: Review Request 21498: CLOUDSTACK-6009: listHosts API fixed to return all "memory" stats in Bytes instead of a mix of Bytes and Kilobytes
Well, I agree. I’m somewhat in two minds because I think it’s on the boundary between being a bug and just being a misdesigned feature. I’d be interested to know what other people think. -- Stephen Turner From: Sam Schmit [mailto:sam.sch...@appcore.com] Sent: 19 May 2014 15:32 To: Stephen Turner Cc: cloudstack Subject: Re: Review Request 21498: CLOUDSTACK-6009: listHosts API fixed to return all "memory" stats in Bytes instead of a mix of Bytes and Kilobytes Stephen, It seems odd that incorrect behavior would be preserved, but I suppose I could understand that. Sam On Mon, May 19, 2014 at 5:42 AM, Stephen Turner mailto:stephen.tur...@citrix.com>> wrote: This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/21498/ Is it possible that someone is relying on the existing behaviour? I realise that you've made a new method to mimic the existing behaviour, but that will still break people's scripts unless they update them to call the new method. My bias tends to be to preserve the API until the next official revision, and work around the problem on the client side. - Stephen Turner On May 15th, 2014, 7:54 p.m. UTC, Sam Schmit wrote: Review request for cloudstack. By Sam Schmit. Updated May 15, 2014, 7:54 p.m. Bugs: CLOUDSTACK-6009<https://issues.apache.org/jira/browse/CLOUDSTACK-6009> Repository: cloudstack-git Description CLOUDSTACK-6009: listHosts API call is returning memoryAvailable and memoryTotal in Bytes, and memoryUsed in Kilobytes. This fix changes the memoryUsed value to return in Bytes as well, and includes a new method to return memoryUsed in Kilobytes if needed. Testing Pre-change: 1) Called "listHosts" API call with no arguments. 2) Validated that memoryAvailable and memoryTotal were in Bytes, while memoryUsed was in Kilobytes (factor of 1000 times smaller than it should be) Post-change: 1) Called "listHosts" API call with no arguments. 2) Validated that memoryAvailable, memoryTotal, and memoryUsed are all in Bytes, and memoryAvailable + memoryUsed = memoryTotal Diffs * api/src/com/cloud/host/HostStats.java (4eb7b1a) * core/src/com/cloud/agent/api/GetHostStatsAnswer.java (6a52e76) * core/src/com/cloud/agent/api/HostStatsEntry.java (c9d25a0) View Diff<https://reviews.apache.org/r/21498/diff/>
RE: [DOCS] Git Flow
I'm not a fan of squashed merges myself, because you lose the history, which can often contain useful check-in comments. My preferred github workflow is to make a new local branch before starting any change, push that to a branch in my fork of the project on github, and then send a pull request. I don't do subsequent work on the same branch (unless the maintainer wants further changes before accepting the pull request), so I don't run into the problem where pull requests build on each other. Having said that, I'm talking about code, not documentation. There may be some reason I'm not aware of why documentation works better with a different workflow. -- Stephen Turner -Original Message- From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On Behalf Of Will Stevens Sent: 22 May 2014 21:36 To: dev@cloudstack.apache.org; Sebastien Goasguen; Pierre-Luc Dion Subject: [DOCS] Git Flow Hey All, In the the README.rst files in the documentation, it refers to this page if you want to contribute: http://cloudstack.apache.org/developers.html I am not sure those instructions are actually up-to-date or valid for contributing to the documentation. I originally tried to use this process ( https://help.github.com/articles/syncing-a-fork) to keep my documentation fork up-to-date with the upstream/master, but after the first pull request the commits have to be cherry-picked because the pull requests will always take everything I have committed in my fork rather than the changes since the last pull request. This got annoying quickly. When contributing to the actual CloudStack code I used a squashed patch approach which worked very well. I have written up that flow as well as a similar flow for working with Github pull requests. I would like you to review what I have written. If you guys approve of the flow, I would like to add it to the README.rst files in the different documentation repositories to make it easier for people to contribute to the documentation. I know I found it really hard to figure out how to contribute to the documentation initially. We want to lower the bar a bit on this so more people feel comfortable helping with the documentation. Let me know what you think. Cheers, Will Contributing to the documentation = Initial setup of your local fork First, fork the original documentation repository to your Github account. Then on your computer, do the following... .. code:: bash $ git clone `url of your forked repo` $ cd `git repo directory` $ git remote add upstream `url of the original repo` $ git checkout master $ git fetch upstream $ git merge upstream/master Making changes -- You will be making changes on a new `dev` branch which is only in your local git repository. .. code:: bash $ git checkout -b dev (make your changes) $ git add . $ git commit -a -m "commit message for your changes" .. note:: The `-b` specifies that you want to create a new branch called `dev`. You only specify `-b` the first time because you are creating a new branch. Once the `dev` branch exists, you can later switch to it with `git checkout dev`. Merging `upstream/master` into your `dev` branch .. code:: bash $ git checkout master $ git fetch upstream $ git merge upstream/master $ git checkout dev $ git pull . master .. note:: Now your `dev` branch is up-to-date with everything from `upstream/master`. Making a squashed patch for `upstream/master` - .. note:: Make sure you have merged `upstream/master` into your `dev` branch before you do this. .. code:: bash $ git checkout master $ git checkout -b squashed $ git merge --squash dev $ git commit -a -m "commit message for this squashed patch" $ git format-patch master $ git checkout master $ git branch -D squashed Upload the resulting patch file to a committer and move it out of your working tree. Continue working on the `dev` branch. When your changes are committed to the `upstream/master`, they will end up in your `master` branch when you re-sync your local `master` with the `upstream/master`. The next time you create a squashed patch between the `dev` branch and `master`, it will only include the changes that are not already in the `upstream/master` branch. Making a squashed pull request for `upstream/master` .. note:: Make sure you have merged `upstream/master` into your `dev` branch before you do this. .. code:: bash $ git checkout master $ git checkout -b squashed $ git merge --squash dev $ git commit -a -m "commit message for this squashed pull request" $ git push origin master $ git push origin squashed Create a pull request on the `squashed` branch in your forked git repo on github to contribute
RE: [DOCS] Git Flow
I've not seen Phabricator, but yes, what I like about github is that the code review is built into the source control. This makes the whole workflow much simpler. -- Stephen Turner -Original Message- From: rohityada...@gmail.com [mailto:rohityada...@gmail.com] On Behalf Of Rohit Yadav Sent: 23 May 2014 11:35 To: dev@cloudstack.apache.org Cc: Sebastien Goasguen; Pierre-Luc Dion Subject: Re: [DOCS] Git Flow Hi, Good effort. Will you should also see this and update the wiki as needed: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git I would say, squashed merges are much better when you're going through list of changes [1] instead of having a branch based workflow, reverting/fixing/bisecting it becomes much easier. I would recommend Stephen and others to checkout Phabricator's pre and post code reviewing and their CLI tool arcanist which IMO give a much better workflow. Right now it's too much pain for a contributor to create a patch, upload to reviewboard, get it reviewed and then for the committer to go see RB, test/review patch and merge it. This is all manual work. Pull request is one good way to solve it at the cost of complicating git trees/graphs, emailing patch directly to ML can be another (historically worked?) and using something like Phabricator (that can be hosted on ASF infra) is another way as well. [1] See the git network/graph: git log --graph --decorate --pretty=oneline --abbrev-commit --all Regards. On Fri, May 23, 2014 at 3:20 PM, Stephen Turner wrote: > I'm not a fan of squashed merges myself, because you lose the history, > which can often contain useful check-in comments. > > My preferred github workflow is to make a new local branch before > starting any change, push that to a branch in my fork of the project > on github, and then send a pull request. I don't do subsequent work on > the same branch (unless the maintainer wants further changes before > accepting the pull request), so I don't run into the problem where > pull requests build on each other. > > Having said that, I'm talking about code, not documentation. There may > be some reason I'm not aware of why documentation works better with a > different workflow. > > -- > Stephen Turner > > > -Original Message- > From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On > Behalf Of Will Stevens > Sent: 22 May 2014 21:36 > To: dev@cloudstack.apache.org; Sebastien Goasguen; Pierre-Luc Dion > Subject: [DOCS] Git Flow > > Hey All, > In the the README.rst files in the documentation, it refers to this > page if you want to contribute: > http://cloudstack.apache.org/developers.html > > I am not sure those instructions are actually up-to-date or valid for > contributing to the documentation. > > I originally tried to use this process ( > https://help.github.com/articles/syncing-a-fork) to keep my > documentation fork up-to-date with the upstream/master, but after the > first pull request the commits have to be cherry-picked because the > pull requests will always take everything I have committed in my fork > rather than the changes since the last pull request. This got annoying > quickly. > > When contributing to the actual CloudStack code I used a squashed > patch approach which worked very well. I have written up that flow as > well as a similar flow for working with Github pull requests. > > I would like you to review what I have written. If you guys approve > of the flow, I would like to add it to the README.rst files in the > different documentation repositories to make it easier for people to > contribute to the documentation. I know I found it really hard to > figure out how to contribute to the documentation initially. We want > to lower the bar a bit on this so more people feel comfortable helping with > the documentation. > > Let me know what you think. > > Cheers, > > Will > > > > Contributing to the documentation > = > > Initial setup of your local fork > > > First, fork the original documentation repository to your Github account. > Then on your computer, do the following... > > .. code:: bash > > $ git clone `url of your forked repo` > $ cd `git repo directory` > $ git remote add upstream `url of the original repo` $ git checkout > master $ git fetch upstream $ git merge upstream/master > > > Making changes > -- > > You will be making changes on a new `dev` branch which is only in your > local git repository. > > .. code:: bash > > $ git checkout -b dev > (make your changes) > $ git add . > $ git commit -a -m "commit message for yo
RE: [PROPOSAL] git workflow
What happens if a fix isn't relevant for newer versions, or has to be rewritten for newer versions because the code has changed? Don't the branches diverge and you end up cherry-picking after that? -- Stephen Turner -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: 30 May 2014 18:48 To: dev@cloudstack.apache.org Subject: Re: [PROPOSAL] git workflow I think this flow is something we should seriously consider. I find cherry picking from branch to branch to be error prone in that it's easy for someone to forget to cherry pick to all applicable branches and you don't have any easy way to see the cherry picks are related. When I worked at HP, we had automated tools check to see if you checked a fix into a prior release, but not later releases. In such a situation, you either 1) forgot to perform the check-in or 2) the check-in was no longer applicable in the later release(s), so you needed to mark it as un-necessary (SVN supported this ability...not sure about Git). On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi < rajani.karut...@citrix.com> wrote: > Hi all, > > > > Our current git workflow is confusing with the *forward branches and > cherry-picking. Its hard to track on what all releases the commit has > gone into unless I do some git log greping. Also, as a contributor, I > endup creating patches for each branch as it doesn’t cleanly apply on > different branches. > > > > I think we should have some guidelines. Here is what I propose. > > > > 1. There should be branch for every major release(ex: 4.3.x, 4.4.x, > 5.0.x,5.1.x) and the minor releases should be tagged accordingly on > the respective branches. > 2. The branch naming convention is to be followed. Many branches > with 4.3, 4.3.0, 4.3.1 etc. is confusing > 3. Cherry-picking should be avoided. In git, when we cherry-pick, > we have two physically distinct commits for the same change or fix and > is difficult to track unless you do cherry-pick -x > 4. There should always be a continous flow from release branches to > master. This doesn’t mean cherry-picking. They should be merged(either > ff or no-ff) which retains the commit ids and easily trackable with > git branch --contains > * Every bug fix should always flow from minimal release uptill > master. A bug isnt fixed until the fix reaches master. > * For ex. A bug 4.2.1 should be committed to > 4.2.x->4.3.x->4.4.x->master > * If someone forgets to do the merge, the next time a new commit is > done this will also get merged. > 5. There should always be a continuous flow from master to feature > branches. Meaning all feature branch owners should proactively take > any new commits from master by doing a merge from master > 6. The commits from feature branch will make to master on code > complete through a merge. > 7. There should never be a merge from master to release branches > 8. Every commit in LTS branch(targetted to any minor release) > should have atleast bug id and correct author information > * Cassandra's template: patch by ; reviewed by > for CASSANDRA- > 9. Once the release branch is created(after code freeze), any bug > in jira can be marked with fix version current release(4.4) only on > RM's approval and only they can go to the release branch. This can be > done through jira and with certain rules.(may be using jira vote?) > this would save the cherry-picking time and another branch maintenance. > > > > Please add your thoughts/suggestions/comments. > > > > Ref: > http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html > https://www.youtube.com/watch?v=AJ-CpGsCpM0 > > ~Rajani > > > > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*
RE: [DISCUSS] Introducing Gerrit for quality? was: [PROPOSAL] Using continuous integration to maintain our code quality...
I think I agree with both of you! In the end, it's a social problem, of actually getting round to doing the reviews: but better tools can help to encourage that. For example, on github, the code review is integrated into the source control: every change is a pull request, and someone has to press the big green button, which acts as a sign-off. Whereas, Review Board may be slightly klunky and adding friction into the process, thus deterring people from doing code review. But even given the best tools in the world, someone still has to do the work... -- Stephen Turner -Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: 11 June 2014 10:52 To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Introducing Gerrit for quality? was: [PROPOSAL] Using continuous integration to maintain our code quality... Sheng, In the end we both want the same thing, which is a higher quality codebase. However i find the technology first approach the wrong approach in this case. Of course supporting tools are needed to make the process more efficient. My main worry here is that the "experts" are not reviewing commits now, why should they start when we have a system like Gerrit in place. As long as all our committers don't take the time to review commits coming into CloudStack, no amount of tooling is going to help improve the code base. It is my opinion that such tooling will not be beneficial to our community unless there is a great willingness to review commits, which there isn't at the moment. Most of the bugs are currently found during the QA phase, which means that they were not found by our committers who have the responsibility to review every incoming commit. (Don't get me wrong, i'm blaming myself as much as anybody else) The next point is the concept of experts. We ask people to become committers because we trust them to act responsibly with regards to the code base. That means they know what they should or shouldn't commit. We should not introduce another level of committers without very carefully thinking about what the criteria are for that particular level and what the responsibilities are. In short, lets show the community that our "experts" are actively reviewing incoming commits and start improving the code base today so we can support them with additional tooling tomorrow. These are some things that we can do without having gerrit and/or PR. * Discus commits on the dev list openly so other people can learn from commonly made mistakes. * Review changes and branches proactively and engage with the contributors * Document intricacies in the codebase that will likely stump new committers. * Refactor code that is not easily maintainable. If we get there, i'm all for setting up whatever tooling we need to facilitate this, but don't let the absence of such tooling be an excuse for not doing what we should be doing. Cheers, Hugo P.S. This is an entirely different discussion than replacing RB with another tool for contributors. Completely +1 to using github PRs or Gerrit for new contributions. On 11 jun. 2014, at 00:56, Sheng Yang wrote: > Hi Hugo, > > The main point I want to bring up an automation tool here is, enforce > mandatory review process and test(regression test probably) to happen > before commit. That would slow down the process of course, but it > should greatly help on code quality. > > Even committers would make mistakes from time to time. By adding and > enforce the review process, we would able to a. reduce the obvious > bugs or potential impact on issues author didn't know about, b. > transfer the knowledge for the project. I really think CloudStack > would going to be a more mature project in the future, but our current > develop process is too random and fail to take the whole control of > the quality. By specifying people in the area to review we should able > to spot error better in the early stage. > > I know integrating the tool would change how people working on > project, since review and testing would be a necessary part of it. The > problem now is a. committers can still push bad commits without > reviewing by experts in the subsystem, b. current reviewboard is too > primitive and overhead for uploading, updating and applying the patch > is too big, and c. reviewboard is not mandatory. I would like to have > devs spend more time on reviewing, by this way at least we can gain a > kind of control over the code base we're working on. > > And correct tool would be important to cut the overhead of our > development process, which can make people more focus on real work. > > In conclusion, I'd like to advocate the enforced(by tool) mandatory > review(and testing integration of course) for every commits, and I >
RE: xapi jar as separate release
This is just the xapi SDK we're talking about, isn't it? Which is BSD licensed. -- Stephen Turner -Original Message- From: Tim Mackey [mailto:tmac...@gmail.com] Sent: 16 July 2014 14:39 To: dev@cloudstack.apache.org Subject: Re: xapi jar as separate release Curious if XAPI being LGPL2 matters for this discussion. http://www.xenproject.org/developers/teams/xapi.html -tim On Wed, Jul 16, 2014 at 9:28 AM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Doh! I mixed up master (4.5) with 4.4 in my e-mail. My mistake. I > understand your question now, Daan. > > On Wednesday, July 16, 2014, Daan Hoogland > wrote: > > > Hey, I missed this mail. Should I have picked something into 4.4 > > before calling a vote? > > > > On Wed, Jul 16, 2014 at 6:42 AM, Mike Tutkowski > > > wrote: > > > That's exactly what I was wondering, Alex. :) > > > > > > > > > On Tue, Jul 15, 2014 at 3:13 PM, Alex Huang > > wrote: > > > > > >> I checked into master the changes that remove our copy and just > > >> use > the > > >> copy the XenServer team checked into maven. Is there any reason > > >> we're talking about this? > > >> > > >> --Alex > > >> > > >> > -Original Message- > > >> > From: David Nalley [mailto:da...@gnsa.us ] > > >> > Sent: Tuesday, July 15, 2014 1:40 AM > > >> > To: dev@cloudstack.apache.org > > >> > Subject: Re: xapi jar as separate release > > >> > > > >> > XAPI is not an apache project. I do not believe that we can > > >> > sanely > > make a > > >> > separate release. Compared to bundling it with our release as > > >> > we We > > have > > >> > essentially 'forked' XAPI from the upstream at Xen Project and > > >> > made > > our > > >> > own changes. Those changes are in the latest version AIUI, but > > >> > not > the > > >> > version that we are currently using. > > >> > > > >> > --David > > >> > > > >> > > > >> > On Mon, Jul 14, 2014 at 6:17 AM, Daan Hoogland < > > daan.hoogl...@gmail.com > > > >> > wrote: > > >> > > LS, > > >> > > > > >> > > One of the issues with the last RC was that the cloudstack > > >> > > xapi > was > > >> > > not a released version (i.e. 6.2.0-1-SNAPSHOT). In the > > >> > > release > build > > >> > > it was numbered as 6.2.0-1 but not referred by that release > > >> > > number > > but > > >> > > by the snapshot id. There are several solutions to this. The > > >> > > most correct would seem to be to release the xapi module > > >> > > separately and create a release for it. I know that there has > > >> > > been some shifting > > back > > >> > > and forth with this module and I would like to get consensus > > >> > > to > > create > > >> > > a separate module and release for it. > > >> > > > > >> > > So my question: How do I get a version into the maven repo? > > >> > > > > >> > > thanks, > > >> > > -- > > >> > > Daan > > >> > > > > > > > > > > > > -- > > > *Mike Tutkowski* > > > *Senior CloudStack Developer, SolidFire Inc.* > > > e: mike.tutkow...@solidfire.com > > > o: 303.746.7302 > > > Advancing the way the world uses the cloud > > > <http://solidfire.com/solution/overview/?video=play>*™* > > > > > > > > -- > > Daan > > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the cloud > <http://solidfire.com/solution/overview/?video=play>*™* >
RE: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases)
In the case that it's a product bug, wouldn't it be better to keep running the test even if you know it's going to fail? That way, you get a consistent view of the overall pass rate from build to build. If you disable all the tests that are failing, you're going to get a 100% pass rate, but you can't see whether your quality is going up or down. -- Stephen Turner -Original Message- From: Gaurav Aradhye [mailto:nore...@reviews.apache.org] On Behalf Of Gaurav Aradhye Sent: 21 July 2014 09:58 To: Girish Shilamkar Cc: Gaurav Aradhye; Hugo Trippaers; cloudstack Subject: Re: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases > On July 21, 2014, 1:03 p.m., Hugo Trippaers wrote: > > Why would we want to disable test cases that fail? Doesn't this mean we > > need to fix something else so they don't fail anymore? Hi Hugo, Whenever we found a test case failing, we create bug for that, may it be a test script issue or product bug, so that the test case gets associated with a particular bug and it's easy to track in future why it is failing. Addition of this decorator BugId to test case skips the test in the run. Whenever the bug gets fixed, then the person who has fixed the bug removes the BugId decorator from test case so that the test case gets picked up in the next run. - Gaurav --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/#review48204 --- On July 17, 2014, 1:17 p.m., Gaurav Aradhye wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/23605/ > --- > > (Updated July 17, 2014, 1:17 p.m.) > > > Review request for cloudstack and Girish Shilamkar. > > > Bugs: CLOUDSTACK-7074 and CLOUDSTACK-7107 > https://issues.apache.org/jira/browse/CLOUDSTACK-7074 > https://issues.apache.org/jira/browse/CLOUDSTACK-7107 > > > Repository: cloudstack-git > > > Description > --- > > Disabling failed test cases on master. > > > Diffs > - > > test/integration/smoke/test_primary_storage.py 66aec59 > test/integration/smoke/test_vm_life_cycle.py 240ab68 > > Diff: https://reviews.apache.org/r/23605/diff/ > > > Testing > --- > > > Thanks, > > Gaurav Aradhye > >
RE: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases)
Tagging is good: that will allow you to see whether a failure is new or known about. Maybe the tag could even contain a date when it was added, to spot failures which are not receiving attention. But I don’t like to see tests skipped whenever we have a bug that is causing them to fail. -- Stephen Turner From: Gaurav Aradhye [mailto:gaurav.arad...@clogeny.com] Sent: 21 July 2014 10:41 To: Stephen Turner; Hugo Trippaers; dev@cloudstack.apache.org; Santhosh Edukulla Cc: Girish Shilamkar Subject: Re: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases) Hugo, Stephen, We have been following this practice as part of Continuous Integration changes as defined in doc [1]. I personally think that tagging test case with BugId is good idea to map the test cases with bugs, but the test case should not be skipped when tagged. We can have discussion on this, and change the process if majority agree. Adding Santhosh. [1]: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Cloudstack+-+Continuous+Integration Regards, Gaurav On Mon, Jul 21, 2014 at 2:37 PM, Stephen Turner mailto:stephen.tur...@citrix.com>> wrote: In the case that it's a product bug, wouldn't it be better to keep running the test even if you know it's going to fail? That way, you get a consistent view of the overall pass rate from build to build. If you disable all the tests that are failing, you're going to get a 100% pass rate, but you can't see whether your quality is going up or down. -- Stephen Turner -Original Message- From: Gaurav Aradhye [mailto:nore...@reviews.apache.org<mailto:nore...@reviews.apache.org>] On Behalf Of Gaurav Aradhye Sent: 21 July 2014 09:58 To: Girish Shilamkar Cc: Gaurav Aradhye; Hugo Trippaers; cloudstack Subject: Re: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases > On July 21, 2014, 1:03 p.m., Hugo Trippaers wrote: > > Why would we want to disable test cases that fail? Doesn't this mean we > > need to fix something else so they don't fail anymore? Hi Hugo, Whenever we found a test case failing, we create bug for that, may it be a test script issue or product bug, so that the test case gets associated with a particular bug and it's easy to track in future why it is failing. Addition of this decorator BugId to test case skips the test in the run. Whenever the bug gets fixed, then the person who has fixed the bug removes the BugId decorator from test case so that the test case gets picked up in the next run. - Gaurav --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/23605/#review48204 --- On July 17, 2014, 1:17 p.m., Gaurav Aradhye wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/23605/ > --- > > (Updated July 17, 2014, 1:17 p.m.) > > > Review request for cloudstack and Girish Shilamkar. > > > Bugs: CLOUDSTACK-7074 and CLOUDSTACK-7107 > https://issues.apache.org/jira/browse/CLOUDSTACK-7074 > https://issues.apache.org/jira/browse/CLOUDSTACK-7107 > > > Repository: cloudstack-git > > > Description > --- > > Disabling failed test cases on master. > > > Diffs > - > > test/integration/smoke/test_primary_storage.py 66aec59 > test/integration/smoke/test_vm_life_cycle.py 240ab68 > > Diff: https://reviews.apache.org/r/23605/diff/ > > > Testing > --- > > > Thanks, > > Gaurav Aradhye > >
RE: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases)
Is there not a way we could have the best of both worlds? Tag them, but leave them running, and reject a check-in if it triggers a failure in an untagged test only? -- Stephen Turner -Original Message- From: Sudha Ponnaganti [mailto:sudha.ponnaga...@citrix.com] Sent: 21 July 2014 12:43 To: dev@cloudstack.apache.org Subject: RE: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases) Hugo, I absolutely agree with you that tests should not be disabled and fixes should be made before check in. As per what Alex has mentioned in his CI enablement mail [1], premise of CI is that it runs at 100% pass rates and if any check in causes failure in CI Run, the bad check-in is easily identified that check-in gets reverted, so rest of the check-ins would move forward so this failure would not block rest of the community and health of branch is maintained. To enable CI in to production, it is absolutely necessary to get 100% pass rate before turning on CI otherwise all master check-ins will halt because of these legacy issues which require some investigation and fixing. If the commit is known then it can be reverted and no need to disable test but this seem to be an old issue but not a current check-in. To me it looks like this is a one off type of thing just to get CI up and running very first time. Once this is fixed and tests are enabled, there should not be any such test disabling in future. Alternatively, If this is too confusing , CI can be stopped now before making in to production and fixes can be done and then enable CI - we have waited long enough and we can wait some more to get these last couple of issues to be fixed before turning on CI. But running CI with arbitrary pass rate is not desirable. It defeats the purpose and hard to manage. Thanks /Sudha [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Development+Process -Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: Monday, July 21, 2014 3:32 AM To: dev@cloudstack.apache.org Subject: Re: Disabling failed test cases (was RE: Review Request 23605: CLOUDSTACK-7107: Disabling failed test cases) Hey Sudha, Sorry, but i disagree. The purpose of tests should not be to get a 100% pass rate. The tests should show an accurate state of the how the tests are doing versus the current state of the branch being tested. If tests fail we should fix why the tests fails and the system should not report an OK in the meantime. Doing so is too confusing, we need to be able to rely on the fact that if the tests report OK everything is actually OK. Cheers, Hugo On 21 jul. 2014, at 12:28, Sudha Ponnaganti wrote: > In the beginning to get CI up and running, it would be ok to disable these > handful of tests while getting fixes in, to achieve 100% pass rates. When > CI runs in production, code changes need to be reverted if there are any > "new" failures to keep CI pass rates at 100% (a known state to make CI > effective). But should not just disable a test and move forward in long run. > > This should not be automated and make it as part of production CI process. > > Thanks > /Sudha > > -Original Message- > From: Santhosh Edukulla [mailto:santhosh.eduku...@citrix.com] > Sent: Monday, July 21, 2014 3:22 AM > To: Gaurav Aradhye; Stephen Turner; Hugo Trippaers; > dev@cloudstack.apache.org > Cc: Girish Shilamkar > Subject: RE: Disabling failed test cases (was RE: Review Request > 23605: CLOUDSTACK-7107: Disabling failed test cases) > > All, > > Alex, wanted to disable test cases in between CI( continuous integration) > runs for the below "reason" for failures. I only, provided a way to achieve > the same using tags, so that it will work for dual purpose, one not to effect > community and can be used in CI as well, it will not effect if some body > wanted to run all test cases immaterial of tags. > > Reason: In CI,automation "auto" kick starts every 3 hours( configurable) and > picks up those delta changes and runs few checks, including sanity. Now, the > idea was to keep baseline of testcases running as always pass. Now between > two CI runs say T1 and T2, if there are "new" failures introduced, it will be > automatically detected with new git changes and bugs are logged automatically > against those check-ins. > > Now, till those bugs gets fixed, those were disabled keeping the baseline as > always pass again. The window to fix those failures( either product or test > case), through triage was almost constant and it need to be done soon, test > cases are then enabled back once fixed, available in next available CI run > again. It was to decide the failures between T1 and T2, as baseline is always > clean a
RE: [DISCUSS][PROPOSAL] git workflow
I agree, every new ticket should be on a new branch. If you have two changesets you might ever want to merge separately, put them on separate branches. -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 24 July 2014 17:30 To: dev Subject: Re: [DISCUSS][PROPOSAL] git workflow On Thu, Jul 24, 2014 at 5:08 PM, Tracy Phillips wrote: > Good read > http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html he agrees with our thread that every work sould start with creating a branch, doesn't he. I think we need to say that a lot of times more. Start a new branch when picking up a ticket. Start a new branch when experimenting on a new feature. Start a new branch when bored. -- Daan
RE: [DISCUSS] git commit proces
I am +1 on the principle. -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 28 July 2014 16:08 To: dev Subject: Re: [DISCUSS] git commit proces Let me explain a little more about this lat mail of mine. I was assuming a lot of context that most people may not have. We want to start working differently with respect to our release procedure and branching habits. The proposals that are out there and about to be voted for are going to require a lot of work of a few people and a lot of discipline from all of us. My idea was to first vote for some of the habits that are part of the gitflow discipline, but I am not strong opinionated about that. I do want to prevent that we go for a grand proposal to completely change our way of moving forward (not just the way we move forward) while there are potentially people opposing to this way of working. So please give a +1/0/-1 to the general idea now, so we fell comfortable spending the time in devising a new release schedule/mechanism. some of the highlights are: it will start with 4.5 (4.4.x will be done with the old manual cherry-pick process) it will require everybody to create a branch for every fix or feature they will contribute. it will require devs to work mainly on a new branch call 'develop' it will be every bodies responsibility to ensure that 'master' is at all times releasable thanks, Daan On Mon, Jul 28, 2014 at 4:39 PM, Daan Hoogland wrote: > I am not for a grand proposal but ok, I can live with it. > > It would be easiest to just vote for using the gitflow model. > Leo is preparing a page on how to do it. I don't know what the status > is on it. The vote for my part would be on the contents of that page. > > On Mon, Jul 28, 2014 at 4:03 PM, Mike Tutkowski > wrote: >> Yeah, I was under the impression this decision would require a vote >> and formal announcement, if it passes. >> >> On Monday, July 28, 2014, Hugo Trippaers wrote: >> >>> Agreed, this kind of important decisions should be made by a vote. >>> >>> Sebastien, Daan, can one of you kick of the vote thread? Preferably >>> with a condensed summary of the thread? >>> >>> Cheers, >>> >>> Hugo >>> >>> >>> On 28 jul. 2014, at 14:07, Ian Duffy >> > >>> wrote: >>> >>> > +1 to what Erik said. >>> > >>> > >>> > On 28 July 2014 13:04, Erik Weber >> > > >>> wrote: >>> > >>> >> On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland >>> >> >> > >>> >> wrote: >>> >> >>> >>> H, >>> >>> >>> >>> I see a lot of commits happening directly on the master branch. >>> >>> Yet there were no counter arguments against the proposed gitflow >>> >>> and the discussion around it. This leaves me with the idea that >>> >>> the thread is largely ignored by the community. It is my >>> >>> understanding that we agreed never to commit anything to master >>> >>> anymore that hasn't been first committed to a branch and is >>> >>> merged back to master (instead of cherry-picked). What mistake in >>> >>> thinking am I making here? >>> >>> >>> >>> >>> >> >>> >> Not familiar with bylaws and the such, but wouldn't a change like >>> >> this require some sort of voting and potentially a more formal >>> >> information? >>> >> >>> >> Requiring everyone to read through a 50+ replies mail thread and >>> comprehend >>> >> it could be a bit much. >>> >> >>> >> I would suggest an updated document that explain the expected workflow. >>> >> >>> >> -- >>> >> Erik >>> >> >>> >>> >> >> -- >> *Mike Tutkowski* >> *Senior CloudStack Developer, SolidFire Inc.* >> e: mike.tutkow...@solidfire.com >> o: 303.746.7302 >> Advancing the way the world uses the cloud >> <http://solidfire.com/solution/overview/?video=play>*™* > > > > -- > Daan -- Daan
RE: [VOTE] git workflow
+1 from me. -- Stephen Turner -Original Message- From: Rajani Karuturi [mailto:rajani.karut...@citrix.com] Sent: 31 July 2014 11:28 To: dev Subject: [VOTE] git workflow Hi All, We had long discussions on the git flow. I tried to capture the summary of it @ http://markmail.org/message/j5z7dxjcqxfkfhpj This is updated on wiki @ https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-ProposedGitflowbasedCheck-inProcess and is up for a vote: Can you share your opinion on the proposal? [ ] +1 approve [ ] +0 no opinion [ ] -1 disapprove (and reason why) Thanks, ~Rajani
RE: [VOTE] git workflow
> From: Sheng Yang [mailto:sh...@yasker.org] > Work need to be tested, but create one branch for every bug seems over doing. > Branch in Git suppose to use with substantial changes. Actually, I don't agree with you on that point. I think git is unusual among source control systems in that the git mantra is that branching and merging are easy and cheap and so everything goes on a new branch and making new branches becomes part of your daily workflow. -- Stephen Turner
RE: [SHOW] Authentication refactoring
Are there any UI changes? Some auth mechanisms might need more than just username and password (RSA token, for example, or even just "give the 1st, 4th and 5th characters"). -- Stephen Turner -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: 12 August 2014 04:51 To: dev Subject: [SHOW] Authentication refactoring Hi, The way we handle login and logout is hardcoded and since there is no APICommand/BaseCmd implementation the apidoc, apidiscovery and other don't discover these apis. For supporting SAML as an authentication mechanism, I've refactored the Auth mechanism as a pluggable service that loads with api-server artifact and both login and logout are now implemented as a pseduo BaseCmd classes. I call them pseudo because their execute() is never called, the authentication guards in ApiServlet class make sure we call an authenticate method of such classes. Since, they are tightly coupled with cloud-server's ApiServlet it only made sense to have the interface definition and implementation within the same package/artifact as well. This also solves the apidoc issue for login/logout and saml related auth apis. I'll merge them after sometime and continue working on saml stuff. Will push the code in the branch "auth-refactor" in an hour for review/testing now. This does not break anything and should not cause any auth related issues for all existing clients. Any suggestions, feedback welcome! Refactoring was pretty straight forward but I'll make sure to write a wiki page on this before merging to master. Regards, Rohit Yadav Software Architect, ShapeBlue M. +41 779015219 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> CSForge - rapid IaaS deployment framework<http://shapeblue.com/csforge/> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
RE: [ACS44][DISCUSS]release 4.4.1
Interestingly, the reason Labour Day is on May 1 in the rest of the world is the same reason it's not in May in the US and Canada, to do with communists and anarchists commemorating a riot in Chicago. See http://en.wikipedia.org/wiki/Labor_Day http://en.wikipedia.org/wiki/Haymarket_affair -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 01 September 2014 09:05 To: dev; Mike Tutkowski Cc: Francois Gaudreault Subject: Re: [ACS44][DISCUSS]release 4.4.1 Hey Mike, You guys are not supposed to add random red holidays to your calendars. You're the commy bashers. May 1st not enough for ya'll? On Mon, Sep 1, 2014 at 12:00 AM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Just an FYI that it's Labor Day Weekend in the U.S., so you might not > get many, if any, replies until Tuesday. > > > On Sat, Aug 30, 2014 at 2:06 PM, Francois Gaudreault < > fgaudrea...@cloudops.com> wrote: > > > On 2014-08-30, 4:01 PM, Daan Hoogland wrote: > > > >> H, > >> > >> How is the felling on list about 4.4.1? Do we have a stable enough > branch > >> 4.4 at this moment? Especially the answer on this of KVM saffy > >> people is appreciated. > >> > >> I am running on 4.4.1 since a week now. I did hit couple small > >> bugs, > but > > no real blocker. We also try to fix the SSL offload code to work > > with projects. We would really really like to get this feature in 4.4.1. > > > > FG > > > > -- > > Francois Gaudreault > > Gestionnaire de Produit | Product Manager - Cloud Platform & > > Services > > t:514-629-6775 > > > > CloudOps Votre partenaire infonuagique | Cloud Solutions Experts > > 420 rue Guy | Montreal | Quebec | H3J 1S6 > > w: cloudops.com | tw: @CloudOps_ > > > > > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkow...@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the cloud > <http://solidfire.com/solution/overview/?video=play>*™* > -- Daan
RE: Clarification on github or and TravisCI
So just to be clear, Sebastien, does that mean it's acceptable for non-committers to submit their code for review via a Github pull request, instead of using ReviewBoard? (I hope so: I think that will make the process easier and so encourage contributions). -- Stephen Turner -Original Message- From: Sebastien Goasguen [mailto:run...@gmail.com] Sent: 02 September 2014 17:19 To: dev@cloudstack.apache.org Subject: Clarification on github or and TravisCI As some of you may have noticed github PR has been turned on for our main repo (it was already the case for the docs repo). In addition, TravisCI config files have been added to master and 4.3 (not yet for 4.4). https://travis-ci.org/apache/cloudstack/builds The Travis jobs, compile cloudstack and deploy the simulator to run the smoke tests. This is an *experimentation* to see how we can change our commit mechanism (pr vs. RB) as well as add CI for every commit. We moved forward with this without a proposal or former vote to get a feel for it and see if it could help. Basically, every pr from a personal fork of cloudstack will trigger a Travis job and the PR will show the Travis job status. The main idea of course being that if the tests pass they we can merge. I personally see it as an addition to Jenkins jobs not a replacement and a quick way to get free CI while we get our act together with a real infra. Comments and help (with tests and travis config) welcome, of course feel free to start sending pr that way knowing that this is still an experiment. ps: thanks to Ian and Rohit for getting it working. -sebastien
RE: Looking for a contacts of Jessica (UI contribution)
It's jessica.w...@citrix.com. -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 09 September 2014 14:57 To: dev Subject: Re: Looking for a contacts of Jessica (UI contribution) do you have a citrix address for her? That's her employer On Tue, Sep 9, 2014 at 3:53 PM, Ilia Shakitko wrote: > How do I contact Jessica Wang? > > I can see her commits in repo, but I can’t get an answer from her > (used this email: > jessicaw...@apache.org<mailto:jessicaw...@apache.org>) or via mailing > list for few weeks ☹ > > Kind regards, > > Ilia Shakitko > Innovation Engineer > LeaseWeb Technologies B.V. > > T: +31 20 316 0235 > > E: i.shaki...@tech.leaseweb.com > W: www.leaseweb.com<http://www.leaseweb.com> > > Luttenbergweg 8, 1101 EC Amsterdam, The Netherlands > > > -- Daan
RE: [DRAFT] Report Q3 Apache Cloudstack
Two trivial typos in this sentence: The comunity decided not to market this release to a bid audience and work on a maintenance release immediately. community (two m's) and big (not bid). -- Stephen Turner -Original Message- From: Trippie [mailto:trip...@gmail.com] On Behalf Of Hugo Trippaers Sent: 10 September 2014 08:38 To: Subject: [DRAFT] Report Q3 Apache Cloudstack Hey All, This is the draft board report for Apache CloudStack for this quarter. Please let me know if you have any feedback. Cheers, Hugo DESCRIPTION Apache CloudStack is open source software designed to deploy and manage large networks of virtual machines, as a highly available, highly scalable Infrastructure as a Service (IaaS) cloud computing platform. ISSUES None CURRENT ACTIVITY * The community is working on maintenance releases for both the 4.3.0 and the 4.4.0 releases. * The agreed release schedule is not met at the moment as we regularly identify quality issues in pending releases. This is an ongoing process, but slowly we are improving our QA processes and introducting more testing capabilities. * Apache CloudStack CloudMonkey 5.2.0 was released on Aug 28 2014. Apache CloudStack CloudMonkey is a CLI tool for interacting with Apache CloudStack and is distributed separate from Apache CloudStack * Apache CloudStack 4.4.0 was released July 26 2014. Some issues were identified with this release after the release. The comunity decided not to market this release to a bid audience and work on a maintenance release immediately. * The community is working with The Linux Foundation to prepare the second European CloudStack Collaboration Conference (CCCEU). CCCEU will planned following ApacheCon in Budapest from November 19 till 21. It will have a new format which will hopefully engage more users and developers. RELEASES Apache CloudStack 4.4.0 was released on July 26, 2014. Apache CloudStack CloudMonkey 5.2.0 was released on Aug 28, 2014 COMMUNITY Including the following additions, CloudStack has 96 (+5) committers and 29 (+1) PMC members. New Committers: Amogh Vasekar (amoghvk) - May 29 Pierre-Luc Dion (pdion891) - June 5 Will Stevens (swill) - June 16 Santhosh Edukulla (santhoshedukulla) - June 24 Rajani Karuturi (rajani) - July 17 New PMC Members: Mark R. Hinkle (mrhinkle) - July 3 The Apache CloudStack project remains a high volume community: //FIXME Old subscribers figures, volumes updated. dev@ 761 729(+32) subs / msgs = Jun: 1852, Jul: 1555, Aug: 1613 users@ 1042(-59) subs / msgs = Jun: 663, Jul: 710, Aug: 640 issues@ 192(+15) subs / msgs = Jun: 1386, Jul: 1381, Aug: 1635 commits@ 202(+8) subs / msgs = Jun: 700, Jul: 790, Aug: 808 marketing@ 178(+15) subs / msgs = Jun: 251, Jul: 189, Aug:99 users-cn@ 508(+40) subs / msgs = Jun: 54, Jul: 133, Aug: 73
RE: Problem of build
Could you send the exact errors? -- Stephen Turner -Original Message- From: yan_5...@163.com [mailto:yan_5...@163.com] Sent: 11 September 2014 08:35 To: dev Subject: Problem of build If I modify a function and make sure the modify is correct,and run "mvn clean install",it will be many kinds of strange error. who can help me? Thanks very much yan_5...@163.com
RE: [CCCEU14] hackathons
Thanks for the pointer, Daan. I'm interested in the API, but when are we planning to do this? On the day before the conference starts? -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 17 September 2014 10:26 To: dev Cc: market...@cloudstack.apache.org Subject: [CCCEU14] hackathons H devs, In the schedule for ccceu there is no hackathon day. The reason is that hackathons have been decreasing in popularity and success. What we do have is; 1. a room for getting together and working on things 2. a planning page for hackathons, which we might hence forth give another name at [1]. At the page, there are 7 subjects there but only one of them has more then one attendee. Please use dev@cloudstack and this page to plan your hackathon/Birds of a feather/workshop/discussion and design sessions. Hope to see you all in Budapest and work with you all. [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Collaboration+Conference+EU -- Daan
RE: [CCCEU14] hackathons
Shall do, but it looks like I don't have wiki edit rights yet. Could you grant them to me? stephen.tur...@citrix.com. Thanks. -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 17 September 2014 14:01 To: dev Subject: Re: [CCCEU14] hackathons We are going to have a launch for organising them. So please add your ideas and find people to join in. I will extend the table on the wiki to include timeslot and leaf room for extra 'contestants' to add their name. On Wed, Sep 17, 2014 at 2:49 PM, Rafael Weingartner < rafaelweingart...@gmail.com> wrote: > Are we going to have hackathons in ccceu in Hungary in November the 19th? > > On Wed, Sep 17, 2014 at 8:29 AM, Stephen Turner > > > wrote: > > > Thanks for the pointer, Daan. I'm interested in the API, but when > > are we planning to do this? On the day before the conference starts? > > > > -- > > Stephen Turner > > > > > > -Original Message- > > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > > Sent: 17 September 2014 10:26 > > To: dev > > Cc: market...@cloudstack.apache.org > > Subject: [CCCEU14] hackathons > > > > H devs, > > > > In the schedule for ccceu there is no hackathon day. The reason is > > that hackathons have been decreasing in popularity and success. What > > we do > have > > is; > > > > 1. a room for getting together and working on things 2. a planning > > page for hackathons, which we might hence forth give another name at [1]. > > > > At the page, there are 7 subjects there but only one of them has > > more > then > > one attendee. Please use dev@cloudstack and this page to plan your > > hackathon/Birds of a feather/workshop/discussion and design sessions. > Hope > > to see you all in Budapest and work with you all. > > > > [1] > > > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Coll > aboration+Conference+EU > > > > -- > > Daan > > > > > > -- > Rafael Weingärtner > -- Daan
RE: [CCCEU14] hackathons
Yes, that's me. Thanks. -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 18 September 2014 08:17 To: dev Subject: Re: [CCCEU14] hackathons Stephen, I see a stephen.turner not a stephen.tur...@citrix.com. Is that you? On Wed, Sep 17, 2014 at 6:26 PM, Stephen Turner wrote: > Shall do, but it looks like I don't have wiki edit rights yet. Could > you grant them to me? stephen.tur...@citrix.com. Thanks. > > -- > Stephen Turner > > > -Original Message- > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > Sent: 17 September 2014 14:01 > To: dev > Subject: Re: [CCCEU14] hackathons > > We are going to have a launch for organising them. So please add your > ideas and find people to join in. I will extend the table on the wiki > to include timeslot and leaf room for extra 'contestants' to add their name. > > On Wed, Sep 17, 2014 at 2:49 PM, Rafael Weingartner < > rafaelweingart...@gmail.com> wrote: > > > Are we going to have hackathons in ccceu in Hungary in November the 19th? > > > > On Wed, Sep 17, 2014 at 8:29 AM, Stephen Turner > > > > > > wrote: > > > > > Thanks for the pointer, Daan. I'm interested in the API, but when > > > are we planning to do this? On the day before the conference starts? > > > > > > -- > > > Stephen Turner > > > > > > > > > -Original Message- > > > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > > > Sent: 17 September 2014 10:26 > > > To: dev > > > Cc: market...@cloudstack.apache.org > > > Subject: [CCCEU14] hackathons > > > > > > H devs, > > > > > > In the schedule for ccceu there is no hackathon day. The reason is > > > that hackathons have been decreasing in popularity and success. > > > What we do > > have > > > is; > > > > > > 1. a room for getting together and working on things 2. a planning > > > page for hackathons, which we might hence forth give another name > > > at > [1]. > > > > > > At the page, there are 7 subjects there but only one of them has > > > more > > then > > > one attendee. Please use dev@cloudstack and this page to plan your > > > hackathon/Birds of a feather/workshop/discussion and design sessions. > > Hope > > > to see you all in Budapest and work with you all. > > > > > > [1] > > > > > > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Co > > ll > > aboration+Conference+EU > > > > > > -- > > > Daan > > > > > > > > > > > -- > > Rafael Weingärtner > > > > > > -- > Daan > -- Daan
RE: [CCCEU14] hackathons
Thanks, Daan, I've added myself to the API session. -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 18 September 2014 14:59 To: dev Subject: Re: [CCCEU14] hackathons you're in On Thu, Sep 18, 2014 at 12:18 PM, Stephen Turner wrote: > Yes, that's me. Thanks. > > -- > Stephen Turner > > > -Original Message- > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > Sent: 18 September 2014 08:17 > To: dev > Subject: Re: [CCCEU14] hackathons > > Stephen, I see a stephen.turner not a stephen.tur...@citrix.com. Is > that you? > > On Wed, Sep 17, 2014 at 6:26 PM, Stephen Turner > > > wrote: > > > Shall do, but it looks like I don't have wiki edit rights yet. Could > > you grant them to me? stephen.tur...@citrix.com. Thanks. > > > > -- > > Stephen Turner > > > > > > -Original Message- > > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > > Sent: 17 September 2014 14:01 > > To: dev > > Subject: Re: [CCCEU14] hackathons > > > > We are going to have a launch for organising them. So please add > > your ideas and find people to join in. I will extend the table on > > the wiki to include timeslot and leaf room for extra 'contestants' > > to add their > name. > > > > On Wed, Sep 17, 2014 at 2:49 PM, Rafael Weingartner < > > rafaelweingart...@gmail.com> wrote: > > > > > Are we going to have hackathons in ccceu in Hungary in November > > > the > 19th? > > > > > > On Wed, Sep 17, 2014 at 8:29 AM, Stephen Turner > > > > > > > > > wrote: > > > > > > > Thanks for the pointer, Daan. I'm interested in the API, but > > > > when are we planning to do this? On the day before the conference > > > > starts? > > > > > > > > -- > > > > Stephen Turner > > > > > > > > > > > > -Original Message- > > > > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > > > > Sent: 17 September 2014 10:26 > > > > To: dev > > > > Cc: market...@cloudstack.apache.org > > > > Subject: [CCCEU14] hackathons > > > > > > > > H devs, > > > > > > > > In the schedule for ccceu there is no hackathon day. The reason > > > > is that hackathons have been decreasing in popularity and success. > > > > What we do > > > have > > > > is; > > > > > > > > 1. a room for getting together and working on things 2. a > > > > planning page for hackathons, which we might hence forth give > > > > another name at > > [1]. > > > > > > > > At the page, there are 7 subjects there but only one of them has > > > > more > > > then > > > > one attendee. Please use dev@cloudstack and this page to plan > > > > your hackathon/Birds of a feather/workshop/discussion and design > > > > sessions. > > > Hope > > > > to see you all in Budapest and work with you all. > > > > > > > > [1] > > > > > > > > > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+ > > > Co > > > ll > > > aboration+Conference+EU > > > > > > > > -- > > > > Daan > > > > > > > > > > > > > > > > -- > > > Rafael Weingärtner > > > > > > > > > > > -- > > Daan > > > > > > -- > Daan > -- Daan
RE: Urgent. Importing certificate to CS 4.3.1 using GUI
Yes, I would like a bug report for this. Please assign it to me. This bit of UI has been rewritten on master, but it should work the same in all browsers, so I'd like to investigate whether it's fixed on master, and also whether there are any other similar controls that aren't working in FF 32. If you can attach a public key and other data that illustrates the problem, that would be great just to make sure that we can repro it. Thank you. -- Stephen Turner -Original Message- From: France [mailto:mailingli...@isg.si] Sent: 25 September 2014 14:52 To: dev@cloudstack.apache.org Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI There is a bug in ACS 4.3.1 GUI. The before mentioned process did not work with Firefox 32.0.2, while it worked on latest Chrome. Because the problem is on the browser side, it did not reach management server logs at all. I have done everything correct. Even a couple of times. ;-) Hopefully this mail will help someone in the future. I would also advise to update the documentation on the issue. Do you want me to open a bug report for this? I am a little reluctant to do so, because some of the bug reports i made previously just sit there for years to come. FYI also got contacted off the mailing list by Steve Roles from ShapeBlue who kindly offered to sell annual 24/7 support to help me sort this issue. Too bad they did not want to provide help/support for this one incident, which which they "have come across" already. They could get payed well for telling me to use another browser. :-) While i appreciate what ShapeBlue does for ACS, they could easily just have told us publicly on the mailing list to use a different browser. Many thanks to anyone else who actually tried to help on the issue. Realhostip.com migration is now officially complete. Regards, F. On 25 Sep 2014, at 14:54, France wrote: > I have created new key and csr. Signed it, converted key to pkcs8 format > without encryption and added in ACS GUI with *.domain.tld and again with > domain.tld. I did copy paste the crt and key with and without -BEGIN > CERTIFICATE-- tags. Nothing works. I have the same GUI error message as > before. Management-log shows no errors or even logs regarding certificate > manipulation. I have not created CA key and certs again. I have confirmed > certificate before importing to ACS using: openssl x509 -in > private/vse.somedomain.tls.crt -noout -text (result below). > > Maybe i could just insert new certs straight into the database, destroy > console proxy and see what happens. > Any more ideas? > > Also there is a bug in 4.3 documentation, because it says one must > enter *.domain.tld while you say, it should be just domain.tld > > " > In the Update SSL Certificate screen of the CloudStack UI, paste the > following: > > * The certificate you've just generated. > * The private key you've just generated. > * The desired domain name, prefixed with *.; for example, > *.consoleproxy.company.com " > > > [root@mc1 private]# openssl x509 -in vse.somedomain.si.crt -noout > -text > Certificate: >Data: >Version: 3 (0x2) >Serial Number: 4097 (0x1001) >Signature Algorithm: sha256WithRSAEncryption >Issuer: C=SI, ST=Slovenia, L=Ljubljana, O=XXX d.o.o., OU=IT > department, CN=optimus.si/emailAddress=sis...@xxxb.si >Validity >Not Before: Sep 25 12:25:32 2014 GMT >Not After : Jun 3 12:25:32 2028 GMT >Subject: C=SI, ST=Slovenia, O=XXX d.o.o., OU=IT department, > CN=*.somedomain.si/emailAddress=sis...@xxxb.si >Subject Public Key Info: >Public Key Algorithm: rsaEncryption >Public-Key: (2048 bit) >Modulus: >00:a8:50:02:21:7a:49:b1:48:07:96:21:87:69:1d: >94:6f:d8:4f:0b:31:f4:8f:6f:e4:b2:78:94:38:d4: >72:92:5b:d5:43:73:aa:e4:33:48:31:11:5a:62:7e: >95:2b:e1:78:11:81:f0:ef:1a:0d:d0:52:90:47:2b: >fd:ab:0d:89:57:fa:ee:6b:3b:d1:24:c9:a9:6d:d6: >fb:0f:14:e3:72:63:a7:75:3d:3e:f5:57:45:09:7e: >83:18:f1:77:c9:3a:1e:de:6f:cd:43:0f:84:11:08: >05:3b:da:ed:3e:a6:65:7c:e9:3f:3b:b9:73:b3:87: >b6:a2:14:af:fd:3e:a9:6f:0f:e4:fb:4d:91:70:d6: >9a:78:b8:00:2e:f0:ad:24:07:01:64:b8:1f:ce:62: >f6:83:e3:fb:45:b9:3e:a1:c3:e6:de:87:d9:37:d3: >28:cf:20:6c:f9:78:5f:24:64:fb:d4:dd:79:90:87: >69:36:ad:83:3d:bd:ab:fd:aa:1d:6a:a6:b8:d5:8a: >f9:d6:e4:f0:db:9a:81:d4:41:e9:19:bf:a5:e8:fb: >d9:f5:e2:50:3c:4d:01:6d:3d
RE: Urgent. Importing certificate to CS 4.3.1 using GUI
Thanks, I've assigned it to myself. -- Stephen Turner -Original Message- From: France [mailto:mailingli...@isg.si] Sent: 26 September 2014 13:44 To: Stephen Turner Cc: dev@cloudstack.apache.org Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI Issue has been created. I would assign it to you, but lack credentials? https://issues.apache.org/jira/browse/CLOUDSTACK-7635 Regards, F. On 26 Sep 2014, at 11:47, Stephen Turner wrote: > Yes, I would like a bug report for this. Please assign it to me. This bit of > UI has been rewritten on master, but it should work the same in all browsers, > so I'd like to investigate whether it's fixed on master, and also whether > there are any other similar controls that aren't working in FF 32. > > If you can attach a public key and other data that illustrates the problem, > that would be great just to make sure that we can repro it. Thank you. > > -- > Stephen Turner > > > -Original Message- > From: France [mailto:mailingli...@isg.si] > Sent: 25 September 2014 14:52 > To: dev@cloudstack.apache.org > Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI > > There is a bug in ACS 4.3.1 GUI. > The before mentioned process did not work with Firefox 32.0.2, while it > worked on latest Chrome. > Because the problem is on the browser side, it did not reach management > server logs at all. > I have done everything correct. Even a couple of times. ;-) > > Hopefully this mail will help someone in the future. I would also advise to > update the documentation on the issue. > > Do you want me to open a bug report for this? I am a little reluctant to do > so, because some of the bug reports i made previously just sit there for > years to come. > > FYI also got contacted off the mailing list by Steve Roles from ShapeBlue who > kindly offered to sell annual 24/7 support to help me sort this issue. > Too bad they did not want to provide help/support for this one incident, > which which they "have come across" already. They could get payed well for > telling me to use another browser. :-) While i appreciate what ShapeBlue does > for ACS, they could easily just have told us publicly on the mailing list to > use a different browser. > > Many thanks to anyone else who actually tried to help on the issue. > Realhostip.com migration is now officially complete. > > Regards, > F. > > On 25 Sep 2014, at 14:54, France wrote: > >> I have created new key and csr. Signed it, converted key to pkcs8 format >> without encryption and added in ACS GUI with *.domain.tld and again with >> domain.tld. I did copy paste the crt and key with and without -BEGIN >> CERTIFICATE-- tags. Nothing works. I have the same GUI error message as >> before. Management-log shows no errors or even logs regarding certificate >> manipulation. I have not created CA key and certs again. I have confirmed >> certificate before importing to ACS using: openssl x509 -in >> private/vse.somedomain.tls.crt -noout -text (result below). >> >> Maybe i could just insert new certs straight into the database, destroy >> console proxy and see what happens. >> Any more ideas? >> >> Also there is a bug in 4.3 documentation, because it says one must >> enter *.domain.tld while you say, it should be just domain.tld >> >> " >> In the Update SSL Certificate screen of the CloudStack UI, paste the >> following: >> >> * The certificate you've just generated. >> * The private key you've just generated. >> * The desired domain name, prefixed with *.; for example, >> *.consoleproxy.company.com " >> >> >> [root@mc1 private]# openssl x509 -in vse.somedomain.si.crt -noout >> -text >> Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: 4097 (0x1001) >> Signature Algorithm: sha256WithRSAEncryption >> Issuer: C=SI, ST=Slovenia, L=Ljubljana, O=XXX d.o.o., OU=IT >> department, CN=optimus.si/emailAddress=sis...@xxxb.si >> Validity >> Not Before: Sep 25 12:25:32 2014 GMT >> Not After : Jun 3 12:25:32 2028 GMT >> Subject: C=SI, ST=Slovenia, O=XXX d.o.o., OU=IT department, >> CN=*.somedomain.si/emailAddress=sis...@xxxb.si >> Subject Public Key Info: >> Public Key Algorithm: rsaEncryption >> Public-Key: (2048 bit) >> Modulus: >> 00:a8:50:02:21:7a:49:b1:48:07:96:21:87:69:1d: >> 94:6f:d8:4f:0b:31:f4:8f:6f:e4:b2:78:94:38:d4: >> 7
RE: Urgent. Importing certificate to CS 4.3.1 using GUI
The UI code on master is different because it was rewritten for the realhostip shutdown. But I will check whether that works properly with Firefox too. -- Stephen Turner -Original Message- From: Sebastien Goasguen [mailto:run...@gmail.com] Sent: 26 September 2014 13:52 To: dev@cloudstack.apache.org Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI On Sep 25, 2014, at 9:52 AM, France wrote: > There is a bug in ACS 4.3.1 GUI. Do you know if this affects 4.4 and master as well ?
RE: Urgent. Importing certificate to CS 4.3.1 using GUI
I'm afraid I couldn't reproduce this, even with your certificate and private key. Everything I tried, I got "Update Certiciate [sic] Succeeded". Does anyone else have a convenient 4.3 and FF 32 that they can try and repro this with? France, if you open the developer tools in Firefox and do this again, do you see any errors? -- Stephen Turner -Original Message- From: France [mailto:mailingli...@isg.si] Sent: 26 September 2014 13:44 To: Stephen Turner Cc: dev@cloudstack.apache.org Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI Issue has been created. I would assign it to you, but lack credentials? https://issues.apache.org/jira/browse/CLOUDSTACK-7635 Regards, F. On 26 Sep 2014, at 11:47, Stephen Turner wrote: > Yes, I would like a bug report for this. Please assign it to me. This bit of > UI has been rewritten on master, but it should work the same in all browsers, > so I'd like to investigate whether it's fixed on master, and also whether > there are any other similar controls that aren't working in FF 32. > > If you can attach a public key and other data that illustrates the problem, > that would be great just to make sure that we can repro it. Thank you. > > -- > Stephen Turner > > > -Original Message- > From: France [mailto:mailingli...@isg.si] > Sent: 25 September 2014 14:52 > To: dev@cloudstack.apache.org > Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI > > There is a bug in ACS 4.3.1 GUI. > The before mentioned process did not work with Firefox 32.0.2, while it > worked on latest Chrome. > Because the problem is on the browser side, it did not reach management > server logs at all. > I have done everything correct. Even a couple of times. ;-) > > Hopefully this mail will help someone in the future. I would also advise to > update the documentation on the issue. > > Do you want me to open a bug report for this? I am a little reluctant to do > so, because some of the bug reports i made previously just sit there for > years to come. > > FYI also got contacted off the mailing list by Steve Roles from ShapeBlue who > kindly offered to sell annual 24/7 support to help me sort this issue. > Too bad they did not want to provide help/support for this one incident, > which which they "have come across" already. They could get payed well for > telling me to use another browser. :-) While i appreciate what ShapeBlue does > for ACS, they could easily just have told us publicly on the mailing list to > use a different browser. > > Many thanks to anyone else who actually tried to help on the issue. > Realhostip.com migration is now officially complete. > > Regards, > F. > > On 25 Sep 2014, at 14:54, France wrote: > >> I have created new key and csr. Signed it, converted key to pkcs8 format >> without encryption and added in ACS GUI with *.domain.tld and again with >> domain.tld. I did copy paste the crt and key with and without -BEGIN >> CERTIFICATE-- tags. Nothing works. I have the same GUI error message as >> before. Management-log shows no errors or even logs regarding certificate >> manipulation. I have not created CA key and certs again. I have confirmed >> certificate before importing to ACS using: openssl x509 -in >> private/vse.somedomain.tls.crt -noout -text (result below). >> >> Maybe i could just insert new certs straight into the database, destroy >> console proxy and see what happens. >> Any more ideas? >> >> Also there is a bug in 4.3 documentation, because it says one must >> enter *.domain.tld while you say, it should be just domain.tld >> >> " >> In the Update SSL Certificate screen of the CloudStack UI, paste the >> following: >> >> * The certificate you've just generated. >> * The private key you've just generated. >> * The desired domain name, prefixed with *.; for example, >> *.consoleproxy.company.com " >> >> >> [root@mc1 private]# openssl x509 -in vse.somedomain.si.crt -noout >> -text >> Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: 4097 (0x1001) >> Signature Algorithm: sha256WithRSAEncryption >> Issuer: C=SI, ST=Slovenia, L=Ljubljana, O=XXX d.o.o., OU=IT >> department, CN=optimus.si/emailAddress=sis...@xxxb.si >> Validity >> Not Before: Sep 25 12:25:32 2014 GMT >> Not After : Jun 3 12:25:32 2028 GMT >> Subject: C=SI, ST=Slovenia, O=XXX d.o.o., OU=IT department, >> CN=*.somedomain.si/emailAddress=sis...@xxxb.si >> Subject Public Key
RE: [VOTE][ACS44]Apache CloudStack 4.4.1 RC 1 in branch 4.4-RC20140924T2100
Can someone who's seeing this confirm whether it's a UI issue, or whether it's the same through the API? The ticket CLOUDSTACK-7219 has Component=Management Server, not UI, and (without having seen it myself) it feels more like a server-side issue to me. -- Stephen Turner -Original Message- From: Pierre-Luc Dion [mailto:pd...@cloudops.com] Sent: 01 October 2014 16:47 To: dev@cloudstack.apache.org Subject: Re: [VOTE][ACS44]Apache CloudStack 4.4.1 RC 1 in branch 4.4-RC20140924T2100 From what I understand from this issue is UI only, which is why it wasn't a blocker before. anyway, you have a valid point :-( now the question would be: who could fix this ? Cluster settings change you are refering are theses [1] , right ? [1] http://cloudstack-release-notes.readthedocs.org/en/4.4.1/upgrade/upgrade_notes.html#settings-changes On Wed, Oct 1, 2014 at 11:33 AM, Erik Weber wrote: > Has been like that since 4.4.0 > > Erik > 1. okt. 2014 17:16 skrev "Geoff Higginbottom" < > geoff.higginbot...@shapeblue.com> følgende: > > > Great, glad to hear it was an easy fix. > > > > Now however I have found another problem. In the UI if I go to > > Infrastructure/Clusters/cluster1/and then choose the settings tab, I > > get > an > > error and no information is displayed. > > > > Can others please check this to see if it is a unique problem to me > > or a common issue. This is on my upgraded install, I'll the check > > the clean install in a few minutes once its power up. > > > > Regards > > > > Geoff Higginbottom > > > > D: +44 20 3603 0542 | S: +44 20 3603 0540 | M: +447968161581 > > > > geoff.higginbot...@shapeblue.com > > > > -Original Message- > > From: Pierre-Luc Dion [mailto:pd...@cloudops.com] > > Sent: 01 October 2014 15:29 > > To: dev@cloudstack.apache.org; Sebastien Goasguen > > Subject: Re: [VOTE][ACS44]Apache CloudStack 4.4.1 RC 1 in branch > > 4.4-RC20140924T2100 > > > > ok, fixed it , /latest is pointing on the master branch for the RN > > git repo. so it's not reflecting the "latest" version of our product. > > I've disable the /latest version so URL will default to 4.4.0 RN > > for > the > > moment, and the 4.4.1 RN is the correct one. > > > > Seb, do you see a problem disabling master and latest build in RTD ? > > > > make more sense? > > > > PL > > > > On Wed, Oct 1, 2014 at 10:00 AM, Geoff Higginbottom < > > geoff.higginbot...@shapeblue.com> wrote: > > > > > Hi Pierre-Luc, > > > > > > Nope, I was deffinately looking at 4.4.1 release notes, complete > > > with sections titled 'Issues fixed in 4.4.1' etc > > > > > > > > > http://cloudstack-release-notes.readthedocs.org/en/latest/upgrade/ > > > upgr > > > ade-4.3.html > > > > > > I would include a screen shot of the page but it will get stripped > > > from the e-mail > > > > > > Regards > > > > > > Geoff Higginbottom > > > > > > D: +44 20 3603 0542 | S: +44 20 3603 0540 | M: +447968161581 > > > > > > geoff.higginbot...@shapeblue.com > > > > > > -Original Message- > > > From: Pierre-Luc Dion [mailto:pd...@cloudops.com] > > > Sent: 01 October 2014 14:49 > > > To: dev@cloudstack.apache.org > > > Subject: Re: [VOTE][ACS44]Apache CloudStack 4.4.1 RC 1 in branch > > > 4.4-RC20140924T2100 > > > > > > Geoff, > > > > > > Could it be possible you've followed 4.4.0 upgrade path ? because > > > we don't have to perform any MySQL query when upgrading to 4.4.1, > > > otherwise the RN is not correct. > > > the current RN for 4.4.1 is: > > > > > > http://docs.cloudstack.apache.org/projects/cloudstack-release-note > > > s/en /4.4.1/ (not /latest yet as it's not release yet) > > > > > > for the vhd-utils, I wasn't sure if it was making sense to keep it > > > on all upgrade path, thanks for the comment, make sense to remove > > > if from upgrade 4.3.x and probably 4.2.x as it should already be in place. > > > > > > > > > PL > > > > > > > > > > > > > > > On Wed, Oct 1, 2014 at 9:35 AM, Geoff Higginbottom < > > > geoff.higginbot...@shapeblue.com> wrote: > > > > > > > +0 only because of the issues in the release notes, a clean > > > > +install and > > > > an upgrade fr
RE: [CCCEU14] hackathons
I just got an email inviting me to register for tutorials on the Wednesday of the conference, but are we planning to do any hackathon-type stuff that day? The interest level on the wiki page seems to be minimal at the moment. :-( -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 17 September 2014 10:26 To: dev Cc: market...@cloudstack.apache.org Subject: [CCCEU14] hackathons H devs, In the schedule for ccceu there is no hackathon day. The reason is that hackathons have been decreasing in popularity and success. What we do have is; 1. a room for getting together and working on things 2. a planning page for hackathons, which we might hence forth give another name at [1]. At the page, there are 7 subjects there but only one of them has more then one attendee. Please use dev@cloudstack and this page to plan your hackathon/Birds of a feather/workshop/discussion and design sessions. Hope to see you all in Budapest and work with you all. [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Collaboration+Conference+EU -- Daan
RE: Urgent. Importing certificate to CS 4.3.1 using GUI
France, I'm sorry, but I'm about to go away for three weeks, and I'm not going to have time to work on this. Is there anyone else who could help France? Is anyone else seeing the problem, because I couldn't reproduce it? -- Stephen Turner -Original Message- From: France [mailto:mailingli...@isg.si] Sent: 08 October 2014 11:44 To: dev@cloudstack.apache.org Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI Send me a private email and you can test it on my exact system with all development options turned on as you wish. We will do it via remote screen sharing, like VNC, RDP, Teamviewer, .. Regards, F. On 26 Sep 2014, at 16:53, Stephen Turner wrote: > I'm afraid I couldn't reproduce this, even with your certificate and private > key. Everything I tried, I got "Update Certiciate [sic] Succeeded". > > Does anyone else have a convenient 4.3 and FF 32 that they can try and repro > this with? > > France, if you open the developer tools in Firefox and do this again, do you > see any errors? > > -- > Stephen Turner > > > -Original Message- > From: France [mailto:mailingli...@isg.si] > Sent: 26 September 2014 13:44 > To: Stephen Turner > Cc: dev@cloudstack.apache.org > Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI > > Issue has been created. > I would assign it to you, but lack credentials? > > https://issues.apache.org/jira/browse/CLOUDSTACK-7635 > > Regards, > F. > > On 26 Sep 2014, at 11:47, Stephen Turner wrote: > >> Yes, I would like a bug report for this. Please assign it to me. This bit of >> UI has been rewritten on master, but it should work the same in all >> browsers, so I'd like to investigate whether it's fixed on master, and also >> whether there are any other similar controls that aren't working in FF 32. >> >> If you can attach a public key and other data that illustrates the problem, >> that would be great just to make sure that we can repro it. Thank you. >> >> -- >> Stephen Turner >> >> >> -Original Message- >> From: France [mailto:mailingli...@isg.si] >> Sent: 25 September 2014 14:52 >> To: dev@cloudstack.apache.org >> Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI >> >> There is a bug in ACS 4.3.1 GUI. >> The before mentioned process did not work with Firefox 32.0.2, while it >> worked on latest Chrome. >> Because the problem is on the browser side, it did not reach management >> server logs at all. >> I have done everything correct. Even a couple of times. ;-) >> >> Hopefully this mail will help someone in the future. I would also advise to >> update the documentation on the issue. >> >> Do you want me to open a bug report for this? I am a little reluctant to do >> so, because some of the bug reports i made previously just sit there for >> years to come. >> >> FYI also got contacted off the mailing list by Steve Roles from ShapeBlue >> who kindly offered to sell annual 24/7 support to help me sort this issue. >> Too bad they did not want to provide help/support for this one incident, >> which which they "have come across" already. They could get payed well for >> telling me to use another browser. :-) While i appreciate what ShapeBlue >> does for ACS, they could easily just have told us publicly on the mailing >> list to use a different browser. >> >> Many thanks to anyone else who actually tried to help on the issue. >> Realhostip.com migration is now officially complete. >> >> Regards, >> F. >> >> On 25 Sep 2014, at 14:54, France wrote: >> >>> I have created new key and csr. Signed it, converted key to pkcs8 format >>> without encryption and added in ACS GUI with *.domain.tld and again with >>> domain.tld. I did copy paste the crt and key with and without -BEGIN >>> CERTIFICATE-- tags. Nothing works. I have the same GUI error message as >>> before. Management-log shows no errors or even logs regarding certificate >>> manipulation. I have not created CA key and certs again. I have confirmed >>> certificate before importing to ACS using: openssl x509 -in >>> private/vse.somedomain.tls.crt -noout -text (result below). >>> >>> Maybe i could just insert new certs straight into the database, destroy >>> console proxy and see what happens. >>> Any more ideas? >>> >>> Also there is a bug in 4.3 documentation, because it says one must >>> enter *.domain.tld while you say, it should be jus
RE: merging versus cherry-picking
I am +1 on using github. I am +1 on all code changes being reviewed by a committer other than the author, as well as undergoing some automated CI testing, before the pull request is merged. I am +0 on only the master RM merging the pull request. I don't want the author to push the code, but I think the code reviewer could do this; in practice the RM will not be able to review everything again so is likely to rubber-stamp the results of the code review / automated testing. But I could live with the master RM doing it for the moment. I am +1 on moving ahead with any of these parts individually, rather than waiting for everything to be in place before doing anything. -- Stephen Turner -Original Message- From: David Nalley [mailto:da...@gnsa.us] Sent: 17 October 2014 01:02 To: dev@cloudstack.apache.org Subject: Re: merging versus cherry-picking I think this needs it's own thread as a [PROPOSAL] So a couple of comments: 1. I think we need to do things in a uniform way. Having patches committed directly, having patches hit RB and having patches hit GH is fail. 2. I think we should gate patches, even from committers. I'd personally like to see ALL code pass a comprehensive testing regimen, as well as be individually reviewed by a committer. That said - I'd rather not let the perfect be the enemy of the good. Some testing is better than none. On Thu, Oct 16, 2014 at 3:23 PM, sebgoa wrote: > > On Oct 16, 2014, at 8:08 PM, Sheng Yang wrote: > >> I totally agree that we should have some staging tree for this >> purpose. But I would prefer deploying gerrit on this rather than >> using github. Also, using gerrit would make it possible to host our >> own Jenkins instance for testing, rather than depends on TravisCI >> which is very limited and shared across all the apache projects as I heard. > > Ok so looks like you are +1 for the general direction. I also agree with this general direction. > > This is going to be a several steps process. While gerrit may end up > being the solution, right now it would require finding infra, > installing software, learning it for those who have not used it yet > etc… > I also have a preference for something more full featured than what we get with GH PR and Travis CI - but frankly it's still better than what we have now. It might be worthwhile to look into [1] which might allow us to use our existing Jenkins instance in the short term. I know that Brooklyn is already using this service, and perhaps others. Gerrit is far more full featured - and I can certainly see us wanting that (as well as a number of other communities at the ASF. > Moving to github PR with a moratorium on master and release branch is only a > matter of agreement that will make us adopt new commit habits. there is no > change of infra/software needed, hence an *easy* step, we just needs +1. Once > we get to a better state of affairs we can improve our infra and processes > with other soft. > >> So moratorium on unreviewed/untested patches = good. Is there a community aspect to people effectively working in forks of our code base in isolation rather than in feature branches in our main code base? (I ask because the easiest method for using GH PR is to use your own fork of the repo. We could have contribs pushed to a feature branch still) [1] https://blogs.apache.org/infra/entry/github_pull_request_builds_now
RE: master broken
If you use github and travis, the way the integration works is that travis builds and tests the code on your own private fork when you submit a pull request. So the results of that inform the decision on whether to accept the pull request into the code. -- Stephen Turner -Original Message- From: Marcus [mailto:shadow...@gmail.com] Sent: 16 October 2014 18:08 To: dev@cloudstack.apache.org Subject: Re: master broken Wouldn't it have to be pushed first to pass any CI testing? So in theory we should never have CI catch compile errors if we don't push code that won't compile.
RE: [PROPOSAL] Move to github PR only during moratorium on commit
As I just said in the other thread -- but to repeat it here in the PROPOSAL thread -- I am +1 on using github pull requests. I am +1 on all code changes being reviewed by a committer other than the author, as well as undergoing some automated CI testing, before the pull request is merged. I am +0 on only the master RM merging the pull request. I don't want the author to push the code, but I think the code reviewer could do this; in practice the RM will not be able to review everything again so is likely to rubber-stamp the results of the code review / automated testing. But I could live with the master RM doing it. I am +1 on moving ahead with any of these parts individually, rather than waiting for everything to be in place before doing anything. -- Stephen Turner -Original Message- From: sebgoa [mailto:run...@gmail.com] Sent: 18 October 2014 10:00 To: dev@cloudstack.apache.org Subject: [PROPOSAL] Move to github PR only during moratorium on commit After [1] I would like to officially bring up the following proposal. [Proposal] All commits come through github PR, *even* for committers. We declare a moratorium period (agreed suspension of activity) during which direct commit to master is forbidden. Only the master RM is allowed to merge PR in master (we define a master RM). If direct commit to master is done, master RM reverts without warning. Same for 4.5 and 4.4. branches. This is drastic and I am sure some folks will not like it, but here is my justification for such a measure: [Reasons]: Our commit and release processes have so far been based on the idea that development happens on master and that a release branch is cut from master (unstable development branch). Then a different set of community members harden the release branch, QA and bring it to GA level. During that time development keeps on going in master. This is an OK process if we have the luxury of having a QA team and can cope with split personality of being developers and release managers. My point of view is that as a community we cannot afford such a split brain organization and our experience overt the last year proves my point (delayed release date, broken builds, features merged without warning...) We can avoid this by cutting a release branch from a stable one (from the start), then as you (Daan) have mentioned several times, fix bugs in the release branch and merge them back in the stable source of the release (be it master). Feature development need to be done outside master, period. Not only for non-committers but also for committers. And merge request need to be called. This will help review and avoid surprises. New git workflow were proposed and shutdown, mostly calling for better CI to solve quality issues. CI will not solve our quality issues alone. We need to better police ourselves. To avoid long discussions, I propose this simple but drastic measure. We move all our commits to github PR until 4.5 is out, this stands for committers and non-committers, direct commits (especially to master) would be reverted immediately. Our development and release process is broken, we cannot continue like this, let's fix it. [1] http://markmail.org/thread/xeliefp3oleq3g54 -sebastien
RE: problem with xapi command in cloudstack
Do you have an error message, Daan? -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 30 January 2015 07:12 To: Tim Mackey Cc: dev; Tim Mackey Subject: problem with xapi command in cloudstack Tim, as you know something about xapi, Would you know if there is a reason a router may not spinup in cloudstack when its dhcp config is 272 k big? -- Daan
RE: Quality improvement meeting this week?
I agree with you, Daan. -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 03 February 2015 12:56 To: dev Subject: Quality improvement meeting this week? H, Last week we had no meeting asaik. I don't think we are dying to have one this week, are we? We should try and adopt and automate the agreed way of working as much as possible and maybe start meeting again when new issues arise. -- Daan
RE: Quality improvement meeting this week?
A good question. I still haven’t seen any reaction to the proposal so far. -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 03 February 2015 13:17 To: dev Subject: Re: Quality improvement meeting this week? glad you do, I was hoping to be more provocative however ;) I don't want this to die out before it has a good spin. Any ideas on how to keep it living? or guarantee a revival? On Tue, Feb 3, 2015 at 2:10 PM, Stephen Turner wrote: > I agree with you, Daan. > > -- > Stephen Turner > > > -Original Message- > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > Sent: 03 February 2015 12:56 > To: dev > Subject: Quality improvement meeting this week? > > H, > > Last week we had no meeting asaik. I don't think we are dying to have one > this week, are we? We should try and adopt and automate the agreed way of > working as much as possible and maybe start meeting again when new issues > arise. > > -- > Daan -- Daan
RE: Autoscaling Bug-Cloudstack-7751
Unfortunately, filing a ticket doesn't make code automatically spring into existence. This is an open source project developed by a community, and we have more incoming requests than we can handle. So you need to discuss it on the dev mailing list first, and then either develop it yourself or persuade other people of its importance so that they want to develop it in preference to all the other features they were planning to write. -- Stephen Turner -Original Message- From: prapul cool [mailto:prapul_cool2...@yahoo.com.INVALID] Sent: 04 March 2015 10:57 To: dev@cloudstack.apache.org; dev-h...@cloudstack.apache.org Subject: Autoscaling Bug-Cloudstack-7751 Hi , Autoscaling with out netscaler - Even though a bug has been registered Cloudstack-7751,there has been no update. Can any one have any idea on this.is there any temporary fix for this. [CLOUDSTACK-7751] Autoscaling without netscaler - ASF JIRA | | | | | | | | | [CLOUDSTACK-7751] Autoscaling without netscaler - ASF JIRAAuto scaling | wizard not available apache cloudstack 4.4.1. no auto scale button | available | | View on issues.apache.org | Preview by Yahoo | | | | Thanks,Prapul
RE: Jira Housekeeping - 'Old Blockers'
-Original Message- From: Erik Weber [mailto:terbol...@gmail.com] Sent: 08 March 2015 19:14 To: dev Subject: Re: Jira Housekeeping - 'Old Blockers' > On Sun, Mar 8, 2015 at 11:50 AM, Rajani Karuturi wrote: > > > I would like to share a blog post I read recently which I believe is > > relevant in this context. > > http://words.steveklabnik.com/how-to-be-an-open-source-gardener > > > > > > I like the 'stale' part > > -- > Erik > I like "People think working on open source is glamorous, but it’s actually not. Working on open source is reading 800 issues over the course of a weekend." -- Stephen Turner
RE: [ASK] Is it possible to sort lists in Cloudstack UI?
I think this would have to be done server-side, and exposed through the API, because the UI can only retrieve 500 rows at a time. -- Stephen Turner -Original Message- From: Paul Shadwell [mailto:p...@shadwell.ch] Sent: 17 March 2015 11:15 To: dev@cloudstack.apache.org Subject: [ASK] Is it possible to sort lists in Cloudstack UI? We have a lot of objects in our Cloudstack environment so when it comes to listing, domains, accounts, networks, volumes, instances etc. it is a laborious task trying to find items because nothing is sorted logically. It would be great to have list tables where you can click the column heading to sort a list based on that column. Thanks for your attention. Paul
RE: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205)
By the way, I don't know if people noticed the XenServer Docker preview last week: http://xenserver.org/blog.html?view=entry&id=85. We might be able to use some of that once it makes it into a release. -- Stephen Turner -Original Message- From: Marcus [mailto:shadow...@gmail.com] Sent: 19 March 2015 03:08 To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Support Docker as a hypervisor in CloudStack ( CloudStack / CLOUDSTACK-8205) +1, I think trying to catch and keep up with all of the great tooling existing for container scheduling is a losing battle. I'm not against implementing it as a hypervisor alongside lxc, but I'm not sure how much value people will find in that compared to the other advanced and purpose-built solutions out there, and to compete with those solutions would be a lot of work if you measure by the effort in those other projects. I like the idea of focusing on making cloudstack an attractive place to host infrastructure for container environments. There have been community members having great success providing and selling container services within CloudStack infrastructure. I do fear a bit that supporting it as a hypervisor will fracture the message a bit or misdirect people away from this option, but it can be overcome. If people see value in making it a top-tier hypervisor, I'm all for that, but my first choice would be to look for integration points with existing, mature technologies. On Mar 18, 2015 5:57 PM, "Nux!" wrote: > +1 Pierre and Sebastien. > We should make sure CoreOS & co run fine on ACS, then let people do > their thing using specific tools. > > Plus I wouldn't like Docker to run straight on shared bare metal > servers (hypervisors), they're not as secure as VMs. > > -- > Sent from the Delta quadrant using Borg technology! > > Nux! > www.nux.ro > > - Original Message - > > From: "Pierre-Luc Dion" > > To: dev@cloudstack.apache.org > > Sent: Thursday, 19 March, 2015 00:39:43 > > Subject: Re: [DISCUSS] Support Docker as a hypervisor in CloudStack > > ( > CloudStack / CLOUDSTACK-8205) > > > I really like Sebastien concept of Container as workload because it > > could be used into an existing cloud without introducing a new > > hypervisor, > also, > > it might be possible to reuse current networking features of cloudstack. > > > > > > > > > > > > > > On Wed, Mar 18, 2015 at 6:35 AM, Sebastien Goasguen > > > > wrote: > > > >> > >> > On Mar 18, 2015, at 10:43 AM, Rohit Yadav > >> > > >> wrote: > >> > > >> > Hi Diwas, > >> > > >> > The idea is to support Docker in ACS, much like LXC since they > >> > are similar (containers). This of course would have some > >> > limitations wrt supporting various network models and disk > >> > operations such as taking snapshot and migrations across hosts. > >> > > >> > ((Btw, you may also consider supporting Bhyve (VMM from FreeBSD > >> > community) in CloudStack using libvirt which is another > >> > interesting > >> > project.)) > >> > > >> > Irrespective of what base OS (RancherOS, CoreOS or Atomic etc) > >> > will > be, > >> > assume it will be at least Linux 3.16. Assume using barebone > >> > technologies instead of relying on other orchestration or high > >> > level systems to control Docker images unless what you're willing > >> > to use are stable enough. > >> > > >> > While it's an open discussion on what the scope or the best way > >> > to do it; IMO, the basic things I'm looking for are: > >> > > >> > - Support Basic networking (supporting at least Linux bridge or > >> > maybe OVS - I'm not sure the best way to do it) > >> > - SystemVMs can be Docker based or VMs running on KVM > >> > - Local or NFS based shared storage. Support basic operations > >> > such as > - > >> > upload/register template, create VMs using template. > >> > - Console proxy support (if possible). > >> > > >> > Since most players in the docker arena are still figuring out > >> > best way to deal with networking and storage, the expectation of > >> > the work is limited to producing an experimental hypervisor plugin. > >> > > >> > For implementation details, read CloudStack 101 on the wiki, see > >> > how plugins are written and follow the LXC plugin implementation > >&
RE: [ANNOUNCE] Rohit Yadav as new PMC member of CloudStack
Congratulations, Rohit, definitely deserved. -- Stephen Turner -Original Message- From: Sebastien Goasguen [mailto:run...@gmail.com] Sent: 27 March 2015 08:08 To: dev@cloudstack.apache.org Subject: [ANNOUNCE] Rohit Yadav as new PMC member of CloudStack The Project Management Committee (PMC) for Apache CloudStack are pleased to announce that Rohit Yadav has accepted our invitation to join the PMC. Please join me in congratulating him. On behalf of the Apache CloudStack PMC
RE: [DISCUSS] Stop using Review Board
+1 from me. All our process discussions over the (Northern Hemisphere) winter agreed that GitHub is the way forward. -- Stephen Turner -Original Message- From: Sebastien Goasguen [mailto:run...@gmail.com] Sent: 27 March 2015 08:52 To: dev@cloudstack.apache.org Subject: [DISCUSS] Stop using Review Board Hi everyone, Since GitHub pull requests have been enabled for cloudstack, we have closed 127 commits. I believe this is a nicer interface, one that folks are used to when contributing to other open source projects. In the meantime, we still have 73 open reviews on Review Board https://reviews.apache.org/ * I propose that we stop using RB all together, and remove any links to it from our website and README. A few of us have tried to close some of the reviews by pinging the authors already. * My second proposition is that we write a comment in all reviews: “Thanks for the patch, the cloudstack community has decided to stop using Review Board in favor of github pull request. You can see to learn how to submit a pull request to cloudstack. Could you move your patch to a PR ? Without response from you we will close this review within 7 days. " There is good contribution guidelines in our docs README: https://github.com/apache/cloudstack-docs -Sebastien
RE: [ANNOUNCE] pull request builder
Nice! -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 14 April 2015 17:07 To: dev Subject: [ANNOUNCE] pull request builder people, there is now a pull request builder active at builds.apache.org. It will detect and build pull requests. It is not yet enabled for simulator or regression tests but those are next steps. regards, -- Daan
RE: xenserver 6.5
I think it should be minimal, because although there are large internal changes (e.g., 3.x kernel, 64-bit dom0, new Xen, new storage datapath, PVHVM mode for RHEL/CentOS 7), the interface is essentially unchanged. -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 20 October 2014 14:32 To: dev Subject: xenserver 6.5 Does anybody (know of) work on supporting xenserver 6.5 or has an idea of how much effort that is going to be? -- Daan
RE: Urgent. Importing certificate to CS 4.3.1 using GUI
I'm still puzzled why it would have worked on my Firefox too. There must be some difference in configuration. -- Stephen Turner -Original Message- From: Amogh Vasekar [mailto:amogh.vase...@citrix.com] Sent: 23 October 2014 16:18 To: dev@cloudstack.apache.org Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI Hi, He certainly is :-) Can you share the screenshot of firebug request and response so as to diagnose better? Also, was the upload call made as admin or regular user? Thanks, Amogh On 10/23/14 3:27 AM, "Suresh Sadhu" wrote: >Thanks France, We(France &myself) have diagnosed the problem and in >firefox after uploading the certificate it shows "HTTP Error 501 Not >implemented" error in api response(firebug output )and > >The request is not reaching the server itself(CS management server and >api server logs not shown any API request details ..) so probably the >failure is due to client side settings or due to some other problem. > >We need to identify reasons for "HTTP error 501 not implemented." >http://www.checkupdown.com/status/E501.html > >Amogh/Nitin : can you please check in which cases this 501 not >implemented will occur. > >Regards >Sadhu > > > > > > > >-Original Message- >From: France [mailto:mailingli...@isg.si] >Sent: 23 October 2014 15:43 >To: dev@cloudstack.apache.org >Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI > >Suresh is awesome. Hope Citrix knows that. :-) We diagnosed the issue >with ACS 4.3.1 and Firefox browser, and Suresh will update this thread >with details. > >Regards, >F. > > >On 15 Oct 2014, at 13:55, France wrote: > >> Because i do not check this mailing list every day due to actual >>payed work, i have not seen your request. >> I will contact you right now. >> >> >> On 08 Oct 2014, at 20:10, Suresh Sadhu wrote: >> >>> Sure Nitin and as of now I didn't hear anything from France. >>> >>> Regards >>> sadhu >>> >>> -Original Message- >>> From: Nitin Mehta [mailto:nitin.me...@citrix.com] >>> Sent: 08 October 2014 21:57 >>> To: dev@cloudstack.apache.org >>> Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI >>> >>> Sadhu - Please do update the thread once you have some observation. >>> Thanks >>> >>> -Nitin >>> >>> On 08/10/14 5:27 AM, "Suresh Sadhu" wrote: >>> >>>> HI France, >>>> >>>> I can help today . >>>> My personal email id is mailtosa...@gmail.com >>>> >>>> >>>> Regards >>>> sadhu >>>> >>>> -Original Message- >>>> From: Stephen Turner [mailto:stephen.tur...@citrix.com] >>>> Sent: 08 October 2014 17:43 >>>> To: dev@cloudstack.apache.org >>>> Subject: RE: Urgent. Importing certificate to CS 4.3.1 using GUI >>>> >>>> France, I'm sorry, but I'm about to go away for three weeks, and >>>> I'm not going to have time to work on this. >>>> >>>> Is there anyone else who could help France? Is anyone else seeing >>>> the problem, because I couldn't reproduce it? >>>> >>>> -- >>>> Stephen Turner >>>> >>>> >>>> >>>> -Original Message- >>>> From: France [mailto:mailingli...@isg.si] >>>> Sent: 08 October 2014 11:44 >>>> To: dev@cloudstack.apache.org >>>> Subject: Re: Urgent. Importing certificate to CS 4.3.1 using GUI >>>> >>>> Send me a private email and you can test it on my exact system with >>>> all development options turned on as you wish. >>>> We will do it via remote screen sharing, like VNC, RDP, Teamviewer, .. >>>> >>>> Regards, >>>> F. >>>> >>>> On 26 Sep 2014, at 16:53, Stephen Turner >>>> >>>> wrote: >>>> >>>>> I'm afraid I couldn't reproduce this, even with your certificate >>>>> and private key. Everything I tried, I got "Update Certiciate >>>>> [sic] Succeeded". >>>>> >>>>> Does anyone else have a convenient 4.3 and FF 32 that they can try >>>>> and repro this with? >>>>> >>>>> France, if you open the developer tools in Firefox and do this >>>>> again, do you see any erro
RE: Question about XenServer plug-ins
I believe it was part of a general clean-up to try and use XenServer public APIs; rather than modify the XenServer itself, which may or may not work in future XenServer versions. -- Stephen Turner -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: 05 November 2014 01:23 To: dev@cloudstack.apache.org Subject: Question about XenServer plug-ins Hi, In XenServerStorageProcessor there are several times when we make calls to XenServer plug-ins (for example, to download a template from secondary storage to a XenServer SR). In Xenserver625StorageProcessor we seem to handle this kind of work in Java code instead of calling into the XenServer plug-ins. I was curious if anyone remembers the history behind this transition? Thanks! -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*
RE: Creating a backup of a hypervisor snapshot
Mike, are you saying that XenCenter disagrees with xe? That doesn't seem right
as they both get their info from the same API. Maybe XenCenter is looking at
something subtly different.
XenCenter is open source (https://github.com/xenserver/xenadmin), so you can
consult the source to see what it's reporting. Or send a screenshot of what
you're looking at and I can find the correct bit of source.
--
Stephen Turner
-Original Message-
From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
Sent: 04 November 2014 17:28
To: dev@cloudstack.apache.org; Edison Su
Subject: Creating a backup of a hypervisor snapshot
Hi,
The standard behavior when we take a snapshot of a volume on XenServer is to
take a hypervisor snapshot of the volume and then copy this snapshot to
secondary storage.
We then try to delete all other hypervisor snapshots for this volume.
I notice the process of deleting all other hypervisor snapshots for this volume
never finds any snapshots to delete and our list of hypervisor snapshots
continues to grow over time for the volume in question.
(Below) Set snapshots = volume.getSnapshots(conn); returns the empty set,
so there's nothing to delete.
However, if I look in XenCenter, I can see hypervisor snapshots for the volume
in question.
It appears we are passing in the correct info to this method, too.
When I use xe, it confirms that the VDI that represents our volume does not
have any snapshots, which seems odds.
protected boolean destroySnapshotOnPrimaryStorageExceptThis(Connection
conn, String volumeUuid, String avoidSnapshotUuid) {
try {
VDI volume = getVDIbyUuid(conn, volumeUuid);
if (volume == null) {
throw new InternalErrorException("Could not destroy snapshot on
volume " + volumeUuid + " due to can not find it");
}
Set snapshots = volume.getSnapshots(conn);
for (VDI snapshot : snapshots) {
try {
if (!snapshot.getUuid(conn).equals(avoidSnapshotUuid)) {
snapshot.destroy(conn);
}
} catch (Exception e) {
String msg = "Destroying snapshot: " + snapshot + " on
primary storage failed due to " + e.toString();
s_logger.warn(msg, e);
}
}
s_logger.debug("Successfully destroyed snapshot on volume: " +
volumeUuid + " execept this current snapshot " + avoidSnapshotUuid);
return true;
} catch (XenAPIException e) {
String msg = "Destroying snapshot on volume: " + volumeUuid + "
execept this current snapshot " + avoidSnapshotUuid + " failed due to " +
e.toString();
s_logger.error(msg, e);
} catch (Exception e) {
String msg = "Destroying snapshot on volume: " + volumeUuid + "
execept this current snapshot " + avoidSnapshotUuid + " failed due to " +
e.toString();
s_logger.warn(msg, e);
}
return false;
}
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*
RE: UI: "CPU (in MHz)" doesn't make sense
Certainly it's wrong at the moment, because XenServer doesn't allow you to change the MHz of the CPU of a VM. Can someone find out which XenServer API calls it actually makes? Then we can work out how to describe it. -- Stephen Turner -Original Message- From: Logan Barfield [mailto:lbarfi...@tqhosting.com] Sent: 10 November 2014 16:24 To: dev@cloudstack.apache.org Subject: Re: UI: "CPU (in MHz)" doesn't make sense I agree completely. We've set all of our service offerings to equal weights, and hard coded the same weight into the custom offering form. It's a bit too confusing otherwise. The way I understand the weights for (Xen/KVM at least) is that they're just relative, so 1 vs 2 is the same as 1 vs 1000. That being the case I'd suggest a solution that has worked for us in the past: set the weight equal to the memory amount (in MB). Thoughts? Thank You, Logan Barfield Tranquil Hosting On Mon, Nov 10, 2014 at 11:17 AM, Nux! wrote: > Hi, > > Basically I'm annoyed with the "CPU (in MHz)" usage in service > offerings as they are a lie basically. > Opened https://issues.apache.org/jira/browse/CLOUDSTACK-7874 and > suggest to have calculated automatically based on CPU cores number or > at least having it renamed to something like "cpu weight". > MHz means nothing. > > Thoughts? > > -- > Sent from the Delta quadrant using Borg technology! > > Nux! > www.nux.ro >
RE: Buda+Pest hackathons
I don't have any particular things, but there are some ideas at https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+changes. I'm flying in on Tuesday, so around all day Wednesday. It seems the tutorials are all at the same time on Wednesday, which is a shame in that I wanted to attend more than one, but will leave plenty of time for these sort of conversations. I hate to ask this in case I'm stirring up a hornet's nest, but is there any value in discussing process things like branching, freezing, code review, automated testing, etc.? Or is it not going to be productive if it's going to have to come back to the mailing list and start again from square one anyway? -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 11 November 2014 16:14 To: dev Subject: Buda+Pest hackathons People, don't forget to lookup and contact people about the subjects you want discussed at CCEU14. I for one want to caal on everybody interested in API refactoring. Can interested people tell whther they have position statements and times of availability? looking forward to it. -- Daan
Re: [DISCUSS] Should we install XenServer tools in systemvmtemplates
I didn't even realise we still support XS 5.6. I would advocate not supporting that any more, independent of this tools discussion, because Citrix won't fix any bugs on it now, even security bugs. Can't we move to a model where we only support hypervisor versions that the hypervisor vendor supports? -- Stephen Turner From: Tim Mackey Date: 21 November 2014 09:38:21 CET To: dev@cloudstack.apache.org Subject: Re: [DISCUSS] Should we install XenServer tools in systemvmtemplates The big problem I recall with the 5.6 Linux tools happened during live migration. I don't recall the specific circumstances, but if the VM was migrated, it could cause either the guest or the host to crash. I've never paid attention to the specific Linux version in the system VMs, but the tools themselves aren't supported for installation on a newer version of an operating system than what was originally certified. XenCenter when faced with 5.6 tools on a 6.2 host would actually say that the tools are there but need to be upgraded for optimal performance. This also opens the question of XCP and the tools since XenServer tools were never designed to work with XCP. They probably do work just fine, but if there was an issue we'd be challenged to get it sorted. If the option of automatically having the tools installed isn't viable, the next things I'd look at would be: - removing support for XenServer versions prior to 6.0 - removing support for XCP (or at least only supporting 1.6) - having the rpm/deb packages for each version of hypervisor pre-loaded (assuming redist EULA) and when a systemVM starts having a first boot which installs the correct package and then reboots the system VM At least that way the tools would be there, and we'd have better system VM performance while still locking ourselves to specific supported hypervisor versions. No idea what impact removal of support for older XenServer versions might have on the install base, but I'd hope those on 5.6 would at least be planning an upgrade given 5.6 went EOL from Citrix a while back. -tim On Fri, Nov 21, 2014 at 3:15 AM, Rohit Yadav wrote: > Tim, during 4.0/4.1 we used to install a very old xstools 5.6, can we just > use that and if we do will that cause any (potential) issue since you > mentioned it has few bugs in it? > > Regards. > > > On 20-Nov-2014, at 10:23 pm, Tim Mackey wrote: > > > > It's the other way around. Newer XenServer works with older tools, not > the > > other way. > > On Nov 20, 2014 4:57 PM, "Rohit Yadav" > wrote: > > > >> If XenServer tools are backward compatible then we can perhaps install > the > >> latest xs-tools (6.2)? Will that cause issue if the underlying > >> Xen/XenServer hypervisor version is not 6.2? > >> > >>> On 20-Nov-2014, at 9:12 pm, Tim Mackey wrote: > >>> > >>> From the XenServer perspective, we have a small problem. The XenServer > >>> tools are backward compatible, but not guaranteed forward compatible. > >> What > >>> that means is we'd need to include the XenServer 5.6 tools, and those > >> have > >>> a commercial license. The XenServer 5.6 tools also have a few bugs > which > >>> were fixed in later versions. > >>> > >>> I'm certain we could define a minimum version which would work, and > could > >>> solve any commercial license concerns, but what about having the system > >> VMs > >>> automatically download and apply the correct tools? Since we know the > >>> hypervisor version, could we even go so far as automatically update the > >>> tools should the hypervisor be upgraded? > >>> > >>> -tim > >>> > >>> On Thu, Nov 20, 2014 at 10:19 AM, Rohit Yadav < > rohit.ya...@shapeblue.com > >>> > >>> wrote: > >>> > >>>> Hi, > >>>> > >>>> During the CCCEU conference, I’ve been in some discussions with few > >> people > >>>> on whether we should install/bundle xenserver tools (and vmware tools > >>>> and/or virtio-modules). > >>>> > >>>> I think we can easily do this, but let’s discuss the following; > >>>> > >>>> - Which version of xs-tools etc. we should install? For the build > >> system, > >>>> is a publicly available source (iso etc)? > >>>> - Will installing these tools cause any issue? > >>>> - If we install all these tools on a single template, could that cause > >> any > >>>> issue? > >>&
RE: [Propose] Improvements in XenServer + ACS integration
Thanks for showing me this at the conference, Marco.
I like the idea of authenticated users, but I haven't understood the role of
the XenServer plugin here. Only a pool admin can call Host.call_plugin, and
pool admins have the same permissions as root, so the plugin can't convey any
additional privileges and I don't see how it acts as a security layer. In
general, I think we should move away from XenServer plugins (and Alex Huang
already made some steps in this direction at the beginning of the year). The
problem with plugins is that if XenServer changes, it may break the plugin, and
we will have to scramble to fix it up when we notice.
You also mentioned xenstore: I would certainly caution against using that,
because it's not supposed to be a public interface.
I guess my philosophy is that we should treat XenServer as a black box as much
as possible, accessible only through the public API. (Of course,
Host.call_plugin is an API call, but you know what I mean). Just because we
know that dom0 is just a Linux box and we can do anything, doesn't mean that
that's good architecture. XenCenter only uses the public API, for example. And
if the public API doesn't provide something we really need, we should advocate
to the upstream project to change it, or even submit a patch as XenServer is
open source too.
--
Stephen Turner
-Original Message-
From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
Sent: 24 November 2014 08:44
To: dev@cloudstack.apache.org
Subject: Re: [Propose] Improvements in XenServer + ACS integration
Great idea and work Marco!
The gist of the proposal is that we can allow non-root users to add hosts and
Marco successfully shows us how that is possible.
> On 23-Nov-2014, at 5:42 pm, Marco Sinhoreli
> wrote:
>
> Hi community,
>
> I'm starting this discussion to share some ideas about XenServer integration
> in ACS. Since XenServer has some nice features to do that like RBAC, host
> plugin and XenStore, I demonstrate these to some community members at CCCEU14.
>
> Some references you can look in these links:
> https://blog.xenproject.org/2011/11/09/xcp-rbac-and-pam-authentication
> -in-the-xenapi/ https://wiki.xenserver.org/index.php?title=RBAC
> http://wiki.xen.org/wiki/XAPI_Host_Plugins
> http://wiki.xen.org/wiki/XenStore
>
> Actual status in ACS:
> During the XenServer setup, is possible to define a user to connect to the
> xapi. In XenCenter, is possible to use a different user (no-root) using
> external authentication like AD our PAM since the RBAC is configured properly
> for this. In ACS it's not possible because many command need be called by
> root using SSH. Another issue in this approach is about security: root
> password is stored in DB and, in this approach we have a security compliance
> issue. The root used used to call shell scripts in the XenServer host are all
> hard-coded.
>
> What we can do?
> - Substitute host SSH connection to XAPI host plugins In my view, I
> prefer use just one-way to connect to XenServer, in this case, changing host
> SSH interactions to use exclusively XAPI. XAPI implements Host Plugins where
> could be used to as a security layer to call commands into host.
>
> An example of host plugin:
> # cat xen_plugin_demo
> #!/usr/bin/python
>
> import XenAPIPlugin
> import subprocess
>
> def main(session, args):
> try:
> p = subprocess.Popen(args["cmd"].split(" "), stdout=subprocess.PIPE,
> stderr=subprocess.PIPE) out, err = p.communicate()
> return out
> except KeyError:
> raise RuntimeError("No argument found with key.")
>
> if __name__ == "__main__":
> XenAPIPlugin.dispatch({"main": main})
>
> And a client:
> $ cat call_plugin.py
> import XenAPI
> import sys
>
> session =
> XenAPI.Session('https://secure-web.cisco.com/11oaIT0CArnYayDlQLndB8lR7
> lQ49gVxf2sio9aLIq1ZY2HcalTSEU-sxMWIGBtez69UyOkhjgoSY99b9P1H6x2vKiMGr79
> TzSNVYdOK6BkY9mgKMi7MzA4LLWJmuMWocGWgyzznE_PdtwBz0xBzr3DuVUqw_OGIWtIDN
> Gb6O0HA/https%3A%2F%2F192.168.56.12')
> session.login_with_password('cloud', 'password') host, =
> session.xenapi.host.get_all()
>
> print
> print session.xenapi.host.call_plugin(host, 'xen_plugin_demo', 'main',
> {'cmd' : " ".join(sys.argv[1:])})
>
> Calling:
> $ python call_plugin.py ls /root
>
> add_roles.sh
> support.tar.bz2
>
> - Setup RBAC to use a non-root to manage the XenServer host As a
> suggestion, for this approach, need to have a user pre-seted in PAM or
> configure XenServer AD. Follow what need be running in the XenServer shell to
> setup the user, external auth, associate RBAC role
RE: [VOTE] Simplify CloudMonkey's branching/maintenance process
+1 as long as CloudMonkey remains backwards compatible with older CloudStack releases, so that we don't have to preserve old monkeys to talk to old stacks. -- Stephen Turner -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: 09 December 2014 13:26 To: dev Subject: [VOTE] Simplify CloudMonkey's branching/maintenance process Hi, CloudMonkey's git repo history is mostly linear and the work on master is simply getting synced on 5.3 branch. I want to ask the community if anyone has any objections on just keeping master as the working branch and have branches when they are needed (say documentation, feature work etc) and once they are merged they can be removed. We have git tags to identify past release so is it also alright with everyone to remove the support branches such as 5.3/5.2 etc. This way we will have: - one main working branch (master) - branch based workflow: feature branches for doing feature work, pull requests or reviewboard for bugfixes for non-committers - master is aimed to remain stable - master will have its own TravisCI and tests (in upcoming weeks) - CloudMonkey aims for progressive/rolling releases that are backward compatible with older releases and have clean upgrades For this please vote with your comments/suggestions; +1 approve +0 no opinion -1 disapprove (and reason why) Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 8826230892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab PS. If you see any footer below, I did not add it :) Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
RE: CloudStack Quality Process
Were we planning to have another meeting at the same time tomorrow (2014-12-17T17:00Z)? Animesh, can you set up a GTM again? (Hoping that no-one's going to complain about my date format if I follow ISO 8601). -- Stephen Turner -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: 11 December 2014 07:23 To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: RE: CloudStack Quality Process Don’t worry the first meeting went all over and the wiki needs a lot of cleanup and capture of discussion that we had. Stay tuned > -Original Message- > From: Rajani Karuturi [mailto:raj...@apache.org] > Sent: Wednesday, December 10, 2014 8:48 PM > To: dev@cloudstack.apache.org > Cc: Steve Wilson > Subject: Re: CloudStack Quality Process > > Thanks for sharing the notes. Sorry, I couldn't make it this time. > Will definitely plan to join the next meeting. > > ~Rajani > > On Thu, Dec 11, 2014 at 1:27 AM, Animesh Chaturvedi < > animesh.chaturv...@citrix.com> wrote: > > > Folks > > > > We had good initial session this morning and we have started a > > public wiki [1] to allow us to collaborate. It is a scratch pad for > > start and we all will refine it as we go along. The link to > > recording and the chat log from today's meeting are also referenced in the > > wiki. > > > > [1] > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quality+and+P > > ro > > cess+Improvement+Initiative > > > > > > > -Original Message- > > > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] > > > Sent: Wednesday, December 10, 2014 9:05 AM > > > To: dev@cloudstack.apache.org > > > Cc: Steve Wilson > > > Subject: RE: CloudStack Quality Process > > > > > > The meeting is on ... > > > > > > > -Original Message- > > > > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] > > > > Sent: Tuesday, December 09, 2014 8:56 PM > > > > To: dev@cloudstack.apache.org > > > > Cc: Steve Wilson > > > > Subject: RE: CloudStack Quality Process > > > > > > > > Yes I am planning to record the GTM > > > > > > > > > -Original Message- > > > > > From: Will Stevens [mailto:williamstev...@gmail.com] > > > > > Sent: Tuesday, December 09, 2014 6:59 PM > > > > > To: dev@cloudstack.apache.org > > > > > Cc: Steve Wilson > > > > > Subject: RE: CloudStack Quality Process > > > > > > > > > > Is it possible to record the meeting? Maybe we can post it so > > > > > others can view it if they are not able to attend (or only > > > > > become interested after the first couple meetings and wants to catch > > > > > up)? > > > > > > > > > > Will > > > > > On Dec 9, 2014 9:52 PM, "Animesh Chaturvedi" > > > > > > > > > > wrote: > > > > > > > > > > > I can setup a GTM since it is free for Citrix. > > > > > > > > > > > > Here are the details. > > > > > > > > > > > > 1. Please join my meeting. > > > > > > https://www1.gotomeeting.com/join/285394368 > > > > > > > > > > > > 2. Use your microphone and speakers (VoIP) - a headset is > > recommended. > > > > > > Or, call in using your telephone. > > > > > > > > > > > > United States: +1 (213) 493-0008 Argentina (toll-free): 0 > > > > > > 800 > > > > > > 444 2385 Australia (toll-free): 1 800 > > > > > > 191 358 > > > > > > Australia: +61 2 9091 7603 > > > > > > Austria (toll-free): 0 800 080061 > > > > > > Austria: +43 (0) 7 2088 0716 Bahrain (toll-free): 800 81 305 > > > > > > Belarus (toll-free): 8 820 > > > > > > 0011 0331 Belgium (toll-free): 0 800 > > > > > > 81388 > > > > > > Belgium: +32 (0) 28 08 4372 > > > > > > Brazil (toll-free): 0 800 047 4909 Bulgaria (toll-free): > > > > > > 00800 > > > > > > 120 > > > > > > 4413 Canada (toll-free): 1 877 777 > > > > > > 3281 > > > > > > Canada: +1 (647) 497-9380 > > > > > > Chile (toll-free): 800 395 146 China (toll-free): 4008 > > > > > > 866154 Colombia
RE: CloudStack Quality Process
The recording is at the bottom of https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quality+and+Process+Improvement+Initiative. -- Stephen Turner -Original Message- From: Nux! [mailto:n...@li.nux.ro] Sent: 16 December 2014 13:53 To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: Re: CloudStack Quality Process Thanks, I'll also want to watch the recording. -- Sent from the Delta quadrant using Borg technology! Nux! www.nux.ro - Original Message - > From: "Animesh Chaturvedi" > To: dev@cloudstack.apache.org > Cc: "Steve Wilson" > Sent: Wednesday, 10 December, 2014 04:55:31 > Subject: RE: CloudStack Quality Process > Yes I am planning to record the GTM > >> -Original Message- >> From: Will Stevens [mailto:williamstev...@gmail.com] >> Sent: Tuesday, December 09, 2014 6:59 PM >> To: dev@cloudstack.apache.org >> Cc: Steve Wilson >> Subject: RE: CloudStack Quality Process >> >> Is it possible to record the meeting? Maybe we can post it so others >> can view it if they are not able to attend (or only become interested >> after the first couple meetings and wants to catch up)? >> >> Will >> On Dec 9, 2014 9:52 PM, "Animesh Chaturvedi" >> >> wrote: >> >> > I can setup a GTM since it is free for Citrix. >> > >> > Here are the details. >> > >> > 1. Please join my meeting. >> > https://www1.gotomeeting.com/join/285394368 >> > >> > 2. Use your microphone and speakers (VoIP) - a headset is recommended. >> > Or, call in using your telephone. >> > >> > United States: +1 (213) 493-0008 >> > Argentina (toll-free): 0 800 444 2385 Australia (toll-free): 1 800 >> > 191 358 >> > Australia: +61 2 9091 7603 >> > Austria (toll-free): 0 800 080061 >> > Austria: +43 (0) 7 2088 0716 >> > Bahrain (toll-free): 800 81 305 >> > Belarus (toll-free): 8 820 0011 0331 Belgium (toll-free): 0 800 >> > 81388 >> > Belgium: +32 (0) 28 08 4372 >> > Brazil (toll-free): 0 800 047 4909 >> > Bulgaria (toll-free): 00800 120 4413 Canada (toll-free): 1 877 777 >> > 3281 >> > Canada: +1 (647) 497-9380 >> > Chile (toll-free): 800 395 146 >> > China (toll-free): 4008 866154 >> > Colombia (toll-free): 01 800 012 9057 Czech Republic (toll-free): >> > 800 500453 Denmark (toll-free): 8025 0919 >> > Denmark: +45 (0) 69 91 84 58 >> > Finland (toll-free): 0 800 94473 >> > Finland: +358 (0) 931 58 1773 >> > France (toll-free): 0 805 541 052 >> > France: +33 (0) 170 950 590 >> > Germany (toll-free): 0 800 184 4230 >> > Germany: +49 (0) 692 5736 7300 >> > Greece (toll-free): 00 800 4414 4282 Hong Kong (toll-free): >> > 30774812 Hungary (toll-free): (06) 80 986 259 Iceland (toll-free): >> > 800 9993 India (toll-free): 000 800 100 8227 Indonesia (toll-free): >> > 001 803 020 2563 Ireland (toll-free): 1 800 818 >> > 263 >> > Ireland: +353 (0) 15 133 006 >> > Israel (toll-free): 1 809 388 020 >> > Italy (toll-free): 800 792289 >> > Italy: +39 0 699 26 68 65 >> > Japan (toll-free): 0 120 242 200 >> > Korea, Republic of (toll-free): 0806180880 Luxembourg (toll-free): >> > 800 >> > 81016 Malaysia (toll-free): 1 800 81 6860 Mexico (toll-free): 01 >> > 800 >> > 123 8367 Netherlands (toll-free): 0 800 020 0178 >> > Netherlands: +31 (0) 208 080 759 >> > New Zealand (toll-free): 0 800 47 0051 New Zealand: +64 (0) 9 974 >> > 9579 Norway (toll-free): 800 69 055 >> > Norway: +47 21 04 30 59 >> > Panama (toll-free): 001 800 507 2789 Peru (toll-free): 0 800 55253 >> > Philippines (toll-free): 1 800 1110 1565 Poland (toll-free): 00 800 >> > 3211434 Portugal (toll-free): 800 180 139 Romania (toll-free): 0 >> > 800 >> > 410 025 Russian Federation (toll-free): 8 800 100 6914 Saudi Arabia >> > (toll-free): 800 844 3636 Singapore (toll-free): 800 101 3000 South >> > Africa (toll-free): 0 800 555 451 Spain (toll-free): 800 900 593 >> > Spain: +34 931 76 1534 >> > Sweden (toll-free): 020 794 545 >> > Sweden: +46 (0) 852 500 691 >> > Switzerland (toll-free): 0 800 000 452 >> > Switzerland: +41 (0) 435 0026 89 >> > Taiwan (toll-free): 0 800 666 846 >> > Thailand (toll-free): 001 800 852 2442 Turkey (toll-free): 00 800 >> > 4488 >> > 29001 Ukraine (toll-free): 0 800 50 4691 United Arab Emirates >> > (toll-free): 800 044 40444 United Kingdom (toll-fr
RE: Deploy new VM - click on Finish - nothing happens !
I've responded on the ticket. -- Stephen Turner -Original Message- From: Andrija Panic [mailto:andrija.pa...@gmail.com] Sent: 17 December 2014 09:28 To: dev@cloudstack.apache.org; us...@cloudstack.apache.org Subject: Deploy new VM - click on Finish - nothing happens ! Hi, I managed to capture some (bug?) - you start new VM wizard, click all the way through the end, and after pressing the FINISH button - simply nothing happens, no spining weel in UI, nothing... Here is my comment - please check this - seems pretty annoying for end user... https://issues.apache.org/jira/browse/CLOUDSTACK-7907?focusedCommentId=14249648&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14249648 Thanks -- Andrija Panić
RE: CloudStack Quality Process
I've set up a GTM for this meeting. 1. Please join my meeting. https://www1.gotomeeting.com/join/759444232 2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone. United States: +1 (646) 749-3129 Argentina (toll-free): 0 800 266 1382 Australia (toll-free): 1 800 193 385 Australia: +61 2 8355 1020 Austria (toll-free): 0 800 202148 Austria: +43 (0) 7 2088 1047 Bahrain (toll-free): 800 81 111 Belarus (toll-free): 8 820 0011 0214 Belgium (toll-free): 0 800 26116 Belgium: +32 (0) 28 08 4368 Brazil (toll-free): 0 800 047 4906 Bulgaria (toll-free): 00800 120 4417 Canada (toll-free): 1 888 455 1389 Canada: +1 (647) 497-9353 Chile (toll-free): 800 395 150 China (toll-free): 4008 811084 Colombia (toll-free): 01 800 012 9054 Czech Republic (toll-free): 800 500448 Denmark (toll-free): 8090 1924 Denmark: +45 (0) 69 91 89 28 Finland (toll-free): 0 800 94507 Finland: +358 (0) 942 59 7850 France (toll-free): 0 805 541 047 France: +33 (0) 170 950 594 Germany (toll-free): 0 800 723 5270 Germany: +49 (0) 692 5736 7317 Greece (toll-free): 00 800 4414 3838 Hong Kong (toll-free): 30713169 Hungary (toll-free): (06) 80 986 255 Iceland (toll-free): 800 9869 India (toll-free): 000 800 100 7855 Indonesia (toll-free): 007 803 011 0395 Ireland (toll-free): 1 800 946 538 Ireland: +353 (0) 19 030 010 Israel (toll-free): 1 809 212 875 Italy (toll-free): 800 793887 Italy: +39 0 247 92 13 01 Japan (toll-free): 0 120 663 800 Korea, Republic of (toll-free): 0806150880 Luxembourg (toll-free): 800 22104 Malaysia (toll-free): 1 800 81 6851 Mexico (toll-free): 01 800 925 0372 Netherlands (toll-free): 0 800 020 0182 Netherlands: +31 (0) 208 080 219 New Zealand (toll-free): 0 800 47 0011 New Zealand: +64 (0) 9 280 6302 Norway (toll-free): 800 69 046 Norway: +47 75 80 32 07 Panama (toll-free): 00 800 226 8832 Peru (toll-free): 0 800 54682 Philippines (toll-free): 1 800 1651 0716 Poland (toll-free): 00 800 1213979 Portugal (toll-free): 800 784 461 Romania (toll-free): 0 800 410 029 Russian Federation (toll-free): 810 800 29674011 Saudi Arabia (toll-free): 800 844 3633 Singapore (toll-free): 800 101 2992 South Africa (toll-free): 0 800 983 867 Spain (toll-free): 800 900 582 Spain: +34 911 82 9906 Sweden (toll-free): 020 980 772 Sweden: +46 (0) 852 500 186 Switzerland (toll-free): 0 800 740 393 Switzerland: +41 (0) 435 0167 13 Taiwan (toll-free): 0 800 666 854 Thailand (toll-free): 001 800 658 131 Turkey (toll-free): 00 800 4488 23683 Ukraine (toll-free): 0 800 50 0641 United Arab Emirates (toll-free): 800 044 40439 United Kingdom (toll-free): 0 808 168 0229 United Kingdom: +44 (0) 20 7151 1853 United States (toll-free): 1 877 309 2073 Uruguay (toll-free): 000 413 598 4110 Viet Nam (toll-free): 120 32 153 Access Code: 759-444-232 Audio PIN: Shown after joining the meeting Meeting ID: 759-444-232 GoToMeeting® Online Meetings Made Easy® Not at your computer? Click the link to join this meeting from your iPhone®, iPad® or Android® device via the GoToMeeting app. -- Stephen Turner -Original Message- From: Stephen Turner [mailto:stephen.tur...@citrix.com] Sent: 16 December 2014 13:03 To: dev@cloudstack.apache.org Subject: RE: CloudStack Quality Process Were we planning to have another meeting at the same time tomorrow (2014-12-17T17:00Z)? Animesh, can you set up a GTM again? (Hoping that no-one's going to complain about my date format if I follow ISO 8601). -- Stephen Turner -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: 11 December 2014 07:23 To: dev@cloudstack.apache.org Cc: Steve Wilson Subject: RE: CloudStack Quality Process Don’t worry the first meeting went all over and the wiki needs a lot of cleanup and capture of discussion that we had. Stay tuned > -Original Message- > From: Rajani Karuturi [mailto:raj...@apache.org] > Sent: Wednesday, December 10, 2014 8:48 PM > To: dev@cloudstack.apache.org > Cc: Steve Wilson > Subject: Re: CloudStack Quality Process > > Thanks for sharing the notes. Sorry, I couldn't make it this time. > Will definitely plan to join the next meeting. > > ~Rajani > > On Thu, Dec 11, 2014 at 1:27 AM, Animesh Chaturvedi < > animesh.chaturv...@citrix.com> wrote: > > > Folks > > > > We had good initial session this morning and we have started a > > public wiki [1] to allow us to collaborate. It is a scratch pad for > > start and we all will refine it as we go along. The link to > > recording and the chat log from today's meeting are also referenced in the > > wiki. > > > > [1] > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quality+and+P > > ro > > cess+Improvement+Initiative > > > > > > > -Original Message- > > > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] > >
RE: CloudStack Quality Process
17:00 - 18:00 GMT, right? -- Stephen Turner -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: 07 January 2015 06:04 To: dev@cloudstack.apache.org Subject: RE: CloudStack Quality Process We can use the following GTM for tomorrow's session 1. Please join my meeting. https://www1.gotomeeting.com/join/411279368 2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone. United States: +1 (571) 317-3129 Argentina (toll-free): 0 800 266 1382 Australia (toll-free): 1 800 193 385 Australia: +61 2 8355 1020 Austria (toll-free): 0 800 202148 Austria: +43 (0) 7 2088 1047 Bahrain (toll-free): 800 81 111 Belarus (toll-free): 8 820 0011 0214 Belgium (toll-free): 0 800 81385 Belgium: +32 (0) 28 08 4368 Brazil (toll-free): 0 800 047 4906 Bulgaria (toll-free): 00800 120 4417 Canada (toll-free): 1 888 455 1389 Canada: +1 (647) 497-9353 Chile (toll-free): 800 395 150 China (toll-free): 4008 811084 Colombia (toll-free): 01 800 012 9054 Czech Republic (toll-free): 800 500448 Denmark (toll-free): 8090 1924 Denmark: +45 (0) 69 91 89 28 Finland (toll-free): 0 800 94507 Finland: +358 (0) 942 59 7850 France (toll-free): 0 805 541 047 France: +33 (0) 170 950 594 Germany (toll-free): 0 800 184 4222 Germany: +49 (0) 692 5736 7317 Greece (toll-free): 00 800 4414 3838 Hong Kong (toll-free): 30713169 Hungary (toll-free): (06) 80 986 255 Iceland (toll-free): 800 9869 India (toll-free): 000 800 100 7855 Indonesia (toll-free): 007 803 011 0395 Ireland (toll-free): 1 800 946 538 Ireland: +353 (0) 19 030 010 Israel (toll-free): 1 809 212 875 Italy (toll-free): 800 906959 Italy: +39 0 247 92 13 01 Japan (toll-free): 0 120 663 800 Korea, Republic of (toll-free): 0806150880 Luxembourg (toll-free): 800 22104 Malaysia (toll-free): 1 800 81 6851 Mexico (toll-free): 01 800 925 0372 Netherlands (toll-free): 0 800 265 8469 Netherlands: +31 (0) 208 080 219 New Zealand (toll-free): 0 800 47 0011 New Zealand: +64 (0) 9 280 6302 Norway (toll-free): 800 69 046 Norway: +47 75 80 32 07 Panama (toll-free): 00 800 226 8832 Peru (toll-free): 0 800 54682 Philippines (toll-free): 1 800 1651 0716 Poland (toll-free): 00 800 1213979 Portugal (toll-free): 800 784 461 Romania (toll-free): 0 800 410 029 Russian Federation (toll-free): 810 800 29674011 Saudi Arabia (toll-free): 800 844 3633 Singapore (toll-free): 800 101 2992 South Africa (toll-free): 0 800 983 867 Spain (toll-free): 800 900 582 Spain: +34 911 82 9906 Sweden (toll-free): 020 980 772 Sweden: +46 (0) 852 500 186 Switzerland (toll-free): 0 800 740 393 Switzerland: +41 (0) 435 0167 13 Taiwan (toll-free): 0 800 666 854 Thailand (toll-free): 001 800 658 131 Turkey (toll-free): 00 800 4488 23683 Ukraine (toll-free): 0 800 50 0641 United Arab Emirates (toll-free): 800 044 40439 United Kingdom (toll-free): 0 808 168 0229 United Kingdom: +44 (0) 330 221 0088 United States (toll-free): 1 877 309 2073 Uruguay (toll-free): 000 413 598 4110 Viet Nam (toll-free): 120 32 153 Access Code: 411-279-368 Audio PIN: Shown after joining the meeting Meeting ID: 411-279-368 GoToMeeting® Online Meetings Made Easy® Not at your computer? Click the link to join this meeting from your iPhone®, iPad® or Android® device via the GoToMeeting app. > -Original Message- > From: Stephen Turner [mailto:stephen.tur...@citrix.com] > Sent: Wednesday, December 17, 2014 7:41 AM > To: dev@cloudstack.apache.org > Subject: RE: CloudStack Quality Process > > I've set up a GTM for this meeting. > > 1. Please join my meeting. > https://www1.gotomeeting.com/join/759444232 > > 2. Use your microphone and speakers (VoIP) - a headset is > recommended. Or, call in using your telephone. > > United States: +1 (646) 749-3129 > Argentina (toll-free): 0 800 266 1382 > Australia (toll-free): 1 800 193 385 > Australia: +61 2 8355 1020 > Austria (toll-free): 0 800 202148 > Austria: +43 (0) 7 2088 1047 > Bahrain (toll-free): 800 81 111 > Belarus (toll-free): 8 820 0011 0214 > Belgium (toll-free): 0 800 26116 > Belgium: +32 (0) 28 08 4368 > Brazil (toll-free): 0 800 047 4906 > Bulgaria (toll-free): 00800 120 4417 > Canada (toll-free): 1 888 455 1389 > Canada: +1 (647) 497-9353 > Chile (toll-free): 800 395 150 > China (toll-free): 4008 811084 > Colombia (toll-free): 01 800 012 9054 > Czech Republic (toll-free): 800 500448 Denmark (toll-free): 8090 1924 > Denmark: +45 (0) 69 91 89 28 > Finland (toll-free): 0 800 94507 > Finland: +358 (0) 942 59 7850 > France (toll-free): 0 805 541 047 > France: +33 (0) 170 950 594 > Germany (toll-free): 0 800 723 5270 > Germany: +49 (0) 692 5736 7317 > Greece (toll-free): 00 800 4414 3838 > Hong Kong (toll-free): 30713169 > Hungary (toll-free): (06) 80 986 255 > Iceland (toll-free): 800 9869 > India (toll-free): 000 800 100 7855 > Indonesia (toll-free): 0
RE: test discard
Hearing you loud and clear, Rohit. -- Stephen Turner -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: 07 January 2015 09:30 To: dev@cloudstack.apache.org Subject: Re: test discard On Wednesday 07 January 2015 02:52 PM, Sebastien Goasguen wrote: > Geoff is reporting being blocked when sending to the list testing if I can send emails, from @shapeblue.com account. -- Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 8826230892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab PS. If you see any footer below, I did not add it :) Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> CSForge - rapid IaaS deployment framework<http://shapeblue.com/csforge/> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
RE: [QUESTION] Integration Port
Min or Prachi might have some information on this. -- Stephen Turner -Original Message- From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] Sent: 08 January 2015 18:54 To: dev@cloudstack.apache.org Cc: Vania Xu Subject: [QUESTION] Integration Port Hi, I noticed with 4.6 that if I run this command that I get back no volumes: http://secure-web.cisco.com/1QFfmjJfPvcx0_-c2Ry2iMJZQHE8ZkZPxYagenr8okTkT5LN35jPMNLSWMSlsNcpCbKakeL3n1SGr7NrB7VJxPXkckQnj0c24Zd_MnZqiMf3_1tD3X7XYBhh_VGLPrN0ofZwPxQTqU2vmBVRqCsrf84l-rrCA6DmVrECQk23mZak/http%3A%2F%2F192.168.129.88%3A8096%2Fapi%3Fcommand%3DlistVolumes This seemed odd (since I have user-facing volumes) and I tracked it down to one parameter: listAll It appears when using the integration port that listAll is null by default, which (in this case) is interpreted the same as false. That being the case, to retrieve volumes via the integration port, I had to run the following instead: http://secure-web.cisco.com/1P_Ssx1LBDJxkhmdc3ZiFePzQhF3rlwXuG8usVFV6agN8RdL72LxFKeEJW-j4u6ClGUjI8ROYXCau2Y3QkOfvjL4scB4yquuafmB5Bsa9y1JYhNldfPOrVaS6fNTheWms0pyrvZtQwAR7X8XCxErN53BBLWnYN80wiIpTfSJF7_0/http%3A%2F%2F192.168.129.88%3A8096%2Fapi%3Fcommand%3DlistVolumes%26listAll%3Dtrue This seems like it might be a recent change. Does anyone know if this is on purpose? The problem is that my tests in Marvin fail now because no volumes come back when they're expected. Thanks! -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*
RE: inconsistent listXXX API behaviors
There is a page on the wiki about inconsistencies in the list* APIs: https://cwiki.apache.org/confluence/display/CLOUDSTACK/API+changes. But I don't think it mentions this particular problem. -- Stephen Turner -Original Message- From: Yiping Zhang [mailto:yzh...@marketo.com] Sent: 09 January 2015 20:45 To: dev@cloudstack.apache.org Subject: inconsistent listXXX API behaviors Hi, all We have noticed some behavior differences among various listXXX API calls as shown bellow: When using listZones API with "name=xxx" argument, the returned zone's name must be an exact match for the given argument value. In this example, zone name must be exactly "xxx" for it to be returned by this call. When using listPods API with "name=pod" argument, all pods whose name ends with "pod" will be returned by this call. For example, pods with name as "my_pod", "my_2nd_pod" and "new_pod" will all be returned. In other words, in these this API call, the name match is a sub string match, not exact string match, with given argument value. The API listClusters behaves the same way as listPods. Are the different behavior among these API calls intentional? If so what are the rationales for the differences ? If the different behavior is due to bugs in implementations, then there are over 100 listXXX type API calls whose behavior needs to be reviewed to see how many of them show buggy behaviors. Thanks Yiping
RE: CloudStack Quality Process
17:00 is the earliest I can do this week, although I realise that's getting late in India and I'm not trying to have a veto. Who's planning to come this week? Last week, it seemed a bit quiet and Citrix-dominated [*], although we still had a good session. Will it pick up again now everyone's back from the Christmas holidays? [*] I know we're representing ourselves not our companies, but it's nice to have a diversity of perspectives. -- Stephen Turner -Original Message- From: Abhinandan Prateek [mailto:abhinandan.prat...@shapeblue.com] Sent: 12 January 2015 10:21 To: dev@cloudstack.apache.org Subject: Re: CloudStack Quality Process Can this be moved earlier by an hour to 16GMT ? -abhi > On 12-Jan-2015, at 1:36 pm, Daan Hoogland wrote: > > People, I can't make it wednesday 14 17 GMT.. I have a meeting at > 17:30 GMT and will be driving there before. Please make a recording > for me? > > regards, > -- > Daan Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.
RE: CloudStack Quality Process
You're right, it was the wrong word to use. I meant in terms of the number of attendees, not the discussion. I was just trying to encourage others to come along if they care about these process-type issues. -- Stephen Turner -Original Message- From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] Sent: 13 January 2015 05:12 To: dev@cloudstack.apache.org Subject: RE: CloudStack Quality Process Not dominated, majority presence > -Original Message- > From: Stephen Turner [mailto:stephen.tur...@citrix.com] > Sent: Monday, January 12, 2015 3:30 AM > To: dev@cloudstack.apache.org > Subject: RE: CloudStack Quality Process > > 17:00 is the earliest I can do this week, although I realise that's > getting late in India and I'm not trying to have a veto. > > Who's planning to come this week? Last week, it seemed a bit quiet and > Citrix- dominated [*], although we still had a good session. Will it > pick up again now everyone's back from the Christmas holidays? > > [*] I know we're representing ourselves not our companies, but it's > nice to have a diversity of perspectives. > > -- > Stephen Turner > > > -Original Message- > From: Abhinandan Prateek [mailto:abhinandan.prat...@shapeblue.com] > Sent: 12 January 2015 10:21 > To: dev@cloudstack.apache.org > Subject: Re: CloudStack Quality Process > > Can this be moved earlier by an hour to 16GMT ? > > -abhi > > > > > > On 12-Jan-2015, at 1:36 pm, Daan Hoogland > wrote: > > > > People, I can't make it wednesday 14 17 GMT.. I have a meeting at > > 17:30 GMT and will be driving there before. Please make a recording > > for me? > > > > regards, > > -- > > Daan > > Find out more about ShapeBlue and our range of CloudStack related > services > > IaaS Cloud Design & > Build<http://shapeblue.com/iaas-cloud-design-and-build//> > CSForge – rapid IaaS deployment > framework<http://shapeblue.com/csforge/> > CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> > CloudStack Software > Engineering<http://shapeblue.com/cloudstack-software- > engineering/> > CloudStack Infrastructure Support<http://shapeblue.com/cloudstack- > infrastructure-support/> > CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack- > training/> > > This email and any attachments to it may be confidential and are > intended solely for the use of the individual to whom it is addressed. > Any views or opinions expressed are solely those of the author and do > not necessarily represent those of Shape Blue Ltd or related > companies. If you are not the intended recipient of this email, you > must neither take any action based upon its contents, nor copy or show > it to anyone. Please contact the sender if you believe you have received this > email in error. Shape Blue Ltd is a company incorporated in England & Wales. > ShapeBlue Services India LLP is a company incorporated in India and is > operated under license from Shape Blue Ltd. Shape Blue Brasil > Consultoria Ltda is a company incorporated in Brasil and is operated > under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company > registered by The Republic of South Africa and is traded under license > from Shape Blue Ltd. ShapeBlue is a registered trademark.
RE: CloudStack Quality Process
It's either 16:00 or 17:00 tomorrow (Wed). Anyone else got a preference? -- Stephen Turner -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: 13 January 2015 10:25 To: dev@cloudstack.apache.org Subject: Re: CloudStack Quality Process Can anyone confirm the final time/date? Thanks. > On 13-Jan-2015, at 2:50 pm, Stephen Turner wrote: > > You're right, it was the wrong word to use. I meant in terms of the number of > attendees, not the discussion. I was just trying to encourage others to come > along if they care about these process-type issues. > > -- > Stephen Turner > > > -Original Message- > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] > Sent: 13 January 2015 05:12 > To: dev@cloudstack.apache.org > Subject: RE: CloudStack Quality Process > > Not dominated, majority presence > >> -Original Message- >> From: Stephen Turner [mailto:stephen.tur...@citrix.com] >> Sent: Monday, January 12, 2015 3:30 AM >> To: dev@cloudstack.apache.org >> Subject: RE: CloudStack Quality Process >> >> 17:00 is the earliest I can do this week, although I realise that's >> getting late in India and I'm not trying to have a veto. >> >> Who's planning to come this week? Last week, it seemed a bit quiet >> and >> Citrix- dominated [*], although we still had a good session. Will it >> pick up again now everyone's back from the Christmas holidays? >> >> [*] I know we're representing ourselves not our companies, but it's >> nice to have a diversity of perspectives. >> >> -- >> Stephen Turner >> >> >> -Original Message- >> From: Abhinandan Prateek [mailto:abhinandan.prat...@shapeblue.com] >> Sent: 12 January 2015 10:21 >> To: dev@cloudstack.apache.org >> Subject: Re: CloudStack Quality Process >> >> Can this be moved earlier by an hour to 16GMT ? >> >> -abhi >> >> >> >> >>> On 12-Jan-2015, at 1:36 pm, Daan Hoogland >> wrote: >>> >>> People, I can't make it wednesday 14 17 GMT.. I have a meeting at >>> 17:30 GMT and will be driving there before. Please make a recording >>> for me? >>> >>> regards, >>> -- >>> Daan >> >> Find out more about ShapeBlue and our range of CloudStack related >> services >> >> IaaS Cloud Design & >> Build<http://shapeblue.com/iaas-cloud-design-and-build//> >> CSForge – rapid IaaS deployment >> framework<http://shapeblue.com/csforge/> >> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> >> CloudStack Software >> Engineering<http://shapeblue.com/cloudstack-software- >> engineering/> >> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack- >> infrastructure-support/> >> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack- >> training/> >> >> This email and any attachments to it may be confidential and are >> intended solely for the use of the individual to whom it is addressed. >> Any views or opinions expressed are solely those of the author and do >> not necessarily represent those of Shape Blue Ltd or related >> companies. If you are not the intended recipient of this email, you >> must neither take any action based upon its contents, nor copy or >> show it to anyone. Please contact the sender if you believe you have >> received this email in error. Shape Blue Ltd is a company incorporated in >> England & Wales. >> ShapeBlue Services India LLP is a company incorporated in India and >> is operated under license from Shape Blue Ltd. Shape Blue Brasil >> Consultoria Ltda is a company incorporated in Brasil and is operated >> under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company >> registered by The Republic of South Africa and is traded under >> license from Shape Blue Ltd. ShapeBlue is a registered trademark. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> CloudStack Software Engineering<http://shapeblue.com/cloudstack-software-engineering/> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrast
RE: CloudStack Quality Process
As we're in the middle of discussing a proposal from Daan, my feeling is that we should have it at 16:00 GMT so that he can attend and I'll sit out this week. (Most weeks I can manage 16:00 or 17:00, but once a month I can't do 16:00). -- Stephen Turner -Original Message- From: Stephen Turner [mailto:stephen.tur...@citrix.com] Sent: 13 January 2015 12:50 To: dev@cloudstack.apache.org Subject: RE: CloudStack Quality Process It's either 16:00 or 17:00 tomorrow (Wed). Anyone else got a preference? -- Stephen Turner -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: 13 January 2015 10:25 To: dev@cloudstack.apache.org Subject: Re: CloudStack Quality Process Can anyone confirm the final time/date? Thanks. > On 13-Jan-2015, at 2:50 pm, Stephen Turner wrote: > > You're right, it was the wrong word to use. I meant in terms of the number of > attendees, not the discussion. I was just trying to encourage others to come > along if they care about these process-type issues. > > -- > Stephen Turner > > > -Original Message- > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] > Sent: 13 January 2015 05:12 > To: dev@cloudstack.apache.org > Subject: RE: CloudStack Quality Process > > Not dominated, majority presence > >> -Original Message- >> From: Stephen Turner [mailto:stephen.tur...@citrix.com] >> Sent: Monday, January 12, 2015 3:30 AM >> To: dev@cloudstack.apache.org >> Subject: RE: CloudStack Quality Process >> >> 17:00 is the earliest I can do this week, although I realise that's >> getting late in India and I'm not trying to have a veto. >> >> Who's planning to come this week? Last week, it seemed a bit quiet >> and >> Citrix- dominated [*], although we still had a good session. Will it >> pick up again now everyone's back from the Christmas holidays? >> >> [*] I know we're representing ourselves not our companies, but it's >> nice to have a diversity of perspectives. >> >> -- >> Stephen Turner >> >> >> -Original Message- >> From: Abhinandan Prateek [mailto:abhinandan.prat...@shapeblue.com] >> Sent: 12 January 2015 10:21 >> To: dev@cloudstack.apache.org >> Subject: Re: CloudStack Quality Process >> >> Can this be moved earlier by an hour to 16GMT ? >> >> -abhi >> >> >> >> >>> On 12-Jan-2015, at 1:36 pm, Daan Hoogland >> wrote: >>> >>> People, I can't make it wednesday 14 17 GMT.. I have a meeting at >>> 17:30 GMT and will be driving there before. Please make a recording >>> for me? >>> >>> regards, >>> -- >>> Daan >> >> Find out more about ShapeBlue and our range of CloudStack related >> services >> >> IaaS Cloud Design & >> Build<http://shapeblue.com/iaas-cloud-design-and-build//> >> CSForge – rapid IaaS deployment >> framework<http://shapeblue.com/csforge/> >> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> >> CloudStack Software >> Engineering<http://shapeblue.com/cloudstack-software- >> engineering/> >> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack- >> infrastructure-support/> >> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack- >> training/> >> >> This email and any attachments to it may be confidential and are >> intended solely for the use of the individual to whom it is addressed. >> Any views or opinions expressed are solely those of the author and do >> not necessarily represent those of Shape Blue Ltd or related >> companies. If you are not the intended recipient of this email, you >> must neither take any action based upon its contents, nor copy or >> show it to anyone. Please contact the sender if you believe you have >> received this email in error. Shape Blue Ltd is a company incorporated in >> England & Wales. >> ShapeBlue Services India LLP is a company incorporated in India and >> is operated under license from Shape Blue Ltd. Shape Blue Brasil >> Consultoria Ltda is a company incorporated in Brasil and is operated >> under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company >> registered by The Republic of South Africa and is traded under >> license from Shape Blue Ltd. ShapeBlue is a registered trademark. Regards, Rohit Yadav Software Architect, ShapeBlue M. +91 88 262 30892 | rohit.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and
RE: CloudStack Quality Process
Well, I sent it yesterday so the Californians would have been awake and may now be expecting a meeting at 8 AM their time. Let's do it at 16:00 GMT. Hopefully David will be able to start the GTM he's already sent out: he indicated that he could do the earlier time if he knew the day before. -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 14 January 2015 08:19 To: dev Subject: Re: CloudStack Quality Process Stephen, I already considdered myself out, and the Californians are asleep at the moment. I'm alright with early start but cannot host a GTM. On Tue, Jan 13, 2015 at 5:14 PM, Stephen Turner wrote: > As we're in the middle of discussing a proposal from Daan, my feeling is that > we should have it at 16:00 GMT so that he can attend and I'll sit out this > week. (Most weeks I can manage 16:00 or 17:00, but once a month I can't do > 16:00). > > -- > Stephen Turner > > > -Original Message- > From: Stephen Turner [mailto:stephen.tur...@citrix.com] > Sent: 13 January 2015 12:50 > To: dev@cloudstack.apache.org > Subject: RE: CloudStack Quality Process > > It's either 16:00 or 17:00 tomorrow (Wed). Anyone else got a preference? > > -- > Stephen Turner > > > -Original Message- > From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] > Sent: 13 January 2015 10:25 > To: dev@cloudstack.apache.org > Subject: Re: CloudStack Quality Process > > Can anyone confirm the final time/date? Thanks. > >> On 13-Jan-2015, at 2:50 pm, Stephen Turner wrote: >> >> You're right, it was the wrong word to use. I meant in terms of the number >> of attendees, not the discussion. I was just trying to encourage others to >> come along if they care about these process-type issues. >> >> -- >> Stephen Turner >> >> >> -Original Message- >> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] >> Sent: 13 January 2015 05:12 >> To: dev@cloudstack.apache.org >> Subject: RE: CloudStack Quality Process >> >> Not dominated, majority presence >> >>> -Original Message- >>> From: Stephen Turner [mailto:stephen.tur...@citrix.com] >>> Sent: Monday, January 12, 2015 3:30 AM >>> To: dev@cloudstack.apache.org >>> Subject: RE: CloudStack Quality Process >>> >>> 17:00 is the earliest I can do this week, although I realise that's >>> getting late in India and I'm not trying to have a veto. >>> >>> Who's planning to come this week? Last week, it seemed a bit quiet >>> and >>> Citrix- dominated [*], although we still had a good session. Will it >>> pick up again now everyone's back from the Christmas holidays? >>> >>> [*] I know we're representing ourselves not our companies, but it's >>> nice to have a diversity of perspectives. >>> >>> -- >>> Stephen Turner >>> >>> >>> -Original Message- >>> From: Abhinandan Prateek [mailto:abhinandan.prat...@shapeblue.com] >>> Sent: 12 January 2015 10:21 >>> To: dev@cloudstack.apache.org >>> Subject: Re: CloudStack Quality Process >>> >>> Can this be moved earlier by an hour to 16GMT ? >>> >>> -abhi >>> >>> >>> >>> >>>> On 12-Jan-2015, at 1:36 pm, Daan Hoogland >>> wrote: >>>> >>>> People, I can't make it wednesday 14 17 GMT.. I have a meeting at >>>> 17:30 GMT and will be driving there before. Please make a recording >>>> for me? >>>> >>>> regards, >>>> -- >>>> Daan >>> >>> Find out more about ShapeBlue and our range of CloudStack related >>> services >>> >>> IaaS Cloud Design & >>> Build<http://shapeblue.com/iaas-cloud-design-and-build//> >>> CSForge – rapid IaaS deployment >>> framework<http://shapeblue.com/csforge/> >>> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> >>> CloudStack Software >>> Engineering<http://shapeblue.com/cloudstack-software- >>> engineering/> >>> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack- >>> infrastructure-support/> >>> CloudStack Bootcamp Training >>> Courses<http://shapeblue.com/cloudstack- >>> training/> >>> >>> This email and any attachments to it may be confidential and are >>> intended solely for the use of the individua
RE: Quality improvement process today
Good question. I'd forgotten it was Wednesday already. I can join at 17:00 but not 16:00 today. I can set up a GTM if necessary too. -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 21 January 2015 15:14 To: dev Subject: Quality improvement process today Is anybody planning to be online for a meeting on any medium? -- Daan
RE: Quality improvement process today
OK, I'll start a GTM at 17:00 and see who turns up. Here is the number: 1. Please join my meeting. https://www1.gotomeeting.com/join/612295913 2. Use your microphone and speakers (VoIP) - a headset is recommended. Or, call in using your telephone. United States: +1 (213) 493-0015 Argentina (toll-free): 0 800 444 5384 Australia (toll-free): 1 800 189 049 Australia: +61 2 8355 1039 Austria (toll-free): 0 800 202144 Austria: +43 (0) 7 2088 2172 Bahrain (toll-free): 800 81 027 Belarus (toll-free): 8 820 0011 0209 Belgium (toll-free): 0 800 81382 Belgium: +32 (0) 42 68 0180 Brazil (toll-free): 0 800 047 4902 Bulgaria (toll-free): 00800 120 4420 Canada (toll-free): 1 888 299 1889 Canada: +1 (647) 497-9379 Chile (toll-free): 800 395 145 China (toll-free): 4008 866143 Colombia (toll-free): 01 800 012 9056 Czech Republic (toll-free): 800 500443 Denmark (toll-free): 8090 1927 Denmark: +45 (0) 89 88 05 39 Finland (toll-free): 0 800 94503 Finland: +358 (0) 931 58 4588 France (toll-free): 0 800 919 896 France: +33 (0) 170 950 589 Germany (toll-free): 0 800 723 5120 Germany: +49 (0) 692 5736 7301 Greece (toll-free): 00 800 4414 3554 Hong Kong (toll-free): 30713171 Hungary (toll-free): (06) 80 986 258 Iceland (toll-free): 800 9871 India (toll-free): 000 800 852 1424 Indonesia (toll-free): 001 803 657 028 Ireland (toll-free): 1 800 946 534 Ireland: +353 (0) 19 036 187 Israel (toll-free): 1 809 494 273 Italy (toll-free): 800 792498 Italy: +39 0 294 75 15 37 Japan (toll-free): 0 120 352 900 Korea, Republic of (toll-free): 0806110880 Luxembourg (toll-free): 800 81021 Malaysia (toll-free): 1 800 81 6859 Mexico (toll-free): 01 800 228 6901 Netherlands (toll-free): 0 800 020 0179 Netherlands: +31 (0) 108 080 116 New Zealand (toll-free): 0 800 47 0050 New Zealand: +64 (0) 9 801 0294 Norway (toll-free): 800 69 054 Norway: +47 21 51 81 86 Panama (toll-free): 00 800 226 8838 Peru (toll-free): 0 800 54684 Philippines (toll-free): 1 800 1651 0714 Poland (toll-free): 00 800 1213978 Portugal (toll-free): 800 780 685 Romania (toll-free): 0 800 410 026 Russian Federation (toll-free): 810 800 29654011 Saudi Arabia (toll-free): 800 844 3635 Singapore (toll-free): 800 101 2999 South Africa (toll-free): 0 800 555 449 Spain (toll-free): 800 900 578 Spain: +34 911 23 4248 Sweden (toll-free): 020 980 768 Sweden: +46 (0) 852 500 516 Switzerland (toll-free): 0 800 000 278 Switzerland: +41 (0) 435 0824 41 Taiwan (toll-free): 0 800 666 674 Thailand (toll-free): 001 800 852 2427 Turkey (toll-free): 00 800 4488 29256 Ukraine (toll-free): 0 800 50 0751 United Arab Emirates (toll-free): 800 044 40442 United Kingdom (toll-free): 0 808 234 0410 United Kingdom: +44 (0) 330 221 0099 United States (toll-free): 1 888 640 7162 Uruguay (toll-free): 000 413 598 4114 Viet Nam (toll-free): 120 32 146 Access Code: 612-295-913 Audio PIN: Shown after joining the meeting Meeting ID: 612-295-913 GoToMeeting® Online Meetings Made Easy® Not at your computer? Click the link to join this meeting from your iPhone®, iPad® or Android® device via the GoToMeeting app. -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 21 January 2015 15:35 To: dev Subject: Re: Quality improvement process today 17:00 is fine by me On Wed, Jan 21, 2015 at 4:27 PM, Stephen Turner wrote: > Good question. I'd forgotten it was Wednesday already. I can join at 17:00 > but not 16:00 today. I can set up a GTM if necessary too. > > -- > Stephen Turner > > > -Original Message- > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > Sent: 21 January 2015 15:14 > To: dev > Subject: Quality improvement process today > > Is anybody planning to be online for a meeting on any medium? > > -- > Daan -- Daan
RE: Quality improvement process today
Thanks for the minutes, Pierre-Luc. I think you're right that gerrit was considered to be good on quality but hard to maintain; but also I think we said that the "hospitality" would be a problem for non-committers. -- Stephen Turner -Original Message- From: Pierre-Luc Dion [mailto:pdion...@apache.org] Sent: 21 January 2015 18:16 To: dev@cloudstack.apache.org Subject: Re: Quality improvement process today Quick resume of 2014-01-21 call on GoToMeeting: - it was not recorded - all notes are on: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Gate+implementation+plan 1. Peer review for pull request, merge request or patches is not viable because it require too much effort from the community. 2. github pull request is the easiest way to contribute, so David will setup trigger on github to launch CI against PR using jenkins plugin: pull request builder 3. gated commit using gerrit might be highly complex to put in place, but highly fit in the hospitality and quality principles 4. need to move jenkins.bac,o into Apache infra On Wed, Jan 21, 2015 at 11:44 AM, Pierre-Luc Dion wrote: > be present too. > > On Wed, Jan 21, 2015 at 11:41 AM, David Nalley wrote: > >> I'll be present. >> >> On Wed, Jan 21, 2015 at 10:14 AM, Daan Hoogland >> >> wrote: >> > Is anybody planning to be online for a meeting on any medium? >> > >> > -- >> > Daan >> > >
RE: quality improvement project status (fyi != just for your information)
Sorry, I was ill yesterday. But I wasn't sure what more we had to discuss before the hardware arrives. -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 28 January 2015 12:39 To: dev Subject: Re: quality improvement project status (fyi != just for your information) I did not see any reactions, are we on for tonight? On Sun, Jan 25, 2015 at 12:10 PM, Daan Hoogland wrote: > H, > > This is a question for feedback (fyi == For Your Input;). In the > meetings we had so far, we created a couple of lists. These are our > only deliverables to date. In order to know if we are on the right > track I would like some feedback. > > First of all there is the highlevel requirement [1]. It should contain > everything we want to accomplish in the end. We will revisit it next > Wednesday and in regular iterations while the project goes on. I hope > everybody that won't attend next session will have their comments sent > to us by then. > > Then there are two detail pages that we have come up with so far and > these are not done until there is some form of consensus on them in > the community. Especially [2] is a page that we should all agree on in > the end. Right now it is just a working document that we will use to > implement our own way of working and later propose everybody will. It > describes what we think are the basics of cloudstack as opposed to the > extras that people should support on their own and will be abandoned > if nobody does. > > The third page [3] contains a set of requirements that we think will > make a gate for contributions that is workable for the community. > > please have a look and give us your feedback. > > [1] > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quality+and+Pro > cess+Improvement+Initiative [2] > https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+basi > c+functionalities [3] > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Gate+requiremen > ts > > > (fyi: we are looking to implement a simple contribution workflow based > on github in combination with jenkins pull request builder for now and > are still considering what would have to be done to implement > something like gerrit.) > > thanks, > -- > Daan -- Daan
RE: quality improvement project status (fyi != just for your information)
Agreed, I was hoping for some comments. Maybe an executive summary would help: * We would like to have a commit/review mechanism that is much easier for new contributors than the current one * Committers cannot be forced to use it, but the benefits should be so obvious that it's the norm (except for emergencies or security patches) * We propose GitHub as the most familiar and easy to use system * All pull requests should trigger Jenkins to run automated tests, and we shouldn't accept the pull request until they've passed What have I forgotten? And does anyone think we're not on the right track? -- Stephen Turner -Original Message- From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] Sent: 29 January 2015 12:25 To: dev Subject: Re: quality improvement project status (fyi != just for your information) no worries, everybody is busy with glibc anyway these days. I didn't have any feedback to our pages, however, That worries me more. On Thu, Jan 29, 2015 at 1:20 PM, Stephen Turner wrote: > Sorry, I was ill yesterday. But I wasn't sure what more we had to discuss > before the hardware arrives. > > -- > Stephen Turner > > > -Original Message- > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > Sent: 28 January 2015 12:39 > To: dev > Subject: Re: quality improvement project status (fyi != just for your > information) > > I did not see any reactions, are we on for tonight? > > On Sun, Jan 25, 2015 at 12:10 PM, Daan Hoogland > wrote: >> H, >> >> This is a question for feedback (fyi == For Your Input;). In the >> meetings we had so far, we created a couple of lists. These are our >> only deliverables to date. In order to know if we are on the right >> track I would like some feedback. >> >> First of all there is the highlevel requirement [1]. It should >> contain everything we want to accomplish in the end. We will revisit >> it next Wednesday and in regular iterations while the project goes >> on. I hope everybody that won't attend next session will have their >> comments sent to us by then. >> >> Then there are two detail pages that we have come up with so far and >> these are not done until there is some form of consensus on them in >> the community. Especially [2] is a page that we should all agree on >> in the end. Right now it is just a working document that we will use >> to implement our own way of working and later propose everybody will. >> It describes what we think are the basics of cloudstack as opposed to >> the extras that people should support on their own and will be >> abandoned if nobody does. >> >> The third page [3] contains a set of requirements that we think will >> make a gate for contributions that is workable for the community. >> >> please have a look and give us your feedback. >> >> [1] >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Quality+and+Pr >> o >> cess+Improvement+Initiative [2] >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+bas >> i >> c+functionalities [3] >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Gate+requireme >> n >> ts >> >> >> (fyi: we are looking to implement a simple contribution workflow >> based on github in combination with jenkins pull request builder for >> now and are still considering what would have to be done to implement >> something like gerrit.) >> >> thanks, >> -- >> Daan > > > > -- > Daan -- Daan
RE: [DISCUSS] [UI] List of timezones available in the picker and potentially other places
The Etc ones won't work as they don't obey DST. The ones on your picture seem to be the standard tzconfig timezones. If we want to produce a smaller list, we'd have to make a mapping of the small list onto standard timezone rules, and maintain it whenever the rules change. (E.g. when countries split or merge or decide to change to a different timezone). -- Stephen Turner -Original Message- From: Erik Weber [mailto:terbol...@gmail.com] Sent: 21 April 2015 11:03 To: dev Subject: Re: [DISCUSS] [UI] List of timezones available in the picker and potentially other places I'm not sure I agree My main issue is the number of elements, not necessarily their order. Now matter how you order ~600 elements it'll be a mess to find the right one There's quite a lot of redundancy here, for my local timezone (UTC+1 / CET) there are multiple options who all maps to the same timezone: - Etc/GMT+1 - Europe/Oslo (or any other city in CET) - CET If I'd been in america there'd even be a couple of of SystemV abbreviations available. My question is; do we really need all this? We're asking for timezone, not location after all. If we are to keep the list, would it make sense to have a condensed version on top, showing all timezones from Etc ? -- Erik On Tue, Apr 21, 2015 at 11:07 AM, Milamber wrote: > > I think a simply alphabetical order would be sufficient. Or perhaps > with a 2 steps, first choose the continent, second choose the city. > > > On 21/04/2015 09:21, Erik Weber wrote: > > When you set up recurring snapshots, and potentially other places in > > the > UI > > where you have to relate to time, you choose timezone from a table > looking > > like [1]. > > > > I, and some of our customers, find this very hard to navigate. > > The list currently contains 618 items.. 618... > > > > I'd like to propose to shorten this list, perhaps to a few common > > abbreviations only (PDT/EST/GMT/CET etc.), but would like feedback > > from others first. > > > > > > > > [1] > > > https://www.dropbox.com/s/iocoek507q0c9r8/Screenshot%202015-04-21%2010 > .10.21.png?dl=0 > > > >
RE: Next ACS release?
I have to admit I'm a bit sceptical because when we did have a four-month release cycle, we never seemed to manage to meet it. Personally I think six-monthly might be easier. Having said that, part of the problem was the long close-down period where we kept finding critical bugs, so more automated testing might help to shorten the cycle. -- Stephen Turner -Original Message- From: Andrei Mikhailovsky [mailto:and...@arhont.com] Sent: 21 April 2015 11:39 PM To: dev@cloudstack.apache.org Subject: Re: Next ACS release? Ilya, Mark, thanks for your feedback, I also see the need to restructure the release schedule for ACS as the current release cycles are not really working. There is no _reliable_ release cycle of the product and as we have recently seen with the 4.5 branch, the release did not happen for months and it is still not clear when this will take place. In my (I must admit somewhat limited) experience if there are no deadlines, developers are not keen on releases and the release are likely to be delayed. This is what we've seen with the past ACS releases, they are overdue by many months. The community might get a much better responce if there is a much shorter release cycle even if it means pushing out less features with each release. At least some features will get completed, tested and implemented in a set time frame. I would rather see a release cycle of every 3-4 months with 5 new features than a release with 15 new features which may or may not get released every 9 - 12 months. By any means, please comment if someone disagrees or thinks there is a better alternative. Andrei - Original Message - > From: "ilya" > To: dev@cloudstack.apache.org > Sent: Tuesday, 21 April, 2015 7:30:34 PM > Subject: Re: Next ACS release? > Andrei, > To best of my knowledge, both 4.4.x and 4.5.x are being worked on > actively. As a community, we need to get better on QA of each release > - > this is something we are planning to cover this year with distributed > QA model, this was not widely discussed yet but something we need to > tackle. > 4.5 rc2 got stalled and we need to restart. We had a 4 month release > cycle, but we can really stick to it hard - as its community driven. > May > will have to revise it down to 6 months or so. > Regards > ilya > On 4/21/15 1:26 AM, Andrei Mikhailovsky wrote: > > Hello guys, > > > > Looking at the dev and user lists it is becoming less certain if > > version 4.5.x is ever coming out. It seems like a few months have > > passed since the not so fortunate release of 4.5.0 and I can't find > > a release schedule for the 4.5.1, which seems to have stopped at rc2 > > stage and haven't progressed further to a release stage. > > > > Are we likely to see any progress with the 4.5.x branch or is the > > community switching towards the 4.6.x branch without releasing the > > 4.5.x? > > > > I am a bit unclear as there are no release dates, schedules or dead > > lines that the community should work with. Possibly as a result of > > this, the ACS releases are not being released on time or fast > > enough. > > > > Does it make sense to introduce release schedules for ACS that the > > dev community should stick to? Similar to what is being done in many > > other projects, like Ubuntu, etc. Or would this break the ACS > > project releases even more? > > > > Andrei > >
RE: Preparing for 4.6
I don't like squashed commits either. Merging a branch on github lets the reviewer switch between seeing the overall diff, and seeing the individual commits' diffs. (And to answer the other point, also allows the author to make a pull request comment, different from any of the individual commits' comments). When reviewing on github, I normally start with the overall diff, but I like to be able to switch into the individual ones too, to understand the motivation for particular parts separately. So I think you get the best of both worlds that way. -- Stephen Turner -Original Message- From: Rajani Karuturi [mailto:raj...@apache.org] Sent: 16 May 2015 03:38 To: dev@cloudstack.apache.org Subject: Re: Preparing for 4.6 -1 for squashed commits. I agree to what Daan said. Feature branch merge is more convenient than squashed single commit. If it was a small feature which involved single dev squashing is still ok. But, a big no when it comes to big feature/refactoring involving effort from multiple people and multiple reviews. On Sat, May 16, 2015 at 3:21 AM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: Those comments may or may not be useful anymore. What they describe may have been superseded by a subsequent commit. On Fri, May 15, 2015 at 3:12 PM, Daan Hoogland > wrote: > those comments will then have to be squashed s well, to this i put a -1. If > those comments where usefull at review-time they will be usefull in > the future as well. > > Op vr 15 mei 2015 om 19:29 schreef Marcus >: > > > I'm not sure it is any different. Either you have a giant block of > > code that represents a bunch of little commits, or a giant block > > that is one commit. We don't want to merge little chunks to master > > that don't fully implement the feature. > > > > To the extent that features and goals can be split up, yes, we don't want > > those features squashed together, or even submitted together, > > squashed or > > not. An example of this is in combining formatting/syntax fixes with > > functional changes, I have tried to review such pull requests and it > > is very difficult to see what is going on in a 1k line request when > > 2/3 of > the > > changes are just reformatting noise. > > > > Ideally the code is reviewed at the commit level as each small > > commit > goes > > from the developer's workstation to the dev branch, but I don't see > > a way > > around reviewing the same amount of code in a pull request that > represents > > multiple small commits vs one squashed commit. You do get more visibility > > into the comments, though. > > > > I suppose a way to get both would be to branch master, do a pull > > request from your dev branch to that branch, at which point it is > > reviewed, then squash merge that back into master. > > On May 15, 2015 8:55 AM, "Daan Hoogland" > > wrote: > > > > > Sebastien, I don't think commits in a big feature should be squashed. > It > > > hinders review if to big chunks are submitted at once. > > > > > > Op vr 15 mei 2015 om 11:27 schreef Sebastien Goasguen < > run...@gmail.com > > >: > > > > > > > Folks, > > > > > > > > As we prepare to try a new process for 4.6 release it would be > > > > nice > to > > > > start paying attention to master. > > > > > > > > - Good commit messages > > > > - Reference to a JIRA bug > > > > - Squashing commits ( cc/ wilder :)) > > > > > > > > While you can apply patches directly, good practice is to apply > > > > the > > patch > > > > to a branch and then merge that branch into master. > > > > > > > > Before we start enforcing some of these things more strongly, > > > > please > > keep > > > > it in mind. > > > > > > > > thanks, > > > > > > > > -sebastien > > > > > > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™* -- ~Rajani Sent from my Windows Phone
RE: Preparing for 4.6
In my XenCenter dev team at Citrix, we have the policy of requiring a ticket number on every commit. If we find a bug and there isn't already a ticket, we create a ticket before committing the fix. I guess I've just dug through history too many times to understand why something that appears wrong was done, only to find an inadequate description at the end of the trail. -- Stephen Turner -Original Message- From: Erik Weber [mailto:terbol...@gmail.com] Sent: 18 May 2015 09:32 To: dev Subject: Re: Preparing for 4.6 On Mon, May 18, 2015 at 10:26 AM, Rene Moser wrote: > Hi > > On 15.05.2015 11:27, Sebastien Goasguen wrote: > > Folks, > > > > As we prepare to try a new process for 4.6 release it would be nice > > to > start paying attention to master. > > > > - Good commit messages > > The question is, what makes a commit message good? Maybe this helps: > > http://secure-web.cisco.com/1cOtAU9lruLvoJl9SBdNSTHN6eyvml6nO5JlwT8_V2 > d_Y7wsnHAV3NiHTOya0cRQyt1WuG_fzithwjk4Qu-l3usM-B_yzy7V4qaxtoDIlEixysid > QZ0ZbuK0YMNgknwBUaRUBJYNkjfGoppsXIpUXcmRvOH565otFMCmJUX2mfkrj_z5Vwm0wh > PDqu2ZkGk1a/http%3A%2F%2Fchris.beams.io%2Fposts%2Fgit-commit%2F > > > - Reference to a JIRA bug > > Must there be a JIRA bug? I did some commits without jira bugs in the > past. But I noticed that those are not "tracked" in the changelog of > the new release. So should there be a policy (is there?) that there > must be a jira bug for fixes? > > I believe there should be a JIRA bug for most things. JIRA is a good place to document why you're doing something, it's also easy to use as a source for release notes as you discovered. It's also good practice to document bugs/fixes, it's generally easier to find JIRA bugs than it is to find commit messages - especially for non-developers / newbies. For major code commits (new features, important fixes, security fixes) I'd say it should be a requirement, but I don't know if it already is or not. > > - Squashing commits ( cc/ wilder :)) > > This really depends. I would not generally prefer squashing commits. > > The example of > https://github.com/apache/cloudstack/commits/master?page=2 is more an > example of "bad" commit messages. > > If you look at the commits, they make sense but the commit message > indicates that they cover similar work in different aspects, which > they actually don't. > > But if you look at this example here > > https://github.com/ansible/ansible-modules-extras/commits/devel?author > =gregdek where you can see dozens of similar commits, those should be > squashed. > > +1 to squashing related commits where it makes sense to do so -1 to a general rule of squashing the whole PR -- Erik
RE: Preparing for 4.6
Speaking for my XenCenter team again, for things like that we would have an improvement ticket, pointing to the wiki page. By the way, this also allows us to schedule the work on our sprint, but we had the policy even before we were doing Scrum. In a large, distributed, volunteer organisation, I would argue that it's even more important to be able to trace the change back to its reason, now and later. -- Stephen Turner -Original Message- From: Wilder Rodrigues [mailto:wrodrig...@schubergphilis.com] Sent: 18 May 2015 10:11 To: dev@cloudstack.apache.org Subject: Re: Preparing for 4.6 Hi there, I agree with the Jira ticket for the "new features, important fixes, security fixes" But I don’t think only about "new features, important fixes, security fixes”. I put most of my time in make the code better and tested, for what we call refactoring/rewriting/redesigning. Should we also create Jira issues for that and mark them as Improvement? Taking into account the [VPC] Virtual Router, Citrix Resource Base and Libvirt Computing Resource refactoring, we had only internal issues on Jira. However, the changes have been documented on the 4.5/4.6 sections of the Apache / Developers / Design Documents wiki: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactor+for+Redundant+Virtual+Router+Implementation https://cwiki.apache.org/confluence/display/CLOUDSTACK/Refactoring+XenServer+Hypervisor+Plugin The Libvirt documentation is on its way, since the PR was pushed only last week. Cheers, Wilder On 18 May 2015, at 10:39, Stephen Turner mailto:stephen.tur...@citrix.com>> wrote: In my XenCenter dev team at Citrix, we have the policy of requiring a ticket number on every commit. If we find a bug and there isn't already a ticket, we create a ticket before committing the fix. I guess I've just dug through history too many times to understand why something that appears wrong was done, only to find an inadequate description at the end of the trail. -- Stephen Turner -Original Message- From: Erik Weber [mailto:terbol...@gmail.com] Sent: 18 May 2015 09:32 To: dev Subject: Re: Preparing for 4.6 On Mon, May 18, 2015 at 10:26 AM, Rene Moser mailto:m...@renemoser.net>> wrote: Hi On 15.05.2015 11:27, Sebastien Goasguen wrote: Folks, As we prepare to try a new process for 4.6 release it would be nice to start paying attention to master. - Good commit messages The question is, what makes a commit message good? Maybe this helps: http://secure-web.cisco.com/1cOtAU9lruLvoJl9SBdNSTHN6eyvml6nO5JlwT8_V2 d_Y7wsnHAV3NiHTOya0cRQyt1WuG_fzithwjk4Qu-l3usM-B_yzy7V4qaxtoDIlEixysid QZ0ZbuK0YMNgknwBUaRUBJYNkjfGoppsXIpUXcmRvOH565otFMCmJUX2mfkrj_z5Vwm0wh PDqu2ZkGk1a/http%3A%2F%2Fchris.beams.io%2Fposts%2Fgit-commit%2F - Reference to a JIRA bug Must there be a JIRA bug? I did some commits without jira bugs in the past. But I noticed that those are not "tracked" in the changelog of the new release. So should there be a policy (is there?) that there must be a jira bug for fixes? I believe there should be a JIRA bug for most things. JIRA is a good place to document why you're doing something, it's also easy to use as a source for release notes as you discovered. It's also good practice to document bugs/fixes, it's generally easier to find JIRA bugs than it is to find commit messages - especially for non-developers / newbies. For major code commits (new features, important fixes, security fixes) I'd say it should be a requirement, but I don't know if it already is or not. - Squashing commits ( cc/ wilder :)) This really depends. I would not generally prefer squashing commits. The example of https://github.com/apache/cloudstack/commits/master?page=2 is more an example of "bad" commit messages. If you look at the commits, they make sense but the commit message indicates that they cover similar work in different aspects, which they actually don't. But if you look at this example here https://github.com/ansible/ansible-modules-extras/commits/devel?author =gregdek where you can see dozens of similar commits, those should be squashed. +1 to squashing related commits where it makes sense to do so -1 to a general rule of squashing the whole PR -- Erik
RE: Preparing for 4.6
Yes, a really detailed commit comment like that Linux one can work too, and I would be happy if I found that when doing code archaeology. But I guess I find that most of the time, a Jira ticket is a better place to hold that information. Somehow the developer is encouraged to write more, and it can also contain screenshots of the error, discussion with other developers, etc. -- Stephen Turner -Original Message- From: Rene Moser [mailto:m...@renemoser.net] Sent: 18 May 2015 10:13 To: dev@cloudstack.apache.org Subject: Re: Preparing for 4.6 Hi Stephan On 18.05.2015 10:39, Stephen Turner wrote: > In my XenCenter dev team at Citrix, we have the policy of requiring a ticket > number on every commit. If we find a bug and there isn't already a ticket, we > create a ticket before committing the fix. I guess I've just dug through > history too many times to understand why something that appears wrong was > done, only to find an inadequate description at the end of the trail. IMHO understanding why commit x changed is more a problem of the commit message or description. If I pick a random fix commit in the linux kernel, https://github.com/torvalds/linux/commit/5c1ac56b51b9d222ab202dec1ac2f4215346129d you see this small fix and a detailed description, why. Personally I do not like the dependency to network related, centraliced ticket tracking system for understanding code changes of a distributed SCM. But I do see the advantage in seeing what has been reported to be broken and what commit fixes this bug. But the commit description should be fairly detailed, why a commit changed something. However since the changelog for the users is actually not generated from the git log, it makes totally sense to open a ticket before fixing bugs, to get all fixes covered in the changelog. Yours René
RE: refresh browser - logged out from ACS ?
Agreed, I thought it was on opening a new window (maybe a new tab too?) rather than refresh. But maybe refresh broke too as a side effect. -- Stephen Turner -Original Message- From: ilya [mailto:ilya.mailing.li...@gmail.com] Sent: 27 May 2015 04:28 To: dev@cloudstack.apache.org Subject: Re: refresh browser - logged out from ACS ? But it was not refresh - to best of my recollection.. On 5/26/15 8:27 PM, ilya wrote: > I vaguely recall Rohit mentioned it was some sort of security fix that > was causing this side effect due to the way sessionids were handled.. > > On 5/26/15 8:15 AM, Andrija Panic wrote: >> Thx Rafael, as usuall :) >> >> I remember there was some thread on this topic, but cant really find >> it... >> >> On 26 May 2015 at 17:14, Rafael Fonseca wrote: >> >>> Hi Andrija, >>> >>> I noticed the same is also happening on the 4.6.0-SNAPSHOT .. it's a >>> bit annoying. >>> >>> I'll have a closer look later today if i can find the time for it :) >>> >>> >>> On Tue, May 26, 2015 at 4:11 PM, Andrija Panic >>> >>> wrote: >>> >>>> Hi guys, >>>> >>>> just wondering - when I refresh browser/UI I get logged out of ACS >>>> - >>> 4.4.3 >>>> (testing with 4.5.1 in few minutes...). >>>> >>>> I remember there was some thread on this, but can't really find it >>> anywhere >>>> This behaviour is not present in 4.3 and prior AFAIK. >>>> >>>> Any tips ? >>>> -- >>>> >>>> Andrija Panić >>>> >> >> >
RE: [DISCUSS] XenServer and HA: the way forward
I'm sorry to come late to this thread, but I only picked it up from Remi's blog post [*] over the weekend. I'm certainly not going to defend the way this change came in under the radar, but speaking as a member of the XenServer development team, I wouldn't want to go back to the old behaviour. The risk is not just theoretical: we had at least one customer with serious data corruption problems as a result of the bad interaction between the CloudStack code and XenServer. I wonder if there's an alternative possibility where CloudStack makes sure that XenServer HA is turned on, and turns it on itself / gives you warnings if it isn't / something? -- Stephen Turner [*] http://blog.remibergsma.com/2015/05/23/making-xenserver-and-cloudstack-sing-and-dance-together-again/ -Original Message- From: Remi Bergsma [mailto:r...@remi.nl] Sent: 04 May 2015 11:04 To: dev@cloudstack.apache.org Subject: [DISCUSS] XenServer and HA: the way forward Hi all, Since CloudStack 4.4 the implementation of HA in CloudStack was changed to use the XenHA feature of XenServer. As of 4.4, it is expected to have XenHA enabled for the pool (not for the VMs!) and so XenServer will be the one to elect a new pool master, whereas CloudStack did it before. Also, XenHA takes care of fencing the box instead of CloudStack should storage be unavailable. To be exact, they both try to fence but XenHA is usually faster. To be 100% clear: HA on VMs is in all cases done by CloudStack. It's just that without a pool master, no VMs will be recovered anyway. This brought some headaches to me, as first of all I didn't know. We probably need to document this somewhere. This is important, because without XenHA turned on you'll not get a new pool master (a behaviour change). Personally, I don't like the fact that we have "two captains" in case something goes wrong. But, some say they like this behaviour. I'm OK with both, as long as one can choose whatever suits their needs best. In Austin I talked to several people about this. We came up with the idea to have CloudStack check whether XenHA is on or not. If it is, it does the current 4.4+ behaviour (XenHA selects new pool master). When it is not, we do the CloudStack 4.3 behaviour where CloudStack is fully in control. I also talked to Tim Mackey and he wants to help implement this, but he doesn't have much time. The idea is to have someone else join in to code the change and then Tim will be able to help out on a regularly basis should we need in depth knowledge of XenServer or its implementation in CloudStack. Before we kick this off, I'd like to discuss and agree that this is the way forward. Also, if you're interested in joining this effort let me know and I'll kick it off. Regards, Remi
RE: refresh browser - logged out from ACS ?
Is this being discussed on the security list? I think that's the place for it, because I wouldn't want us to restore the old behaviour without a proper audit from security experts. -- Stephen Turner -Original Message- From: Rafael Fonseca [mailto:rsafons...@gmail.com] Sent: 27 May 2015 10:39 To: dev@cloudstack.apache.org Subject: Re: refresh browser - logged out from ACS ? Hi guys, I had a look at this issue yesterday and created a PR to fix it, it's being discussed here https://github.com/apache/cloudstack/pull/308 Since this seems to be a security related issue I will be updating my PR soon with a secure fix :) On Wed, May 27, 2015 at 11:24 AM, Andrija Panic wrote: > its not the case with i.e. 4.3.2...its is the case with 4.4.3 and > 4.5.1 at the moment... > > On 27 May 2015 at 11:20, Vadim Kimlaychuk > wrote: > > > Is it possible to fix? It seems such a behaviour was always be like this. > > > > Vadim. > > > > -Original Message- > > From: Andrija Panic [mailto:andrija.pa...@gmail.com] > > Sent: Wednesday, May 27, 2015 12:17 PM > > To: dev@cloudstack.apache.org > > Subject: Re: refresh browser - logged out from ACS ? > > > > openign a new windows/tab with same address/URL also break things... > > > > > > On 27 May 2015 at 11:11, Stephen Turner > wrote: > > > > > Agreed, I thought it was on opening a new window (maybe a new tab > > > too?) rather than refresh. But maybe refresh broke too as a side > effect. > > > > > > -- > > > Stephen Turner > > > > > > > > > -Original Message- > > > From: ilya [mailto:ilya.mailing.li...@gmail.com] > > > Sent: 27 May 2015 04:28 > > > To: dev@cloudstack.apache.org > > > Subject: Re: refresh browser - logged out from ACS ? > > > > > > But it was not refresh - to best of my recollection.. > > > > > > On 5/26/15 8:27 PM, ilya wrote: > > > > I vaguely recall Rohit mentioned it was some sort of security > > > > fix that was causing this side effect due to the way sessionids > > > > were > > handled.. > > > > > > > > On 5/26/15 8:15 AM, Andrija Panic wrote: > > > >> Thx Rafael, as usuall :) > > > >> > > > >> I remember there was some thread on this topic, but cant really > > > >> find it... > > > >> > > > >> On 26 May 2015 at 17:14, Rafael Fonseca > wrote: > > > >> > > > >>> Hi Andrija, > > > >>> > > > >>> I noticed the same is also happening on the 4.6.0-SNAPSHOT .. > > > >>> it's a bit annoying. > > > >>> > > > >>> I'll have a closer look later today if i can find the time for > > > >>> it > > > >>> :) > > > >>> > > > >>> > > > >>> On Tue, May 26, 2015 at 4:11 PM, Andrija Panic > > > >>> > > > >>> wrote: > > > >>> > > > >>>> Hi guys, > > > >>>> > > > >>>> just wondering - when I refresh browser/UI I get logged out > > > >>>> of ACS > > > >>>> - > > > >>> 4.4.3 > > > >>>> (testing with 4.5.1 in few minutes...). > > > >>>> > > > >>>> I remember there was some thread on this, but can't really > > > >>>> find it > > > >>> anywhere > > > >>>> This behaviour is not present in 4.3 and prior AFAIK. > > > >>>> > > > >>>> Any tips ? > > > >>>> -- > > > >>>> > > > >>>> Andrija Panić > > > >>>> > > > >> > > > >> > > > > > > > > > > > > > > > > -- > > > > Andrija Panić > > > > > > -- > > Andrija Panić >
