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

[Rohit Yadav]

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


- Rohit





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 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 
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 with a PR/commit is to
> be able to track changes for an open bug and gather such a list in the
> release notes. It also helps with cross-searching of a PR against a JIRA
> ticket and searching a JIRA id for possible discussion from an accepted PR.
> A git commit (for example on github) can also help by telling us which tags
> or branches the commit was included in, so helps in knowing which version
> of ACS will have that in.
>  - Behaviours:
> With the current strict requirement of JIRA ids for each PR, we see these
> behaviours:
> (a) many times the author may not engage after sending the PR and may not
> add a JIRA id causing that PR to get blocked indefinitely,
> (b) the author would create a JIRA id just for the sake of it with minimal
> description and not filling all available fields such as affects and/or fix
> version.
> After a PR is accepted the JIRA ticket may not be properly closed/resolved
> to leave us with several open tickets which are in fact close-able.
> - Pollution:
> Due to JIRA-caused behaviours 'administrative' changes such as changing of
> versions, addition of upgrade paths after a version is cut, changes to
> update the iso url, dependency version in pom.xml etc end up creating '00s
> of new JIRA ticket. We're already in our 10k numbers. At this point in time
> it is not likely that all these tickets will be addressed, the workload
> involved would simply not make this feasible.
> # Let's discuss Solutions
> Let me acknowledge here that enforcing any process in the community is a
> challenge and to some extent not possible in a community of contributors
> doing work in their *free time*. In an ideal world, I understand we would
> want all procedures to be followed (as some of mentioned in favour of that)
> but practically if there are other ways to fix our problems and reduce
> red-tape we should explore that. Let me propose a

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

[Wido den Hollander]

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
>   
>  
> 
> 

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

[Rohit Yadav]

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.


- 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
  
 

Re: Notice that Gabriel Bräscher now works at PCextreme

[Daan Hoogland]

nice going Gabriel and congratulations to PCextreme!

On Tue, Mar 20, 2018 at 8:36 PM, Gabriel Beims Bräscher <
gabrasc...@gmail.com> wrote:

> Thank you, guys :)
>
> 2018-03-20 16:23 GMT-03:00 Wei ZHOU :
>
> > Congratulations Gabriel!
> >
> > Welcome to NL :)
> >
> >
> >
> > 2018-03-20 14:50 GMT+01:00 Wido den Hollander :
> >
> >> Hi,
> >>
> >> Just wanted to let you know that Gabriel Bräscher started working at
> >> PCextreme this week.
> >>
> >> He'll be committing and developing on CloudStack for PCextreme and the
> >> community.
> >>
> >> Just so everybody knows that we are colleagues now.
> >>
> >> Let's make CloudStack even better!
> >>
> >> Wido
> >>
> >
> >
>



-- 
Daan

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

[Rafael Weingärtner]

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 
> 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 with a PR/commit is to
> > be able to track changes for an open bug and gather such a list in the
> > release notes. It also helps with cross-searching of a PR against a JIRA
> > ticket and searching a JIRA id for possible discussion from an accepted
> PR.
> > A git commit (for example on github) can also help by telling us which
> tags
> > or branches the commit was included in, so helps in knowing which version
> > of ACS will have that in.
> >  - Behaviours:
> > With the current strict requirement of JIRA ids for each PR, we see these
> > behaviours:
> > (a) many times the author may not engage after sending the PR and may not
> > add a JIRA id causing that PR to get blocked indefinitely,
> > (b) the author would create a JIRA id just for the sake of it with
> minimal
> > description and not filling all available fields such as affects and/or
> fix
> > version.
> > After a PR is accepted the JIRA ticket may not be properly
> closed/resolved
> > to leave us with several open tickets which are in fact close-able.
> > - Pollution:
> > Due to JIRA-caused behaviours 'administrative' changes such as changing
> of
> > versions, addition of upgrade paths after a version is cut, changes to
> > update the iso url, dependency version in pom.xml etc end up creating
> '00s
> > of new JIRA ticket. We're already in our 10k numbers. At this point in
> time
> > it is not likely that all these tickets will be addressed, the workload
> > involved would simply not make this feasible.
> > # Let's discuss Solutions
> > Let me acknowledge here that enforcing any process in the community is a
> > challenge and to some exten

Re: New committer: Dag Sonstebo

[Daan Hoogland]

hey Dag, keep up the good work, thanks and welcome

On Tue, Mar 20, 2018 at 9:21 PM, Simon Weller 
wrote:

> Congrats Dag, much deserved!
>
> 
> From: John Kinsella 
> Sent: Tuesday, March 20, 2018 8:58 AM
> To: 
> Subject: New committer: Dag Sonstebo
>
> The Project Management Committee (PMC) for Apache CloudStack has
> invited Dag Sonsteboto become a committer and we are pleased to
> announce that he has accepted.
>
> I’ll take a moment here to remind folks that being an ASF committer
> isn’t purely about code - Dag has been helping out for quite a while
> on users@, and seems to have a strong interest around ACS and the
> community. We welcome this activity, and encourage others to help
> out as they can - it doesn’t necessarily have to be purely code-related.
>
> Being a committer enables easier contribution to the project since
> there is no need to go via the patch submission process. This should
> enable better productivity.
>
> Please join me in welcoming Dag!
>
> John
>



-- 
Daan

Re: CFP- Cloudstack collab conference 2018

[Kevin A. McGrail]

+planners

One thing I would add if Rich thinks it is ok would be a link added to
apachecon.com to  http://cloudstackcollab.org/?

Regards,
KAM

--
Kevin A. McGrail
Asst. Treasurer & VP Fundraising, Apache Software Foundation
Chair Emeritus Apache SpamAssassin Project
https://www.linkedin.com/in/kmcgrail - 703.798.0171

On Tue, Mar 20, 2018 at 6:44 PM, Will Stevens  wrote:

> It is a bit quick and dirty, but I have updated the CloudStack
> Collaboration Conference websites.
>
> Here is the parent site: http://cloudstackcollab.org/
>
> Here is the site for this specific event: http://ca.cloudstackcollab.org/
>
> I have setup the 'Sponsor' button to basically do a `mailto` the PMC
> list.  I don't have a better solution than that for now.
>
> Also, I have defined the dates as what I expect them to be, but we don't
> know them for sure yet.
>
> I setup the hashtag of #ccc2018mtl which follows a similar format as some
> previous hashtags for the event.
>
> I have tried to setup the 'Speaker' and 'Schedule' details with as much
> appropriate info as I can.
>
> Let me know if you see things that are wrong or you would like changes.  I
> basically built the site while I sat in a meeting this afternoon, so it is
> not perfect or very extensive, but it covers the main pieces it needs to.
>
> Thoughts?
>
> *Will Stevens*
> Chief Technology Officer
> c 514.826.0190 <(514)%20826-0190>
>
> 
>
> On Mon, Mar 19, 2018 at 6:18 AM, Giles Sirett 
> wrote:
>
>> All
>> CFP - CLOUDSTACK COLLAB 2018 - DEADLINE 30 MARCH
>>
>> We have an agreement in principle to co-locate this years Cloudstack
>> conference with Apachecon
>> Montreal  24-25 September
>> https://www.apachecon.com/
>> As last year in Miami, we will be having a "conference in a conference" -
>> so tickets will allow people to experience the whole Apachecon event
>>
>> There are still some details still to work out (on the name, exact format
>> and exactly what facilities we can have), but the key thing right now  is
>> to get talks  submitted. We're using the Apachecon CFP:
>> https://www.apachecon.com/acna18/
>>
>> I apologise for the short notice, but the CFP closes on March 30.
>> There is no way to tell the CFP that you are submitting something
>> specifically for Cloudstack - so please tag your talk title with
>> "[Cloudstack]:talk name"
>>
>> There is lots to do around sponsorship, exact format, etc but the key
>> deadline this stage is to get plenty of talks submitted
>>
>> Other things worth considering:
>>
>>   1.  We will need a panel to sift/select talks. Wido led on this last
>> year. MikeT, do you want to lead this year ?
>>   2.  It will be important that we encourage interested companies to help
>> sponsor the event. Anybody who think their company may sponsor, please ping
>> Kevin A. McGrail kmcgr...@apache.org
>>
>> Kind regards
>> Giles
>>
>>
>> giles.sir...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N
>> 
>> 4HSUK
>> @shapeblue
>>
>>
>>
>>
>

Re: CFP- Cloudstack collab conference 2018

[Will Stevens]

I don't even see a CloudStack reference on their site right now, so I am
not sure where that would go.  Are you basically saying that we should ask
that the CloudStack Collab be added to their site and pointed to our site?

*Will Stevens*
Chief Technology Officer
c 514.826.0190



On Wed, Mar 21, 2018 at 9:00 AM, Kevin A. McGrail 
wrote:

> +planners
>
> One thing I would add if Rich thinks it is ok would be a link added to
> apachecon.com to  http://cloudstackcollab.org/?
>
> Regards,
> KAM
>
> --
> Kevin A. McGrail
> Asst. Treasurer & VP Fundraising, Apache Software Foundation
> Chair Emeritus Apache SpamAssassin Project
> https://www.linkedin.com/in/kmcgrail - 703.798.0171 <(703)%20798-0171>
>
> On Tue, Mar 20, 2018 at 6:44 PM, Will Stevens 
> wrote:
>
>> It is a bit quick and dirty, but I have updated the CloudStack
>> Collaboration Conference websites.
>>
>> Here is the parent site: http://cloudstackcollab.org/
>>
>> Here is the site for this specific event: http://ca.cloudstackcollab.org/
>>
>> I have setup the 'Sponsor' button to basically do a `mailto` the PMC
>> list.  I don't have a better solution than that for now.
>>
>> Also, I have defined the dates as what I expect them to be, but we don't
>> know them for sure yet.
>>
>> I setup the hashtag of #ccc2018mtl which follows a similar format as some
>> previous hashtags for the event.
>>
>> I have tried to setup the 'Speaker' and 'Schedule' details with as much
>> appropriate info as I can.
>>
>> Let me know if you see things that are wrong or you would like changes.
>> I basically built the site while I sat in a meeting this afternoon, so it
>> is not perfect or very extensive, but it covers the main pieces it needs to.
>>
>> Thoughts?
>>
>> *Will Stevens*
>> Chief Technology Officer
>> c 514.826.0190 <(514)%20826-0190>
>>
>> 
>>
>> On Mon, Mar 19, 2018 at 6:18 AM, Giles Sirett > > wrote:
>>
>>> All
>>> CFP - CLOUDSTACK COLLAB 2018 - DEADLINE 30 MARCH
>>>
>>> We have an agreement in principle to co-locate this years Cloudstack
>>> conference with Apachecon
>>> Montreal  24-25 September
>>> https://www.apachecon.com/
>>> As last year in Miami, we will be having a "conference in a conference"
>>> - so tickets will allow people to experience the whole Apachecon event
>>>
>>> There are still some details still to work out (on the name, exact
>>> format and exactly what facilities we can have), but the key thing right
>>> now  is to get talks  submitted. We're using the Apachecon CFP:
>>> https://www.apachecon.com/acna18/
>>>
>>> I apologise for the short notice, but the CFP closes on March 30.
>>> There is no way to tell the CFP that you are submitting something
>>> specifically for Cloudstack - so please tag your talk title with
>>> "[Cloudstack]:talk name"
>>>
>>> There is lots to do around sponsorship, exact format, etc but the key
>>> deadline this stage is to get plenty of talks submitted
>>>
>>> Other things worth considering:
>>>
>>>   1.  We will need a panel to sift/select talks. Wido led on this last
>>> year. MikeT, do you want to lead this year ?
>>>   2.  It will be important that we encourage interested companies to
>>> help sponsor the event. Anybody who think their company may sponsor, please
>>> ping Kevin A. McGrail kmcgr...@apache.org
>>>
>>> Kind regards
>>> Giles
>>>
>>>
>>> giles.sir...@shapeblue.com
>>> www.shapeblue.com
>>> 53 Chandos Place, Covent Garden, London  WC2N
>>> 
>>> 4HSUK
>>> @shapeblue
>>>
>>>
>>>
>>>
>>
>

Re: Notice that Gabriel Bräscher now works at PCextreme

[Khosrow Moossavi]

Congratulations Gabriel!



On Wed, Mar 21, 2018 at 5:40 AM, Daan Hoogland 
wrote:

> nice going Gabriel and congratulations to PCextreme!
>
> On Tue, Mar 20, 2018 at 8:36 PM, Gabriel Beims Bräscher <
> gabrasc...@gmail.com> wrote:
>
> > Thank you, guys :)
> >
> > 2018-03-20 16:23 GMT-03:00 Wei ZHOU :
> >
> > > Congratulations Gabriel!
> > >
> > > Welcome to NL :)
> > >
> > >
> > >
> > > 2018-03-20 14:50 GMT+01:00 Wido den Hollander :
> > >
> > >> Hi,
> > >>
> > >> Just wanted to let you know that Gabriel Bräscher started working at
> > >> PCextreme this week.
> > >>
> > >> He'll be committing and developing on CloudStack for PCextreme and the
> > >> community.
> > >>
> > >> Just so everybody knows that we are colleagues now.
> > >>
> > >> Let's make CloudStack even better!
> > >>
> > >> Wido
> > >>
> > >
> > >
> >
>
>
>
> --
> Daan
>

Re: New committer: Dag Sonstebo

[Khosrow Moossavi]

Congratulations Dag!



On Wed, Mar 21, 2018 at 6:57 AM, Daan Hoogland 
wrote:

> hey Dag, keep up the good work, thanks and welcome
>
> On Tue, Mar 20, 2018 at 9:21 PM, Simon Weller 
> wrote:
>
> > Congrats Dag, much deserved!
> >
> > 
> > From: John Kinsella 
> > Sent: Tuesday, March 20, 2018 8:58 AM
> > To: 
> > Subject: New committer: Dag Sonstebo
> >
> > The Project Management Committee (PMC) for Apache CloudStack has
> > invited Dag Sonsteboto become a committer and we are pleased to
> > announce that he has accepted.
> >
> > I’ll take a moment here to remind folks that being an ASF committer
> > isn’t purely about code - Dag has been helping out for quite a while
> > on users@, and seems to have a strong interest around ACS and the
> > community. We welcome this activity, and encourage others to help
> > out as they can - it doesn’t necessarily have to be purely code-related.
> >
> > Being a committer enables easier contribution to the project since
> > there is no need to go via the patch submission process. This should
> > enable better productivity.
> >
> > Please join me in welcoming Dag!
> >
> > John
> >
>
>
>
> --
> Daan
>

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

[Khosrow Moossavi]

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 
> > 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 with a PR/commit is
> to
> > > be able to track changes for an open bug and gather such a list in the
> > > release notes. It also helps with cross-searching of a PR against a
> JIRA
> > > ticket and searching a JIRA id for possible discussion from an accepted
> > PR.
> > > A git commit (for example on github) can also help by telling us which
> > tags
> > > or branches the commit was included in, so helps in knowing which
> version
> > > of ACS will have that in.
> > >  - Behaviours:
> > > With the current strict requirement of JIRA ids for each PR, we see
> these
> > > behaviours:
> > > (a) many times the author may not engage after sending the PR and may
> not
> > > add a JIRA id causing that PR to get blocked indefinitely,
> > > (b) the author would create a JIRA id just for the sake of it with
> > minimal
> 

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

[Syed Ahmed]

+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 with a PR/commit
> is
> > to
> > > > be able to track changes for an open bug and gather such a list in
> the
> > > > release notes. It also helps with cross-searching of a PR against a
> > JIRA
> > > > ticket and searching a JIRA id for possible discussion from an
> accepted
> > > PR.
> > > > A git commit (for example on github) can also help by telling us
> which
> > > tags
> > > > or branches the commit was included in, so helps in knowing which
> > version
> > > > of ACS

Re: New committer: Dag Sonstebo

[Syed Ahmed]

Welcome Dag
On Wed, Mar 21, 2018 at 11:12 AM Khosrow Moossavi 
wrote:

> Congratulations Dag!
>
>
>
> On Wed, Mar 21, 2018 at 6:57 AM, Daan Hoogland 
> wrote:
>
> > hey Dag, keep up the good work, thanks and welcome
> >
> > On Tue, Mar 20, 2018 at 9:21 PM, Simon Weller 
> > wrote:
> >
> > > Congrats Dag, much deserved!
> > >
> > > 
> > > From: John Kinsella 
> > > Sent: Tuesday, March 20, 2018 8:58 AM
> > > To: 
> > > Subject: New committer: Dag Sonstebo
> > >
> > > The Project Management Committee (PMC) for Apache CloudStack has
> > > invited Dag Sonsteboto become a committer and we are pleased to
> > > announce that he has accepted.
> > >
> > > I’ll take a moment here to remind folks that being an ASF committer
> > > isn’t purely about code - Dag has been helping out for quite a while
> > > on users@, and seems to have a strong interest around ACS and the
> > > community. We welcome this activity, and encourage others to help
> > > out as they can - it doesn’t necessarily have to be purely
> code-related.
> > >
> > > Being a committer enables easier contribution to the project since
> > > there is no need to go via the patch submission process. This should
> > > enable better productivity.
> > >
> > > Please join me in welcoming Dag!
> > >
> > > John
> > >
> >
> >
> >
> > --
> > Daan
> >
>

Re: New committer: Dag Sonstebo

[Ian Rae]

Great stuff Dag!!

On Wed, Mar 21, 2018 at 3:21 PM, Syed Ahmed  wrote:
> Welcome Dag
> On Wed, Mar 21, 2018 at 11:12 AM Khosrow Moossavi 
> wrote:
>
>> Congratulations Dag!
>>
>>
>>
>> On Wed, Mar 21, 2018 at 6:57 AM, Daan Hoogland 
>> wrote:
>>
>> > hey Dag, keep up the good work, thanks and welcome
>> >
>> > On Tue, Mar 20, 2018 at 9:21 PM, Simon Weller 
>> > wrote:
>> >
>> > > Congrats Dag, much deserved!
>> > >
>> > > 
>> > > From: John Kinsella 
>> > > Sent: Tuesday, March 20, 2018 8:58 AM
>> > > To: 
>> > > Subject: New committer: Dag Sonstebo
>> > >
>> > > The Project Management Committee (PMC) for Apache CloudStack has
>> > > invited Dag Sonsteboto become a committer and we are pleased to
>> > > announce that he has accepted.
>> > >
>> > > I’ll take a moment here to remind folks that being an ASF committer
>> > > isn’t purely about code - Dag has been helping out for quite a while
>> > > on users@, and seems to have a strong interest around ACS and the
>> > > community. We welcome this activity, and encourage others to help
>> > > out as they can - it doesn’t necessarily have to be purely
>> code-related.
>> > >
>> > > Being a committer enables easier contribution to the project since
>> > > there is no need to go via the patch submission process. This should
>> > > enable better productivity.
>> > >
>> > > Please join me in welcoming Dag!
>> > >
>> > > John
>> > >
>> >
>> >
>> >
>> > --
>> > Daan
>> >
>>



-- 
Ian Rae
CEO | PDG
c: 514.944.4008

CloudOps | Cloud Infrastructure and Networking Solutions
www.cloudops.com | 420 rue Guy | Montreal | Canada | H3J 1S6

Re: New committer: Dag Sonstebo

[Jan-Arve Nygård]

Well deserved Dag! Gratulerer!

ons. 21. mar. 2018 kl. 23:59 skrev Ian Rae :

> Great stuff Dag!!
>
> On Wed, Mar 21, 2018 at 3:21 PM, Syed Ahmed  wrote:
> > Welcome Dag
> > On Wed, Mar 21, 2018 at 11:12 AM Khosrow Moossavi <
> kmooss...@cloudops.com>
> > wrote:
> >
> >> Congratulations Dag!
> >>
> >>
> >>
> >> On Wed, Mar 21, 2018 at 6:57 AM, Daan Hoogland  >
> >> wrote:
> >>
> >> > hey Dag, keep up the good work, thanks and welcome
> >> >
> >> > On Tue, Mar 20, 2018 at 9:21 PM, Simon Weller  >
> >> > wrote:
> >> >
> >> > > Congrats Dag, much deserved!
> >> > >
> >> > > 
> >> > > From: John Kinsella 
> >> > > Sent: Tuesday, March 20, 2018 8:58 AM
> >> > > To: 
> >> > > Subject: New committer: Dag Sonstebo
> >> > >
> >> > > The Project Management Committee (PMC) for Apache CloudStack has
> >> > > invited Dag Sonsteboto become a committer and we are pleased to
> >> > > announce that he has accepted.
> >> > >
> >> > > I’ll take a moment here to remind folks that being an ASF committer
> >> > > isn’t purely about code - Dag has been helping out for quite a while
> >> > > on users@, and seems to have a strong interest around ACS and the
> >> > > community. We welcome this activity, and encourage others to help
> >> > > out as they can - it doesn’t necessarily have to be purely
> >> code-related.
> >> > >
> >> > > Being a committer enables easier contribution to the project since
> >> > > there is no need to go via the patch submission process. This should
> >> > > enable better productivity.
> >> > >
> >> > > Please join me in welcoming Dag!
> >> > >
> >> > > John
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Daan
> >> >
> >>
>
>
>
> --
> Ian Rae
> CEO | PDG
> c: 514.944.4008
>
> CloudOps | Cloud Infrastructure and Networking Solutions
> www.cloudops.com | 420 rue Guy | Montreal | Canada | H3J 1S6
>