Re: [XenServer] meltdown-spectre

[Pierre-Luc Dion]

Hi,

Another problem,  VR are configured via eth0 (cloudlinklocal) that is
create via PV params of the VM on XenServer. So Creation HVM VR will not
work. We will have to think about an alternative way to setup eth0 on VR on
XenServer.
We will file a jira issue about this. This will be problematic with XS
7,1cu1, 7.2, 7.3

Tim, yes fro XS template, the maping, at least on Xs7.1 seams to work just
fine. They were pretty much all as HVM exept Centos 6, Debian,.. until the
Meltdown hotfix.




On Mon, Jan 8, 2018 at 10:47 PM, Tim Mackey  wrote:

> PLD,
>
> One thing to add to your testing is template management. When I was doing
> all the Packer stuff with XS 6.5 and 7, ACS needed to know if the template
> was PV or HVM to provision properly. No idea if the ACS template logic has
> changed since then, but something to be aware of.
>
> From a performance perspective with XS 6.5 started having newer XS
> templates follow an HVM model. e.g. CentOS 7 on XS 6.5 was HVM not PV.
> iirc, the performance difference was negligible on reasonably new CPUs
> (Sandy Bridge+ I think).
>
> -tim
>
> On Mon, Jan 8, 2018 at 9:39 PM, Ivan Kudryavtsev  >
> wrote:
>
> > Hi. Every kind of virtualization is affected according to qemu
> developers.
> >
> > 9 янв. 2018 г. 9:32 пользователь "Pierre-Luc Dion" 
> > написал:
> >
> > >  Hi,
> > >
> > > From recent blog post, I've read that system using full virtualization
> > such
> > > as KVM, VMware or Xen-HVM are not affected?  Anyhow, from the latest
> > hotfix
> > > of XenServer 7.1cu1 hf8, it look like they systematically convert VM
> from
> > > PV to HVM, so in the case of a VM stop/start by CloudStack, a PV vm
> would
> > > be restarted as HVM.
> > >
> > > Look like this could be problematic if your VM kernel does not support
> > > both, we've just starting tested and so far look like our Debian
> systemvm
> > > template work fine, it can be created as HVM.
> > >
> > > Another point is that Citrix released an hotfix for xs7.2, 7.3 but not
> > for
> > > 7.1, you need to cumulative update to remain on 7.1 which is LTS.
> > >
> > > And last, does anyone did some benchmark before and after the kernel
> fix
> > > for Meltdown ?  Some report state 30-35% cpu usage increase (not
> > hypervisor
> > > specific) and  Lucian [1] might indicate it would depend on the cpu
> > model.
> > > Any metrics to share ?  We are doing some tests on our side we should
> be
> > > able to share some stuff soon...
> > >
> > > Regards,
> > >
> > > [1] http://markmail.org/thread/wkzze3n24mns274x
> > >
> >
>

Re: IP Address Discrepancy with VMware

[Tutkowski, Mike]

Hi Paul,

Thanks for looking into that!

I was just spinning up a VM in a Basic Zone using VMware and NFS…nothing really 
out of the ordinary.

I’m traveling today, but should be able to re-try this use case again tomorrow.

Thanks again!
Mike

On 1/11/18, 2:12 AM, "Paul Angus"  wrote:

Hey Mike, were you doing anything specific/special?  I haven't yet managed 
to get the wrong IP address.
how does the config for dhcp leases look on the VR?


Kind regards,

Paul Angus

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com] 
Sent: 11 January 2018 07:52
To: dev@cloudstack.apache.org
Subject: Re: IP Address Discrepancy with VMware

Thanks, Paul!

> On Jan 11, 2018, at 12:49 AM, Paul Angus  wrote:
> 
> I'll have a look @ mike
> 
> 
> 
> Kind regards,
> 
> Paul Angus
> 
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
> 
> 
> 
> 
> -Original Message-
> From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com] 
> Sent: 11 January 2018 07:31
> To: dev@cloudstack.apache.org
> Subject: IP Address Discrepancy with VMware
> 
> Hi,
> 
> While I was running some tests related to 4.11 tonight, I noticed the 
following discrepancy with regards to the IP address given to a VM of mine:
> 
> https://imgur.com/3ODXHNe
> 
> According to CloudStack, the IP address should be 10.117.40.28. However, 
when I run ifconfig, I get 10.117.40.115.
> 
> In this situation, I’m running only with VMware (no other hypervisor type 
in use) in a Basic Zone where the root disk of the VM is on NFS.
> 
> Anyone else able to reproduce this issue?
> 
> Thanks,
> Mike

Re: Which StringUtils to use?

[Rafael Weingärtner]

Wrapping would still hold code on our side. We have to get rid of code…

If we want to start removing CloudStack’s StringUtils in favor of
StringUtils from Apache, we could start creating PRs by components (java
project in Eclipse). That is manageable to do and to review. There are
about 119 classes that use CloudStack’s StringUtils.


We will not be able to remove CloudStack's StringUtils though. There are
very specific things there such as "applyPagination" that should not even
be there... I guess the programmer was running out of places to write code

On Thu, Jan 11, 2018 at 6:25 PM, Daan Hoogland 
wrote:

> All, I am having second thoughts. I think we should maintain a wrapper for
> string utils and pass through as much as possible to commons string utils.
> A similar thing is applicable to logging. It was started at one time and a
> second attempt was started to use slf4j.
> I think we should encapsulate these kind of utilities to facilitate
> migration.
> There is also json and xml formatting and maybe handling sockets and (big
> one) data access objects :/
>
> @Ron, all string utils are static methods.
>
> On Thu, Jan 11, 2018 at 12:11 AM, Ron Wheeler  com> wrote:
>
> > Certainly better to find the references and remove them if you can get
> > that done in a single effort.
> >
> > Just a technical question: Could one not just add the Warning to the
> > constructor?
> > Might have to create a null (log warning only) constructor.
> >
> > Ron
> >
> >
> > On 10/01/2018 3:58 PM, Daan Hoogland wrote:
> >
> >> We can add log messages to each of the methods in StringUtils but I do
> not
> >> think that is a good way to go. Any method you touch you can reform or
> >> remove anyhow.
> >>
> >> On Wed, Jan 10, 2018 at 9:51 PM, Ron Wheeler <
> >> rwhee...@artifact-software.com
> >>
> >>> wrote:
> >>> Agreed about deprecation.
> >>> A logged WARNing would be detected during testing as well as at
> run-time.
> >>>
> >>> Ron
> >>>
> >>> On 10/01/2018 3:34 PM, Daan Hoogland wrote:
> >>>
> >>> Ron, we could but that would only log during compile-time, not on
> >>> runtime.
> >>> I am doing some analysis and commenting in Wido's ticket.
> >>>
> >>> On Wed, Jan 10, 2018 at 9:23 PM, Ron Wheeler
>  >>> com> wrote:
> >>>
> >>> Is it possible to mark it as deprecated and have it log a warning when
>  used?
> 
>  Ron
> 
> 
>  On 10/01/2018 2:26 PM, Daan Hoogland wrote:
> 
>  I think we could start with giving it an explicit non standard name
> like
> > CloudStackLocalStringUtils or something a little shorter. Making sure
> > that
> > we prefer for these types of utils to be imported from other
> projects.
> >
> > On Wed, Jan 10, 2018 at 4:26 PM, Wido den Hollander 
> > wrote:
> >
> >
> > On 01/10/2018 01:09 PM, Rafael Weingärtner wrote:
> >>
> >> Instead of creating a PR for that, we could do the bit by bit job
> >>
> >>> (hopefully one day we finish the job).
> >>> Every time we see a code using ACS's StringUtils, we check if it
> can
> >>> be
> >>> replaced by Apache's one.
> >>>
> >>>
> >>> Yes, but that will slip from peoples attention and we will probably
> >>> see
> >>>
> >> cases where people still use the old one by accident.
> >>
> >> I've created a issue: https://issues.apache.org/jira
> >> /browse/CLOUDSTACK-10225
> >>
> >> I also started on some low hanging fruit as some methods in
> >> StringUtils
> >> are not used or are very easy to replace.
> >>
> >>
> >> Wido
> >>
> >> On Wed, Jan 10, 2018 at 10:01 AM, Wido den Hollander <
> w...@widodh.nl>
> >>
> >> wrote:
> >>>
> >>>
> >>> On 01/10/2018 12:01 PM, Daan Hoogland wrote:
> >>>
>  I'd say remove as much functionality as we can from 'our'
>  StringUtils
>  and
> 
>  phase them out asap.
> >
> >
> > Yes, but such a PR would be invasive and would be difficult to
> > merge
> > and
> >
> > also break a lot of other code.
> 
>  It's not easy since it will touch a lot, but I mean, a lot of
> files.
> 
>  Our StringUtils was a very good solution, but the Apache one is
>  better I
>  think.
> 
>  Wido
> 
> 
>  On Wed, Jan 10, 2018 at 11:59 AM, Wido den Hollander <
>  w...@widodh.nl>
> 
>  wrote:
> 
> > Hi,
> >
> > We have com.cloud.utils.StringUtils which has a few nice
> functions,
> >
> >> but
> >> throughout the code I also see org.apache.commons.lang.String
> >> Utils
> >>
> >> They both provide about the same functionality, but which one do
> >> we
> >> prefer?
> >>
> 

Re: Which StringUtils to use?

[Daan Hoogland]

All, I am having second thoughts. I think we should maintain a wrapper for
string utils and pass through as much as possible to commons string utils.
A similar thing is applicable to logging. It was started at one time and a
second attempt was started to use slf4j.
I think we should encapsulate these kind of utilities to facilitate
migration.
There is also json and xml formatting and maybe handling sockets and (big
one) data access objects :/

@Ron, all string utils are static methods.

On Thu, Jan 11, 2018 at 12:11 AM, Ron Wheeler  wrote:

> Certainly better to find the references and remove them if you can get
> that done in a single effort.
>
> Just a technical question: Could one not just add the Warning to the
> constructor?
> Might have to create a null (log warning only) constructor.
>
> Ron
>
>
> On 10/01/2018 3:58 PM, Daan Hoogland wrote:
>
>> We can add log messages to each of the methods in StringUtils but I do not
>> think that is a good way to go. Any method you touch you can reform or
>> remove anyhow.
>>
>> On Wed, Jan 10, 2018 at 9:51 PM, Ron Wheeler <
>> rwhee...@artifact-software.com
>>
>>> wrote:
>>> Agreed about deprecation.
>>> A logged WARNing would be detected during testing as well as at run-time.
>>>
>>> Ron
>>>
>>> On 10/01/2018 3:34 PM, Daan Hoogland wrote:
>>>
>>> Ron, we could but that would only log during compile-time, not on
>>> runtime.
>>> I am doing some analysis and commenting in Wido's ticket.
>>>
>>> On Wed, Jan 10, 2018 at 9:23 PM, Ron Wheeler >> com> wrote:
>>>
>>> Is it possible to mark it as deprecated and have it log a warning when
 used?

 Ron


 On 10/01/2018 2:26 PM, Daan Hoogland wrote:

 I think we could start with giving it an explicit non standard name like
> CloudStackLocalStringUtils or something a little shorter. Making sure
> that
> we prefer for these types of utils to be imported from other projects.
>
> On Wed, Jan 10, 2018 at 4:26 PM, Wido den Hollander 
> wrote:
>
>
> On 01/10/2018 01:09 PM, Rafael Weingärtner wrote:
>>
>> Instead of creating a PR for that, we could do the bit by bit job
>>
>>> (hopefully one day we finish the job).
>>> Every time we see a code using ACS's StringUtils, we check if it can
>>> be
>>> replaced by Apache's one.
>>>
>>>
>>> Yes, but that will slip from peoples attention and we will probably
>>> see
>>>
>> cases where people still use the old one by accident.
>>
>> I've created a issue: https://issues.apache.org/jira
>> /browse/CLOUDSTACK-10225
>>
>> I also started on some low hanging fruit as some methods in
>> StringUtils
>> are not used or are very easy to replace.
>>
>>
>> Wido
>>
>> On Wed, Jan 10, 2018 at 10:01 AM, Wido den Hollander 
>>
>> wrote:
>>>
>>>
>>> On 01/10/2018 12:01 PM, Daan Hoogland wrote:
>>>
 I'd say remove as much functionality as we can from 'our'
 StringUtils
 and

 phase them out asap.
>
>
> Yes, but such a PR would be invasive and would be difficult to
> merge
> and
>
> also break a lot of other code.

 It's not easy since it will touch a lot, but I mean, a lot of files.

 Our StringUtils was a very good solution, but the Apache one is
 better I
 think.

 Wido


 On Wed, Jan 10, 2018 at 11:59 AM, Wido den Hollander <
 w...@widodh.nl>

 wrote:

> Hi,
>
> We have com.cloud.utils.StringUtils which has a few nice functions,
>
>> but
>> throughout the code I also see org.apache.commons.lang.String
>> Utils
>>
>> They both provide about the same functionality, but which one do
>> we
>> prefer?
>>
>> I'd say org.apache.commons.lang.StringUtils as that allows us to
>> remove
>> our own StringUtils, but we could also have 'our' StringUtils
>> simply
>> be a
>> wrapper around org.apache.commons.lang.StringUtils
>>
>> Opinions?
>>
>> Wido
>>
>>
>>
>>
>>
> --
 Ron Wheeler
 President
 Artifact Software Inc
 email: rwhee...@artifact-software.com
 skype: ronaldmwheeler
 phone: 866-970-2435, ext 102



>>> --
>>> Daan
>>>
>>>
>>> --
>>> Ron Wheeler
>>> President
>>> Artifact Software Inc
>>> email: rwhee...@artifact-software.com
>>> skype: ronaldmwheeler
>>> phone: 866-970-2435, ext 102
>>>
>>>
>>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>


-- 

Re: [PROPOSE] EOL for supported OSes & Hypervisors

[Will Stevens]

I like this initiative.  I think this would be valuable to set an
expectation around supportability.

Cheers,

*Will Stevens*
CTO



On Thu, Jan 11, 2018 at 12:11 PM, Paul Angus 
wrote:

> I've cross-posted this as it ultimately effects users more than developers.
>
> I've created a wiki page with the EOL dates from the respective 'vendors'
> of our main supported hypervisors and mgmt. server OSes.
> I've taken End Of Life to be the end of 'mainstream' support i.e. the
> point at which updates to packages will no longer be available.  And part
> of the discussion should be whether this EOL date should be moved out to
> consider end of security patching instead.
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/
> WIP+-+UNOFFICIAL+-+PROPOSAL+-+EOL+Dates
>
> I would like to propose, that as part of the release notes for the
> forthcoming 4.11 release and as a general announcement, that we declare
> that:
>
>
>   *   For any OSes/Hypervisors that are already EOL - we will no longer
> test/support them from the first release after June 2018 (6 months from
> now). And they will be removed from codebase (mainly the database) in the
> first release after Sept 2018 (9 months from now).
>   *   We set End Of Support dates and Removal from Code dates for the
> remaining OSes/Hypervisors.  I propose that End Of Support should be the
> first release after EOL from the vendor, with code removal taking place in
> the first release which occurs after 6 months from 'vendor' EOL date.
>
> Thoughts please
>
>
> Kind regards,
>
> Paul Angus
>
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>

[PROPOSE] EOL for supported OSes & Hypervisors

[Paul Angus]

I've cross-posted this as it ultimately effects users more than developers.

I've created a wiki page with the EOL dates from the respective 'vendors' of 
our main supported hypervisors and mgmt. server OSes.
I've taken End Of Life to be the end of 'mainstream' support i.e. the point at 
which updates to packages will no longer be available.  And part of the 
discussion should be whether this EOL date should be moved out to consider end 
of security patching instead.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/WIP+-+UNOFFICIAL+-+PROPOSAL+-+EOL+Dates

I would like to propose, that as part of the release notes for the forthcoming 
4.11 release and as a general announcement, that we declare that:


  *   For any OSes/Hypervisors that are already EOL - we will no longer 
test/support them from the first release after June 2018 (6 months from now). 
And they will be removed from codebase (mainly the database) in the first 
release after Sept 2018 (9 months from now).
  *   We set End Of Support dates and Removal from Code dates for the remaining 
OSes/Hypervisors.  I propose that End Of Support should be the first release 
after EOL from the vendor, with code removal taking place in the first release 
which occurs after 6 months from 'vendor' EOL date.

Thoughts please


Kind regards,

Paul Angus


paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Re: [DISCUSS] Freezing master for 4.11

[Wido den Hollander]

On 01/10/2018 07:26 PM, Daan Hoogland wrote:

I hope we understand each other correctly: No-one running an earlier
version then 4.11 should miss out on any functionality they are using now.

So if you use ipv6 and multiple cidrs now it must continue to work with no
loss of functionality. see my question below.

On Wed, Jan 10, 2018 at 7:06 PM, Ivan Kudryavtsev 
wrote:


Daan, yes this sounds reasonable, I suppose who would like to fix, could
do custom build for himself...

But still it should be aknowledged somehow, if you use several cidrs for
network, don't use v6, or don't upgrade to 4.11 because things will stop
running well.


​Does this mean that several cidrs in ipv6 works in 4.9 and not in 4.11?



No, it doesn't. IPv6 was introduced in 4.10 and this broke in 4.10.

You can't run with 4.10 with multiple IPv4 CIDRs as well when you have 
IPv6 enabled.


So this is broken in 4.10 and 4.11 in that case.

Wido



if yes; it is a blocker

if no; you might as well upgrade for other features as it doesn't work now
either.

Call for Presentations FOSS Backstage open

[Isabel Drost-Fromm]

Hi,

As announced on Berlin Buzzwords we (that is Isabel Drost-Fromm, Stefan
Rudnitzki as well as the eventing team over at newthinking communications GmbH)
are working on a new conference in summer in Berlin. The name of this new
conference will be "FOSS Backstage". Backstage comprises all things
FOSS governance, open collaboration and how to build and manage communities
within the open source space.


Submission URL: https://foss-backstage.de/call-papers 

The event will comprise presentations on all things FOSS governance,
decentralised decision making, open collaboration. We invite you to submit talks
on the topics: FOSS project governance, collaboration, community management.
Asynchronous/ decentralised decision making.  Vendor neutrality in FOSS,
sustainable FOSS, cross team collaboration.  Dealing with poisonous people.
Project growth and hand-over. Trademarks. Strategic licensing.  While it's
primarily targeted at contributions from FOSS people, we would love to also
learn more on how typical FOSS collaboration models work well within
enterprises. Closely related topics not explicitly listed above are welcome. 

Important Dates (all dates in GMT +2)

Submission deadline: February 18th, 2018.

Conference: June, 13th/14th, 2018


High quality talks are called for, ranging from principles to practice. We are
looking for real world case studies, background on the social architecture of
specific projects and a deep dive into cross community collaboration.
Acceptance notifications will be sent out soon after the submission deadline.
Please include your name, bio and email, the title of the talk, a brief abstract
in English language.

We have drafted the submission form to allow for regular talks, each 45 min in
length. However you are free to submit your own ideas on how to support the
event: If you would like to take our attendees out to show them your favourite
bar in Berlin, please submit this offer through the CfP form.  If you are
interested in sponsoring the event (e.g. we would be happy to provide videos
after the event, free drinks for attendees as well as an after-show party),
please contact us.

Schedule and further updates on the event will be published soon on the event
web page.

Please re-distribute this CfP to people who might be interested.

 Contact us at:
 newthinking communications GmbH
 Schoenhauser Allee 6/7
 10119 Berlin, Germany
 i...@foss-backstage.de


Looking forward to meeting you all in person in summer :) I would love to see 
all those
tracks filled with lots of valuable talks on the Apache Way, on how we work,
on how the incubator works, on how being a 501(c3) influences how people get 
involved
and projects are being run, on how being a member run organisation is different,
on merit for life, on growing communities, on things gone great - and things
gone entirely wrong in the ASF's history, on how to interact with Apache
projects as a corporation and everything else you can think of.


Isabel


-- 
Sorry for any typos: Mail was typed in vim, written in mutt, via ssh (most 
likely involving some kind of mobile connection only.)

RE: IP Address Discrepancy with VMware

[Paul Angus]

Hey Mike, were you doing anything specific/special?  I haven't yet managed to 
get the wrong IP address.
how does the config for dhcp leases look on the VR?


Kind regards,

Paul Angus

paul.an...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 


-Original Message-
From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com] 
Sent: 11 January 2018 07:52
To: dev@cloudstack.apache.org
Subject: Re: IP Address Discrepancy with VMware

Thanks, Paul!

> On Jan 11, 2018, at 12:49 AM, Paul Angus  wrote:
> 
> I'll have a look @ mike
> 
> 
> 
> Kind regards,
> 
> Paul Angus
> 
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
> 
> 
> 
> 
> -Original Message-
> From: Tutkowski, Mike [mailto:mike.tutkow...@netapp.com] 
> Sent: 11 January 2018 07:31
> To: dev@cloudstack.apache.org
> Subject: IP Address Discrepancy with VMware
> 
> Hi,
> 
> While I was running some tests related to 4.11 tonight, I noticed the 
> following discrepancy with regards to the IP address given to a VM of mine:
> 
> https://imgur.com/3ODXHNe
> 
> According to CloudStack, the IP address should be 10.117.40.28. However, when 
> I run ifconfig, I get 10.117.40.115.
> 
> In this situation, I’m running only with VMware (no other hypervisor type in 
> use) in a Basic Zone where the root disk of the VM is on NFS.
> 
> Anyone else able to reproduce this issue?
> 
> Thanks,
> Mike