RE: Marketing CCC Montreal

[Giles Sirett]

You are correct.
The tweet was incorrect - has been deleted and a new tweet posted 

Its SEPTEMBER  everybody 

Kind regards
Giles

giles.sir...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Khosrow Moossavi  
Sent: 22 March 2018 14:59
To: dev 
Cc: users ;  
; market...@cloudstack.apache.org
Subject: Re: Marketing CCC Montreal

Well whatever the dates it will not be in May, it will be in September!




On Thu, Mar 22, 2018 at 10:55 AM, Will Stevens 
wrote:

> The dates are somewhat unclear, so its not really 'wrong' yet.  We 
> know we start on the 24th.  We are not sure what the second day we 
> will get from ApacheCon is yet.  I am working on getting a space 
> together for a hackathon day on either the 25th or 26th depending on 
> what the second day we get from ApacheCon is, so there are still some 
> logistics in play still.
>
> I am advertising the 24-26th in the absence of official details as I 
> am confident I can get another space online for a hackathon day.  More 
> details will be available once we get details from ApacheCon and I 
> work out a space for the hackathon.
>
> I hope that is not too difficult to understand.
>
> Cheers,
>
> *Will Stevens*
> Chief Technology Officer
> c 514.826.0190
>
> 
>
> On Thu, Mar 22, 2018 at 10:49 AM, Khosrow Moossavi 
>  >
> wrote:
>
> > Somehow related, the tweet sent out earlier today, has the date wrong.
> >
> > https://twitter.com/CloudStack/status/976819870426902530?s=19
> >
> >
> > On Mar 22, 2018 10:37, "Will Stevens"  wrote:
> >
> > > Hey Everyone,
> > > We need your help to promote the visibility of the CCC conference 
> > > we
> are
> > > running later this year in September.
> > >
> > > I have put together an information website to help us promote the CCC:
> > > http://ca.cloudstackcollab.org/
> > >
> > > I will keep the website updated with additional detail as we get 
> > > more information.
> > >
> > > *PLEASE NOTE: Call For Papers closes on March 30th.  Please get 
> > > your
> > topics
> > > in ASAP.*  On that note, make sure the title of your talk includes 
> > > the
> > word
> > > 'CloudStack' so we are able to get the talk in the correct CCC track.
> > >
> > > Additionally, in order to get more visibility for the event, 
> > > please consider adding the following footer to your email 
> > > signature (ideally linking to the CCC site).  The footer is available 
> > > here:
> > > http://ca.cloudstackcollab.org/img/ccc_mtl_footer.png
> > >
> > > Let us know if you have any questions...
> > >
> > > *Will Stevens*
> > >
> > >
> > > * *
> > >
> >
>

Re: [DISCUSS] Enhancement: Use CA framework to enable secured live KVM VM migration

[Rohit Yadav]

Wido - fair point, considering this I'll add some notes in our release notes. 
With the suggested change, during pkg upgrade libvirtd will not be reconfigured:

https://github.com/shapeblue/cloudstack-apple/pull/65/commits/9dd93ee3c7b0a31cbd262a51aaed2b325decfbd8


Instead, KVM hosts that don't meet following conditions will show up as 
'unsecure' when they connect to management server:

- Host does not have certificates setup at /etc/cloudstack/agent

- Host's libvirtd is not tls enabled with any provisioned certificate


The admin can then simply choose to provision certificate to secure 'unsecure' 
hosts post upgrade via api or the newly added button. This process will 
provision (or renew) certificates, configure only tls settings in libvirtd and 
restart libvirtd and then restart the agent. See the PR for details. Thanks.



- Rohit






From: Wido den Hollander 
Sent: Thursday, March 22, 2018 10:14:31 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Enhancement: Use CA framework to enable secured live KVM 
VM migration



On 03/21/2018 10:06 AM, Rohit Yadav wrote:
> Thanks Wido for your comments.
>
>
> Yes, for any changes to libvirtd the proposal is to re-use 
> cloudstack-setup-agent which in fact reconfigures libvirtd config at the time 
> of the addition of host and also configure iptables rule. As part of 
> upgrading a KVM agent, the post-install script (part of deb/rpm pkg) can also 
> run the same to secure libvirt tls configuration only on KVM hosts that have 
> any existing certificates/keystore.
>

Hmm, we might want to be careful with a postinst. I'm not against it
being handled by a postinst, but we should watch out with overwriting
config files without the user knowing.

Wido

>
> - Rohit
>
> 
>
>
>
> 
> From: Wido den Hollander 
> Sent: Wednesday, March 21, 2018 1:38:19 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Enhancement: Use CA framework to enable secured live 
> KVM VM migration
>
>
>
> On 03/21/2018 08:05 AM, Rohit Yadav wrote:
>> All,
>>
>>
>> With the introduction of a native CA framework in CloudStack, with 4.11+ it 
>> will be used to secure addition of KVM hosts and agents (cpvm, ssvm). 
>> However, the KVM host agent may be secured while it communicates to the 
>> management server, the live VM migration still happens on insecure tcp 
>> connection.
>>
>>
>> It is proposed to re-use the existing mechanism introduced in 4.11 and 
>> re-use host certificates that are used to secure a KVM host to secure 
>> libvirt for allowing secured TLS-enabled VM migration. Further, the UI may 
>> be enhanced to discover unsecured KVM hosts and allow securing (or 
>> renewal/provisioning of certificates) through a button. Please find the FS 
>> for the proposed enhancement:
>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM
>>
>
> Seems good! As long as we make sure that only cloudstack-setup-agent
> touches the libvirt config files I'm good with it.
>
> Many people (like us) have the libvirt config files managed through a
> tool like Salt/Puppet/Chef and don't like it when daemons suddenly start
> changing configuration files.
>
> But this looks good to me!
>
> Wido
>
>>
>> - Rohit
>>
>> 
>>
>>
>>
>> rohit.ya...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
>>
>>
>>
>>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>

rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

[Rohit Yadav]

Thanks all for your feedback. Since it's been positive so far, I'll start a 
vote on Monday to formalize this.

In the meanwhile, please keep sharing your feedback and opinion. Thanks (and 
happy weekends).


- Rohit






From: Syed Ahmed 
Sent: Thursday, March 22, 2018 12:51:01 AM
To: dev@cloudstack.apache.org
Cc: us...@cloudstack.apache.org
Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs

+1 To Rohit’s suggestion
On Wed, Mar 21, 2018 at 11:35 AM Khosrow Moossavi 
wrote:

> Thanks Rohit, that's a really great sum-up of proposition!
>
> According to the private issue topic, as far as I understand, we don't have
> any private issue per se, unless they are security, vulnerability
> or CVE related and the process of reporting them -being really private
> until they are fixed- are well-defined. So I would say the mentioned
> security@ ML and have an interim ticket in Jira or the ML itself works and
> when the fix is out, for sake of archive, the issue can be created
> in GH and set as closed right away.
>
>
>
> On Wed, Mar 21, 2018 at 6:38 AM, Rafael Weingärtner <
> rafaelweingart...@gmail.com> wrote:
>
> > I think that works as well. Let's see what others think about it.
> >
> > On Wed, Mar 21, 2018 at 4:15 AM, Rohit Yadav 
> > wrote:
> >
> > > Thanks Rafael for your inputs. You're right about access control
> > > limitation on Github.
> > >
> > >
> > > However, I think having another repository to track security stuff can
> > add
> > > overhead (and to manage its custom ACLs with INFRA, as all cloudstack*
> > > repos are allowed access to all PMC/committers now).
> > >
> > >
> > > Users are advised to report security issues on security@, so how about
> > we
> > > continue to use JIRA for security issues (logging, tracking, and
> > > discussions) and limit the proposed change to just moving to Github
> > issues
> > > as a first step?
> > >
> > >
> > > - Rohit
> > >
> > > 
> > >
> > >
> > >
> > > 
> > > From: Rafael Weingärtner 
> > > Sent: Tuesday, March 20, 2018 11:46:32 PM
> > > To: dev
> > > Cc: us...@cloudstack.apache.org
> > > Subject: Re: [DISCUSS] Relax strict requirement of JIRA ID for PRs
> > >
> > > It looks like you have done all of the homework here. If it comes to a
> > > vote, I am +1 on migrating issues to Github, and even the Wiki in the
> > > future.  The Github would be able to pretty much provide everything
> that
> > we
> > > have in both Wiki and Jira. Therefore, it feels better to work on a
> > single
> > > platform than to spread information across them. However, we still have
> > one
> > > problem. The security issues/tickets in Jira. How can we manage them in
> > > Github? As far as I know, there is no way to control the access to
> > certain
> > > issues/tickets in Github.
> > >
> > > To tackle that problem with security issues we could open a ticket with
> > > Github; and in the meantime, we could set up a private repository in
> the
> > > Apache organization to hold the security issues (e.g.
> > cloudstack-security).
> > >
> > >
> > > Thanks Rohit.
> > >
> > >
> > >
> > > On Mon, Mar 19, 2018 at 7:58 AM, Rohit Yadav <
> rohit.ya...@shapeblue.com>
> > > wrote:
> > >
> > > > (I've cc-ed user ML to gather feedback from users for this email as
> > > well.)
> > > > All,
> > > > Thank you for your feedbacks, discussions, and suggestions. I have
> > tried
> > > > to take on board all the feedback from the discussion and I propose
> the
> > > > following:
> > > > # Problem
> > > > Let me summarize the problems we're facing and propose some solution
> > > > (which may require voting) in the next section:
> > > > - Search:
> > > > The source of truth is in the git repository (Github or asf mirror),
> > > > however, our issue tracking and wiki systems are different. Therefore
> > any
> > > > task requires us to move back and forth between these various
> > > > portals/systems. As an example - a contributor trying to find whether
> > an
> > > > issue was fixed, requires them to search both JIRA, Github for pull
> > > > requests or commits (and sometimes the release notes and MLs).
> > > > - Audience/Platform:
> > > > From an audience's perspective, the user ML and JIRA issue are for
> > users
> > > > to be able to reach the community and seek help with a bug or
> request a
> > > new
> > > > feature.
> > > > The dev ML, and github PR are ways that developers usually use to
> > > > fix/address an issue or develop a new feature, and get them accepted
> > > > towards a release.
> > > > CWiki is used by both to track articles, documentation and FSs, the
> > docs
> > > > website hosts docs for install/admin/release notes is user-facing.
> Both
> > > > JIRA and Confluence are slow compared to Github. The docs website is
> a
> > > > static website and is fast.
> > > > - Relationship and discovery:
> > > > Historically, the main reason for having a JIRA id wi

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

[Rafael Weingärtner]

 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

cloudmonkey ServiceCapabilities question

[Nux!]

Hi,

I hit a UI bug[1] and wanted to work around it by using Cloudmonkey, but I 
caught my ears in the syntax.
Anyone knows how to use it to define service capabilities for Guest networks?

Tried 
"servicecapabilitylist=Dns:VirtualRouter,Dhcp:VirtualRouter,UserData:VirtualRouter",
 but that failed with great success.

Lucian


--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

Re: cloudmonkey ServiceCapabilities question

[Nux!]

The said UI bug is at
https://issues.apache.org/jira/browse/CLOUDSTACK-10343

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Nux!" 
> To: "dev" 
> Sent: Friday, 23 March, 2018 14:57:59
> Subject: cloudmonkey ServiceCapabilities question

> Hi,
> 
> I hit a UI bug[1] and wanted to work around it by using Cloudmonkey, but I
> caught my ears in the syntax.
> Anyone knows how to use it to define service capabilities for Guest networks?
> 
> Tried
> "servicecapabilitylist=Dns:VirtualRouter,Dhcp:VirtualRouter,UserData:VirtualRouter",
> but that failed with great success.
> 
> Lucian
> 
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro

Re: cloudmonkey ServiceCapabilities question

[Rohit Yadav]

Hi Lucian,


With cloudmonkey can you try:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+cloudmonkey+CLI#CloudStackcloudmonkeyCLI-Argumentpassing



Example;

> create networkoffering supportedservices=Dhcp,Dns 
> serviceproviderlist[0].service=Dhcp 
> serviceproviderlist[0].provider=VirtualRouter 
> serviceproviderlist[1].service=Dns 
> serviceproviderlist[1].provider=VirtualRouter ... pass rest of the params ...


- Rohit






From: Nux! 
Sent: Friday, March 23, 2018 8:27:59 PM
To: dev
Subject: cloudmonkey ServiceCapabilities question

Hi,

I hit a UI bug[1] and wanted to work around it by using Cloudmonkey, but I 
caught my ears in the syntax.
Anyone knows how to use it to define service capabilities for Guest networks?

Tried 
"servicecapabilitylist=Dns:VirtualRouter,Dhcp:VirtualRouter,UserData:VirtualRouter",
 but that failed with great success.

Lucian


--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Re: cloudmonkey ServiceCapabilities question

[Nux!]

Excellent, thanks!

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Rohit Yadav" 
> To: "dev" 
> Sent: Friday, 23 March, 2018 15:39:51
> Subject: Re: cloudmonkey ServiceCapabilities question

> Hi Lucian,
> 
> 
> With cloudmonkey can you try:
> 
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+cloudmonkey+CLI#CloudStackcloudmonkeyCLI-Argumentpassing
> 
> 
> 
> Example;
> 
>> create networkoffering supportedservices=Dhcp,Dns
>> serviceproviderlist[0].service=Dhcp
>> serviceproviderlist[0].provider=VirtualRouter
>> serviceproviderlist[1].service=Dns
>> serviceproviderlist[1].provider=VirtualRouter ... pass rest of the params ...
> 
> 
> - Rohit
> 
> 
> 
> 
> 
> 
> From: Nux! 
> Sent: Friday, March 23, 2018 8:27:59 PM
> To: dev
> Subject: cloudmonkey ServiceCapabilities question
> 
> Hi,
> 
> I hit a UI bug[1] and wanted to work around it by using Cloudmonkey, but I
> caught my ears in the syntax.
> Anyone knows how to use it to define service capabilities for Guest networks?
> 
> Tried
> "servicecapabilitylist=Dns:VirtualRouter,Dhcp:VirtualRouter,UserData:VirtualRouter",
> but that failed with great success.
> 
> Lucian
> 
> 
> --
> Sent from the Delta quadrant using Borg technology!
> 
> Nux!
> www.nux.ro
> 
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue

Re: cloudmonkey ServiceCapabilities question

[Dag Sonstebo]

Rohit beat me to it but yes works a treat:

create networkoffering name=nux2 displaytext=nux2 networkrate=200 
guestiptype=Shared supportedservices=DHCP,Dns,Firewall specifyvlan=true 
specifyipranges=true serviceProviderList[0].service=Dhcp 
serviceProviderList[0].provider=VirtualRouter 
serviceProviderList[1].service=Dns 
serviceProviderList[1].provider=VirtualRouter 
serviceProviderList[2].service=Firewall 
serviceProviderList[2].provider=VirtualRouter traffictype=GUEST

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 23/03/2018, 15:39, "Rohit Yadav"  wrote:

Hi Lucian,


With cloudmonkey can you try:


https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+cloudmonkey+CLI#CloudStackcloudmonkeyCLI-Argumentpassing



Example;

> create networkoffering supportedservices=Dhcp,Dns 
serviceproviderlist[0].service=Dhcp 
serviceproviderlist[0].provider=VirtualRouter 
serviceproviderlist[1].service=Dns 
serviceproviderlist[1].provider=VirtualRouter ... pass rest of the params ...


- Rohit






From: Nux! 
Sent: Friday, March 23, 2018 8:27:59 PM
To: dev
Subject: cloudmonkey ServiceCapabilities question

Hi,

I hit a UI bug[1] and wanted to work around it by using Cloudmonkey, but I 
caught my ears in the syntax.
Anyone knows how to use it to define service capabilities for Guest 
networks?

Tried 
"servicecapabilitylist=Dns:VirtualRouter,Dhcp:VirtualRouter,UserData:VirtualRouter",
 but that failed with great success.

Lucian


--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

rohit.ya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 




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

Re: cloudmonkey ServiceCapabilities question

[Nux!]

Thanks Dag :)

--
Sent from the Delta quadrant using Borg technology!

Nux!
www.nux.ro

- Original Message -
> From: "Dag Sonstebo" 
> To: "dev" 
> Sent: Friday, 23 March, 2018 15:43:49
> Subject: Re: cloudmonkey ServiceCapabilities question

> Rohit beat me to it but yes works a treat:
> 
> create networkoffering name=nux2 displaytext=nux2 networkrate=200
> guestiptype=Shared supportedservices=DHCP,Dns,Firewall specifyvlan=true
> specifyipranges=true serviceProviderList[0].service=Dhcp
> serviceProviderList[0].provider=VirtualRouter
> serviceProviderList[1].service=Dns
> serviceProviderList[1].provider=VirtualRouter
> serviceProviderList[2].service=Firewall
> serviceProviderList[2].provider=VirtualRouter traffictype=GUEST
> 
> Regards,
> Dag Sonstebo
> Cloud Architect
> ShapeBlue
> 
> On 23/03/2018, 15:39, "Rohit Yadav"  wrote:
> 
>Hi Lucian,
>
>
>With cloudmonkey can you try:
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+cloudmonkey+CLI#CloudStackcloudmonkeyCLI-Argumentpassing
>
>
>
>Example;
>
>> create networkoffering supportedservices=Dhcp,Dns
>> serviceproviderlist[0].service=Dhcp
>> serviceproviderlist[0].provider=VirtualRouter
>> serviceproviderlist[1].service=Dns
>> serviceproviderlist[1].provider=VirtualRouter ... pass rest of the 
> params ...
>
>
>- Rohit
>
>
>
>
>
>
>From: Nux! 
>Sent: Friday, March 23, 2018 8:27:59 PM
>To: dev
>Subject: cloudmonkey ServiceCapabilities question
>
>Hi,
>
>I hit a UI bug[1] and wanted to work around it by using Cloudmonkey, but I
>caught my ears in the syntax.
>Anyone knows how to use it to define service capabilities for Guest 
> networks?
>
>Tried
>
> "servicecapabilitylist=Dns:VirtualRouter,Dhcp:VirtualRouter,UserData:VirtualRouter",
>but that failed with great success.
>
>Lucian
>
>
>--
>Sent from the Delta quadrant using Borg technology!
>
>Nux!
>www.nux.ro
>
>rohit.ya...@shapeblue.com
>www.shapeblue.com
>53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>@shapeblue
>  
> 
>
>
> 
> 
> dag.sonst...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue