Re: Asking this in dev as there are many fixes for volumes/snapshots on 4.15.2 and 4.16.0

[Riepl, Gregor (SWISS TXT)]

When you create reoccurring volume snapshot task, instead of transferring only 
that volume all volumes that are associated with VM are transferred to 
secondary storage.
That doesn't sound right.

Are you sure you're really creating a recurring volume snapshot and not a VM 
snapshot?
I believe the VM snapshot includes all disks, but the volume snapshot should 
not.

Related API:
https://cloudstack.apache.org/api/apidocs-4.15/apis/createSnapshot.html
https://cloudstack.apache.org/api/apidocs-4.15/apis/createVMSnapshot.html

CVE-2021-40346 (haproxy 2.x)

[Riepl, Gregor (SWISS TXT)]

Hi,

Are you aware of https://nvd.nist.gov/vuln/detail/CVE-2021-40346 ?
Haproxy 2.0 through 2.5 has a vulnerability that can be exploited to smuggle 
requests to backend systems.

If the CloudStack VR is using one of these versions, it should be patched 
everywhere ASAP.

Regards,
Greg

Re: Dev Environment

[Riepl, Gregor (SWISS TXT)]

Hi Dirk,


My second problem is with git branches. My problem here is that I wanted to use 
the cloudstack version 4.13.1 as base, for this reason I checkout the 4.13.1 
branch, but the build process goes wrong with a couple of errors, after this I 
checkout the master and revert it to the commit 
b2ffa3e.

But the build process still didn’t work. Then I thought  that I have  problems 
with my dev environment and test the build process with the official release, 
but this works fine. So now I’m a little bit confused. What should I do, when I 
want to use a specific code base version?


I had similar problems when I tried to build tags, but I can't quite remember 
how I solved them.
Note that there is no 4.13.1 branch, only 4.13. There is a tag for 4.13.1.0 
though. Perhaps you should try again with the HEAD of 4.13?

Your best option will probably be to clean out any build leftovers and maybe 
even your Maven cache, then try again. There may also be subtle differences in 
building with IntelliJ and from the command line.

Regards,
Gregor

Re: [VOTE] Release Apache CloudStack CloudMonkey 6.1.0

[Riepl, Gregor (SWISS TXT)]

+1 (non-binding)

I tested a few common and less-common things and found no regressions.
Note: I built the binary locally, didn't try the binaries on the Github release 
page.

From: Rohit Yadav 
Sent: 01 July 2020 06:51
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Subject: [VOTE] Release Apache CloudStack CloudMonkey 6.1.0

Hi All,

I've created a 6.1.0 release of CloudMonkey, with the following artifacts
up for a vote:

Git Branch:
https://github.com/apache/cloudstack-cloudmonkey/commits/abc31929e74a9f5b07507db203e75393fffc9f3e
Commit: abc31929e74a9f5b07507db203e75393fffc9f3e

Commits since last release 6.0.0:
https://github.com/apache/cloudstack-cloudmonkey/compare/6.0.0...abc31929e74a9f5b07507db203e75393fffc9f3e

Source release (checksums and signatures are available at the same
location):
https://dist.apache.org/repos/dist/dev/cloudstack/cloudmonkey-6.1.0

To facilitate voting and testing, the builds are uploaded in this
pre-release:
https://github.com/apache/cloudstack-cloudmonkey/releases/tag/6.1.0

List of changes:
https://github.com/apache/cloudstack-cloudmonkey/blob/master/CHANGES.md

PGP release keys (signed using 5ED1E1122DC5E8A4A45112C2484248210EE3D884):
https://dist.apache.org/repos/dist/release/cloudstack/KEYS

For sanity in tallying the vote, can PMC members please be sure to indicate
"(binding)" with their vote?
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Vote will be open for till the end of the next week (10 July 2020),
otherwise, extend until we reach lazy consensus. Thanks.

Regards.

Re: [VOTE] Apache CloudStack 4.14.0.0 RC3

[Riepl, Gregor (SWISS TXT)]

Thank you, Andrija!

We will keep that in mind when we upgrade to 6.7.

From: Andrija Panic 
Sent: 20 May 2020 23:02
To: users 
Cc: dev 
Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC3

@gregor - the legacy should be fine with UEFI (what I had run on some of my
laptops); UEFI is not a problem, happens with 4.13 also, any VirtualBox OVA
file will cause the issue

###
To conclude the ISSUE, based on my few hour testing today:

- happens when you deliberately use VirtualBox OVA template with vSphere
(who and why would do that, is another topic..), in ACS 4.13.x and
4.14/master

...out of which...:

- does NOT happen with vCenter 6.0 and 6.5 (confirmed by Daan/Bobby),
proper OVF parsing takes place and an error message is generated in ACS logs
- NOT tested:   6.7 / 6.7 U1xxx / 6.7 U2xxx (i.e. not tested with any
variant < 6.7 U3)
- issues happen with vCenter 6.7 U3  / U3a / U3b / U3f - these were
explicitly tested by me and some vCenter services would crash (though still
appearing as running) - the problem is solved by restarting (most?)
services - namely "VMware afd Service" will trigger other services to
restart (dependency) and after a while vCenter is UP again (I could not
find which exact service (single one) might be the issue)
- Worth mentioning this was observed on vCenter on Windows Server, not the
VCSA appliance

-  seems FINE - NO ISSUES with vCenter 6.7 U3g (the latest 6.7 U3 variants
at the moment - build 16046470 from 28.04.2020) and the VM deployment fails
gracefully with a proper error message of not being able to create SPEC
file based on the (bad) OVF.


Since the issue is solved in the (current) latest vSphere 6.7 U3g variant,
I will make sure to have the proper warning message on both 4.13.1 and
4.14.0.0 Release notes documentation (4.13 is when we started supporting
vSphere 6.7 and the same issue present here)

I'll proceed tomorrow with releasing 4.14 based on the voting done so far.

Thanks

On Wed, 20 May 2020 at 22:09, Marcus  wrote:

> I would say, if it is proven that this happens with existing released
> CloudStack versions, with or without the UEFI feature, against a specific
> VMware release with a specific broken template, then it becomes an
> environment issue and shouldn't block the release.  In this case it would
> not matter if we tried to revert the feature, or if we did or did not
> release 4.14, the users who would hit this would be hitting this now in
> live environments, with the released versions of CloudStack.
>
> To be clear, I'm not 100% certain this is exactly what Bobby was saying,
> but if this is the case then I think it should not block us.
>
> On Wed, May 20, 2020 at 1:00 AM Riepl, Gregor (SWISS TXT) <
> gregor.ri...@swisstxt.ch> wrote:
>
> > Hi everyone
> >
> > Sorry for the late response, but I have a few concerns:
> >
> >
> >   *   As Bobby stated, this bug seems to only occur with VMware 6.7+, and
> > it sounds to me like they should take action on it. Does someone track
> this
> > with VMware?
> >   *   Do I understand correctly that the issue only occurs when the image
> > is set to UEFI mode, but the VM is configured as Legacy Boot in
> CloudStack?
> > How would this combination even work? I think CloudStack should either
> > reject such a mismatch or autocorrect it. Or at least display a warning
> to
> > the user.
> >   *   If the bug can break vCenter (if only temporarily), there should
> > definitely some sort of safeguard around it, even if it isn't a proper
> fix
> > or workaround.
> >
> > Regards,
> > Gregor
> > 
> > From: Andrija Panic 
> > Sent: 19 May 2020 21:11
> > To: users 
> > Cc: dev@cloudstack.apache.org 
> > Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC3
> >
> > Hi all,
> >
> > In my humble opinion, we should release 4.14 as it is (considering we
> have
> > enough votes), but we'll further investigate the actual/behind-the-scene
> > root-cause for the vSphere 6.7 harakiri (considering 6.0 and 6.5 are not
> > affected) - this is possibly a VMware bug and we'll certainly try to
> > address it.
> >
> > If I don't hear any more concerns or -1 votes until tomorrow morning CET
> > time, I will proceed with concluding the voting process and crafting the
> > release.
> >
> > Thanks,
> > Andrija
> >
> > On Tue, 19 May 2020 at 19:23, Pavan Kumar Aravapalli <
> > pavankuma...@accelerite.com> wrote:
> >
> > > Thank you Bobby and Daan for the update. However I have not encountered
> > > such issue while doing dev test with Vmware 5.5

Re: [VOTE] Apache CloudStack 4.14.0.0 RC3

[Riepl, Gregor (SWISS TXT)]

Hi everyone

Sorry for the late response, but I have a few concerns:


  *   As Bobby stated, this bug seems to only occur with VMware 6.7+, and it 
sounds to me like they should take action on it. Does someone track this with 
VMware?
  *   Do I understand correctly that the issue only occurs when the image is 
set to UEFI mode, but the VM is configured as Legacy Boot in CloudStack? How 
would this combination even work? I think CloudStack should either reject such 
a mismatch or autocorrect it. Or at least display a warning to the user.
  *   If the bug can break vCenter (if only temporarily), there should 
definitely some sort of safeguard around it, even if it isn't a proper fix or 
workaround.

Regards,
Gregor

From: Andrija Panic 
Sent: 19 May 2020 21:11
To: users 
Cc: dev@cloudstack.apache.org 
Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC3

Hi all,

In my humble opinion, we should release 4.14 as it is (considering we have
enough votes), but we'll further investigate the actual/behind-the-scene
root-cause for the vSphere 6.7 harakiri (considering 6.0 and 6.5 are not
affected) - this is possibly a VMware bug and we'll certainly try to
address it.

If I don't hear any more concerns or -1 votes until tomorrow morning CET
time, I will proceed with concluding the voting process and crafting the
release.

Thanks,
Andrija

On Tue, 19 May 2020 at 19:23, Pavan Kumar Aravapalli <
pavankuma...@accelerite.com> wrote:

> Thank you Bobby and Daan for the update. However I have not encountered
> such issue while doing dev test with Vmware 5.5 & 6.5.
>
>
>
>
>
> Regards,
>
> Pavan Aravapalli.
>
>
> 
> From: Daan Hoogland 
> Sent: 19 May 2020 20:56
> To: users 
> Cc: dev@cloudstack.apache.org 
> Subject: Re: [VOTE] Apache CloudStack 4.14.0.0 RC3
>
> Thanks Bobby,
> All, I've been closely working with Bobby and seen the same things. Does
> anybody see any issues releasing 4.14 based on this code? I can confirm
> that it is not Pavernalli's UEFI PR and we should not create a new PR to
> revert it.
> thanks for all of your patience,
>
> (this is me giving a binding +1)
>
>
> On Tue, May 19, 2020 at 5:04 PM Boris Stoyanov <
> boris.stoya...@shapeblue.com>
> wrote:
>
> > Hi guys,
> >
> > I've done more testing around this and I can now confirm it has nothing
> to
> > do with cloudstack code.
> >
> > I've tested it with rc3, reverted UEFI PR and 4.13.1 (which does not
> > happen to have the feature at all). Also I've used a matrix of VMware
> > version of 6.0u2, 6.5u2 and 6.7u3.
> >
> > The bug is reproducible with all the cloudstack versions, and only vmware
> > 6.7u3, I was not able to reproduce this with 6.5/6.0. All of my results
> > during testing show it must be related to that specific version of
> VMware.
> >
> > Therefore I'm reversing my '-1' and giving a +1 vote on the RC. I think
> it
> > needs to be included in release notes to refrain from that version for
> now
> > until further investigation is done.
> >
> > Thanks,
> > Bobby.
> >
> > On 19.05.20, 10:08, "Boris Stoyanov" 
> > wrote:
> >
> > Indeed it is severe, but please note it's a corner case which was
> > unearthed almost by accident. It falls down to using a new feature of
> > selecting a boot protocol and the template must be corrupted. So with
> > already existing templates I would not expect to encounter it.
> >
> > As for recovery, we've managed to recover vCenter and Cloudstack
> after
> > reboots of the vCenter machine and the Cloudstack management service.
> > There's no exact points to recover for now, but restart seems to work.
> > By graceful failure I mean, cloudstack erroring out the deployment
> and
> > VM finished in ERROR state, meanwhile connection and operability with
> > vCenter cluster remains the same.
> >
> > We're currently exploring options to fix this, one could be to
> disable
> > the feature for VMWare and work to introduce more sustainable fix in next
> > release. Other is to look for more guarding code when installing a
> > template, since VMware doesn’t actually allow you install that particular
> > template but cloudstack does. We'll keep you posted.
> >
> > Thanks,
> > Bobby.
> >
> > On 18.05.20, 23:01, "Marcus"  wrote:
> >
> > The issue sounds severe enough that a release note probably won't
> > suffice -
> > unless there's a documented way to recover we'd never want to
> > leave a
> > system susceptible to being unrecoverable, even if it's rarely
> > triggered.
> >
> > What's involved in "failing gracefully"? Is this a small fix, or
> an
> > overhaul?  Perhaps the new feature could be disabled for VMware,
> or
> > disabled altogether until a fix is made in a patch release.
> >
> > Does it only affect new templates, or is there a risk that an
> > existing
> > template out in vSphere could suddenly cause problems?
> >
> > On Mon, May 18, 2020 at 12:49 

Re: [DISCUSS] Primate - publishing release and docs

[Riepl, Gregor (SWISS TXT)]

Hi Rohit,

Let me comment on just a few of the topics:

> Release cycle

I think we should definitely have a daily/nightly build, at least as long as a 
lot of changes are incoming.

I'm think along the lines of a parallel installation, so all versions can be 
tested and users still get a fallback in case of bugs:
- Stable legacy UI (included in cloudstack-management-server, as long as it's 
available)
- Stable new UI (alongside legacy UI, updated manually)
- Beta test from nightly (updated by an automated script)

> Versioning

Nightlies should not bear a release version, IMHO.
Something like cloudstack-primate-nightly-20200506.x86_64.rpm would be enough.
These should be built and published automatically, and no voting should take 
place.

When an actual stable/beta release is made, it should only contain the version 
and not the date, such as cloudstack-primate-0.4.0.x86_64.rpm
These could be voted on, depending on how often they're released.

> Package types and documentation

I'm in favour of supplying all three types of packages, and adding installation 
instructions for all three.
For the container variant, it may also make sense to provide an example 
Kubernetes manifest. In can contribute that if desired.

Regards,
Gregor

From: Rohit Yadav 
Sent: 08 May 2020 12:21
To: dev ; Sven Vogel 
Cc: us...@cloudstack.apache.org 
Subject: Re: [DISCUSS] Primate - publishing release and docs

Hi Daan,

Thanks for replying and participating. Some points:

  *   The document links within Primate is a different topic than the docs for 
Primate itself, the scope of current discussion is limited to documentation for 
Primate. The doc link within Primate would be done against the 1.0/GA 
milestone, it would require going through all the sections/APIs against the 
current CloudStack docs and put a link (or part of it).
  *   The documentation for Primate currently won't be huge, perhaps a single 
long page would do (to explain how to install).
  *   Primate would be a separately installable package and installing 
cloudstack-management won't automatically trigger installing it (at least in 
the tech preview, we can discuss how we handle longer term starting with GA/1.0 
later).
  *   We've setup automation for all kinds of packaging formats/channels (we 
already have that for rpm/deb and archive formats, except for dockerhub hosting 
which is in discussion with ASF infra). I think publishing artifacts should be 
quick and mostly automated.
  *   Github has a new feature called Github packages for each repo, where one 
can host things like npm, docker packages etc. We can explore this feature.
On a Github release wrt a git tag, we can upload an artifact (I've seen many 
projects doing this).
  *   On releasing without voting, my thought and preference is that as our 
users test Primate, and report bugs and until GA/1.0 we fix those issues, 
implement missing feature users get faster fixes via a "preview" or "testing" 
or "beta" release channel periodically (deb/rpms repos, archives, docker 
container builds).

Doing this would require that we agree on this strategy, without a single 
tag/version but a set of releases (with a timestamp, so packages would look 
like cloudstack-primate-$version-$date). So effectively we're saying - let's 
release the tech preview without doing an official release (which would mean a 
fix git tag/version). This is where the discussion of a single tech preview 
release vs rolling tech preview release would come in.

Looking forward to more feedback from our dev/user community and of course our 
VP @Sven Vogel who has been a major Primate-SIG 
collaborator. Thanks.

Regards,

Rohit Yadav

Software Architect, ShapeBlue

https://www.shapeblue.com


From: Daan Hoogland 
Sent: Thursday, May 7, 2020 12:34
To: dev 
Cc: us...@cloudstack.apache.org 
Subject: Re: [DISCUSS] Primate - publishing release and docs

Hey Rohit,
This is a lot to take in at once. We have discussed some of those off line
but let me give my initial answers to your discussion points inline.
Hopefully those more directly involved and with more at stake can give some
input as well.

On Wed, May 6, 2020 at 3:03 PM Rohit Yadav 
wrote:

> All,
>
> With this thread I want to start a discussion around:
>
>   *   How do we host/publish technical preview release
>   *   How do we host/publish technical preview documentation (release
> notes, setup/install instructions)
>
> To set the expectation:
>
>   *   This thread limits discussion wrt technical preview (beta).
>   *   Plan we've already agreed, just to recap: 

...

>   *   References:
>  *   Voting thread: https://markmail.org/message/tblrbrtew6cvrusr
>  *   Proposal:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Proposal%3A+CloudStack+Primate+UI
>  *   Discussion thread: https://markmail.org/message/z6fuvw4regig7aqb
>
...

>   *   Outstanding issues wrt 

Re: https://hub.docker.com/u/apache

[Riepl, Gregor (SWISS TXT)]

Hi Rohit,

I'm also still waiting on official container builds for 
https://github.com/apache/cloudstack-kubernetes-provider/ 

The readme already contains a reference to 
https://hub.docker.com/r/apache/cloudstack-kubernetes-provider/ , so could you 
extend the request to the infra team to include this repository as well?

Thank you very much.

Regards,
Gregor

From: Rohit Yadav 
Sent: 06 May 2020 13:35
To: in...@apache.org ; d...@community.apache.org 

Cc: dev@cloudstack.apache.org 
Subject: Re: https://hub.docker.com/u/apache

Hi Infra-team, dev community,

I've a Dockerfile in one of the apache/cloudstack-primate repo:
https://github.com/apache/cloudstack-primate/blob/master/Dockerfile

What is required for it to be built/hosted on the apache dockerhub
organisation?
For example, https://hub.docker.com/r/apache/cloudstack-primate is still
404.

What is the process of build integration that must be done? Thanks.

Regards

On Thu, Jan 16, 2020 at 3:20 PM Paul Angus  wrote:

> Hi Infra Folks,
>
>
>
> Please could you tell us at Apache CloudStack how we upload and maintain
> images on docker hub under the Apache banner?
>
> Are there any policies that we should be aware of?
>
>
>
>
>
> Many thanks
>
>
>
>
>
>
>
> Paul Angus
>
> Apache CloudStack PMC
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> @shapeblue
>
>
>
>

Re: [ Proposal ] Managing CloudStack Load Balancer configuration

[Riepl, Gregor (SWISS TXT)]

Hi Wei,

Thank you for this proposal!
We are also very much interested in this feature.

There's a few things we're not quite happy with, though - but we still need to 
discuss this internally a bit.
Liridon or myself will give some feedback soon.

Regards,
Gregor

From: Wei ZHOU 
Sent: 01 May 2020 08:01
To: dev@cloudstack.apache.org 
Subject: [ Proposal ] Managing CloudStack Load Balancer configuration

Our improvements to cloudstack load balancer (implemented by HAproxy in the
VRs) allow cloudstack users to manage certain restricted configuration
settings. With this feature, users can

* Change basic configuration of HAproxy (e.g. set the amount of allowed
connections),

* choose if load balancer is transparent,

* enable or disable the support for SSL offloading in isolated networks.

* choose if load balancer supports HTTP/2.

* more settings.



To make this possible to the user, we provide two forms on cloudstack GUI
(old GUI, will add changes on Primate) from which the settings can be
managed and applied in virtual routers.



FS can be found at
https://cwiki.apache.org/confluence/display/CLOUDSTACK/VR+haproxy+customization+in+CloudStack


Any suggestions ?



Kind regards,

*Wei Zhou*

Principal Cloud Engineer

Leaseweb Global B.V.

Re: CloudStack Kubernetes provider containers on DockerHub

[Riepl, Gregor (SWISS TXT)]

Hi everyone

Sorry for being off the hook for a while, I was busy with other stuff and 
couldn't work on CloudStack related matters.

It looks like that INFRA ticket was closed due to a lack of feedback.
Was there a followup?

Quote:
Usually, Infra sets up new repositories for you, based on what you have on 
Github. Then its a matter of deciding if you want to enable 'autobuilds' based 
on a tag or branch or pattern. Or, if not autobuilds, then Infra configures 
access by creating a 'Cloudstack' team on DockerHub (using your DockerHub IDs), 
that team can then have read/write access to upload images. Another option is 
that some projects build in our Jenkins and our jenkins user has permissions to 
upload to your repos in DockerHub.

Let me know what more info you need.

Note that there is a Cloudstack-ec2stack repos already in the ASF Dockerhub, 
and was configured for that repos in GH, using autobuild.
I'd vote for "autobuilds", at least for the cloudmonkey, primate and kubernetes 
repos.
If this was already configured by INFRA, is there anything else we need to do?

Regards,
Gregor

From: Paul Angus 
Sent: 29 January 2020 21:20
To: dev@cloudstack.apache.org 
Subject: RE: CloudStack Kubernetes provider containers on DockerHub

Just a note to say that I've created a ticket in Apache's Jira as we've not 
heard back from the email...

https://issues.apache.org/jira/browse/INFRA-19792



paul.an...@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue




-Original Message-
From: Paul Angus 
Sent: 19 January 2020 15:19
To: Sven Vogel ; dev 
Cc: Rohit Yadav ; Pierre-Luc Dion 
; Will Stevens ; 
gabrasc...@gmail.com; Wido den Hollander 
Subject: RE: CloudStack Kubernetes provider containers on DockerHub

I’ve already emailed infra on Thursday Sven, dev@ was in copy.

From: Sven Vogel 
Sent: 17 January 2020 16:13
To: dev 
Cc: Rohit Yadav ; Paul Angus 
; Pierre-Luc Dion ; Will Stevens 
; gabrasc...@gmail.com; Wido den Hollander 

Subject: Re: CloudStack Kubernetes provider containers on DockerHub

Hi Paul,

Yes this sounds interesting and would help to get an consistent state.

@Rohit Do you know how to upload it to "/apache/cloudstack-cloudmonkey“ Maybe 
its the same way like your repo was created.

If we know how to upload we can after that find a way like @Paul said to make 
it automatic and consistent.

I can ask infra to get an information how we get and new area and use existing?

Cheers

Sven




__

Sven Vogel
Teamlead Platform

EWERK DIGITAL GmbH
Brühl 24, D-04109 Leipzig
P +49 341 42649 - 99
F +49 341 42649 - 98
s.vo...@ewerk.com<mailto:s.vo...@ewerk.com>
www.ewerk.com<http://www.ewerk.com>

Geschäftsführer:
Dr. Erik Wende, Hendrik Schubert, Frank Richter
Registergericht: Leipzig HRB 9065

Support:
+49 341 42649 555

Zertifiziert nach:
ISO/IEC 27001:2013
DIN EN ISO 9001:2015
DIN ISO/IEC 2-1:2011

ISAE 3402 Typ II Assessed

EWERK-Blog<https://blog.ewerk.com/> | 
LinkedIn<https://www.linkedin.com/company/ewerk-group> | 
Xing<https://www.xing.com/company/ewerk> | 
Twitter<https://twitter.com/EWERK_Group> | 
Facebook<https://de-de.facebook.com/EWERK.IT/>

E-World 2020 in Essen.
Das EWERK ist dabei! Treffen Sie uns vom 11-13.02.20 in Halle 5 am Stand: 
5-724, mit spannenden Vorträgen rund um das Thema Urban Data.

Mit Handelsregistereintragung vom 09.07.2019 ist die EWERK RZ GmbH auf die 
EWERK IT GmbH verschmolzen und firmiert nun gemeinsam unter dem Namen: EWERK 
DIGITAL GmbH, für weitere Informationen klicken Sie 
hier<https://www.ewerk.com/ewerkdigital>.

Auskünfte und Angebote per Mail sind freibleibend und unverbindlich.

Disclaimer Privacy:
Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist 
vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der 
bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, 
Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte 
informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die 
E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen 
Dank.

The contents of this e-mail (including any attachments) are confidential and 
may be legally privileged. If you are not the intended recipient of this 
e-mail, any disclosure, copying, distribution or use of its contents is 
strictly prohibited, and you should please notify the sender immediately and 
then delete it (including any attachments) from your system. Thank you.
Am 16.01.2020 um 15:39 schrieb Riepl, Gregor (SWISS TXT) 
mailto:gregor.ri...@swisstxt.ch>>:

Hi Rohit,

That surprises me a bit, since the org and name is not specified inside the 
container spec.
You need to be logged into a Docker Hub account that has access to the 
organisation to push containers there.

Regards,
Gregor


From: Rohit Ya

Re: New joiner!

[Riepl, Gregor (SWISS TXT)]

Welcome, Vladimir!

From: Vladimir Petrov 
Sent: 16 January 2020 15:59
To: dev@cloudstack.apache.org 
Subject: New joiner!

Hello everyone,

I'm happy to announce that I just joined ShapeBlue as a QA engineer. I have 
about 17 years of experience in different QA areas and I’m going to do my very 
best to further improve the quality of CloudStack project.

Best wishes,
Vladimir Petrov

vladimir.pet...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue

Re: CloudStack Kubernetes provider containers on DockerHub

[Riepl, Gregor (SWISS TXT)]

r one org name vs the other.
>>>>
>>>> [1] https://hub.docker.com/u/bhaisaab/
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Rohit Yadav
>>>>
>>>> Software Architect, ShapeBlue
>>>>
>>>> https://www.shapeblue.com
>>>>
>>>> 
>>>> From: Pierre-Luc Dion 
>>>> Sent: Friday, January 10, 2020 19:24
>>>> To: dev@cloudstack.apache.org 
>>>> Cc: Pierre-Luc Dion ; Will Stevens
>>>> ; gabrasc...@gmail.com ;
>>>> Wido den Hollander 
>>>> Subject: Re: CloudStack Kubernetes provider containers on DockerHub
>>>>
>>>> hi, sorry for the late response,
>>>>
>>>> I still have admin access to or cloudstack org on docker hub, [1]  if
>>>> you want admin access to it, provide me your account name on docker
>>>> hub and I'll add you to the admin group.
>>>> Quickly looking at it, it's more than overdue, unfortunately all our
>>>> containers there are outdated :-(
>>>>
>>>> We also have apachecloudstack org name if it's preferable.
>>>>
>>>> These 2 orgs are not subprojects of Apache orgs in docker hub, and
>>>> probably it would be better to use the apache orgs  ? I don't have any
>>>> rights on apache docker hub org.
>>>>
>>>> Cheers,
>>>>
>>>>
>>>> [1] https://hub.docker.com/orgs/cloudstack
>>>>
>>>>> On Fri, Jan 10, 2020 at 3:07 AM Riepl, Gregor (SWISS TXT) <
>>>>> gregor.ri...@swisstxt.ch> wrote:
>>>>>
>>>>> Hello and happy new year to everybody!
>>>>>
>>>>> The k8s provider[1] is still lacking built containers so people can
>>>>> use it directly.
>>>>> Were you able to figure out how to access the mentioned Docker hub
>>>>> accounts in the meantime?
>>>>>
>>>>> We can also create a new one if necessary...
>>>>>
>>>>> Thanks,
>>>>> Greg
>>>>>
>>>>>
>>>>> [1] https://github.com/apache/cloudstack-kubernetes-provider
>>>>>
>>>>> 
>>>>> From: Rohit Yadav 
>>>>> Sent: 01 October 2019 12:18
>>>>> To: dev@cloudstack.apache.org ; Pierre-Luc
>>>>> Dion ; Will Stevens ;
>>>>> gabrasc...@gmail.com ; Wido den Hollander <
>>>>> w...@widodh.nl>
>>>>> Subject: Re: CloudStack Kubernetes provider containers on DockerHub
>>>>>
>>>>> Thanks Gregor.
>>>>>
>>>>> Let me tag a few people that may have access to one of the following
>>>>> docker hub organizations:
>>>>>
>>>>> apache
>>>>> apachecloudstack
>>>>> cloudstack
>>>>>
>>>>>
>>>>> Can you grant access to me (my docker username is 'bhaisaab') and
>> Gregor?
>>>>> Thanks.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Rohit Yadav
>>>>>
>>>>> Software Architect, ShapeBlue
>>>>>
>>>>> https://www.shapeblue.com
>>>>>
>>>>> 
>>>>> From: Riepl, Gregor (SWISS TXT) 
>>>>> Sent: Tuesday, October 1, 2019 14:30
>>>>> To: dev@cloudstack.apache.org 
>>>>> Subject: CloudStack Kubernetes provider containers on DockerHub
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> We still need to publish the new
>>>>> https://github.com/apache/cloudstack-kubernetes-provider on a public
>>>>> container registry.
>>>>> It looks like the ASF and/or CloudStack project already have accounts
>>>>> on
>>>>> DockerHub:
>>>>> https://hub.docker.com/u/apache
>>>>> https://hub.docker.com/u/apachecloudstack
>>>>>
>>>>> Who has access to these organisations and can publish the provider
>> there?
>>>>> The Github repository contains a suitable Dockerfile that we used
>>>>> with DockerHub before and shouldn't require any complicated repository
>> setup.
>>>>>
>>>>> If possible, please give access to @rhtyd so he can take care of
>> things.
>>>>>
>>>>> Thanks!
>>>>> Gregor
>>>>>
>>>>> rohit.ya...@shapeblue.com
>>>>> www.shapeblue.com<http://www.shapeblue.com>
>>>>> Amadeus House, Floral Street, London  WC2E 9DPUK @shapeblue
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> rohit.ya...@shapeblue.com
>>>> www.shapeblue.com<http://www.shapeblue.com>
>>>> Amadeus House, Floral Street, London  WC2E 9DPUK
>>>> @shapeblue
>>>>
>>>>
>>>>
>>>
>>
>
>
> --
>
> *Pierre-Luc Dion*Lead Cloud Architect | Architecte infonuagique principal
> t 888.796.8364 ext. 1403
>
> c 514.880.7765
>
> [image: LOGO-CloudDotCa-RGB (1) (1).png]

Re: CloudStack Kubernetes provider containers on DockerHub

[Riepl, Gregor (SWISS TXT)]

Hello and happy new year to everybody!

The k8s provider[1] is still lacking built containers so people can use it 
directly.
Were you able to figure out how to access the mentioned Docker hub accounts in 
the meantime?

We can also create a new one if necessary...

Thanks,
Greg


[1] https://github.com/apache/cloudstack-kubernetes-provider


From: Rohit Yadav 
Sent: 01 October 2019 12:18
To: dev@cloudstack.apache.org ; Pierre-Luc Dion 
; Will Stevens ; 
gabrasc...@gmail.com ; Wido den Hollander 
Subject: Re: CloudStack Kubernetes provider containers on DockerHub

Thanks Gregor.

Let me tag a few people that may have access to one of the following docker hub 
organizations:

apache
apachecloudstack
cloudstack


Can you grant access to me (my docker username is 'bhaisaab') and Gregor? 
Thanks.


Regards,

Rohit Yadav

Software Architect, ShapeBlue

https://www.shapeblue.com


From: Riepl, Gregor (SWISS TXT) 
Sent: Tuesday, October 1, 2019 14:30
To: dev@cloudstack.apache.org 
Subject: CloudStack Kubernetes provider containers on DockerHub

Hi everyone,

We still need to publish the new 
https://github.com/apache/cloudstack-kubernetes-provider on a public container 
registry.
It looks like the ASF and/or CloudStack project already have accounts on 
DockerHub:
https://hub.docker.com/u/apache
https://hub.docker.com/u/apachecloudstack

Who has access to these organisations and can publish the provider there?
The Github repository contains a suitable Dockerfile that we used with 
DockerHub before and shouldn't require any complicated repository setup.

If possible, please give access to @rhtyd so he can take care of things.

Thanks!
Gregor

rohit.ya...@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue

Re: Replace VR

[Riepl, Gregor (SWISS TXT)]

(Resend, accidentally sent it to Andrija instead of the list)

Hi,
You can experiment with Dedicating a host to the customer. I can't advise
(from top of my head) if also the customer's VR will be created there (but
you can do one-time live migrate if needed to that host) - all customer VMs
will be created on this host while there are free resources there.
Make sure you disable RDS on your VMware cluster, or your instances might get 
migrated away when the host is under load.

Also, about your firewall problem: We have a customer that does exactly what 
Andrija suggested, operating a VPN gateway behind the VR. But since you 
mentioned max-hops (not quite sure why that would be a problem) - there may be 
another solution:
You could build a custom VR image that runs the Barracuda software alongside 
the other VR components.

Re: unpublished parameter for resetpasswordforvirtualmachine

[Riepl, Gregor (SWISS TXT)]

Just for my understanding: What is the reason that you need user-defined 
passwords?

Ideally, you shouldn't even need a password at all. Log in using SSH keys 
instead, which *can* be provisioned by users.
Are you deploying Windows VMs, perhaps?

But I suppose you could expose the parameter, then gate the 
generateRandomPassword() call with a check if password is null.

Not sure if this is something that would be accepted in the CloudStack code 
base though...

From: li jerry 
Sent: 09 December 2019 08:12
To: dev@cloudstack.apache.org 
Subject: 回复: unpublished parameter for resetpasswordforvirtualmachine

No. we need to implement user-defined passwords instead of randomly generating 
them. So I went to look up the code.

I see an unopened parameter password on 
https://github.com/apache/cloudstack/blob/master/api/src/main/java/org/apache/cloudstack/api/command/user/vm/ResetVMPasswordCmd.java#L60,



I want to enable the password parameter and let the user pass the user-defined 
password through the API

-邮件原件-
发件人: Andrija Panic 
发送时间: 2019年12月9日 15:06
收件人: dev 
主题: Re: unpublished parameter for resetpasswordforvirtualmachine

Is that not what you can see in the GUI when the VM is stopped, assuming you 
created the VM from a password-enabled template?

On Mon, 9 Dec 2019, 02:52 li jerry,  wrote:

> Hi All
>
> I saw an unpublished parameter "password" in the API code
> resetpasswordforvirtualmachine Who knows why the password parameter is
> not enabled?
>
>
>
> -Jerry
>
>

Re: Introduction

[Riepl, Gregor (SWISS TXT)]

Welcome, Pearl!


From: Pearl d'Silva 
Sent: 06 November 2019 05:34
To: dev@cloudstack.apache.org 
Subject: Introduction

Hello Everyone,

I'm Pearl and have recently joined Shapeblue. Really excited about being part 
of Cloudstack community. Looking forward to learn and contribute to the 
community.


Thanks & Regards,
Pearl Dsilva
pearl.dsi...@shapeblue.com




pearl.dsi...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue

Re: [VOTE] Primate as modern UI for CloudStack

[Riepl, Gregor (SWISS TXT)]

Automated UI testing is usually done by running a web browser, generating 
artificial user input, then verifying the result either by DOM analysis or 
image recognition on screenshots.

Our devs have achieved good results with TestCafe: 
https://devexpress.github.io/testcafe/
It's very easy to write tests and run them in different browser engines. You 
can even run certain browser engines in headless mode for automated testing.

From: Rohit Yadav 
Sent: 09 October 2019 11:58
To: dev 
Subject: Re: [VOTE] Primate as modern UI for CloudStack

Hi Ivan,

Thanks for your advice.

I agree with the general idea of automating regression test for the UI, 
however, I don't have the expertise around writing tests using best practices, 
and I look forward to you or anyone else who can share some pointers, examples 
or maybe a plan. Given the UI is largely config and data driven, the number of 
components shouldn't be high except for any customization we do for some views.


Regards,

Rohit Yadav

Software Architect, ShapeBlue

https://www.shapeblue.com


From: Ivan Kudryavtsev 
Sent: Wednesday, October 9, 2019 09:37
To: dev 
Subject: Re: [VOTE] Primate as modern UI for CloudStack

Hello, community. I know it's just a voting process, but still... a piece
of wisdom from webdev company:

1. Manual testing is an extremely bad idea, you've meet a lot of
regression, much more than the backend typically has.

2. In our teams frontend/backend ratio have shifted from 1/1 to 2/1,
without UI automation QA engineers, so 3/1 is average ratio for real life
high quality web UIs.

3. Try to use/invent some sort of Django-like UI generator frameworks, no
code manually. I see the high risk of fail without that. May be need to add
some sort of metadata to backend first. The Cloudmonkey approach is a great
basic idea... Oracle also has certain frameworks for that. Ideally, to
define the forms and sitemap and generate everything else from the ORM.

4. Happy to see the initiative, as it could help to decrease the pace of
backend changes and increase the stability, as certain amount of
influencers turn into frontend JS developers.



ср, 9 окт. 2019 г., 7:45 Anurag Awasthi :

> +1
>
> Kind Regards,
> Anurag Awasthi
> 
> From: Marco Sinhoreli 
> Sent: Wednesday, October 9, 2019 4:10 AM
> To: dev@cloudstack.apache.org ;
> us...@cloudstack.apache.org ;
> priv...@cloudstack.apache.org 
> Subject: Re: [VOTE] Primate as modern UI for CloudStack
>
> +1
>
>
> Marco Sinhoreli
> Latam Technical Director
> marco.sinhor...@shapeblue.com
> mobile: +55 11 95656-3636
>
> Rua Gomes de Carvalho, 911 – Sala 316
> Vila Olímpia, São Paulo, SP, Brasil, 04547-003
> Phone: + 55 11 2818-3419
> http://www.shapeblue.com/ | twitter: @shapeblue
>
> Em 07/10/2019 08:31, "Rohit Yadav"  escreveu:
>
> All,
>
> The feedback and response has been positive on the proposal to use
> Primate as the modern UI for CloudStack [1] [2]. Thank you all.
>
> I'm starting this vote (to):
>
>   *   Accept Primate codebase [3] as a project under Apache CloudStack
> project
>   *   Create and host a new repository (cloudstack-primate) and follow
> Github based development workflow (issues, pull requests etc) as we do with
> CloudStack
>   *   Given this is a new project, to encourage cadence until its
> feature completeness the merge criteria is proposed as:
>  *   Manual testing against each PR and/or with screenshots from
> the author or testing contributor, integration with Travis is possible once
> we get JS/UI tests
>  *   At least 1 LGTM from any of the active contributors, we'll
> move this to 2 LGTMs when the codebase reaches feature parity wrt the
> existing/old CloudStack UI
>  *   Squash and merge PRs
>   *   Accept the proposed timeline [1][2] (subject to achievement of
> goals wrt Primate technical release and GA)
>  *   the first technical preview targetted with the winter 2019
> LTS release (~Q1 2020) and release to serve a deprecation notice wrt the
> older UI
>  *   define a release approach before winter LTS
>  *   stop taking feature FRs for old/existing UI after winter 2019
> LTS release, work on upgrade path/documentation from old UI to Primate
>  *   the first Primate GA targetted wrt summer LTS 2020 (~H2
> 2019), but still ship old UI with a final deprecation notice
>  *   old UI codebase removed from codebase in winter 2020 LTS
> release
>
> The vote will be up for the next two weeks to give enough time for PMC
> and the community to gather consensus and still have room for questions,
> feedback and discussions. The results to be shared on/after 21th October
> 2019.
>
> For sanity in tallying the vote, can PMC members please be sure to
> indicate "(binding)" with their vote?
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> 

Re: CloudStack Kubernetes provider containers on DockerHub

[Riepl, Gregor (SWISS TXT)]

I don't strictly need access, but if you think it makes sense, my DockerHub id 
is: gregorriepl

From: Rohit Yadav 
Sent: 01 October 2019 12:18
To: dev@cloudstack.apache.org ; Pierre-Luc Dion 
; Will Stevens ; 
gabrasc...@gmail.com ; Wido den Hollander 
Subject: Re: CloudStack Kubernetes provider containers on DockerHub

Thanks Gregor.

Let me tag a few people that may have access to one of the following docker hub 
organizations:

apache
apachecloudstack
cloudstack


Can you grant access to me (my docker username is 'bhaisaab') and Gregor? 
Thanks.


Regards,

Rohit Yadav

Software Architect, ShapeBlue

https://www.shapeblue.com


From: Riepl, Gregor (SWISS TXT) 
Sent: Tuesday, October 1, 2019 14:30
To: dev@cloudstack.apache.org 
Subject: CloudStack Kubernetes provider containers on DockerHub

Hi everyone,

We still need to publish the new 
https://github.com/apache/cloudstack-kubernetes-provider on a public container 
registry.
It looks like the ASF and/or CloudStack project already have accounts on 
DockerHub:
https://hub.docker.com/u/apache
https://hub.docker.com/u/apachecloudstack

Who has access to these organisations and can publish the provider there?
The Github repository contains a suitable Dockerfile that we used with 
DockerHub before and shouldn't require any complicated repository setup.

If possible, please give access to @rhtyd so he can take care of things.

Thanks!
Gregor

rohit.ya...@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue

cloud-init bug fix for VMs with mixed network interfaces

[Riepl, Gregor (SWISS TXT)]

Hi CloudStack community,

We're still stuck with cloud-init's problematic way of searching for a metadata 
server: https://github.com/apache/cloudstack/issues/3557

Would you consider taking a look at our proposed fix and comment on it, so it 
can be pushed ahead?
https://code.launchpad.net/~joschi36/cloud-init/+git/cloud-init/+merge/371807

The proposed fix uses the well-known data-server host name, that is 
automatically provided by CloudStack VRs and should always point to a valid 
metadata server.
This is similar to what other cloud platforms do and should be the documented 
way to go.
The rest of the search code wasn't touched, so it still serves as a fallback 
when data-server isn't available.

If you agree, I will prepare a cloudstack-documentation update that documents 
this as the recommended way to fetch metadata.

Thanks,
Gregor

CloudStack Kubernetes provider containers on DockerHub

[Riepl, Gregor (SWISS TXT)]

Hi everyone,

We still need to publish the new 
https://github.com/apache/cloudstack-kubernetes-provider on a public container 
registry.
It looks like the ASF and/or CloudStack project already have accounts on 
DockerHub:
https://hub.docker.com/u/apache
https://hub.docker.com/u/apachecloudstack

Who has access to these organisations and can publish the provider there?
The Github repository contains a suitable Dockerfile that we used with 
DockerHub before and shouldn't require any complicated repository setup.

If possible, please give access to @rhtyd so he can take care of things.

Thanks!
Gregor

Re: [DISCUSS] CloudStack Kubernetes Service plugin

[Riepl, Gregor (SWISS TXT)]

Isn't multi-master kind of a baseline requirement?
etcd should be operated on at least three nodes to have a quorum, so a there 
should be at least three masters...

From: Abhishek Kumar 
Sent: 26 September 2019 08:11
To: dev@cloudstack.apache.org 
Subject: Re: [DISCUSS] CloudStack Kubernetes Service plugin

I would be really interested in exploring multi-master k8s cluster but it is 
not in proposal at the moment. We can surely look into this.
FS mentions, for deployment, plugin will use kubeadm and kubectl tools.


From: Pierre-Luc Dion 
Sent: 25 September 2019 22:41
To: dev@cloudstack.apache.org 
Subject: Re: [DISCUSS] CloudStack Kubernetes Service plugin

Make sense for the proposed implementation, would it handle redundant
master?
How would the k8s cluster would be created, using Rancher tools, kubectl or
other?

so far, the small part I understand from MaaS, it could be very interesting
to integrate it to cloudstack in a way where it could be use to  scale
Hypervisor host, specially KVM nodes.


On Wed, Sep 25, 2019 at 10:47 AM Paul Angus 
wrote:

> The proposed implementation will create a master and n worker nodes.
> It will also support (graceful) cluster resizing, the next step would be
> to enable the CloudStack plugin for Kubernetes to allow Kubernetes to drive
> that scaling, so that you can scale with demand rather than needing to
> oversize you environment to begin with.
>
> I've been keeping MaaS in mind as way of doing baremetal Kubernetes along
> side VM based Kubernetes clusters.  Interestingly a few people that I have
> spoken to have said that they prefer the use of VMs, because whole servers
> as the unit of scale is often very wasteful, unless you 'share' them which
> has all sorts of security implications...
>
>
>
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> Amadeus House, Floral Street, London  WC2E 9DPUK
> @shapeblue
>
>
>
>
> -Original Message-
> From: Pierre-Luc Dion 
> Sent: 25 September 2019 15:31
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] CloudStack Kubernetes Service plugin
>
> Hi Paul,
>
> Yeah, was bad timing for the CCCNA this year unfortunately :-(,  I'm not
> sure I'm curious to see how cloudstack could become more "other Apache
> products friendly" but I don't have particular use case compared to k8s
> integration. Has you are suggesting, would probably make sense to use Helm
> to deploy any other application stack.
>
> btw, we are still working on the Canonical MaaS integration, a bit more
> challenging than anticipated...
>
>
> To get back to a *Kubernetes Service plugin*:
> To me, as a user of cloudstack at the moment, If I deploy a k8s cluster, I
> need to deploy monstrous instances for worker nodes.
> which doesn't make sense if I'm a cloud consumer. So I think we need to
> solve something challenging: a k8s service that would scale has needed
> while keeping in mind redundancy of worker nodes without sacrifice on
> security. Is the worker node is part of the ongoing work or it's more about
> offering a k8s master and api infrastructure to a user ?
>
> An easy path would be some kind of shared worker nodes pool but that
> involve possible security risk unless you would trust users that consume
> those workers.
>
>
> On Wed, Sep 25, 2019 at 10:15 AM Paul Angus 
> wrote:
>
> > Hi Pierre-Luc,
> >
> > (we missed you at CCCNA!) How are you seeing CloudStack being more
> > deployment friendly?  What you do think that we could do on top of
> > creating the Kubenetes Cluster to begin with?
> > [thinking out loud - we could pre-package Tiller to make it easier to
> > deploy openWhisk via Helm charts ? ]
> >
> > Kind regards
> >
> >
> > Paul.
> >
> >
> >
> > paul.an...@shapeblue.com
> > www.shapeblue.com
> > Amadeus House, Floral Street, London  WC2E 9DPUK @shapeblue
> >
> >
> >
> >
> > -Original Message-
> > From: Pierre-Luc Dion 
> > Sent: 25 September 2019 13:37
> > To: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] CloudStack Kubernetes Service plugin
> >
> > Hi Rohit, Nux,
> >
> > Thanks Rohit for cloudstack-provider, that's exactly it ! :-D Nux, I
> agree
> > with your opinion, but there is a lot of interest for k8s and seams like
> a
> > lot of organisations are moving to container based infrastructures to
> > standardized their deployment.
> >
> > if we want to extent the discussion to function as a service, would you
> > guys see a possibility for us to be more aligned or more deployment
> > friendly for Openwhisk ?
> >
> > Cheers,
> >
> >
> > On Wed, Sep 25, 2019 at 6:54 AM Will Stevens 
> > wrote:
> >
> > > We see huge demand for K8s in our customer base. Just a note...
> > >
> > > On Wed, Sep 25, 2019, 4:03 AM Nux!  wrote:
> > >
> > > > Do you guys see high demand for K8s?
> > > >  From where I'm looking it seems to be going the way of Openstack,
> > > > loads of hype, overcomplicated, near-impossible to 

Re: [DISCUSS] CloudStack Kubernetes Service plugin

[Riepl, Gregor (SWISS TXT)]

Hi all,

kubernetes-cloudstack-provider provides the missing link between Kubernetes and 
CloudStack resources (firewall, loadbalancer, node information, ...).

There is one other component that you still need, though: Suitable images.
I'm not sure if this is something that CloudStack should provide, but without 
them, automated resizing will be difficult.

Paul, do you already have an idea on how to do handle this?
Require users to build their own images?
Create a ready-to-use template like it's done for the system VMs?
How could PaaS deployments (for example, OpenShift) be handled?
What about node security?

We've been deploying Kubernetes very successfully via custom Ansible scripts so 
far. But having CloudStack do much of the heavy lifting might allow for some 
very interesting use cases.
If cluster scaling can be abstracted at the API level, it could also be added 
to the cloud provider - allowing infrastructure scaling from within k8s itself, 
or even based on load!
In such a case, initial setup should focus first and foremost on the control 
plane (i.e. bootstrapping master nodes), then allowing worker scaling via k8s 
resources.

Regards,
Gregor

From: Paul Angus 
Sent: 25 September 2019 16:47
To: dev@cloudstack.apache.org 
Subject: RE: [DISCUSS] CloudStack Kubernetes Service plugin

The proposed implementation will create a master and n worker nodes.
It will also support (graceful) cluster resizing, the next step would be to 
enable the CloudStack plugin for Kubernetes to allow Kubernetes to drive that 
scaling, so that you can scale with demand rather than needing to oversize you 
environment to begin with.

I've been keeping MaaS in mind as way of doing baremetal Kubernetes along side 
VM based Kubernetes clusters.  Interestingly a few people that I have spoken to 
have said that they prefer the use of VMs, because whole servers as the unit of 
scale is often very wasteful, unless you 'share' them which has all sorts of 
security implications...




paul.an...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue




-Original Message-
From: Pierre-Luc Dion 
Sent: 25 September 2019 15:31
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] CloudStack Kubernetes Service plugin

Hi Paul,

Yeah, was bad timing for the CCCNA this year unfortunately :-(,  I'm not sure 
I'm curious to see how cloudstack could become more "other Apache products 
friendly" but I don't have particular use case compared to k8s integration. Has 
you are suggesting, would probably make sense to use Helm to deploy any other 
application stack.

btw, we are still working on the Canonical MaaS integration, a bit more 
challenging than anticipated...


To get back to a *Kubernetes Service plugin*:
To me, as a user of cloudstack at the moment, If I deploy a k8s cluster, I need 
to deploy monstrous instances for worker nodes.
which doesn't make sense if I'm a cloud consumer. So I think we need to solve 
something challenging: a k8s service that would scale has needed while keeping 
in mind redundancy of worker nodes without sacrifice on security. Is the worker 
node is part of the ongoing work or it's more about offering a k8s master and 
api infrastructure to a user ?

An easy path would be some kind of shared worker nodes pool but that involve 
possible security risk unless you would trust users that consume those workers.


On Wed, Sep 25, 2019 at 10:15 AM Paul Angus 
wrote:

> Hi Pierre-Luc,
>
> (we missed you at CCCNA!) How are you seeing CloudStack being more
> deployment friendly?  What you do think that we could do on top of
> creating the Kubenetes Cluster to begin with?
> [thinking out loud - we could pre-package Tiller to make it easier to
> deploy openWhisk via Helm charts ? ]
>
> Kind regards
>
>
> Paul.
>
>
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> Amadeus House, Floral Street, London  WC2E 9DPUK @shapeblue
>
>
>
>
> -Original Message-
> From: Pierre-Luc Dion 
> Sent: 25 September 2019 13:37
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] CloudStack Kubernetes Service plugin
>
> Hi Rohit, Nux,
>
> Thanks Rohit for cloudstack-provider, that's exactly it ! :-D Nux, I agree
> with your opinion, but there is a lot of interest for k8s and seams like a
> lot of organisations are moving to container based infrastructures to
> standardized their deployment.
>
> if we want to extent the discussion to function as a service, would you
> guys see a possibility for us to be more aligned or more deployment
> friendly for Openwhisk ?
>
> Cheers,
>
>
> On Wed, Sep 25, 2019 at 6:54 AM Will Stevens 
> wrote:
>
> > We see huge demand for K8s in our customer base. Just a note...
> >
> > On Wed, Sep 25, 2019, 4:03 AM Nux!  wrote:
> >
> > > Do you guys see high demand for K8s?
> > >  From where I'm looking it seems to be going the way of Openstack,
> > > loads of hype, 

Re: [DISCUSS] Primate - new UI for CloudStack?

[Riepl, Gregor (SWISS TXT)]

Hi Rohit

+1

Kudos to the plans and the work already done on the new UI!
I'm definitely in favour of something more modern and easier to maintain.
Also, the complete separation of the UI from the mgmt server is definitely the 
way to go.

We've tested the current state of the frontend and while a lot of functionality 
is still missing, it's looking very promising.
We're also planning to give some of our customers a sneak preview soonish to 
collect some feedback, which we'll gladly pass on.

Regards,
Gregor

From: Rohit Yadav 
Sent: 23 September 2019 04:20
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: Re: [DISCUSS] Primate - new UI for CloudStack?

Hi Sid,

I've put the proposal on the wiki for reference:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Proposal%3A+CloudStack+Primate+UI


Regards,

Rohit Yadav

Software Architect, ShapeBlue

https://www.shapeblue.com


From: Siddhartha Kattoju 
Sent: Friday, September 20, 2019 20:47
To: dev@cloudstack.apache.org 
Cc: us...@cloudstack.apache.org 
Subject: Re: [DISCUSS] Primate - new UI for CloudStack?

+1 from me as well.

Just a side note: I feel like there is a high risk of tldr here. May be its
just me. It may be would be good to put most of the details in a wiki page
and just post a summarized version on the list ?

*Sid Kattoju*

Cloud Software Architect | Professional Services

c 514.466.0951


* *




On Fri, Sep 20, 2019 at 8:10 AM Rohit Yadav 
wrote:

> All,
>
>
>
> == Summary ==
>
>
> I have been working on a new, modern role-based UI for Cloudstack (project
> Primate: https://github.com/shapeblue/primate) I demoed this for the
> first time at CCCNA19 last week and it was very well received. It was
> discussed, at length, as an item in the hackathon and the general consensus
> there was that this could become Cloudstacks new UI. We discussed a plan to
> achieve that and now I’m bringing that plan to the list for discussion.
>
>
>
> == Background ==
>
>
> The current CloudStack UI has grown technical debt over time and it has
> become harder to extend, develop, maintain in the long run, it is also
> difficult for new contributors to learn and get started. Since late 2018, I
> started working on a side-project with the aim to create a modern
> progressive and role-based declaratively-programmed UI for CloudStack,
> called Primate. Before creating Primate, I set out to create a list of core
> requirements of what would give us an extensible, modern UI that was easy
> to develop now and in the future. These are the requirements I came up with:
>
>   *   designed from ground up to be  a complete replacement for our
> combined user/admin UI
>   *   to respect all entities in cloudstack and not make assumptions on
> use-cases of cloudstack
>   *   data-driven and auto-generation of UI widgets and to be easy to
> learn, develop, extend, customise and maintain.
>   *   declarative programming
>   *   support for API discovery and parameter completion like CloudMonkey
>   *   support for custom roles
>
>
>
> I looked at existing Cloudstack UI projects but none of them fully
> satisfied all these requirements and started Primate.
>
>
>
> == Project Primate ==
>
>
> For the implementation, I compared a couple of opensource JS and UI
> frameworks and decided to use VueJS (https://vuejs.org)
> which is a JavaScript framework and AntD (https://ant.design<
> https://ant.design/>) which is a UI design language with a well-defined
> spec, styling guide, and an implementation-specific to VueJS. VueJS was
> selected because among a few other JS frameworks I surveyed it was the
> easiest (for me) to learn and get started. I also surveyed a few UI
> frameworks and selected AntD because it came with a well-defined spec,
> styling guide and VueJS specific implementation which gives several
> re-usable components out of the box.
>
>
>
> During the development of Primate, I used my previous experience from
> CloudMonkey and another PoC angular-based UI ProjectX, and it currently
> supports:
>
>   *   role-based UI based on API autodiscovery
>   *   auto-generated action/API forms with parameter completion
>   *   declarative component-driven views
>   *   modern programming methodologies (hot reloading, npm based
> build/run/compile etc.)
>   *   decoupled from core Cloudstack code
>   *   dynamic translation (most/many of old translation files ported)
>   *   includes dashboards, async job/API polling, all list views/tables
> per the old UI
>   *   browser history and url/route driven navigation
>   *   support for mobiles/tables/desktop screens
>   *   configuration driven UI customisation (of navigation, icons, APIs
> etc)
>
>
>
> To get to this point, I’ve had some valuable help from Anurag and Sven et
> al at EWerk.
> The development strategy to support all APIs out of the box in a
> data-driven way gives a functioning UI and 

Re: VR/LB inject others options in haproxy.cfg

[Riepl, Gregor (SWISS TXT)]

Nice!

I wonder if LB configuration could be put into a dedicated UI. Editing network 
and rule tags seems a bit clunky.
The disadvantage would be that the UI has to be adapted whenever support for 
new options is added.
Maybe an autogenerated UI from the list of supported tags is possible?

From: Wei ZHOU 
Sent: 17 September 2019 19:21
To: dev@cloudstack.apache.org 
Subject: Re: VR/LB inject others options in haproxy.cfg

fyi

That is what we have implemented.

https://kb.leaseweb.com/customer-portal/cloudstack/network-cloudstack#Network:CloudStack-ConfiguringaloadbalancerforanIPAddressofanIsolatedNetwork

We will create pull request later this year.

-Wei

On Tuesday, 17 September 2019, Rauklei P. S. Guimarães 
wrote:

> Maibe in Panel/Global Config?
>
> On Tue, Sep 17, 2019 at 11:17 AM Riepl, Gregor (SWISS TXT) <
> gregor.ri...@swisstxt.ch> wrote:
>
> >
> > > haproxy.cfg is generated by this file
> > >
> > https://github.com/apache/cloudstack/blob/master/core/
> src/main/java/com/cloud/network/HAProxyConfigurator.java
> >
> > Allowing changes to the HAProxy config via the CloudStack API could be
> > a very useful addition, as the defaults are sometimes a bit limiting.
> >
> > For example, the timeout values don't make much sense for certain use
> > cases.
> >
> > Any thoughts?
> >
>
>
> --
> '''
>   Rauklei P.S. Guimarães
>   
>'''
>

Re: VR/LB inject others options in haproxy.cfg

[Riepl, Gregor (SWISS TXT)]

> haproxy.cfg is generated by this file
> https://github.com/apache/cloudstack/blob/master/core/src/main/java/com/cloud/network/HAProxyConfigurator.java

Allowing changes to the HAProxy config via the CloudStack API could be
a very useful addition, as the defaults are sometimes a bit limiting.

For example, the timeout values don't make much sense for certain use
cases.

Any thoughts?

Re: Dynamic scaling support for KVM

[Riepl, Gregor (SWISS TXT)]

> Just to add some context, this was awhile back that I tried it,
> years. The idea was that we could just set max memory to some crazy
> high number and then “unlock” just the amount in the offering, and
> adjust on the fly. As mentioned I found it was trivial for VM users
> to unlock the full amount and get a “free” upgrade, so it was
> useless. There was also a non trivial amount of RAM overhead just
> lost to support balloon, if I recall.

IMHO, supporting full dynamic scaling included shrinkage has a limited
number of use cases. If you want a workload to be dynamically scalable,
it would usually be much better to look into horizontal scaling, i.e.
deploying more instances as load increases. If your workload is too
small to make horizontal scaling effective, you should probably ask
yourself the question if you need scaling at all.

Limiting scaling to memory increase only might have some merit and
should be much easier to implement by means of memory hotplug
emulation. Though, is it really worth the complexity when an offline
upgrade would normally only cause a very short downtime (or none at all
in a HA setup)?

Re: kvm: /var/log/cloudstack/agent/agent.log is a binary file

[Riepl, Gregor (SWISS TXT)]

> > Wido, makes sense that log4j and logrotate would conflict. Log4j
> > has its
> > own rotate functionality.
> 

Note that a few CS log files are not generated by log4j.
You still need external logrotatation if you don't want them to fill up
your disk.

I had this issue with access.log, for example.

I haven't encountered your "binary" log file issue, however.

Re: [VOTE][RESULT] Apache CloudStack 4.13.0.0

[Riepl, Gregor (SWISS TXT)]

Thanks, everybody!

From: Rohit Yadav 
Sent: 02 September 2019 09:41
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Subject: Re: [VOTE][RESULT] Apache CloudStack 4.13.0.0

Great, congrats all.


Regards,

Rohit Yadav

Software Architect, ShapeBlue

https://www.shapeblue.com


From: Paul Angus 
Sent: Sunday, September 1, 2019 18:15
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 
Subject: [VOTE][RESULT] Apache CloudStack 4.13.0.0

Hi all,

After 3 business days, the vote for CloudStack 4.13.0.0 *passes* with 3 PMC
+ 1 non-PMC votes.

+1 (PMC / binding)
* Gabriel Beims Bräscher
* Boris Stoyanov
* Rohit Yadav

+1 (nonbinding)
* Liridon Ismaili

0
none

-1
none

Thanks to everyone participating.

I will now prepare the release announcement to go out after 24 hours to give 
the mirrors time to catch up.


paul.an...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue




rohit.ya...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue

Re: Introduction: Radu Todirica

[Riepl, Gregor (SWISS TXT)]

Welcome, Radu!

On Wed, 2019-08-21 at 15:06 +, Simon Weller wrote:
> All,
> 
> I'd like to introduce Radu Todirica to the community.  Radu is a
> new(er) member of the ENA team and has been making lots of
> contributions to CloudStack and you can expect to see some PRs from
> him pretty soon.
> 
> Please join me in making him welcome!
> 
> -Si
> 
> 

Re: [ANNOUNCE] Nathan Johnson has joined the PMC

[Riepl, Gregor (SWISS TXT)]

Congratulations, Nathan!

From: Paul Angus 
Sent: 19 July 2019 16:58
To: dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org ; 
priv...@cloudstack.apache.org 
Subject: [ANNOUNCE] Nathan Johnson has joined the PMC

Fellow CloudStackers,



It gives me great pleasure to say that Nathan has been invited to join the
PMC and has gracefully accepted.


Please join me in congratulating Nathan!




Kind regards,



Paul Angus

CloudStack PMC

Re: CloudStack Kubernetes Provider

[Riepl, Gregor (SWISS TXT)]

Hi Rohit,

Three questions:

1. Would you be ok with one large PR from our Github repo? Since Git does not 
permit merging unrelated branches, I'd need to figure out a way to preserve 
history first. The alternative would be several PRs containing individual 
aspects of the code.

2. How should authorship information be handled? Do I need to collect a list of 
contributors for those parts that were taken from the old cloud provider? On 
the SWISS TXT side, only @joschi36 and myself contributed code. Should there be 
an AUTHORS file?

3. How should contributions be handled? Exclusively via PRs or would you give 
commit rights to @joschi36 and me?

I'm unfamiliar with the development process in Apache projects, so links to 
relevant documentation would also be helpful.

Regards,
Gregor


From: Rohit Yadav 

Sent: 21 July 2019 17:04

To: priv...@cloudstack.apache.org ; 
dev@cloudstack.apache.org ; 
us...@cloudstack.apache.org 

Subject: Re: CloudStack Kubernetes Provider

 


Hi Gregor,





The repository is up now to receive contributions:



https://github.com/apache/cloudstack-kubernetes-provider





PMCs - ping, any thoughts on contributions? Can Gregor or any interested 
parties simply send a pull request based on the old provider codebase that is 
under Apache License v2.0 
(https://github.com/kubernetes/kubernetes/tree/release-1.15/pkg/cloudprovider/providers/cloudstack)?





Regards,



Rohit Yadav



Software Architect, ShapeBlue



https://www.shapeblue.com





From: Riepl, Gregor (SWISS TXT) 

Sent: Thursday, July 11, 2019 3:15:12 PM

To: priv...@cloudstack.apache.org ; 
dev@cloudstack.apache.org 

Cc: us...@cloudstack.apache.org 

Subject: Re: CloudStack Kubernetes Provider



Hi Rohit,



> One of the community contributors from SwissTxt Gregor Riepl

> (@onitake) have also offered to contribute their provider (which is

> already under the Apache v2.0 license) which they have based on the

> original provider:

> 
https://github.com/kubernetes/enhancements/issues/672#issuecomment-510353660



This CCM is actually based on the old code in

>

https://github.com/kubernetes/kubernetes/tree/release-1.15/pkg/cloudprovider/providers/cloudstack



We removed some stuff that is not relevant for a standalone controller

and added a few patches that were not accepted upstream due to the

deprecation.



There's still some open issues, if you look at the tracker at

https://github.com/swisstxt/cloudstack-cloud-controller-manager/issues



Issue #9 in particular needs fixing, or the controller will be a bit

difficult to deploy in a generic k8s environment.



> PMCs - If Gregor wants to donate their changes based on the

> old/original provider to CloudStack, is there a formal donation

> process that he/swisstxt needs to be used or a simple pull request

> can be sent?



We're open to any suggestions.

You can also simply fork the Github repo and start from there. ☺



Regards,

Gregor



rohit.ya...@shapeblue.com 

www.shapeblue.com

Amadeus House, Floral Street, London  WC2E 9DPUK

@shapeblue

  

 

Re: Using S3/Minio as the only secondary storage

[Riepl, Gregor (SWISS TXT)]

Hi Jean-François

> I have always used NFS to install the SSVM templates and the install
> script (cloud-install-sys-tmplt) only takes a mount point.  How, if
> possible, would I proceed with S3 only storage ?

CloudStack doesn't support object storage as a backend for the
secondary storage. You'd have to use something like s3fs-fuse[1],
ObjectiveFS[2] or RioFS[3].

But I have no idea how well that will work... Take into consideration
that secondary storage will be mounted on at least the Management
Server and the SSVMs.

I think NFS is your only option for now.
What you can do, however, is mounting the S3 object store on one
machine and exporting it as an NFS share to the other hosts.

Regards,
Gregor

[1] https://github.com/s3fs-fuse/s3fs-fuse
[2] https://objectivefs.com/
[3] https://github.com/skoobe/riofs

Re: [ANNOUNCE] Bobby (Boris Stoyanov) has joined the PMC

[Riepl, Gregor (SWISS TXT)]

Congratulations, Boris!

Re: [ANNOUNCE] Gabriel Beims Bräscher, Andrija Panic, Sven Vogel has joined the PMC

[Riepl, Gregor (SWISS TXT)]

Congratulations, everyone!

Re: [ANNOUNCE] Apache CloudStack LTS Maintenance Release 4.11.3.0

[Riepl, Gregor (SWISS TXT)]

Good work everybody!

This release contains a few crucial fixes for us, so we're happy it's
there!

On Sat, 2019-07-13 at 16:52 +0100, Paul Angus wrote:
> Announcing Apache CloudStack LTS Maintenance Release 4.11.30
> 
> 
> 
> The Apache CloudStack project is pleased to announce the release of
> CloudStack 4.11.3.0 as part of its LTS 4.11.x releases. The
> CloudStack
> 4.11.3.0 release contains c. 50 fixes on top of the CloudStack
> 4.11.2.0
> release. CloudStack LTS branches are supported for 20 months and will
> receive updates for the first 14 months. For the final six months,
> only
> security updates are provided.
> 
> 
> 
> Apache CloudStack is an integrated Infrastructure-as-a-Service (IaaS)
> software platform allowing users to build feature-rich public and
> private
> cloud environments. CloudStack includes an intuitive user interface
> and
> rich API for managing the compute, networking, software, and storage
> resources. The project became an Apache top level project in March,
> 2013.
> More information about Apache CloudStack can be found at:
> 
> http://cloudstack.apache.org/
> 
> 
> 
> # Documentation
> 
> 
> 
> The 4.11.3.0 release notes include a full list of issues fixed:
> 
> http://docs.cloudstack.apache.org/en/4.11.3.0/releasenotes/fixed_issues.html
> 
> 
> 
> 
> The CloudStack documentation includes upgrade instructions from
> previous
> versions of Apache CloudStack, and can be found at:
> 
> http://docs.cloudstack.apache.org/en/4.11.3.0/upgrading/index.html
> 
> 
> The official installation, administration and API documentation for
> each of
> the releases are available on our documentation page:
> 
> http://docs.cloudstack.apache.org/
> 
> 
> 
> # Downloads
> 
> 
> 
> The official source code for the 4.11.3.0 release can be downloaded
> from
> our downloads page:
> 
> http://cloudstack.apache.org/downloads.html
> 
> 
> 
> In addition to the official source code release, individual
> contributors
> have also made convenience binaries available on the Apache
> CloudStack
> download page, and can be found at:
> 
> 
> http://download.cloudstack.org/ubuntu/dists/
> 
> http://download.cloudstack.org/centos/6/
> 
> http://download.cloudstack.org/centos/7/
> 
> http://www.shapeblue.com/packages/
> 
> 
> 
> Kind regards,
> 
> 
> 
> Paul Angus

Re: CloudStack Kubernetes Provider

[Riepl, Gregor (SWISS TXT)]

Hi Rohit,

> One of the community contributors from SwissTxt Gregor Riepl
> (@onitake) have also offered to contribute their provider (which is
> already under the Apache v2.0 license) which they have based on the
> original provider: 
> https://github.com/kubernetes/enhancements/issues/672#issuecomment-510353660

This CCM is actually based on the old code in 
> 
https://github.com/kubernetes/kubernetes/tree/release-1.15/pkg/cloudprovider/providers/cloudstack

We removed some stuff that is not relevant for a standalone controller
and added a few patches that were not accepted upstream due to the
deprecation.

There's still some open issues, if you look at the tracker at
https://github.com/swisstxt/cloudstack-cloud-controller-manager/issues

Issue #9 in particular needs fixing, or the controller will be a bit
difficult to deploy in a generic k8s environment.

> PMCs - If Gregor wants to donate their changes based on the
> old/original provider to CloudStack, is there a formal donation
> process that he/swisstxt needs to be used or a simple pull request
> can be sent?

We're open to any suggestions.
You can also simply fork the Github repo and start from there. ☺

Regards,
Gregor

Re: [VOTE][RESULT] Apache CloudStack 4.11.3.0

[Riepl, Gregor (SWISS TXT)]

> https://github.com/apache/cloudstack/pull/3417
> 
> 
> The issue only affects 4.11.2.0 users for which the upgrade path does
> not run (a noop upgrade path runs) and it does not automatically fix
> any registered 4.11.3 systemvmtemplate to be used post-upgrade. I've
> mentioned workaround steps on the PR.

This sounds pretty much exactly like the issue we had...

https://lists.apache.org/thread.html/3a6ba604a77c944640cb159d7a55bda2c4646afa32bd494e3072e012@%3Cdev.cloudstack.apache.org%3E
https://lists.apache.org/thread.html/94d226e7cd832cda45c877db7f3d40c4802812da1a09b14ba63ccaf7@%3Cdev.cloudstack.apache.org%3E
https://lists.apache.org/thread.html/17d603ed695ce926ced124dc99cf41102f763e9dffc4e08259d74a44@%3Cusers.cloudstack.apache.org%3E

Re: Get VM OS type

[Riepl, Gregor (SWISS TXT)]

> @Riepl
> nmap -sS -O does help in fetching the OS type only if they have
> public ip. I cant ssh into the machines because they are customer
> machines and I dont have credentials for them.

We had such a situation a few times, and simply asked the affected
customer if they would permit us to deploy a temporary VM into their
network.

You could also use the virtual router as a gateway, but it doesn't have
nmap installed by default.

Re: Get VM OS type

[Riepl, Gregor (SWISS TXT)]

> version. Another way is to open the console and see the login screen.
> This will get the actual data but I want to do automation to see for
> all VM's and opening the console is not feasible to automate. Is
> there any other way to get it?

Are the VMs networked?

You could fetch their public IPs and run nmap -sS -O against them. This
should produce fairly accurate results.

If they are all on the same Cloudstack network, you could also SSH into
a connected VM and run nmap from there.

I don't think that there is a generic way to obtain the actual OS
running on a VM via Cloudstack. It might be possible through the
hypervisor, but nmap will work in most cases.

Re: [VOTE] 4.11.3.0 RC1

[Riepl, Gregor (SWISS TXT)]

+1

Based on:
- Packages from http://packages.shapeblue.com/testing/41130rc1/ and 
http://packages.shapeblue.com/testing/systemvm/41130rc1/
- Upgrade of our test cloud from 4.11.2 to 4.11.3 worked without problems 
(aside from the mentioned template issue)
- Our internal smoke test stack ran successfully

The only thing I'm a bit unhappy about is the backported ostype API fix: 
https://github.com/apache/cloudstack/pull/3066
Since this is a breaking API change, I don't think it should be included in a 
minor release, even if it fixes an API bug.
It triggers an error in Packer, which we use to create templates.
However, a fix was already commited and will be in the next Packer release, so 
I'm ok'ing it: https://github.com/hashicorp/packer/pull/7694

Re: [VOTE] 4.11.3.0 RC1

[Riepl, Gregor (SWISS TXT)]

So, I think it's ok to leave this issue aside.

I have a suspicion why the templates don't get upgraded, but since we know how 
to fix them manually, it's not release critical.

We'll open a ticket later.



From: Rohit Yadav 
Sent: 13 June 2019 12:49:40
To: dev; us...@cloudstack.apache.org
Subject: Re: [VOTE] 4.11.3.0 RC1

Gregor,


Please follow the following guide, but use the systemvmtemplate URL from the 
mirror shared on this thread and register the template with the name as 
"systemvm--4.11.3" before upgrading to 4.11.3.0-rc1:

http://docs.cloudstack.apache.org/en/4.11.2.0/upgrading/upgrade/upgrade-4.11.html



Regards,

Rohit Yadav

Software Architect, ShapeBlue

https://www.shapeblue.com


From: Andrija Panic 
Sent: Thursday, June 13, 2019 2:45:50 AM
To: dev
Cc: us...@cloudstack.apache.org
Subject: Re: [VOTE] 4.11.3.0 RC1

Gregor,

can you confirm if you followed the steps exactly in regards to template
flags and more importantly the actual name - I believe in the code, during
upgrading, it will search for specific template name (i.e.
systemvm-vmware-4.11.3) and update it's DB values so it becomes a "SYSTEM"
instead of "USER" type that it was initially.

Andrija

On Wed, 12 Jun 2019 at 16:46, Riepl, Gregor (SWISS TXT) <
gregor.ri...@swisstxt.ch> wrote:

> Hi Paul,
>
> > The release notes are still work-in-progress, but the systemvm
> > template upgrade section has been updated. You may refer the
> > following for systemvm template upgrade testing:
> >
> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/index.html
>
> Thanks!
>
> We're doing our own tests right now, but ran into problems when
> updating the system VMs.
>
> For one, after registering the new VMware systemvm template, it is
> shown as a "USER" template. I'm not sure if this is correct. Is there
> an additional step to ensure it is considered a "SYSTEM" template?
> I believe this is important so the SSVM and Console Proxy get upgraded.
>
> Secondly, the upgrade instructions do not mention updating
> minreq.sysvmtemplate.version
> and
> router.template.
> to the
> version/name of the new template.
>
> Without this step, routers won't be upgraded to the new template.
> IMHO, it should be mentioned in all upgrade instructions.
>
> Should I prepare a PR against the documentation?
>
> Best regards,
> Gregor
>


--

Andrija Panić

rohit.ya...@shapeblue.com
www.shapeblue.com<http://www.shapeblue.com>
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue

Re: Hello

[Riepl, Gregor (SWISS TXT)]

Hi Darrin, welcome!


From: Darrin H?sselmann 
Sent: 13 June 2019 14:14:00
To: dev@cloudstack.apache.org; us...@cloudstack.apache.org
Subject: Hello

Hi All,


I have joined Shapeblue as a software engineer and look forward to contributing 
to the cloudstack project and working with the community.


Cheers

Darrin


darrin.husselm...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue

Re: [VOTE] 4.11.3.0 RC1

[Riepl, Gregor (SWISS TXT)]

Hi Paul,

> The release notes are still work-in-progress, but the systemvm
> template upgrade section has been updated. You may refer the
> following for systemvm template upgrade testing:
> http://docs.cloudstack.apache.org/projects/cloudstack-release-notes/en/latest/index.html

Thanks!

We're doing our own tests right now, but ran into problems when
updating the system VMs.

For one, after registering the new VMware systemvm template, it is
shown as a "USER" template. I'm not sure if this is correct. Is there
an additional step to ensure it is considered a "SYSTEM" template?
I believe this is important so the SSVM and Console Proxy get upgraded.

Secondly, the upgrade instructions do not mention updating 
minreq.sysvmtemplate.version
and
router.template.
to the
version/name of the new template.

Without this step, routers won't be upgraded to the new template.
IMHO, it should be mentioned in all upgrade instructions.

Should I prepare a PR against the documentation?

Best regards,
Gregor

Re: Do not see KVM Hosts after 4.9.3 -> 4.11.2

[Riepl, Gregor (SWISS TXT)]

> - You did the upgrade on a newly built MySQL / MariaDB server (keep in mind 
> you can not at this point run MariaDB version 10.x)
> - AND you imported database dumps to the new DB servers
> - AND you didn't give 'cloud@%' permissions before the import:
> GRANT ALL ON *.* TO 'cloud'@'%' IDENTIFIED BY '' WITH GRANT OPTION;
>
> If these apply then the import fails after all tables are imported but before 
> the views are imported - hence the GUI struggles to display data.

Could this be related to the fact that views are created with the creating 
user's permissions by default?
When I recently migrated our CS database to a new host, I ran into errors 
because of subtle root user changes (i.e. different host parts) on the new DB 
server.

MySQL/MariaDB sets the SQL SECURITY to DEFINER by default, which means that the 
exact user/hostname combo must exist on the target host when importing a 
database. In my opinion, this makes absolutely no sense. The default should be 
INVOKER, i.e. queries on the view should be executed with the permissions of 
the user sending the query on the view, not those of the user who created the 
view in the first place.

See https://dev.mysql.com/doc/refman/8.0/en/create-view.html for more info on 
the topic.

Is there a particular reason why CloudStack uses the MySQL default? Perhaps all 
views should be changed to use SQL SECURITY INVOKER?

My quick fix to the problem was to comment out the DEFINER = ... lines from the 
database dump during import:
zcat cloudstack.sql.gz | grep -v "50013 DEFINER" | mysql -p

Re: [VOTE] Remove el6 support in future CloudStack versions (was Re: [DISCUSS] Remove support for el6 packaging in 4.13/4.14)

[Riepl, Gregor (SWISS TXT)]

+1

Re: [DISCUSS] WIP PRs and contribution transparency

[Riepl, Gregor (SWISS TXT)]

> In order to be more transparent, I would like to propose that we put
> something like ' [WIP DO NOT MERGE]' in the PR title as my colleagues
> and I have done on some new PRs you can follow. Labels cannot be used
> as not every contributor is a committer. Once the PR is ready for
> merging, we can remove it.

Is it possible to attach bots to PRs, like for Issues?

That way, a bot could take care of attaching and removing labels, and
access control could be done according to the contributor's role.

Re: Any plan for 4.11 LTS extension ?

[Riepl, Gregor (SWISS TXT)]

Hi Giles,

> I would *expect*  4.13.0 (LTS) to be released in Q2, which  will
> supersede the 4.11 branch as the current LTS branch

Are you confident that this schedule can be kept?
4.12 is still in RC right now, and I don't think it's a good idea to
rush another major release in just 3 months...

Re: New* UI SVG hires icons for CloudStack (Vote)

[Riepl, Gregor (SWISS TXT)]

> I create a new iconset for cloudstack and we think we will implement
> it. There is a Vote Formular and some examples. I oriented myself on
> the original one. Its a lot of work to make them all looks good but
> if you do not start it will be nothing. Lets start with the dashboard
> and left control panel.

Looking good to me, but I'm also fine with the old icons.

Question: Are you going to prepare different colour sets, or "dark"
versions of the images?
Though with SVGs, it will be relatively easy to recolour the icons
later, I suppose.

Re: [VOTE] Release Apache CloudStack CloudMonkey 6.0.0

[Riepl, Gregor (SWISS TXT)]

No sure if my vote counts, but a
[x] +1 approve
from me.

I built the tag 6.0.0 locally with Go 1.11.5 and tested against a CS
4.5.2 and a CS 4.11.2 instance.

Listing VMs and stopping/starting instances works as expected, on both
CloudStack versions.

I also filed a few minor issues on Github, but nothing critical. The -p
argument bug should be fixed in the next release if possible, though.

Re: New VP of CloudStack: Paul Angus

[Riepl, Gregor (SWISS TXT)]

> I’m happy to announce that the CloudStack PMC has elected Paul Angus
> as our new VP of CloudStack.

Congratulations, Paul!

Re: [DISCUSS] Bring back static analysis and bugfixing

[Riepl, Gregor (SWISS TXT)]

Looks like it's only temporary: 
https://community.synopsys.com/s/article/Coverity-Scan-Update


Their old hosting provider shut down, but they want to restore the service as 
soon as possible.


From: Rohit Yadav 
Sent: 17 January 2019 20:49:21
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Bring back static analysis and bugfixing

All,


Unfortunately, it seems the Coverity project is no longer available due to the 
project sponsorers removing the infra/websites. I've configured static analysis 
with sonarcloud instead:

https://sonarcloud.io/dashboard?id=apachecloudstack


- Rohit






From: Rohit Yadav 
Sent: Sunday, December 23, 2018 3:39:29 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Bring back static analysis and bugfixing

All,


Coverity has processed latest master (4.12.0.0-SNAPSHOT), results are available 
now: https://scan.coverity.com/projects/cloudstack?tab=overview


In addition, I've also setup latest master on sonarcloud: 
https://sonarcloud.io/dashboard?id=rhtyd_cloudstack


- Rohit






From: Rohit Yadav 
Sent: Sunday, December 9, 2018 3:28:03 PM
To: dev@cloudstack.apache.org
Subject: [DISCUSS] Bring back static analysis and bugfixing

All,


Our coverity integration has been dead/unused for about 3 years now, I've build 
latest master/ecd2b95d492282d60107f5e132e39f0cd2d808c0 and submitted a build 
[1]. We should be able to see outstanding defects towards master 
(4.12.0.0-SNAPSHOT) soon.


After some searching, I could find my login access. If you want to collaborate 
and don't have an invite ping me. Happy fixing!


[1] https://scan.coverity.com/projects/cloudstack


- Rohit





rohit.ya...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue




rohit.ya...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue




rohit.ya...@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue