Re: [NOTICE] Remove branches 4.5.2.1-*, 4.7.0-*, 4.8.0-*, 4.9-*, and CLOUDSTACK* from Apache CloudStack official repository

2018-04-03 Thread Rafael Weingärtner
 The following branches were removed from our official repository.

   - 4.5.2.1-security-RC20160525T120
   - 4.7.0-RC20151213T2109
   - 4.7.1-RC20160120T2318
   - 4.7.1.1-RC20160525T1230
   - 4.8.0-RC20160120T2343
   - 4.8.0.1-RC20160525T1247
   - 4.8.1-RC20160808T1006
   - 4.8.2.0-RC20161210T0832
   - 4.9-bountycastle-daan
   - 4.9-systemdubuntupkging
   - 4.9.0-RC20160706T1546
   - 4.9.0-RC20160725T1656
   - 4.9.1.0-RC20161210T0838
   - 4.9.2.0-RC20161227T1309
   - CLOUDSTACK-10012
   - CLOUDSTACK-1302
   - CLOUDSTACK-2554
   - CLOUDSTACK-8243
   - CLOUDSTACK-8301
   - CLOUDSTACK-8313
   - CLOUDSTACK-8489
   - CLOUDSTACK-8530
   - CLOUDSTACK-8559
   - CLOUDSTACK-8560
   - CLOUDSTACK-8566
   - CLOUDSTACK-8766

Thanks for the understanding.


On Tue, Apr 3, 2018 at 7:13 AM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Final warning, these branches will be deleted today 17:00 (UTC-03:00). If
> you disagree, please do so before the deadline.
>
> On Fri, Mar 23, 2018 at 11:17 AM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
>> Following the protocol defined in [1], this is the notice email regarding
>> the removal branches from Apache CloudStack official repository. The
>> Jira ticket for the branches removal is https://issues.apache.org/jira
>> /browse/CLOUDSTACK-10342
>> . The branches
>> that will be removed are the following:
>>
>>
>>- 4.5.2.1-security-RC20160525T120
>>- 4.7.0-RC20151213T2109
>>- 4.7.1-RC20160120T2318
>>- 4.7.1.1-RC20160525T1230
>>- 4.8.0-RC20160120T2343
>>- 4.8.0.1-RC20160525T1247
>>- 4.8.1-RC20160808T1006
>>- 4.8.2.0-RC20161210T0832
>>- 4.9-bountycastle-daan
>>- 4.9-systemdubuntupkging
>>- 4.9.0-RC20160706T1546
>>- 4.9.0-RC20160725T1656
>>- 4.9.1.0-RC20161210T0838
>>- 4.9.2.0-RC20161227T1309
>>- CLOUDSTACK-10012
>>- CLOUDSTACK-1302
>>- CLOUDSTACK-2554
>>- CLOUDSTACK-8243
>>- CLOUDSTACK-8301
>>- CLOUDSTACK-8313
>>- CLOUDSTACK-8489
>>- CLOUDSTACK-8530
>>- CLOUDSTACK-8559
>>- CLOUDSTACK-8560
>>- CLOUDSTACK-8566
>>- CLOUDSTACK-8766
>>
>> If you have objections, please do share your concerns before the
>> deletion. The removal will happen on 03/April/2018.
>>
>> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old
>> +and+obsolete+branches+protocol
>>
>> --
>> Rafael Weingärtner
>>
>
>
>
> --
> Rafael Weingärtner
>



-- 
Rafael Weingärtner


Re: Committee to Sort through CCC Presentation Submissions

2018-04-03 Thread Tutkowski, Mike
Hi Ron,

I don’t actually have insight into how many people have currently signed up 
online to be CFP reviewers for ApacheCon. At present, I’m only aware of those 
who have responded to this e-mail chain.

We should be able to find out more in the coming weeks. We’re still quite early 
in the process.

Thanks for your feedback,
Mike

On 4/1/18, 9:18 AM, "Ron Wheeler"  wrote:

How many people have signed up to be reviewers?

I don't think that scheduling is part of the review process and that can 
be done by the person/team "organizing" ApacheCon on behalf of the PMC.

To me review is looking at content for
- relevance
- quality of the presentations (suggest fixes to content, English, 
graphics, etc.)
This should result in a consensus score
- Perfect - ready for prime time
- Needs minor changes as documented by the reviewers
- Great topic but needs more work - perhaps a reviewer could volunteer 
to work with the presenter to get it ready if chosen
- Not recommended for topic or content reasons

The reviewers could also make non-binding recommendations about the 
balance between topics - marketing(why Cloudstack), 
Operations/implementation, Technical details, Roadmap, etc. based on 
what they have seen.

This should be used by the organizers to make the choices and organize 
the program.
The organizers have the final say on the choice of presentations and 
schedule

Reviewers are there to help the process not control it.

I would be worried that you do not have enough reviewers rather than too 
many.
Then the work falls on the PMC and organizers.

When planning meetings, I would recommend that you clearly separate the 
roles and only invite the reviewers to the meetings about review. Get 
the list of presentation to present to the reviewers and decide if there 
are any instructions that you want to give to reviewers.
I would recommend that you keep the organizing group small. Membership 
should be set by the PMC and should be people that are committed to the 
ApacheCon project and have the time. The committee can request help for 
specific tasks from others in the community who are not on the committee.

I would also recommend that organizers do not do reviews. They should 
read the finalists but if they do reviews, there may be a suggestion of 
favouring presentations that they reviewed. It also ensures that the 
organizers are not getting heat from rejected presenters - "it is the 
reviewers fault you did not get selected".

My advice is to get as many reviewers as you can so that no one is 
essential and each reviewer has a limited number of presentations to 
review but each presentation gets reviewed by multiple people. Also bear 
in mind that not all reviewers have the same ability to review each 
presentation.
Reviews should be anonymous and only the summary comments given to the 
presenter. Reviewers of a presentation should be able to discuss the 
presentation during the review to make sure that reviewers do not feel 
isolated or get lost when they hit content that they don't understand fully.



Ron


On 01/04/2018 12:20 AM, Tutkowski, Mike wrote:
> Thanks for the feedback, Will!
>
> I agree with the approach you outlined.
>
> Thanks for being so involved in the process! Let’s chat with Giles once 
he’s back to see if we can get your questions answered.
>
>> On Mar 31, 2018, at 10:14 PM, Will Stevens  wrote:
>>
>> In the past the committee was chosen as a relatively small group in order
>> to make it easier to manage feedback.  In order to make it fair to 
everyone
>> in the community, I would suggest that instead of doing it with a small
>> group, we do it out in the open on a scheduled call.
>>
>> We will have to get a list of the talks that are CloudStack specific from
>> ApacheCon, but that should be possible.
>>
>> Once we have the talks selected, then a smaller number of us can work on
>> setting up the actual ordering and the details.
>>
>> I have been quite involved so far.  Giles and I have been organizing the
>> sponsors, website and dealing with ApacheCon so far.  Obviously, Mike is
>> also working on this as well.
>>
>> I think we are headed in the right direction on this.
>>
>> Cheers,
>>
>> Will
>>
>> On Mar 31, 2018 11:49 PM, "Tutkowski, Mike" 
>> wrote:
>>
>> Hi Ron,
>>
>> I am definitely open to working this however makes the most sense.
>>
>> It looks like Will’s e-mail indicates that the process I suggested has 
been
>> followed in the past (which is how I recall, as well).
>>
>> Let’s make sure I understood Will correctly.
>>
>> Will – Are you, in fact, indicating t

[ANNOUNCE][SECURITY] CloudStack 4.9.3.1 Robot TLS attack

2018-04-03 Thread Rohit Yadav
All,

On private@ and security@, we discussed and worked on a fix for robot TLS
[1] attack and released CloudStack 4.9.3.1. The issue does not affect the
latest 4.11.0.0 version and does not require any upgrades/fixes/changes in
that regard.

The issue primarily affects installations that are using an older version
of bouncycastle, the only change we did against the 4.9.3.0 release was to
upgrade the bouncycastle dependency version [2] 1.59. Post upgrade to
4.9.3.1 from 4.9.3.0, users will be required to destroy old CPVMs and SSVMs
(new ones will be patched by a newer systemvm.iso that will have the v1.59
bc dependency jar), and upgrade and restart KVM agent(s) and management
server(s).

Download page:
http://cloudstack.apache.org/downloads.html

Release notes for 4.9.3.1:
http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/4.9.3.1/

[1] robotattack.org
[2]
https://github.com/bcgit/bc-java/commit/a00b684465b38d722ca9a3543b8af8568e6bad5c

Regards,
Rohit Yadav


Re: 4.11.0.0 - Error to Register ISO in All Zones

2018-04-03 Thread Parth Patel
Lotic,

Same here. I too am not able to register ISO when using the default option
"All Zones". Thank you for raising a jira bug issue. I'm also seeing the
same error in my logs.

Regards,
Parth Patel

On Tue 3 Apr, 2018, 18:16 Lotic Lists,  wrote:

> Hi Dag.
>
> Cloudmonkey not have "zoneids" parameter
>
> [root@acs01 ~]# cloudmonkey
> ☁ Apache CloudStack  cloudmonkey 5.3.3. Type help or ? to list commands.
> (local)  > help register iso
> (registerIso) Registers an existing ISO into the CloudStack Cloud.
> Required params are displaytext url zoneid name
> Parameters
> ==
> account = (string) an optional account name. Must be used with domainId.
> ostypeid = (uuid) the ID of the OS type that best represents the OS of
> this ISO. If the ISO is bootable this parameter needs to be passed
> displaytext = (string) the display text of the ISO. This is usually used
> for display purposes.
> bootable = (boolean) true if this ISO is bootable. If not passed
> explicitly its assumed to be true
> domainid = (uuid) an optional domainId. If the account parameter is used,
> domainId must also be used.
> url = (string) the URL to where the ISO is currently being hosted
> imagestoreuuid = (string) Image store UUID
> directdownload = (boolean) true if ISO should bypass Secondary Storage and
> be downloaded to Primary Storage on deployment
> zoneid = (uuid) the ID of the zone you wish to register the ISO to.
> ispublic = (boolean) true if you want to register the ISO to be publicly
> available to all users, false otherwise.
> projectid = (uuid) Register ISO for the project
> isfeatured = (boolean) true if you want this ISO to be featured
> isdynamicallyscalable = (boolean) true if ISO contains XS/VMWare tools
> inorder to support dynamic scaling of VM CPU/memory
> checksum = (string) the checksum value of this ISO. The parameter
> containing the checksum will be considered a MD5sum if it is not prefixed
>  and just a plain ascii/utf8 representation of a hexadecimal string. If it
> is required to
>  use another algorithm the hexadecimal string is to be prefixed with a
> string of the form,
>  "{}", not including the double quotes. In this  is
> the exact string
>  representing the java supported algorithm, i.e. MD5 or SHA-256. Note that
> java does not
>  contain an algorithm called SHA256 or one called sha-256, only SHA-256.
> name = (string) the name of the ISO
> isextractable = (boolean) true if the ISO or its derivatives are
> extractable; default is false
>
> (local)  > register iso
> account=directdownload= filter=
>  isextractable=  name=   url=
> bootable=   displaytext=imagestoreuuid=
>  isfeatured= ostypeid=   zoneid=
> checksum=   domainid=   isdynamicallyscalable=
> ispublic=   projectid=
>
> Regards
> Marcelo
>
>
> -Original Message-
> From: Dag Sonstebo 
> Sent: segunda-feira, 2 de abril de 2018 05:07
> To: dev@cloudstack.apache.org
> Subject: Re: 4.11.0.0 - Error to Register ISO in All Zones
>
> Hi Marcelo,
>
> One thing I noticed - if you check
> http://cloudstack.apache.org/api/apidocs-4.11/apis/registerTemplate.html
> there is a difference between “zoneid” and “zoneids”, the latter taking the
> -1 option. That doesn’t explain your GUI issue, but may explain your
> CloudMonkey run failure?
>
> Regards,
> Dag Sonstebo
> Cloud Architect
> ShapeBlue
>
> On 01/04/2018, 04:36, "Lotic Lists"  wrote:
>
> Problem to register ISO in all zones
>
>
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-10349
>
>
>
> Regards
>
> Marcelo
>
>
>
>
>
>
> dag.sonst...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
>
>
>
>
>


RE: 4.11.0.0 - Error to Register ISO in All Zones

2018-04-03 Thread Lotic Lists
Hi Dag.

Cloudmonkey not have "zoneids" parameter

[root@acs01 ~]# cloudmonkey 
☁ Apache CloudStack  cloudmonkey 5.3.3. Type help or ? to list commands.
(local)  > help register iso
(registerIso) Registers an existing ISO into the CloudStack Cloud.
Required params are displaytext url zoneid name
Parameters
==
account = (string) an optional account name. Must be used with domainId.
ostypeid = (uuid) the ID of the OS type that best represents the OS of this 
ISO. If the ISO is bootable this parameter needs to be passed
displaytext = (string) the display text of the ISO. This is usually used for 
display purposes.
bootable = (boolean) true if this ISO is bootable. If not passed explicitly its 
assumed to be true
domainid = (uuid) an optional domainId. If the account parameter is used, 
domainId must also be used.
url = (string) the URL to where the ISO is currently being hosted
imagestoreuuid = (string) Image store UUID
directdownload = (boolean) true if ISO should bypass Secondary Storage and be 
downloaded to Primary Storage on deployment
zoneid = (uuid) the ID of the zone you wish to register the ISO to.
ispublic = (boolean) true if you want to register the ISO to be publicly 
available to all users, false otherwise.
projectid = (uuid) Register ISO for the project
isfeatured = (boolean) true if you want this ISO to be featured
isdynamicallyscalable = (boolean) true if ISO contains XS/VMWare tools inorder 
to support dynamic scaling of VM CPU/memory
checksum = (string) the checksum value of this ISO. The parameter containing 
the checksum will be considered a MD5sum if it is not prefixed
 and just a plain ascii/utf8 representation of a hexadecimal string. If it is 
required to
 use another algorithm the hexadecimal string is to be prefixed with a string 
of the form,
 "{}", not including the double quotes. In this  is the 
exact string
 representing the java supported algorithm, i.e. MD5 or SHA-256. Note that java 
does not
 contain an algorithm called SHA256 or one called sha-256, only SHA-256.
name = (string) the name of the ISO
isextractable = (boolean) true if the ISO or its derivatives are extractable; 
default is false

(local)  > register iso 
account=directdownload= filter= 
isextractable=  name=   url=
bootable=   displaytext=imagestoreuuid= 
isfeatured= ostypeid=   zoneid=
checksum=   domainid=   isdynamicallyscalable=  
ispublic=   projectid=  

Regards
Marcelo


-Original Message-
From: Dag Sonstebo  
Sent: segunda-feira, 2 de abril de 2018 05:07
To: dev@cloudstack.apache.org
Subject: Re: 4.11.0.0 - Error to Register ISO in All Zones

Hi Marcelo,

One thing I noticed - if you check 
http://cloudstack.apache.org/api/apidocs-4.11/apis/registerTemplate.html there 
is a difference between “zoneid” and “zoneids”, the latter taking the -1 
option. That doesn’t explain your GUI issue, but may explain your CloudMonkey 
run failure? 

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 01/04/2018, 04:36, "Lotic Lists"  wrote:

Problem to register ISO in all zones

 

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

 

Regards

Marcelo

 




dag.sonst...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
  
 




Re: [NOTICE] Remove branches 4.5.2.1-*, 4.7.0-*, 4.8.0-*, 4.9-*, and CLOUDSTACK* from Apache CloudStack official repository

2018-04-03 Thread Rafael Weingärtner
 Final warning, these branches will be deleted today 17:00 (UTC-03:00). If
you disagree, please do so before the deadline.

On Fri, Mar 23, 2018 at 11:17 AM, Rafael Weingärtner <
rafaelweingart...@gmail.com> wrote:

> Following the protocol defined in [1], this is the notice email regarding
> the removal branches from Apache CloudStack official repository. The Jira
> ticket for the branches removal is https://issues.apache.org/jira
> /browse/CLOUDSTACK-10342
> . The branches
> that will be removed are the following:
>
>
>- 4.5.2.1-security-RC20160525T120
>- 4.7.0-RC20151213T2109
>- 4.7.1-RC20160120T2318
>- 4.7.1.1-RC20160525T1230
>- 4.8.0-RC20160120T2343
>- 4.8.0.1-RC20160525T1247
>- 4.8.1-RC20160808T1006
>- 4.8.2.0-RC20161210T0832
>- 4.9-bountycastle-daan
>- 4.9-systemdubuntupkging
>- 4.9.0-RC20160706T1546
>- 4.9.0-RC20160725T1656
>- 4.9.1.0-RC20161210T0838
>- 4.9.2.0-RC20161227T1309
>- CLOUDSTACK-10012
>- CLOUDSTACK-1302
>- CLOUDSTACK-2554
>- CLOUDSTACK-8243
>- CLOUDSTACK-8301
>- CLOUDSTACK-8313
>- CLOUDSTACK-8489
>- CLOUDSTACK-8530
>- CLOUDSTACK-8559
>- CLOUDSTACK-8560
>- CLOUDSTACK-8566
>- CLOUDSTACK-8766
>
> If you have objections, please do share your concerns before the deletion.
> The removal will happen on 03/April/2018.
>
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old
> +and+obsolete+branches+protocol
>
> --
> Rafael Weingärtner
>



-- 
Rafael Weingärtner