Re: [DISCUSS] [IMPORTANT] CloudStack 4.14 release WITH updated UI

[Erik Weber]

On Thu, Dec 3, 2020 at 7:09 PM  wrote:
>
> Hi all,
>
[ snip ]
>
> 1. I think that the repo 'apache/cloudstack-primate' should be renamed to
> '/apache/cloudstack-ui', to keep everything just 'cloudstack'.

No big opinion here. 'cloudstack-ui' makes it a bit clearer what it is/does

> 2. In the repo RPM/DEB packaging make cloudstack-ui a dependency of
> cloudstack - and finally, when creating the repo, include both the
> 'cloudstack' and 'cloudstack-ui'  RPMs/DEBs so that there is one repo
> (http://download.cloudstack.org/centos7/4.15/) which contains both.

I've not used cloudstack for a while, is it a requirement to run both
the mgmt/api and primate/ui on the same machine?
If not then I would vote -1 to make mgmt a requirement for primate
unless 'cloudstack' is a meta package to give you an all-in-one
package.
(e.g. if it is possible to install the mgmt by using a more distinct
name like cloudstack-mgmt, then I am fine with the proposal)

I can see why people would want to separate them

-- 
Erik

Re: UI adjustments and refactoring css code

[Erik Weber]

I don’t recall their name, but there’s a company that works on an open
sourced alternative ui.

I’m not sure of the state, but last I looked it was promising. I’d be
tempted to suggest a total switch if the other ui is close enough to
feature alike.

Erik

man. 1. jul. 2019 kl. 16:47 skrev Maximilian Weber :

> We want to contribute our work on a new iconset and styles for the
> existing UI.
> The User Interface of Cloudstack has (relatively to web technology and
> design history of the past years) a pretty outdated state. Thus it’s
> necessary to scrutinize if several techniques and styles are still state of
> the art and replace them step by step.
> Now out target of UI works is to do optical UI improvements will perhaps
> help to increase the number of audience of Cloudstack community users as
> well and of cause improves the user experience for general.
> In addition UI enhancements we should refactoring css-code until it’s
> easier to maintain, read, organize, extend, simplify and automatize.
>
>
> Here you can find a list of general UI enhancements:
>
>   *   improve or unify icons and vectorize them as well
>   *   replace hard gradients and hard drop shadows with more flat designs
> (hard means very obvious visible, which was on no time best practice)
>   *   unify and modernize some hover effects and transitions, as well as
> colors and paddings etc.
>
> For the initial step we already made a screenshot of the improved
> Cloudstack UI frame (header and navigation).
> Open this screenshot to see it
> – https://ibb.co/F3LT7jL –––
>
> We adjusted the menu icons, the sizes of the header and made the design
> more flat.
> And we will allocate the Illustrator file next to the new svg icons to
> provide the possibility of a file versioning via GIT and to make it
> possible for the community to do icon changes faster. In future we could
> advance this Illustrator file with all icons used on Cloudstack.
>
>
> Let’s face the css-code quality now. Writing css may appear more complex
> than expected for most developer, especially if the main css-file is over
> 1 lines large.
> It’s almost impossible to prevent redundancies or outdated css-hacks and
> prefixes as well as importance, specificity and source order of css rules
> in such a huge file!
> Therefor we need a tool that automate most of this tasks. A technology
> stack of Node, Gulp and SCSS will do it here. Node package manager NPM can
> provide powerful packages that are executable in Gulp task and SCSS allows
> us to use features like variables and linters and organize our rules more
> professional.
>
> Here you can find a list of general refactoring enhancements
>
>   *   split 1+ lines css-file into many modular scss files and
> organize them inside folders.
>   *   remove outdated css rules or rules that are no longer supported by
> almost all modern browser
>   *   create a possibility to minify final transpiled css file
>   *   add a linter-tool that warns the developer from doing bad practices
>   *   add a autofix-tool that unifies some parts css-code automatically
>
>
>
> We are happy to contribute this enhancements to the community.
> Max
>
>
>
>
>
>
>
>
>
>
>
> __
>
> Maximilian Weber
> Frontend Developer
>
> EWERK IT GmbH
> Brühl 24, D-04109 Leipzig
> 
> P +49 341 42649 - 99
> F +49 341 42649 - 98
> m.we...@ewerk.com
> www.ewerk.com
>
> Geschäftsführer:
> Dr. Erik Wende, Hendrik Schubert, Frank Richter
> Registergericht: Leipzig HRB 9065
>
> Zertifiziert nach:
> ISO/IEC 27001:2013
> DIN EN ISO 9001:2015
>
> EWERK-Blog | 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/>
>
> 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.
>

Re: [DISCUSS] Remove support for el6 packaging in 4.13/4.14

[Erik Weber]

CentOS7 was released 5 years ago, upgrading is long overdue anyway.
Realistically the next CloudStack release won't be out the door for
another ~4-6 months either.

-- 
Erik

On Wed, Apr 24, 2019 at 3:27 PM Ron Wheeler
 wrote:
>
> According to https://en.wikipedia.org/wiki/CentOS
>
> CentOS 6 EOL is 2020
> CentOS 7 EOL is 2024
>
>
> +1 for removing support for CentOS 6.
>
> As Erik pointed out the sites running CentOS6 will have to move soon in
> any event and it is probably better to do it now when there is still a
> lot of current expertise and information available about how to do it
> and how to make any changes to applications.
>
> Upgrading in a project that is under your control is usually easier than
> one forced on you by a security issue or an operational failure.
>
> Ron
>
> On 4/24/19 3:24 AM, Erik Weber wrote:
> > As an operations guy I can understand the want for future updates and
> > not upgrading, but with the release plan of RHEL/CentOS I don't find
> > it feasible.
> >
> > RHEL6 is 8 years old (and is still running kernel 2.6!) and isn't
> > scheduled to be fully EOL until 2024.
> >
> > It is true that upgrading requires some effort (and risk) from
> > operators, but this is work they eventually have to do anyway, so it's
> > not a matter of /if/ they have to do it, but rather when.
> >
> > It is also true that current CloudStack releases should continue to
> > work, it's also possible that someone might back port future fixes to
> > a RHEL6 compatible fork (you're more than welcome to).
> >
> > I'd vote +1 to remove support for el6 packaging.
> >

Re: [DISCUSS] Remove support for el6 packaging in 4.13/4.14

[Erik Weber]

As an operations guy I can understand the want for future updates and
not upgrading, but with the release plan of RHEL/CentOS I don't find
it feasible.

RHEL6 is 8 years old (and is still running kernel 2.6!) and isn't
scheduled to be fully EOL until 2024.

It is true that upgrading requires some effort (and risk) from
operators, but this is work they eventually have to do anyway, so it's
not a matter of /if/ they have to do it, but rather when.

It is also true that current CloudStack releases should continue to
work, it's also possible that someone might back port future fixes to
a RHEL6 compatible fork (you're more than welcome to).

I'd vote +1 to remove support for el6 packaging.

-- 
Erik

On Mon, Apr 22, 2019 at 11:54 AM Vladimir Melnik  wrote:
>
> Hi Rohit,
>
> I agree that being stuck to CentOS-6 is not the best strategy and I'd gladly 
> get rid of this old distro in my environments. It could be pretty easy to 
> upgrade the management servers, but upgrading the hosts means "cold" 
> migration from the CentOS6-based cluster to a CentOS7-based one (alas, "hot" 
> migration between different QEMUs won't work, I tried it before). So I'll 
> have to move ~100 VMs between the clusters, which means shutting them all 
> down one by one. That's scary :-)
>
> Maybe it would be possible to make ACS "know" what operating system is being 
> run, so ACS could only use the available features? It would be cool.
>
> On Sun, Apr 21, 2019 at 08:02:00PM +, Rohit Yadav wrote:
> > Hi Vladimir,
> >
> >
> > Thanks for sharing your opinion. I can understand the position of our 
> > conservative users such as yourself with respect to a potential upgrade, 
> > both the effort and the risks involved in doing the upgrades.
> >
> >
> > That said, I would like to encourage you and other conservative users to 
> > consider upgrading because it becomes difficult to support older 
> > distributions moving forward especially when CentOS/RHEL 8 will arrive and 
> > it also hinders us to (a) support newer features wrt KVM and (b) forces us 
> > to depend on older distro-provided dependencies that CloudStack uses and 
> > potentially puts a cloud environment under security risks.
> >
> >
> > As Andrija puts it, you can attempt to upgrade to CentOS7 based infra by 
> > doing a fresh installation and move to the new server/hosts in a rolling 
> > way. If you'd need any pointers in that regard I'm sure we can ask Andrija 
> > and others to share some details on how to do that. Meanwhile, you may also 
> > refer to my colleague Dag's talk on upgrade best practices from CCCNA17: 
> > https://www.slideshare.net/ShapeBlue/cccna17-cloudstack-upgrade-best-practicespdf
> >
> >
> > I would like to hear again from you on this and see if we can all agree 
> > towards a decision that benefits all of our community. Thanks.
> >
> >
> > Regards,
> >
> > Rohit Yadav
> >
> > Software Architect, ShapeBlue
> >
> > https://www.shapeblue.com
> >
> > 
> > From: Vladimir Melnik 
> > Sent: Friday, April 19, 2019 8:01:20 PM
> > To: us...@cloudstack.apache.org
> > Cc: dev@cloudstack.apache.org
> > Subject: Re: [DISCUSS] Remove support for el6 packaging in 4.13/4.14
> >
> > Dear colleagues,
> >
> > As for me, I still have 3 hosts running CentOS 6 and 2 management servers 
> > in one of my production environments.
> >
> > Also I have 1 management servers running CentOS 6 in another environment.
> >
> > If my voice counts, I'd propose -1.
> >
> > Thanks for attention :-)
> >
> > On Mon, Apr 15, 2019 at 07:44:58AM +, Rohit Yadav wrote:
> > > All,
> > >
> > >
> > > With CentOS8 around the corner to be released sometime around the summer, 
> > > I would like to propose to deprecate CentOS6 as support management server 
> > > host distro and KVM host distro. Non-systemd enabled Ubuntu releases have 
> > > been already deprecated [1].
> > >
> > >
> > > The older CentOS6 version would hold us back as we try to adapt, use and 
> > > support newer JRE version, kvm/libvirt version, the Linux kernel, and 
> > > several other older dependencies. Both CentOS6 and RHEL6 have reached EOL 
> > > on May 10th, 2017 wrt full updates [1].
> > >
> > >
> > > If we don't have any disagreements, I propose we remove el6 packaging 
> > > support in the next major release - 4.13. But, if there are users and 
> > > organisations that will be badly impacted, let 4.13 be the last of 
> > > releases to support el6 and we definitely remove el6 support in 4.14.
> > >
> > > What are your thoughts?
> > >
> > >
> > > [1] EOL date wiki reference: 
> > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Hypervisor+and+Management+Server+OS+EOL+Dates
> > >
> > >
> > >
> > > Regards,
> > >
> > > Rohit Yadav
> > >
> > > Software Architect, ShapeBlue
> > >
> > > https://www.shapeblue.com
> > >
> > > rohit.ya...@shapeblue.com
> > > www.shapeblue.com
> > > Amadeus House, Floral Street, London  WC2E 9DPUK
> > > @shapeblue
> > >
> > >
> 

Re: John Kinsella and Wido den Hollander now ASF members

[Erik Weber]

ons. 2. mai 2018 kl. 17:58 skrev David Nalley :

> Hi folks,
>
> As noted in the press release[1] John Kinsella and Wido den Hollander
> have been elected to the ASF's membership.
>
> Members are the 'shareholders' of the foundation, elect the board of
> directors, and help guide the future of the ASF.
>
> Congrats to both of you, very well deserved.
>

Congratulations to both of you :-)

Erik

Re: Clean up old and obsolete branches

[Erik Weber]

On Thu, Nov 30, 2017 at 9:05 PM, Khosrow Moossavi
 wrote:
> Hi Community
>
> I would like to start the discussion around deleting old and obsolete
> branches on github repository. This will help newcomers (including myself)
> to keep track of which branches are important and which are not. And since
> almost everyone's working on their own forks there is no need to keep
> feature/bugfix/hotfix branches around in the main official repository.
>
> I've created an issue which contains full list of branches in
> GH/apache/cloudstack repo as of time of writing this email and the
> proposition of which one of them can be deleted.
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-10169
>
> I would appreciate your questions, comments, suggestions.

Do note that there might be branches with unmerged changes, I don't
think we should just automatically delete those without reflecting
over its content.
Although these branch might be stray now, there could be pieces there
that someone else could use at a later point.

As for old feature/fix branches that has been merged, I'm +1 to
cleanup up those.

-- 
Erik

Re: Hello

[Erik Weber]

Welcome on board :-)

On Thu, Nov 30, 2017 at 9:38 AM, Ernie Janse van Rensburg
 wrote:
> Hi All
>
> I have recently joined Shape Blue as a software engineer and looking forward 
> to be part of the community.
>
> Regards
>
> Ernie Janse van Rensburg
>
> (Cape Town - South Africa)
>
> ernie.jvrensb...@shapeblue.com
> www.shapeblue.com
> ,
> @shapeblue
>
>
>

Re: [VR] dnsmasq reload instead of restart

[Erik Weber]

I'm not sure if this applies to dnsmasq or not, but some services does
not bind to new interfaces during a reload.
Meaning you'll have to be sure the reason you're reloading isn't
because of something that added a device (say adding a new tier or
similar).

-- 
Erik

On Fri, Nov 24, 2017 at 9:05 PM, Pierre-Luc Dion  wrote:
> Hi,
>
> We recently found a way to reload dnsmasq process instead of doing a
> restart.
> Does anyone see a problem with that?  Basically we have to change where the
> file /etc/dhcphosts.txt is define in the config so it would be define via
> "--dhcp-hostsfile=/etc/dhcphosts.txt" when the process is start so it would
> be re-read in a kill -HUP.
>
> The problem to solve here is that during VM.CREATE in a VPC, the dns
> service is restarted and cause DNS service interruption to VM inside the
> VPC.
>
> We are preparing a PR for this.
>
> is this could be problematic for rVR ?
>
> Thanks,
>
> PL

Re: Introduction

[Erik Weber]

Welcome :-)

On Thu, Nov 23, 2017 at 9:00 AM, Dingane Hlaluku
 wrote:
> Dear Community
>
>
>
>
>
> It is with great pleasure that I would like to introduce myself to this 
> community. I am Dingane and I have recently joined ShapeBlue to work on 
> CloudStack. I am looking forward to future collaborating and learning from 
> everyone.
>
>
>
> Thank you,
>
> dingane.hlal...@shapeblue.com
> www.shapeblue.com
> ,
> @shapeblue
>
>
>

Re: Adoption Survey seems to be abandoned

[Erik Weber]

On Mon, Oct 30, 2017 at 4:51 AM, Ivan Kudryavtsev
 wrote:
> Hi, DevTeam.
>
> May be dev@ is wrong list, sorry in advance.
>
> It seems that adopters list is abandoned. I mean that I filled it about 3+
> month ago and don't see our org in list of adopters (might be it was just
> ignored, but worth to mention anyway). I don't know either it's intended or
> not, just wanted to note that.

Hey Ivan,

I just want to acknowledge that your submission is received and let
you know that it is not ignored.

I'll see if I can find time tonight to update the web page with the
latest entries.

-- 
Erik

Re: Usage Server in Docker Simulator

[Erik Weber]

Are you running the usage server?

It is a different service and run independently of the mgmt server

-- 
Erik

ons. 12. jul. 2017 kl. 00.25 skrev John McDonnell :

> Hi,
>
> I asked this back in April on the Users mailing list and the response
> I got was that the usage server should be on by default in the docker
> container.  I got sidetracked by other things and am coming back to
> this issue.
>
> Is it meant to be running by default? or is there something needed to
> do to turn it on in the container?  (wasn't sure if this is a defect,
> so thought I'd ask here.)
>
>
> I use the container as a development tool(to avoid using a real life
> system) to test the API out and usage collection is a major part of
> what I use the API for.
>
>
> Steps to reproduce:
>
> (Have docker installed)
> $ docker pull cloudstack/simulator
> $ docker run --name cloudstack -d -p 8080:8080 cloudstack/simulator
> $ docker exec -ti cloudstack python \
> /root/tools/marvin/marvin/deployDataCenter.py -i
> /root/setup/dev/advanced.cfg
>
> After a while login to the UI: localhost:8080/client (admin:password)
>
> And usually, after a while, there will be a General Alert saying there
> is no Usage Server running.  Even before this message, if I add an
> instance, and attempt to collection usage with the API, I don't get
> anything back.
>
> Any help?
>

Re: Extend CloudStack for a new hypervisor

[Erik Weber]

Cool, I like it ;-)

I can already hear the slogan in my head "CloudStack - making
OpenStack great again" :-p

Can't help you with the your actual questions, but best of luck :-)

-- 
Erik

On Fri, May 19, 2017 at 12:57 PM, John Smith  wrote:
> Ok...so bear with me on this one.
>
> "Hypervisor" was a little white lie.  What I actually want to do is
> implement OpenStack as a backend for CloudStack (yo dawg, I hear you like
> cloud in your clouds, etc).  I know I can use KVM and OVS as backends for
> CloudStack natively but, as I said, this is for a project with some very
> specific needs...
>
> As OpenStack is completely API driven, I see no issues with the basics of
> communication between CS and OS.
>
> This would, of course, bypass the OS concept of Linux network namespaces
> for routing and I would implement the CS routing VM as a VM (just like in
> VMware or Xen) connected between an OS tenant network and an OS external
> network.  CS volumes would be OS volumes.  Secondary storage would be a VM
> running NFS.
>
> In principle, I see that the CS concepts of compute, network and storage
> could be implemented on OS.  I was hoping that I could basically write a
> "driver" that would do the necessary actions against OS based on standard
> calls to a CS class/method/whatever, based on some assumption that the
> underlying hypervisor in CS was at least some sort of pluggable
> architecture.
>
> Yes, this may sound a little crazy, and I did say this was probably not
> something strategic to the CloudStack direction, but for me it actually
> fits a funny shaped hole I've discovered and I'm interested in at least
> understanding how such a thing could be done.
>
> Thanks,
>
> John.
>
>
>
> On Fri, May 19, 2017 at 12:06 AM, Simon Weller 
> wrote:
>
>> Which hypervisor are you wanting to implement?
>>
>> Simon Weller/615-312-6068
>>
>> -Original Message-
>> From: John Smith [john.smith@gmail.com]
>> Received: Thursday, 18 May 2017, 5:29PM
>> To: dev@cloudstack.apache.org [dev@cloudstack.apache.org]
>> Subject: Extend CloudStack for a new hypervisor
>>
>> Greetings!
>>
>> I have a need to extend CloudStack to support an additional hypervisor.
>> This is not something I consider strategic for CloudStack itself, but I
>> have a project with a very specific need.
>>
>> I have a development background but am not an active developer right now
>> ... so looking forward to getting back in the saddle!  I've never developed
>> against the CloudStack tree before.
>>
>> I can't find any docs on how one would introduce support for a new
>> hypervisor (eg. what classes, methods, etc, need to be implemented,
>> extended, etc) and checking the source tree I can't easily see if there is
>> a base to build from.  I would appreciate any pointers about where to start
>> looking to save me going through the entire tree from scratch.
>>
>> The standard CloudStack concepts should be easy enough (ha!) to map 1:1 to
>> this additional hypervisor (including primary & secondary storage, router &
>> secondary storage VMs, the networking concepts, etc) so I'm hoping that I
>> can simply implement it like a VMware or Xen backend ...
>>
>> Thanks in advance!
>>
>> John.
>>

Re: Docs: where to put it - want to update docs for Private Gateway adding...

[Erik Weber]

My bad, the image should have a relative url, like
"src=_images/guest-traffic-setup.png"

-- 
Erik

On Fri, May 12, 2017 at 3:27 PM, Erik Weber <terbol...@gmail.com> wrote:
> Images are here:
> https://github.com/apache/cloudstack-docs-admin/tree/master/source/_static/images
>
> The image will have an url like: /_images/guest-traffic-setup.png
>
> --
> Erik
>
> On Fri, May 12, 2017 at 2:48 PM, Andrija Panic <andrija.pa...@gmail.com> 
> wrote:
>> Thanks, this is what I'm editing ATM.
>>
>> I'm new to this editing procedure,
>> so how do I insert/upload images as part of docs? I see images in finall
>> guide, but can't find them in repo ?
>>
>> Thanks,
>> Andrija
>>
>> On 11 May 2017 at 18:35, Rajani Karuturi <raj...@apache.org> wrote:
>>
>>> you can send a doc update PR at
>>> https://github.com/apache/cloudstack-docs-admin
>>>
>>> ~ Rajani
>>>
>>> http://cloudplatform.accelerite.com/
>>>
>>> On May 11, 2017 at 8:26 PM, Syed Ahmed (sah...@cloudops.com)
>>> wrote:
>>>
>>> CCing Pierre-Luc,
>>>
>>> He might be better able to answer your question Andrija asn
>>> Pierre-Luc
>>> deals a lot with documentation.
>>>
>>> Thanks,
>>> -Syed
>>>
>>> On Sat, May 6, 2017 at 11:10 AM, Andrija Panic
>>> <andrija.pa...@gmail.com>
>>> wrote:
>>>
>>> Hi all,
>>>
>>> I would like to update documentation about adding private
>>> gateways
>>> additionaly, after Zone without dedicated Guest network (for
>>> Priv.Gtw) has
>>> been creaated and used for some time.
>>>
>>> Idea is to make life more easy for people who are in situations
>>> like we
>>> were:
>>> - we needed to add new physical network (requires CM command,
>>> and manual DB
>>> changes to configure isolation method), configure it as Guest
>>> network (DB
>>> changes manually), do needed physical network and network
>>> offering tagging
>>> (again some DB changes here), etc.
>>>
>>> Also, my steps (to be documented) were executed on ACS 4.5 - so:
>>>
>>> 1) not sure on which branch to commit additional documentation?
>>> I also have
>>> 4.8 installation where I could also do CM commands to add new
>>> physical
>>> network (but I assume same DB changes will be needed to be done
>>> here as on
>>> 4.5)
>>>
>>> 2) where to exactly put this additional steps -
>>> http://docs.cloudstack.apache.org/projects/cloudstack-
>>> administration/en/4.8/networking_and_traffic.html#adding-priv-gw-vpc
>>> - this section is about adding private gateways - basically, I
>>> don't want
>>> to edit this section (perhaps make some correction and further
>>> explanation)
>>> - but I actually need to make docs on how to add additional
>>> Physical
>>> (guest) network and do network tagging etc.. i.e. some externam
>>> page, or
>>> section on the main HTML url above ?
>>>
>>> Sorry for long question...
>>>
>>> THanks,
>>>
>>> --
>>>
>>> Andrija Panić
>>>
>>
>>
>>
>> --
>>
>> Andrija Panić

Re: Docs: where to put it - want to update docs for Private Gateway adding...

[Erik Weber]

Images are here:
https://github.com/apache/cloudstack-docs-admin/tree/master/source/_static/images

The image will have an url like: /_images/guest-traffic-setup.png

--
Erik

On Fri, May 12, 2017 at 2:48 PM, Andrija Panic  wrote:
> Thanks, this is what I'm editing ATM.
>
> I'm new to this editing procedure,
> so how do I insert/upload images as part of docs? I see images in finall
> guide, but can't find them in repo ?
>
> Thanks,
> Andrija
>
> On 11 May 2017 at 18:35, Rajani Karuturi  wrote:
>
>> you can send a doc update PR at
>> https://github.com/apache/cloudstack-docs-admin
>>
>> ~ Rajani
>>
>> http://cloudplatform.accelerite.com/
>>
>> On May 11, 2017 at 8:26 PM, Syed Ahmed (sah...@cloudops.com)
>> wrote:
>>
>> CCing Pierre-Luc,
>>
>> He might be better able to answer your question Andrija asn
>> Pierre-Luc
>> deals a lot with documentation.
>>
>> Thanks,
>> -Syed
>>
>> On Sat, May 6, 2017 at 11:10 AM, Andrija Panic
>> 
>> wrote:
>>
>> Hi all,
>>
>> I would like to update documentation about adding private
>> gateways
>> additionaly, after Zone without dedicated Guest network (for
>> Priv.Gtw) has
>> been creaated and used for some time.
>>
>> Idea is to make life more easy for people who are in situations
>> like we
>> were:
>> - we needed to add new physical network (requires CM command,
>> and manual DB
>> changes to configure isolation method), configure it as Guest
>> network (DB
>> changes manually), do needed physical network and network
>> offering tagging
>> (again some DB changes here), etc.
>>
>> Also, my steps (to be documented) were executed on ACS 4.5 - so:
>>
>> 1) not sure on which branch to commit additional documentation?
>> I also have
>> 4.8 installation where I could also do CM commands to add new
>> physical
>> network (but I assume same DB changes will be needed to be done
>> here as on
>> 4.5)
>>
>> 2) where to exactly put this additional steps -
>> http://docs.cloudstack.apache.org/projects/cloudstack-
>> administration/en/4.8/networking_and_traffic.html#adding-priv-gw-vpc
>> - this section is about adding private gateways - basically, I
>> don't want
>> to edit this section (perhaps make some correction and further
>> explanation)
>> - but I actually need to make docs on how to add additional
>> Physical
>> (guest) network and do network tagging etc.. i.e. some externam
>> page, or
>> section on the main HTML url above ?
>>
>> Sorry for long question...
>>
>> THanks,
>>
>> --
>>
>> Andrija Panić
>>
>
>
>
> --
>
> Andrija Panić

Re: [PROPOSAL] branch on first RC and open up master for features

[Erik Weber]

On Mon, May 8, 2017 at 10:40 AM, Daan Hoogland
 wrote:
> LS,
>
> In a lot of occasions, we have seen new features that are waiting for 
> releases with blocker bugs and while these bugs certainly must be solved, 
> users that are not hindered by those bugs directly are stopped by them. 
> Therefore, I propose we will fork on the first RC branches for future 
> releases, so that development is not stopped for it. If the release process 
> takes too long and to nice features get merged in between we can always 
> decide to re-branch before releasing.


I might be misunderstanding, but isn't your proposal more or less how
we used to do releases back in the day?

-- 
Erik

Re: GSoC'17

[Erik Weber]

On Fri, May 5, 2017 at 6:30 PM, Sverrir Berg  wrote:
> Congratulations with the selection!
>
> We at Greenqloud have been using NoVNC as integral part of Qstack until
> recently.

Why not upstream it? ;-)

> We are now using Apache Guacamole
> https://guacamole.incubator.apache.org/.

Why not upstream it? ;-)


-- 
Erik

Re: GSoC'17

[Erik Weber]

Congratulations!

CloudStack will do well with a new console :-)


-- 
Erik
fre. 5. mai 2017 kl. 17.49 skrev sachin patil :

> Hello all,
>
>I have been selected for GSoC'17 and would be working on
> CloudStack-9778 (
>  Adding a new NoVNC console ).
>
> The aim of this feature is to make it possible to connect to VM consoles
> using  VNC client called NoVNC in browsers.
>
> NoVNC console is better than our current customized console. Additional
> features that NoVNC provides over the current customized console include a
> copy/paste functionality, scrollback. NoVNC uses websockets that provides a
> more reliable and secure connections.
>
> My proposal can be found here
>
> https://docs.google.com/document/d/1IqJiZ_sJZktAoPjdQePoinBNZzPboR1jCkUXBpqanjo/edit
>
> I have been selected for this project with my mentors Rohit Yadav and Syed
> Ahmed.
>
> Would like to know about your thoughts/ideas on this project.
>
> Regards,
> Sachin Patil
>

Re: MySQL 5.7 and SQL Mode

[Erik Weber]

Instead of hacking mysql settings, wouldn't it be better to fix the query?

-- 
Erik

On Wed, Apr 12, 2017 at 9:56 AM, Wido den Hollander  wrote:
>
>> Op 12 april 2017 om 7:23 schreef Koushik Das :
>>
>>
>> Hi Wido,
>>
>> Check initDataSource() in TransactionLegacy.java. The connection properties 
>> are read from db.properties.
>
> Thanks! After looking into this I found that you can just add this to 
> db.cloud.url.params
>
> sessionVariables=sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'
>
> My line now looks like this in db.properties:
>
> db.cloud.url.params=prepStmtCacheSize=517=true=sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'
>
> Created a issue: https://issues.apache.org/jira/browse/CLOUDSTACK-9871
>
> I created a PR to include this into db.properties by default: 
> https://github.com/apache/cloudstack/pull/2037
>
> Wido
>
>>
>> -Koushik
>>
>> On 11/04/17, 10:27 PM, "Wido den Hollander"  wrote:
>>
>>
>> > Op 11 april 2017 om 10:51 schreef Rohit Yadav 
>> :
>> >
>> >
>> > Hi Wido,
>> >
>> >
>> > You're right, MySQL 5.7 has by default strict(er) sql mode enabled. To 
>> make CloudStack work with MySQL 5.7, changing the sql mode makes MySQL 5.7 
>> behave like 5.6 with which the mgmt server/usage server should work.
>> >
>>
>> Yes, but a client can do this as well. It doesn't have to be server wide.
>>
>> Do you know where the MySQL client is initiated by CloudStack? A few 
>> lines of code there should/might be enough.
>>
>> Wido
>>
>> >
>> > Regards.
>> >
>> > 
>> > From: Wido den Hollander 
>> > Sent: 10 April 2017 20:30:55
>> > To: dev@cloudstack.apache.org
>> > Subject: MySQL 5.7 and SQL Mode
>> >
>> > Hi,
>> >
>> > While testing with Ubuntu 16.04 and CloudStack 4.10 (from master) I've 
>> ran into this error on the management server:
>> >
>> > com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Expression 
>> #1 of SELECT list is not in GROUP BY clause and contains nonaggregated 
>> column 'cloud.i.id' which is not functionally dependent on columns in GROUP 
>> BY clause; this is incompatible with sql_mode=only_full_group_by
>> > at 
>> sun.reflect.GeneratedConstructorAccessor50.newInstance(Unknown Source)
>> > at 
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>> > at 
>> java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>> > at com.mysql.jdbc.Util.handleNewInstance(Util.java:404)
>> > at com.mysql.jdbc.Util.getInstance(Util.java:387)
>> > at 
>> com.mysql.jdbc.SQLError.createSQLException(SQLError.java:939)
>> > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3878)
>> > at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3814)
>> >
>> > I was able to fix this to add this to my my.cnf:
>> >
>> > [mysqld]
>> > sql_mode = 
>> "STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
>> >
>> > Should we maybe set the SQL Mode as a connection parameter when 
>> connecting to the DB? This prevents users from having to set this manually 
>> in their MySQL configuration.
>> >
>> > Did somebody else run into this with MySQL 5.7?
>> >
>> > Thank you,
>> >
>> > Wido
>> >
>> > rohit.ya...@shapeblue.com
>> > www.shapeblue.com
>> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> > @shapeblue
>> >
>> >
>> >
>>
>>
>>
>>
>>
>> DISCLAIMER
>> ==
>> This e-mail may contain privileged and confidential information which is the 
>> property of Accelerite, a Persistent Systems business. It is intended only 
>> for the use of the individual or entity to which it is addressed. If you are 
>> not the intended recipient, you are not authorized to read, retain, copy, 
>> print, distribute or use this message. If you have received this 
>> communication in error, please notify the sender and delete all copies of 
>> this message. Accelerite, a Persistent Systems business does not accept any 
>> liability for virus infected mails.

Re: [PROPOSAL] Apache Cloudstack should join the gitbox experiment

[Erik Weber]

+1

On Wed, Apr 5, 2017 at 8:40 AM, Daan Hoogland  wrote:
> In the Apache foundation an experiment has been going on to host
> mirrors of Apache project on github with more write access then just
> to the mirror-bot. For those projects committers can merge on github
> and put labels on PRs. I want to propose that we join that project and
> intend to start a vote on it here, soon.
>
> questions, thoughts?
>
> --
> Daan

Re: Need help in getting CentOS 7 templates to run on Cloudstack 4.9 and VMWare

[Erik Weber]

On Mon, Apr 3, 2017 at 9:41 AM, Nux!  wrote:
> Syed,
>
> AFAIK the standard behaviour that is baked in the password script as well as 
> in the cloud-init Cloudstack meta source is to try whichever address provides 
> the DHCP.
>
> Can't wait to see config drive implemented so we can get rid of all these 
> head aches.

Or the 169.254.169.254 address implemented :-)

-- 
Erik

Re: [VOTE] Retirement of midonet plugin

[Erik Weber]

+1


Erik

On Tue, Mar 28, 2017 at 10:46 PM, Rafael Weingärtner
 wrote:
> Dear ACS fellows,
> We have discussed the retirement of Midonet plugin [*]. After quite some
> talk, we converged in a retirement process and it seems that we all agree
> that the Midonet plugin should be retired. So, to formalize things, we
> should vote Midonet retirement.
>
> All users and devs are welcome to vote here:
> [+1] I *do want to retire *the Midonet plugin
> [0] Whatever happens I am happy
> [-1] I *do not want to retire* the Midonet plugin
>
>
> [*] http://markmail.org/message/x6p3gnvqbbxcj6gs
>
> --
> Rafael Weingärtner

Re: [DISCUSS] Retirement of midonet plugin

[Erik Weber]

Sounds good :-)


Erik

man. 27. mar. 2017 kl. 18.03 skrev Will Stevens <wstev...@cloudops.com>:

> I think we are planning to do something like "at least 6 months" because of
> the irregularity of releases.  This gives us a date (from when the
> announcement was release becomes available) till the PR to remove gets
> merged.  That PR will then be included in the next release whenever it is.
> So if the "time" is 6 months, it could actually be closer to 9 months
> before it actually gets removes since the release may not be ready to be
> cut at 6 months.
>
> Does this make sense?  It gives us a way to have a date alert when a PR
> should be merged rather than trying to track which releases each
> decommissioned item is targeted for, which could mess up timing if there is
> some long release cycles as well as short ones...
>
> *Will STEVENS*
> Lead Developer
>
> <https://goo.gl/NYZ8KK>
>
> On Mon, Mar 27, 2017 at 9:46 AM, Daan Hoogland <
> daan.hoogl...@shapeblue.com>
> wrote:
>
> > I am against that
> > Strain on the community is not in releases but in time. We already
> > guarantee it is at least one minor
> >
> > On 27/03/17 15:24, "Erik Weber" <terbol...@gmail.com> wrote:
> >
> > Personally I would be in favour of using releases rather than months
> > as time unit.
> > Our release schedule is very unpredictable, and it's hard to foresee
> > how many releases we've rolled out in 6 months.
> >
> > Deprecate in the next (4.11?), remove a few releases later (4.13?).
> >
> > --
> > Erik
> >
> > On Sat, Mar 18, 2017 at 11:23 PM, Rafael Weingärtner
> > <rafaelweingart...@gmail.com> wrote:
> > > Sorry the delay guys, I have been swapped these last days.
> > >
> > > In summary, everybody that spoke is in favor of the plugin
> > retirement. I am
> > > assuming that people who did not present their opinion agree with
> > the ones
> > > presented here.
> > >
> > > The process to retire this plugin would be the following:
> > >
> > >1. Announce in our mailing lists the road map of retirement, a
> > data for
> > >the final removal should be defined and presented in this road
> > map;
> > >2. Create a Jira ticket to execute the plugin disabling (is this
> > >expression right?!), and of course, a PR to disable the build
> > until final
> > >deletion;
> > >3. Create a Jira ticket to execute the final removal of the
> > plugin. The
> > >removal should only happen when the defined date comes by;
> > >4. Wait patiently while time goes by….
> > >5. When the time comes, create the PR and execute the plugin
> > removal.
> > >
> > >
> > > What date would you guys prefer to execute the plugin removal? 3,
> 6,
> > or 12
> > > months from now?
> > > What do you think of this process? Am I missing something else?
> > >
> > >
> > >
> > > On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair <j...@greenqloud.com>
> > wrote:
> > >
> > >> Complete removal of the plugin was my solution to the problem of
> > the jar
> > >> file's dependencies. If it's not used or maintained, then it
> should
> > be
> > >> removed, in my opinion. Disabling it in the build is a good first
> > step.
> > >>
> > >> *Jeff Hair*
> > >> Technical Lead and Software Developer
> > >>
> > >> Tel: (+354) 415 0200
> > >> j...@greenqloud.com
> > >> www.greenqloud.com
> > >>
> > >> On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav <
> > rohit.ya...@shapeblue.com>
> > >> wrote:
> > >>
> > >> > +1 as others have noted
> > >> >
> > >> >
> > >> > Disable the plugin from the default build for next few releases
> > and
> > >> > eventually deprecate/remove the plugin from the codebase. The
> > roadmap can
> > >> > look something like:
> > >> >
> > >> > - Announce on the MLs that we're planning to do this, send a PR
> > and get
> > >> it
> > >> > accepted
> > >> >
> > >> > - During the release

Re: [DISCUSS] Retirement of midonet plugin

[Erik Weber]

Personally I would be in favour of using releases rather than months
as time unit.
Our release schedule is very unpredictable, and it's hard to foresee
how many releases we've rolled out in 6 months.

Deprecate in the next (4.11?), remove a few releases later (4.13?).

-- 
Erik

On Sat, Mar 18, 2017 at 11:23 PM, Rafael Weingärtner
 wrote:
> Sorry the delay guys, I have been swapped these last days.
>
> In summary, everybody that spoke is in favor of the plugin retirement. I am
> assuming that people who did not present their opinion agree with the ones
> presented here.
>
> The process to retire this plugin would be the following:
>
>1. Announce in our mailing lists the road map of retirement, a data for
>the final removal should be defined and presented in this road map;
>2. Create a Jira ticket to execute the plugin disabling (is this
>expression right?!), and of course, a PR to disable the build until final
>deletion;
>3. Create a Jira ticket to execute the final removal of the plugin. The
>removal should only happen when the defined date comes by;
>4. Wait patiently while time goes by….
>5. When the time comes, create the PR and execute the plugin removal.
>
>
> What date would you guys prefer to execute the plugin removal? 3, 6, or 12
> months from now?
> What do you think of this process? Am I missing something else?
>
>
>
> On Wed, Mar 15, 2017 at 9:13 AM, Jeff Hair  wrote:
>
>> Complete removal of the plugin was my solution to the problem of the jar
>> file's dependencies. If it's not used or maintained, then it should be
>> removed, in my opinion. Disabling it in the build is a good first step.
>>
>> *Jeff Hair*
>> Technical Lead and Software Developer
>>
>> Tel: (+354) 415 0200
>> j...@greenqloud.com
>> www.greenqloud.com
>>
>> On Wed, Mar 15, 2017 at 8:18 AM, Rohit Yadav 
>> wrote:
>>
>> > +1 as others have noted
>> >
>> >
>> > Disable the plugin from the default build for next few releases and
>> > eventually deprecate/remove the plugin from the codebase. The roadmap can
>> > look something like:
>> >
>> > - Announce on the MLs that we're planning to do this, send a PR and get
>> it
>> > accepted
>> >
>> > - During the release process RM should make this information available to
>> > everyone (including voting thread, would be nice to have a shortlog of
>> > major changes in the voting email?)
>> >
>> > - In the release notes and release announcement, note that midonet is no
>> > longer included in the default build and is planned to be deprecated
>> >
>> > - By end of the year, if we've no communication received deprecate and
>> > remove the plugin with an announcement
>> >
>> >
>> > I think this should be done with Midonet and any other plugins that are
>> > causing issues and are no longer maintained by anyway.
>> >
>> >
>> > Regards.
>> >
>> > 
>> > From: Sergey Levitskiy 
>> > Sent: 15 March 2017 07:00:51
>> > To: dev@cloudstack.apache.org
>> > Subject: Re: [DISCUSS] Retirement of midonet plugin
>> >
>> > I am for:
>> >  (i) disable the build for the plugin for the next 2 major release
>> > followed by
>> > (ii)  remove everything in ACS 4.12 if no one express regrets by then
>> >
>> >
>> >
>> >
>> > rohit.ya...@shapeblue.com
>> > www.shapeblue.com
>> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> > @shapeblue
>> >
>> >
>> >
>> >
>>
>
>
>
> --
> Rafael Weingärtner

Re: Welcoming Wido as the new ACS VP

[Erik Weber]

Thanks for all you hard work and dedication, Will!

Congratulations Wido! :-)

-- 
Erik
tor. 16. mar. 2017 kl. 18.00 skrev Will Stevens :

> Hello Everyone,
> It has been a pleasure working with you as the ACS VP over the past year.
> I would like to say Thank You to everyone who has supported me in this role
> and have supported the project as a whole.
>
> It is my pleasure to announce that Wido den Hollander has been voted in to
> replace me as the Apache Cloudstack VP in our annual VP rotation.  Wido has
> a long history with the project and we are happy welcome him into this new
> role.
>
> Be sure to join us at CCC in Miami [1] so we can initiate him correctly
> over many beers.  :)
>
> Cheers,
>
> *Will Stevens*
>
> ​[1] http://us.cloudstackcollab.org/​
>

Re: midonet-client and Guava dependency conflict

[Erik Weber]

On Mon, Mar 13, 2017 at 7:45 PM, Rafael Weingärtner
 wrote:
> I got a reply from Midonet community; they said that midonet-client was
> incorporated by midonet-cluster (
> https://github.com/midonet/midonet/tree/staging/v5.4/midonet-cluster).
>
>
> So, if anyone wants to invest energy on this, it might be a good idea to
> upgrade the dependency. Moreover, I start to question the compatibility of
> the current client we are using, with the mido-net server side that might
> be deployed by users. Will this partial integration that we have work?


Just as important to ask: "Has it ever worked?"
Do we know anyone who use, or have used, this integration?

-- 
Erik

Re: Modern template hosting

[Erik Weber]

Feel free to do it, I wouldn't know where to begin to ask such a
question tbh :-)

-- 
Erik

On Sat, Mar 4, 2017 at 12:51 AM, Will Stevens <williamstev...@gmail.com> wrote:
> Erik, yes I think this is the right approach and covers the main problem
> case. I can start the conversation with infra unless you would like to. Let
> me know.
>
> We did get some statistics from the other mirrors last year, but I don't
> think we ever had visibility into the cloud.com repository traffic.
>
> On Mar 3, 2017 6:42 PM, "Erik Weber" <terbol...@gmail.com> wrote:
>
> It'll most likely only be an issue in the case where a mirror goes
> down without any immediate chance of getting back up, right?
> Could we check with ASF Infra beforehand if such case is OK to warrant
> an urgent Jira ticket to resolve - should it happen?
>
> We can document all the mirrors and provide the howtos for manually
> downloading and seeding the image as a backup.
>
> Do we have any traffic statistics for the current solution, or is that
> not available at S3?
>
> --
> Erik
>
> On Sat, Mar 4, 2017 at 12:28 AM, Will Stevens <williamstev...@gmail.com>
> wrote:
>> Yes Erik, I agree with you. The only thing that could add complexity in
>> this is the fact that we don't control the domain, the ASF does (from what
>> I understand).  Do we expect this to be managed by ASF infra or would
> there
>> be another way? Ideally the domain is community controlled so we can adapt
>> in case of change without long delays.
>>
>> I am 100% in agreement that this is the shortest path and likely to be
> good
>> enough.
>>
>> On Mar 3, 2017 6:19 PM, "Erik Weber" <terbol...@gmail.com> wrote:
>>
>> IMHO; implement it as simple as possible, use DNS RR and assume/expect
>> mirror hosts to use the same path.
>>
>>
>> Yes I know; DNS RR isn't bulletproof, but as already mentioned in this
>> thread - mirrors rarely go down and they aren't used all that often
>> (primarily seeding).
>> We can keep a low TTL on the record so that we're able to remove a
>> mirror that goes down for a significant period of time (more than
>> hours).
>>
>> And yes I know, some operators might find it a burden having to set up
>> a new vhost with another document root, but tbh if they don't care
>> enough to do it we'll manage without that mirror.
>>
>> --
>> Erik
>>
>> On Sat, Mar 4, 2017 at 12:09 AM, Will Stevens <williamstev...@gmail.com>
>> wrote:
>>> I agree with Paul. Look at the list of things they have to
>>> learn/master/care about. We don't want to add to that list, we want to
>>> remove from that list. Make the project/product more accessible. Reduce
>> the
>>> barrier to entry...
>>>
>>> On Mar 3, 2017 5:50 PM, "Chiradeep Vittal" <chirade...@gmail.com> wrote:
>>>
>>>> Seriously?
>>>> apt-get install apache2
>>>>
>>>> To install CloudStack, they need to know
>>>> - DB installation, perhaps some SQL
>>>> - VLAN configuration on their switches
>>>> - Ins-and-outs between port forwarding, static ips,
>>>> - NFS
>>>> - package management
>>>> - VHDs, qcow2. vmdk
>>>> - hyperviosrs
>>>> - and on and on.
>>>>
>>>> If they can figure all that out and not figure out a web server, they
> can
>>>> always come to the mailing list.
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Mar 3, 2017 at 1:45 PM, Paul Angus <paul.an...@shapeblue.com>
>>>> wrote:
>>>>
>>>> > The issue is not with supporting highly experienced cloud operators.
> It
>>>> is
>>>> > an issue for new users and other 'relatively' inexperienced operators.
>>>> >
>>>> > I have helped enough newbies and cloud operators who have been running
>>>> > their cloud for a while to know that the barriers to entry are too
> high
>>>> as
>>>> > they are. And telling anyone that they need to create a web server so
>>>> that
>>>> > they can add their initial template to get started or in order to
>> create
>>>> a
>>>> > new zone, just isn't going to fly.
>>>> >
>>>> > I'm a huge advocate of the 'download.cloudstack.org' endpoint which
> the
>>>> > community can add/remove mirrors to or from for system VMs or built-in
>>>> > templates.  Can the same system be use

Re: Modern template hosting

[Erik Weber]

It'll most likely only be an issue in the case where a mirror goes
down without any immediate chance of getting back up, right?
Could we check with ASF Infra beforehand if such case is OK to warrant
an urgent Jira ticket to resolve - should it happen?

We can document all the mirrors and provide the howtos for manually
downloading and seeding the image as a backup.

Do we have any traffic statistics for the current solution, or is that
not available at S3?

-- 
Erik

On Sat, Mar 4, 2017 at 12:28 AM, Will Stevens <williamstev...@gmail.com> wrote:
> Yes Erik, I agree with you. The only thing that could add complexity in
> this is the fact that we don't control the domain, the ASF does (from what
> I understand).  Do we expect this to be managed by ASF infra or would there
> be another way? Ideally the domain is community controlled so we can adapt
> in case of change without long delays.
>
> I am 100% in agreement that this is the shortest path and likely to be good
> enough.
>
> On Mar 3, 2017 6:19 PM, "Erik Weber" <terbol...@gmail.com> wrote:
>
> IMHO; implement it as simple as possible, use DNS RR and assume/expect
> mirror hosts to use the same path.
>
>
> Yes I know; DNS RR isn't bulletproof, but as already mentioned in this
> thread - mirrors rarely go down and they aren't used all that often
> (primarily seeding).
> We can keep a low TTL on the record so that we're able to remove a
> mirror that goes down for a significant period of time (more than
> hours).
>
> And yes I know, some operators might find it a burden having to set up
> a new vhost with another document root, but tbh if they don't care
> enough to do it we'll manage without that mirror.
>
> --
> Erik
>
> On Sat, Mar 4, 2017 at 12:09 AM, Will Stevens <williamstev...@gmail.com>
> wrote:
>> I agree with Paul. Look at the list of things they have to
>> learn/master/care about. We don't want to add to that list, we want to
>> remove from that list. Make the project/product more accessible. Reduce
> the
>> barrier to entry...
>>
>> On Mar 3, 2017 5:50 PM, "Chiradeep Vittal" <chirade...@gmail.com> wrote:
>>
>>> Seriously?
>>> apt-get install apache2
>>>
>>> To install CloudStack, they need to know
>>> - DB installation, perhaps some SQL
>>> - VLAN configuration on their switches
>>> - Ins-and-outs between port forwarding, static ips,
>>> - NFS
>>> - package management
>>> - VHDs, qcow2. vmdk
>>> - hyperviosrs
>>> - and on and on.
>>>
>>> If they can figure all that out and not figure out a web server, they can
>>> always come to the mailing list.
>>>
>>>
>>>
>>>
>>> On Fri, Mar 3, 2017 at 1:45 PM, Paul Angus <paul.an...@shapeblue.com>
>>> wrote:
>>>
>>> > The issue is not with supporting highly experienced cloud operators. It
>>> is
>>> > an issue for new users and other 'relatively' inexperienced operators.
>>> >
>>> > I have helped enough newbies and cloud operators who have been running
>>> > their cloud for a while to know that the barriers to entry are too high
>>> as
>>> > they are. And telling anyone that they need to create a web server so
>>> that
>>> > they can add their initial template to get started or in order to
> create
>>> a
>>> > new zone, just isn't going to fly.
>>> >
>>> > I'm a huge advocate of the 'download.cloudstack.org' endpoint which the
>>> > community can add/remove mirrors to or from for system VMs or built-in
>>> > templates.  Can the same system be used for binary repos ? although
> there
>>> > is an added complication of redist vs no-redist there...
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > paul.an...@shapeblue.com
>>> > www.shapeblue.com
>>> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>>> > @shapeblue
>>> >
>>> >
>>> >
>>> >
>>> > -Original Message-
>>> > From: Chiradeep Vittal [mailto:chirade...@gmail.com]
>>> > Sent: 03 March 2017 18:28
>>> > To: dev <dev@cloudstack.apache.org>
>>> > Subject: Re: Modern template hosting
>>> >
>>> > I do feel like this is early optimization. Mirrors rarely fail. I'd
>>> expect
>>> > a single web server hosted on Apache Infra without any monitors to fail
>>> > more often than a mirror. We alrea

Re: Modern template hosting

[Erik Weber]

IMHO; implement it as simple as possible, use DNS RR and assume/expect
mirror hosts to use the same path.


Yes I know; DNS RR isn't bulletproof, but as already mentioned in this
thread - mirrors rarely go down and they aren't used all that often
(primarily seeding).
We can keep a low TTL on the record so that we're able to remove a
mirror that goes down for a significant period of time (more than
hours).

And yes I know, some operators might find it a burden having to set up
a new vhost with another document root, but tbh if they don't care
enough to do it we'll manage without that mirror.

-- 
Erik

On Sat, Mar 4, 2017 at 12:09 AM, Will Stevens  wrote:
> I agree with Paul. Look at the list of things they have to
> learn/master/care about. We don't want to add to that list, we want to
> remove from that list. Make the project/product more accessible. Reduce the
> barrier to entry...
>
> On Mar 3, 2017 5:50 PM, "Chiradeep Vittal"  wrote:
>
>> Seriously?
>> apt-get install apache2
>>
>> To install CloudStack, they need to know
>> - DB installation, perhaps some SQL
>> - VLAN configuration on their switches
>> - Ins-and-outs between port forwarding, static ips,
>> - NFS
>> - package management
>> - VHDs, qcow2. vmdk
>> - hyperviosrs
>> - and on and on.
>>
>> If they can figure all that out and not figure out a web server, they can
>> always come to the mailing list.
>>
>>
>>
>>
>> On Fri, Mar 3, 2017 at 1:45 PM, Paul Angus 
>> wrote:
>>
>> > The issue is not with supporting highly experienced cloud operators. It
>> is
>> > an issue for new users and other 'relatively' inexperienced operators.
>> >
>> > I have helped enough newbies and cloud operators who have been running
>> > their cloud for a while to know that the barriers to entry are too high
>> as
>> > they are. And telling anyone that they need to create a web server so
>> that
>> > they can add their initial template to get started or in order to create
>> a
>> > new zone, just isn't going to fly.
>> >
>> > I'm a huge advocate of the 'download.cloudstack.org' endpoint which the
>> > community can add/remove mirrors to or from for system VMs or built-in
>> > templates.  Can the same system be used for binary repos ? although there
>> > is an added complication of redist vs no-redist there...
>> >
>> >
>> >
>> >
>> >
>> >
>> > paul.an...@shapeblue.com
>> > www.shapeblue.com
>> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> > @shapeblue
>> >
>> >
>> >
>> >
>> > -Original Message-
>> > From: Chiradeep Vittal [mailto:chirade...@gmail.com]
>> > Sent: 03 March 2017 18:28
>> > To: dev 
>> > Subject: Re: Modern template hosting
>> >
>> > I do feel like this is early optimization. Mirrors rarely fail. I'd
>> expect
>> > a single web server hosted on Apache Infra without any monitors to fail
>> > more often than a mirror. We already expect Wido's systemvm repository to
>> > be up all the time. And it has been. Similarly, I don't believe Nux's
>> > repository has ever been down. And if Accelerite wants to host on S3,
>> that
>> > one is pretty solid as well.
>> >
>> > This is an infrequent operation in a cloud. After the cloud is installed,
>> > the download servers are only needed for a new zone. If we trust the user
>> > to run a cloud, surely he/she can run a web server to serve some built-in
>> > templates. And if her cloud is successful, she needs to figure out how to
>> > host her templates anyway and not rely on 3rd parties.
>> >
>> >
>> > On Fri, Mar 3, 2017 at 9:31 AM, Will Stevens 
>> > wrote:
>> >
>> > > 1) If the legacy implementations do not support redirects, that does
>> > > cause a problem.  A potential solution in that case is to have the web
>> > > server actually proxy the download, but that is not ideal and I would
>> > > like to avoid it if possible.  Thanks for bringing that up Chiradeep.
>> > >
>> > > 2) I think we need to have a single URL which people can target.  Once
>> > > they make the switch to the new URL, we want the implementation to be
>> > > able to handle mirror failures without affecting the end client.  We
>> > > want to avoid the situation where an ACS user will ever have to change
>> > > this URL more than once.  Mirror failures SHOULD NOT affect the ACS
>> > > users assuming there is still at least one mirror who can serve the
>> > requested resource.
>> > >
>> > > These are obviously my personal opinions and others will probably have
>> > > differing opinions.
>> > >
>> > > *Will STEVENS*
>> > > Lead Developer
>> > >
>> > > 
>> > >
>> > > On Fri, Mar 3, 2017 at 12:23 PM, Chiradeep Vittal
>> > > 
>> > > wrote:
>> > >
>> > > > 1. If you are targeting legacy installations, they are not able to
>> > > > follow redirects. The line of code that added this capability was
>> > > > added on
>> > > 11/16.
>> > > > 2. If you trust the users to 

Re: Modern template hosting

[Erik Weber]

On Tue, Feb 28, 2017 at 8:59 AM, Daan Hoogland  wrote:
> On Tue, Feb 28, 2017 at 2:40 AM, Pierre-Luc Dion  wrote:
>> For our systemvm templates, can we just change the URL for somthing like
>> cloudstack.apache.org/systemvm/... ?
>
> I agree,
> is there any change we can host a domain for this at apache, if we
> can't keep downloads.cloud.com then maybe downloads.cloudstack.com. To
> many people are used to this this way of working and a patch for a
> name change is the easiest. Devising a new mechanism is nice but a
> different job, is it?

packages.apache.org exists.

Has been discussed before in a thread called 'Package Repositories'.

One thing that should be focused on is that if we go the ASF hosted
route, we should be able to update the content without involving ASF
Infra team.

-- 
Erik

Slack archive

[Erik Weber]

Hi all,

I recently wanted to link some content from our Slack channel but
couldn't find a way, would it make sense to use something like
http://slackarchive.io/?

I do know that mail is the only accepted communication for decisions
etc, but having our slack history publicly available makes it easier
to refer to and for others to find.

-- 
Erik

Re: re-introduction

[Erik Weber]

On Wed, Feb 1, 2017 at 9:26 AM, Daan Hoogland
 wrote:
> Hello,
>
>
> My name is Daan Hoogland. I've been mostly out of the community since May 
> last year. I am now back through the generous sponsorship of my new employer 
> and will be working (mostly) as developer on cloudstack.
>

Congratulations with the new job, it's good to see you back Daan! :-)

Out of curiousity, did your new employer demand that you change your
name to 'Dan'? :-p

-- 
Erik

Re: [PROPOSAL] add native container orchestration service

[Erik Weber]

On Fri, Jan 27, 2017 at 7:20 AM, Murali Reddy  wrote:
> All,
>
> I would like propose native functionality into CloudStack to provide a 
> container service through which users out-of-the box can use to launch 
> container based application. Idea is to support ability to orchestrate the 
> resources and automate aspects of setting up container orchestrator through 
> CloudStack. Public IAAS service providers AWS with its ECS [1] and google 
> with GKE [2] already provides ability container applications.  Competitive 
> cloud orchestration platforms already have native support for container 
> service. Users of CloudStack both as public cloud providers and users with 
> private clouds will benefit with such functionality.
>
> While container orchestrator of user choice can be provisioned on top of 
> CloudStack (with out CloudStack being involved) with tools like TerraForm[3], 
> Ansible[4] etc, advantage of having native orchestration is giving user a 
> nice cohesive integration. This proposal would like add a notion of first 
> class CloudStack entity called container cluster which can be used to 
> provision resources, scale up, scale down, start and stop the cluster of VM’s 
> on which containerised applications can be run. For actual container 
> orchestration we will still need container orchestrator like docker swarm, 
> marathon, kubernetes, but CloudStack container service can automate setting 
> up of control place automatically.
>

To be honest I'm torn on this one.

Containers are a rapid changing thing, and while docker swam,
kubernetes, rancher or whatnot is popular today, they might not be
tomorrow.
They might use CoreOS today, but might not tomorrow.

We have a rather poor track record of staying up to date with new
features/versions, and adding a feature that is so rapidly changing
is, I fear, going to be hard to maintain.
Want an example, look at xenserver. It is one of the most used
hypervisors we support, yet it took 6 months or so for us to support
the latest release.
Or IPv6...

I don't mean to bash at maintainers/implementers of those features, I
appreciate all the work being done in every aspect, but I believe we
should be realistic and realize that we have issues with keeping stuff
up to date.

I'd say focus on making sure other tools can do their job well against
CloudStack (kops, rancher, ++), but that does not mean I will -1 the
idea if anyone really wants to go through with it.

-- 
Erik

Re: Dedicated IP range for SSVM/CPVM

[Erik Weber]

Hi Nitin,

There are legit reasons for separating VR public pool from SSVM and CPVM.

For instance if you run a private cloud and don't want to have your
cpvm/ssvm publically available, but still want to have the VRs accessible

Erik

tir. 17. jan. 2017 kl. 05.37 skrev Nitin Kumar Maharana <
nitinkumar.mahar...@accelerite.com>:

> Hi Rene,
>
>
>
> The default pool, which means are you mentioning the public IP range?
>
>
>
> If it is a public IP range, user VMs won’t be consuming any IP from there.
>
> Only system VMs(CPVM/SSVM/VR) will be consuming. VRs will be providing
> public access to the user VMs.
>
>
>
>
>
> Thanks,
>
> Nitin
>
> > On 16-Jan-2017, at 8:56 PM, Rene Moser  wrote:
>
> >
>
> > Hi
>
> >
>
> > We would like to make a change proposal for SSVM/CPVM.
>
> >
>
> > Currently, the SSVM/CPVM get an IP from the "default" pool of
>
> > vlaniprange which is the from the account "system"
>
> >
>
> >
>
> >  "vlaniprange": [
>
> >{
>
> >  "account": "system",
>
> >  "domain": "ROOT",
>
> >  "endip": "10.101.0.250",
>
> >  "forvirtualnetwork": true,
>
> >  "gateway": "10.101.0.1",
>
> >  "netmask": "255.255.255.0",
>
> >  "startip": "10.101.0.11",
>
> >  ...
>
> >
>
> >},
>
> >
>
> >
>
> >  "systemvm": [
>
> >{
>
> >  "activeviewersessions": 0,
>
> >  "gateway": "10.101.0.1",
>
> >  "hypervisor": "VMware",
>
> >  "id": "d9a8abe5-b1e0-47d6-8f39-01b48ff1e0fa",
>
> >  "name": "v-5877-VM",
>
> >  "privatenetmask": "255.255.255.0",
>
> >  "publicip": "10.101.0.113",
>
> >  "publicnetmask": "255.255.255.0",
>
> >  "state": "Running",
>
> >  ...
>
> >},
>
> >
>
> >
>
> > For security considerations we would like to define a dedicated IP range
>
> > for SSVM/CPVM, which, preferably, should not have any relation to the
>
> > default pool range.
>
> >
>
> > The default pool range should be used for userVMs only. To indicate the
>
> > use I propolse 2 new flags, which only considered for "account=system"
>
> > and indicate if the range can be used for userVMs or/and systemVMs.
>
> >
>
> > For backwards compatibility this would be the default
>
> >
>
> > "foruservms": true,
>
> > "forsystemvms": true,
>
> >
>
> >
>
> > to have a separate range for UserVMs/SystemVMs, it would look like
>
> >
>
> >
>
> >  "vlaniprange": [
>
> >{
>
> >  "account": "system",
>
> >  "domain": "ROOT",
>
> >  "foruservms": true,
>
> >  "forsystemvms": false,
>
> >  "endip": "192.160.123.250",
>
> >  "forvirtualnetwork": true,
>
> >  "gateway": "192.160.123.1",
>
> >  "netmask": "255.255.255.0",
>
> >  "startip": "192.160.123.11",
>
> >  ...
>
> >
>
> >},
>
> >
>
> >  "vlaniprange": [
>
> >{
>
> >  "account": "system",
>
> >  "domain": "ROOT",
>
> >  "foruservms": false,
>
> >  "forsystemvms": true,
>
> >  "endip": "10.101.0.250",
>
> >  "forvirtualnetwork": true,
>
> >  "gateway": "10.101.0.1",
>
> >  "netmask": "255.255.255.0",
>
> >  "startip": "10.101.0.11",
>
> >  ...
>
> >
>
> >},
>
> >
>
> >
>
> > Does anyone has see any conflicts with this proposal?
>
> >
>
> > Regards
>
> > René
>
> >
>
>
>
>
>
>
>
>
>
> DISCLAIMER
>
> ==
>
> This e-mail may contain privileged and confidential information which is
> the property of Accelerite, a Persistent Systems business. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Accelerite, a Persistent Systems business does not accept any
> liability for virus infected mails.
>
>

Re: Welcoming Simon Weller & Paul Angus to the PMC

[Erik Weber]

Congratulations both of you, well deserved :-)

-- 
Erik
fre. 13. jan. 2017 kl. 17.30 skrev Will Stevens :

> Join me in welcoming Simon Weller and Paul Angus to the Apache CloudStack
>
> PMC.  Both have been dedicated members of the community and it is with
>
> great pleasure that we welcome them to the PMC.
>
>
>
> Next time you see either of them, buy them a drink.  :)
>
>
>
> Welcome guys...
>
>

Re: [GitHub] cloudstack issue #1888: CLOUDSTACK-9710: Switch to JRE1.8

[Erik Weber]

@milamberspace I don't agree. Ubuntu 14.04 isn't EOL for another two years,
rhel6 even longer.

But users should be given proper directions as to how they can update Java.

And we need to fix systemd/Ubuntu 16.04 support


Erik


tir. 10. jan. 2017 kl. 08.24 skrev milamberspace :

> Github user milamberspace commented on the issue:
>
>
>
> https://github.com/apache/cloudstack/pull/1888
>
>
>
> I'm not agree with this PR because it's break the support of Ubuntu
> 14.04 with the default JRE (java7) provide by Ubuntu and the support of
> Ubuntu 16.04 (java8) the is currently partial for the cloudstack-management.
>
> If you don't know that you need to install a Java 8 via a PPA or
> manually, you cannot run CS 4.10 on Ubuntu 14.04...
>
> I would not block the PR, but I think at least the installation guide
> must be update to mention theses points for Ubuntu 14 (need a PPA or manual
> installation of Java8) and 16 (no support for management)
>
>
>
> (Or remove the Ubuntu support entirely?)
>
>
>
>
>
> ---
>
> If your project is set up for it, you can reply to this email and have your
>
> reply appear on GitHub as well. If your project does not have this feature
>
> enabled and wishes so, or if the feature is enabled but not working, please
>
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
>
> with INFRA.
>
> ---
>
>

Re: [DISCUSS] Moving for JDK8, this time for real!

[Erik Weber]

Yes, I understood that your proposal didn't change the debian version, I
suggested that it should do, since when we do update the debian version we
have to test everything over again anyway.

That said, I won't oppose your proposal, I'm +1 of upgrading to jdk 1.8

-- 
Erik


tor. 5. jan. 2017 kl. 15.46 skrev Rohit Yadav <rohit.ya...@shapeblue.com>:

> Erik,
>
>
>
>
>
> The PR I've proposed does not change the base Debian distro, it's still
> Debian 7 (wheezy) and not Jessie. I would like to avoid making too many
> changes in the same PR, especially moving to Jessie which won't be straight
> forward as it would introduce several changes, major package version
> changes, systemd usage etc.
>
>
>
>
>
> What I'm proposing is simple -- moving to jdk8 for building CloudStack
> (this works flawlessly now), and using jre-8 on systemvm template.
>
>
>
>
>
> Regards.
>
>
>
> 
>
> From: Erik Weber <terbol...@gmail.com>
>
> Sent: 05 January 2017 18:25:38
>
> To: dev
>
> Subject: Re: [DISCUSS] Moving for JDK8, this time for real!
>
>
>
>
>
> rohit.ya...@shapeblue.com
>
> www.shapeblue.com
>
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>
> @shapeblue
>
>
>
>
>
>
>
> On Thu, Jan 5, 2017 at 1:11 PM, Rohit Yadav <rohit.ya...@shapeblue.com>
> wrote:
>
> > All,
>
> >
>
> >
>
> > I've been working on moving our codebase and runtime-environment to Java
> 8, and since this is a much needed big change I want your feedback and
> blessings on:
>
> >
>
> > https://github.com/apache/cloudstack/pull/1888
>
> >
>
> >
>
> > In order for this to work, I had to make changes in our veewee-based
> systemvmtemplate build scripts to install a third party opensource
> openjdk-8-jre distribution (xulu-8 is a openjdk-8 distribution from Azul,
> please review and advise wrt their terms of usage here:
> http://www.azul.com/products/zulu/zulu-terms-of-use/), since
>
> >
>
> > Debian 7 (wheezy) repositories don't have openjdk-8-jre and installing
> openjdk-8-jre from testing/sid updates several system packages such as libc
> that I wanted to avoid. Accepting this change on master/4.10 would require
> us to have a new systemvmtemplate for 4.10+ releases.
>
> >
>
> >
>
> > With these changes, I've ran smoke tests across KVM, VMware and
> XenServer in the following PR and all of the tests are passing (ignoring
> known intermittent failures in vpc/rvr related tests).
>
> >
>
> >
>
> > Thoughts, feedback?
>
>
>
> Wheezy has roughly 1 year left (until May 2018) before it is EOL.
>
> Since 4.10 is not LTS and the fact that both Java8 and Debian Jessie
>
> could have hard to find issues I would suggest that you update the
>
> systemvm now, and work through bugs and quirks throught the 4.10.x
>
> version.
>
> I believe there are other changes, like strongswan, as well that could
>
> make 4.10 a potentially unstable version?
>
>
>
> --
>
> Erik
>
>

Re: [DISCUSS] Moving for JDK8, this time for real!

[Erik Weber]

On Thu, Jan 5, 2017 at 1:11 PM, Rohit Yadav  wrote:
> All,
>
>
> I've been working on moving our codebase and runtime-environment to Java 8, 
> and since this is a much needed big change I want your feedback and blessings 
> on:
>
> https://github.com/apache/cloudstack/pull/1888
>
>
> In order for this to work, I had to make changes in our veewee-based 
> systemvmtemplate build scripts to install a third party opensource 
> openjdk-8-jre distribution (xulu-8 is a openjdk-8 distribution from Azul, 
> please review and advise wrt their terms of usage here: 
> http://www.azul.com/products/zulu/zulu-terms-of-use/), since
>
> Debian 7 (wheezy) repositories don't have openjdk-8-jre and installing 
> openjdk-8-jre from testing/sid updates several system packages such as libc 
> that I wanted to avoid. Accepting this change on master/4.10 would require us 
> to have a new systemvmtemplate for 4.10+ releases.
>
>
> With these changes, I've ran smoke tests across KVM, VMware and XenServer in 
> the following PR and all of the tests are passing (ignoring known 
> intermittent failures in vpc/rvr related tests).
>
>
> Thoughts, feedback?

Wheezy has roughly 1 year left (until May 2018) before it is EOL.
Since 4.10 is not LTS and the fact that both Java8 and Debian Jessie
could have hard to find issues I would suggest that you update the
systemvm now, and work through bugs and quirks throught the 4.10.x
version.
I believe there are other changes, like strongswan, as well that could
make 4.10 a potentially unstable version?

-- 
Erik

Re: [DISCUSS][FUTURE] Move to JDK1.8 and support JRE1.8

[Erik Weber]

I am +1 to removing code without maintainers, as long as it's not a core
feature.

Erik


tir. 27. des. 2016 kl. 08.23 skrev Rohit Yadav :

> All,
>
>
>
>
>
> Java7 has eol-ed, it's about time to move to Java8 for both codebase and
> runtime [1].
>
>
>
>
>
> An experimental PR [2] shows that moving to Java8 is fairly straight
> forward. The only component that is failing is F5 network plugin, which
> lacks authors/maintainers as this issue has been previously raised on dev@
> [3].
>
>
>
>
>
> In order to move to JDK8, we'll need to take hard decisions to
> comment/exclude plugins such as F5 from the default build profiles that may
> not get fixes and improvements from their authors/maintainers. Thoughts,
> comments?
>
>
>
>
>
> [1] https://issues.apache.org/jira/browse/CLOUDSTACK-9710
>
>
>
> 
>
>
>
> [2] https://github.com/apache/cloudstack/pull/1864
>
>
>
> [3] http://markmail.org/message/ggx5ycoezyr2ywel
>
>
>
>
>
> Regards.
>
>
>
> rohit.ya...@shapeblue.com
>
> www.shapeblue.com
>
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>
> @shapeblue
>
>
>
>
>
>
>
>

Re: Apache Cloudstack 4.8 and XenServer 7

[Erik Weber]

On Fri, Jul 29, 2016 at 7:53 AM, Marty Godsey  wrote:

> Should there be any issues running XS7 with CS 4.8?
>
>
Most likely, yes. There are some major changes with the OS in XS7 that is
likely to break.

I think there are some efforts from Accelerite to fix it, but I don't know
the status.

-- 
Erik

Re: Few tables in cloudstack schema use MyISAM engine

[Erik Weber]

Just nit-picking, but MyISAM allows replication as well.

I'm +1 to the change.

-- 
Erik

On Wed, Aug 31, 2016 at 5:37 AM, Abhinandan Prateek <
abhinandan.prat...@shapeblue.com> wrote:

> Thanks, Koushik.
>
> Have created a PR to make the engine type consistent for all tables.
> InnoDB allows for replication, that is all the more reason that we change
> the engine type of these few tables to InnoDB.
>
> Regards,
> -abhi
>
> PR: https://github.com/apache/cloudstack/pull/1667
>
>
> From: Koushik Das >
> Date: Tuesday, 30 August 2016 at 5:25 PM
> To: Abhinandan Prateek >, "dev@cloudstack.apache.org dev@cloudstack.apache.org>" >
> Cc: Rajani Karuturi >, Raja
> Pullela >
> Subject: Re: Few tables in cloudstack schema use MyISAM engine
>
> I cannot think of any. Most probably in all cases the engine was not
> explicitly specified and the default got used. As per below default was
> myisam before mysql 5.5.5.
> https://dev.mysql.com/doc/refman/5.5/en/storage-engine-setting.html
>
> Thanks,
> Koushik
> From: Abhinandan Prateek >
> Date: Tuesday, 30 August 2016 at 4:23 PM
> To: "dev@cloudstack.apache.org" <
> dev@cloudstack.apache.org>
> Cc: Rajani Karuturi >, Raja
> Pullela >,
> Koushik Das  >>
> Subject: Few tables in cloudstack schema use MyISAM engine
>
> Hi,
>
>Was there any specific reason that some tables in cloudstack schema use
> MyISAM engine.
> I know of “ quota_account” that I created and put in the diff table type
> unknowingly. I assume such is the case with other such tables –
> load_balancer_cert_map, monitoring_services, nic_ip_alias, sslcerts.
>
> Filed a ticket here to get this fixed or reason for not fixing it captured.
>
> Regards,
> -abhi
>
> abhinandan.prat...@shapeblue.com
> www.shapeblue.com
> @shapeblue
>
>
>
>
> DISCLAIMER == This e-mail may contain privileged and confidential
> information which is the property of Accelerite, a Persistent Systems
> business. It is intended only for the use of the individual or entity to
> which it is addressed. If you are not the intended recipient, you are not
> authorized to read, retain, copy, print, distribute or use this message. If
> you have received this communication in error, please notify the sender and
> delete all copies of this message. Accelerite, a Persistent Systems
> business does not accept any liability for virus infected mails.
>
> abhinandan.prat...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
>

Re: CCC Brasil

[Erik Weber]

On the web page, the date is updated to Sept 29-30, is this correct? If so,
it should be advertised.

-- 
Erik

On Tue, Aug 16, 2016 at 5:32 PM, Marco Sinhoreli <
marco.sinhor...@shapeblue.com> wrote:

> All,
>
>
>
> I am very sorry to have to say that we have had to postpone the upcoming
> CCC conference in Sao Paluo.
>
>
>
> Over the past few months we have been working very hard with an events
> organiser to try and get the conference off the ground. Conferences are
> very expensive to stage here in Brasil so we were relying on a number of
> large sponsors. Unfortunately , we are unable to get enough sponsors for
> the proposed September dates due to multiple schedule conflicts.
>
>
>
> I appreciate that this is very late notice. Up until this week we were
> hoping to have enough sponsorship to run the event but we were also
> conscious that this would have left only a little time for CFP and people
> to make travel arrangements. We have therefore decided to cancel the
> September conference. We’re working with local sponsors and our venue hosts
> to try and find some dates either later in 2016 or in 2017.
>
>
> Best regards,
>
>
>
> *Marco Sinhoreli*
>
> Managing Consultant
>
> marco.sinhor...@shapeblue.com
>
> mobile: +55 21 98276 3636
>
>
>
> Praia de Botafogo 501, bloco 1 - sala 101 – Botafogo
>
> Rio de Janeiro, RJ - Brazil - CEP 22250-040
>
> office: + 55 21 2586 6390 | fax: +55 21 2586 6002
>
> http://www.shapeblue.com/ | twitter: @shapeblue
>

Re: 4.10.0 release

[Erik Weber]

A newline or two wouldn't hurt, this is pretty hard to read tbh.

-- 
Erik

On Wed, Aug 3, 2016 at 9:27 AM, Rajani Karuturi  wrote:

> Hi All,These are the proposed dates for 4.10 release (copied from
> another thread by John Burwell)* Development (master open to
> features and defect fixes): 1 August 2016 - 11 September 2016*
> Testing: 12 - 18 September 2016* RC Voting: 19 - 25 September
> 2016* Release: 26 September 2016
> master is open for 4.10.0. It still means that only PRs will be
> merged and they will be merged only by RMs ( For 4.10.0, its John
> Burwell and Rajani Karuturi)Every PR should have a JIRA bug ID, 1
> code review and 1 test review.It would help in reviewing if the
> contributor could put information about the feature/bug and how
> its tested.Also, please rebase any pending PRs you have to the
> latest master or the 4.9 release branch.
> Finally, anyone in the community can review and test PRs. We
> currently have huge backlog. We need everyones help in getting
> them merged(especially running the tests)Looking forward for your
> help in merging PRs. Happy PR bashing!!
> Thanks,~ Rajanihttp://cloudplatform.accelerite.com/

Re: XenServer 7

[Erik Weber]

For clarity, is the correct to assume that you'll upstream this to ACS?

-- 
Erik

On Wed, Jul 13, 2016 at 10:22 AM, Raja Pullela <raja.pull...@accelerite.com>
wrote:

> Hi Erik
>
> BVT – build verification tests or smoke tests are the test automation
> scripts we have in cloudstack repo.
> We will run these tests first and see if anything is broken.  For any
> failures, we will create bugs.
> IMO, since 4.9 is out, the next version should have the support for XS 7.0.
> Are you look at anything specific feature/functionality in XS 7.0?  can
> you share what it is ?
>
> Best,
> Raja Pullela
> Senior Manager, Product Development
> Accelerate, www.accelerite.com,@accelerite
> 2055, Laurelwood Road,  Santa Clara, CA 95054, USA
> Phone: 1-408-216-7010
>
> On 7/13/16, 11:58 AM, "Erik Weber" <terbol...@gmail.com> wrote:
>
> Would you mind elaborating a bit what that means?
>
> Does it mean that you have already done some fixing to get it to work and
> will start testing it?
> Or that you plan on testing it now, to figure out what needs fixing?
> Or something else?
>
> I'm trying to figure out when I can expect to use ACS (or a commercial
> distribution) with XS7
>
> --
> Erik
>
> On Tue, Jul 12, 2016 at 6:01 PM, Raja Pullela <raja.pull...@accelerite.com
> >
> wrote:
>
> > we are going to use XS7 for our testing and will be running BVTs/smoke
> > tests against the same.
> >
> > Best,
> > Raja Pullela
> > Senior Manager, Product Development
> > Accelerate, www.accelerite.com,@accelerite
> > 2055, Laurelwood Road,  Santa Clara, CA 95054, USA
> > Phone: 1-408-216-7010
> >
> > On 7/12/16, 2:17 PM, "Erik Weber" <terbol...@gmail.com> wrote:
> >
> > I'm interested in knowing more about any efforts as well, there are
> several
> > things in XS7 that we really want to use.
> >
> > --
> > Erik
> >
> > On Wed, May 25, 2016 at 2:59 PM, Paul Angus <paul.an...@shapeblue.com>
> > wrote:
> >
> > > Is anyone here working on XenServer 7 support for CloudStack?
> > >
> > >
> > > Kind regards,
> > >
> > > Paul Angus
> > >
> > >
> > > paul.an...@shapeblue.com
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > @shapeblue
> > >
> > >
> > >
> >
> >
> >
> >
> >
> > DISCLAIMER
> > ==
> > This e-mail may contain privileged and confidential information which is
> > the property of Accelerite, a Persistent Systems business. It is intended
> > only for the use of the individual or entity to which it is addressed. If
> > you are not the intended recipient, you are not authorized to read,
> retain,
> > copy, print, distribute or use this message. If you have received this
> > communication in error, please notify the sender and delete all copies of
> > this message. Accelerite, a Persistent Systems business does not accept
> any
> > liability for virus infected mails.
> >
>
>
>
>
>
> DISCLAIMER
> ==
> This e-mail may contain privileged and confidential information which is
> the property of Accelerite, a Persistent Systems business. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Accelerite, a Persistent Systems business does not accept any
> liability for virus infected mails.
>

Re: XenServer 7

[Erik Weber]

Primarily we're awaiting thin provisioning of fiber channel SAN disks.

Hope to see it in the next release :-)

-- 
Erik

On Wed, Jul 13, 2016 at 10:22 AM, Raja Pullela <raja.pull...@accelerite.com>
wrote:

> Hi Erik
>
> BVT – build verification tests or smoke tests are the test automation
> scripts we have in cloudstack repo.
> We will run these tests first and see if anything is broken.  For any
> failures, we will create bugs.
> IMO, since 4.9 is out, the next version should have the support for XS 7.0.
> Are you look at anything specific feature/functionality in XS 7.0?  can
> you share what it is ?
>
> Best,
> Raja Pullela
> Senior Manager, Product Development
> Accelerate, www.accelerite.com,@accelerite
> 2055, Laurelwood Road,  Santa Clara, CA 95054, USA
> Phone: 1-408-216-7010
>
> On 7/13/16, 11:58 AM, "Erik Weber" <terbol...@gmail.com> wrote:
>
> Would you mind elaborating a bit what that means?
>
> Does it mean that you have already done some fixing to get it to work and
> will start testing it?
> Or that you plan on testing it now, to figure out what needs fixing?
> Or something else?
>
> I'm trying to figure out when I can expect to use ACS (or a commercial
> distribution) with XS7
>
> --
> Erik
>
> On Tue, Jul 12, 2016 at 6:01 PM, Raja Pullela <raja.pull...@accelerite.com
> >
> wrote:
>
> > we are going to use XS7 for our testing and will be running BVTs/smoke
> > tests against the same.
> >
> > Best,
> > Raja Pullela
> > Senior Manager, Product Development
> > Accelerate, www.accelerite.com,@accelerite
> > 2055, Laurelwood Road,  Santa Clara, CA 95054, USA
> > Phone: 1-408-216-7010
> >
> > On 7/12/16, 2:17 PM, "Erik Weber" <terbol...@gmail.com> wrote:
> >
> > I'm interested in knowing more about any efforts as well, there are
> several
> > things in XS7 that we really want to use.
> >
> > --
> > Erik
> >
> > On Wed, May 25, 2016 at 2:59 PM, Paul Angus <paul.an...@shapeblue.com>
> > wrote:
> >
> > > Is anyone here working on XenServer 7 support for CloudStack?
> > >
> > >
> > > Kind regards,
> > >
> > > Paul Angus
> > >
> > >
> > > paul.an...@shapeblue.com
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > @shapeblue
> > >
> > >
> > >
> >
> >
> >
> >
> >
> > DISCLAIMER
> > ==
> > This e-mail may contain privileged and confidential information which is
> > the property of Accelerite, a Persistent Systems business. It is intended
> > only for the use of the individual or entity to which it is addressed. If
> > you are not the intended recipient, you are not authorized to read,
> retain,
> > copy, print, distribute or use this message. If you have received this
> > communication in error, please notify the sender and delete all copies of
> > this message. Accelerite, a Persistent Systems business does not accept
> any
> > liability for virus infected mails.
> >
>
>
>
>
>
> DISCLAIMER
> ==
> This e-mail may contain privileged and confidential information which is
> the property of Accelerite, a Persistent Systems business. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Accelerite, a Persistent Systems business does not accept any
> liability for virus infected mails.
>

Re: XenServer 7

[Erik Weber]

Would you mind elaborating a bit what that means?

Does it mean that you have already done some fixing to get it to work and
will start testing it?
Or that you plan on testing it now, to figure out what needs fixing?
Or something else?

I'm trying to figure out when I can expect to use ACS (or a commercial
distribution) with XS7

-- 
Erik

On Tue, Jul 12, 2016 at 6:01 PM, Raja Pullela <raja.pull...@accelerite.com>
wrote:

> we are going to use XS7 for our testing and will be running BVTs/smoke
> tests against the same.
>
> Best,
> Raja Pullela
> Senior Manager, Product Development
> Accelerate, www.accelerite.com,@accelerite
> 2055, Laurelwood Road,  Santa Clara, CA 95054, USA
> Phone: 1-408-216-7010
>
> On 7/12/16, 2:17 PM, "Erik Weber" <terbol...@gmail.com> wrote:
>
> I'm interested in knowing more about any efforts as well, there are several
> things in XS7 that we really want to use.
>
> --
> Erik
>
> On Wed, May 25, 2016 at 2:59 PM, Paul Angus <paul.an...@shapeblue.com>
> wrote:
>
> > Is anyone here working on XenServer 7 support for CloudStack?
> >
> >
> > Kind regards,
> >
> > Paul Angus
> >
> >
> > paul.an...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
>
>
>
>
>
> DISCLAIMER
> ==
> This e-mail may contain privileged and confidential information which is
> the property of Accelerite, a Persistent Systems business. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Accelerite, a Persistent Systems business does not accept any
> liability for virus infected mails.
>

Re: XenServer 7

[Erik Weber]

I'm interested in knowing more about any efforts as well, there are several
things in XS7 that we really want to use.

-- 
Erik

On Wed, May 25, 2016 at 2:59 PM, Paul Angus 
wrote:

> Is anyone here working on XenServer 7 support for CloudStack?
>
>
> Kind regards,
>
> Paul Angus
>
>
> paul.an...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>

Re: apachecloudstack.net and apachecloudstack.org

[Erik Weber]

On Thu, Jun 9, 2016 at 3:40 PM, Wido den Hollander  wrote:

>
> > Op 9 juni 2016 om 15:21 schreef Pierre-Luc Dion :
> >
> >
> > Hi,
> >
> > From the #jenkins slack channel discussion this morning we kind a took a
> > quick action on getting our hands on domain registration for
> > apachecloudstack{.org,.net}
> >
> > So, we also did some DNS updated until we have help from INFRA to use
> > cloudstack.org  which to me make more sense.
> >
> > So we added few dns entry:
> >
> > builds.apachecloudstack.net   => new jenkins to replace
> > jenkins.buildacloud.org
> > download.apachecloudstack.net =>  cname to cloudstack.apt-get.eu
> > artifacts.apachecloudstack.net=> nexus service for the new jenkins
> > system
> >
> > all apachecloudstack.org point to .net
> >
>
> Great! download.apachecloudstack.net is already working I see :)
>
> Now we just have to make sure that some organization will own these domain
> names instead of a private individual, but that's something for later.
>
>

No idea if this is possible within ASF boundaries, but could the ASF own
them, and provide the PMC access to the management of the zone(s)?

I believe ASF use Bind (or similar) with management in puppet, but if
allowed there are cloud solutions that works well and have nice APIs
(CloudFlare is one).


-- 
Erik

Re: Migrating CloudStack content from download.cloud.com

[Erik Weber]

As a user (with old ACS installations) I'd say that this isn't all that
troublesome, this is easily fixed by updating the appropriate db records.

We should ensure that we have some good posts discovered by Google and
other search engines, so that when somebody running old installations hit
this issue they find the workaround.
There's a lot of time to reach out to users and inform of the fix necessary.

-- 
Erik


On Tue, May 17, 2016 at 10:34 AM, Giles Sirett 
wrote:

> This is a MAJOR problem and needs to be figured out before the current
> download site is removed - @Raja - have Citrix committed to it being there
> another year ?
>
> It is my understanding that Cloudstack relies on this download at initial
> build/startup and then periodically if people do things like build a new
> zone
>
> So, users environments aren't going to stop if its pulled, but nobody
> would be a able to build/install cloudstack and it may cause issues as and
> when users make config changes
>
> The problem is, for new builds, its hard coded : you start the  Sec
> Storage VM, CloudStack will try to download the built in template from
> download.cloud.com
>
> My understanding is that its simple db  change to make once an environment
> is running (exisiting users) but *may* require a code patch to fix the
> initial install
>
> #notideal
>
> Really, this should be maintained by ASF/ the project as its key to the
> software working, however my understanding is it involves binaries which
> ASF is never keen on (and may be some 3rd party binaries) - so that just
> wont happen
>
>
>
> Apt-get is controlled by Wido et al (for which we all owe him a massive
> thanks)  - but you are right, it is a 3rd party dependency and arguably a
> SPOF.  But, if ASF wont host binaries, we're always going to have this
> issue.
>
> So, we could patch the code to point somewhere else - but where ? - by
> definition its got to be something maintained by a 3rd party
>
>
> We had this debate some time ago when talking about the repositories. We
> (ShapeBlue) maintain a repo for our customers, which wev'e always opened up
> as public. However, there were concerns about having a company domain name
> (which I understand) - so apt-get became our preferred repo.
>
>
> Thoughts on how to fix this:
>
> 1. if ASF would allow us to create the host entry download.cloudstack.org.
> Its under their domain, but with the site being with a 3rd party it could
> be allowed
>
> 2. maybe Citrix could commit to pointing the current DNS entry to a new
> location (would be simplest but may be legally complex and relies on
> ongoing goodwill)
>
> 3. make a mod to allow users to choose the download location on install.
> We can then maintain apt-get. To remove the SPOF, we could then get the
> templates copied to a number of 3rd party locations and allow people to
> choose which one they use
>
>
>
>
> Kind Regards
> Giles
>
>
> giles.sir...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
> -Original Message-
> From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On
> Behalf Of Will Stevens
> Sent: 16 May 2016 18:59
> To: dev@cloudstack.apache.org
> Cc: Wido den Hollander 
> Subject: Re: Migrating CloudStack content from download.cloud.com
>
> @Ian, yes, but I think there is more to it than that.  We can change it
> going forward and we can move everything from there over to a new domain.
> I believe the problem is with all of the existing ACS or CCP installs out
> there currently pointing at the download.cloud.com URL, so when it goes
> down, those installs have to be updated.
>
> Maybe I don't understand exactly, but that is the impression I am getting
> from this thread.  Can this be confirmed?
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw
> @CloudOps_
>
> On Mon, May 16, 2016 at 1:38 PM, Ian Rae  wrote:
>
> > Hey guys, who controls apt-get.eu and given the (rather concerning)
> > level of dependency on the operation of the download.cloud.com - would
> > it not make sense to use a domain that is under the control of party
> > whose alignment with CloudStack will not shift. I hesitate to
> > implicate the red tape of Apache Foundation, but perhaps the fabled
> > CloudStack alliance organization would be a good way to handle this
> > long term.
> >
> > On Mon, May 16, 2016 at 1:32 PM, Raja Pullela
> >  wrote:
> > > Paul,
> > >
> > > trust me, it won’t be go away overnight.  We are talking to Citrix
> > > and
> > requested them to keep it active for another year.
> > >
> > > Once we have the content copied over (I will work with Wido and
> > > verify
> > this) to cloudstack.apt-get.eu and update the documentation (user
> > guides update and create a wiki to show how an existing installation
> > can fixed to 

Re: [ANNOUNCE] Will Stevens as new Apache CloudStack VP

[Erik Weber]

On Thu, May 19, 2016 at 8:56 AM, Sebastien Goasguen 
wrote:

> Morning Everyone,
>
> Yesterday at the ASF board meeting, the board passed the resolution making
> Will Stevens the new Vice President of the Apache CloudStack project.
>
> Join me in congratulating Will on this appointment, wish him luck and
> bring your unwavering support !
>
> You may have noticed that Will took on RM duties for the new releases
> going forward and has also taken a very active role to finish bringing us
> to github based  workflow and CI. Will has some updates on that front that
> I am sure you will all like.
>
>

Thanks for all your hard work Sebastien, and congratulations Will!

-- 
Erik

Re: Migrating CloudStack content from download.cloud.com

[Erik Weber]

In case it was unclear, i meant hosting the mirrorlist with gh Pages :-)

Den onsdag 18. mai 2016 skrev Will Stevens <williamstev...@gmail.com>
følgende:

> Haha. I thought of that and didn't want to mention it because I thought it
> would be too fragile and not very ASFy. But if we have a
> ​ mirror
> ​ list, it would be a good option as one of the items in the list as a
> backup.
>
>
> On May 18, 2016 8:33 AM, "Erik Weber" <terbol...@gmail.com <javascript:;>>
> wrote:
>
> I guess we could even host it with github pages?
>
> On Wed, May 18, 2016 at 2:28 PM, Will Stevens <williamstev...@gmail.com
> <javascript:;>>
> wrote:
>
> > I like this approach as well. Seems like a nice solution and builds in
> > redundancy if a specific mirror is down for some reason.
> > On May 18, 2016 4:06 AM, "Paul Angus" <paul.an...@shapeblue.com
> <javascript:;>> wrote:
> >
> > > Pulling a few threads together - if the ASF would create a
> > > download.cloudstack.org page on ASF infra with the mirrorlist json in
> it
> > > as suggested by Nux, we can maintain just that page and add/remove
> > mirrors
> > > at will.
> > >
> > >
> > > Kind regards,
> > >
> > > Paul Angus
> > >
> > > paul.an...@shapeblue.com <javascript:;>
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > > @shapeblue
> > >
> > >
> > >
> > > -Original Message-
> > > From: Wido den Hollander [mailto:w...@widodh.nl <javascript:;>]
> > > Sent: 18 May 2016 08:37
> > > To: Giles Sirett <giles.sir...@shapeblue.com <javascript:;>>;
> dev@cloudstack.apache.org <javascript:;>
> > > Subject: RE: Migrating CloudStack content from download.cloud.com
> > >
> > >
> > > > Op 17 mei 2016 om 10:34 schreef Giles Sirett <
> > giles.sir...@shapeblue.com <javascript:;>
> > > >:
> > > >
> > > >
> > > > This is a MAJOR problem and needs to be figured out before the
> current
> > > download site is removed - @Raja - have Citrix committed to it being
> > there
> > > another year ?
> > > >
> > > > It is my understanding that Cloudstack relies on this download at
> > > > initial build/startup and then periodically if people do things like
> > > > build a new zone
> > > >
> > > > So, users environments aren't going to stop if its pulled, but nobody
> > > > would be a able to build/install cloudstack and it may cause issues
> as
> > > > and when users make config changes
> > > >
> > > > The problem is, for new builds, its hard coded : you start the  Sec
> > > > Storage VM, CloudStack will try to download the built in template
> from
> > > > download.cloud.com
> > > >
> > > > My understanding is that its simple db  change to make once an
> > > > environment is running (exisiting users) but *may* require a code
> > > > patch to fix the initial install
> > > >
> > > > #notideal
> > > >
> > > > Really, this should be maintained by ASF/ the project as its key to
> > > > the software working, however my understanding is it involves
> binaries
> > > > which ASF is never keen on (and may be some 3rd party binaries) - so
> > > > that just wont happen
> > > >
> > > >
> > > >
> > > > Apt-get is controlled by Wido et al (for which we all owe him a
> massive
> > > thanks)  - but you are right, it is a 3rd party dependency and arguably
> a
> > > SPOF.  But, if ASF wont host binaries, we're always going to have this
> > > issue.
> > > >
> > >
> > > Fully agree with you. I'am happy to host this, but for the project it
> is
> > a
> > > danger. The domain name should be controlled by the project.
> > >
> > > > So, we could patch the code to point somewhere else - but where ? -
> by
> > > > definition its got to be something maintained by a 3rd party
> > > >
> > > >
> > > > We had this debate some time ago when talking about the repositories.
> > We
> > > (ShapeBlue) maintain a repo for our customers, which wev'e always
> opened
> > up
> > > as public. However, there were concerns about having a company domain
> > name
> > > (whic

Re: Migrating CloudStack content from download.cloud.com

[Erik Weber]

I guess we could even host it with github pages?

On Wed, May 18, 2016 at 2:28 PM, Will Stevens 
wrote:

> I like this approach as well. Seems like a nice solution and builds in
> redundancy if a specific mirror is down for some reason.
> On May 18, 2016 4:06 AM, "Paul Angus"  wrote:
>
> > Pulling a few threads together - if the ASF would create a
> > download.cloudstack.org page on ASF infra with the mirrorlist json in it
> > as suggested by Nux, we can maintain just that page and add/remove
> mirrors
> > at will.
> >
> >
> > Kind regards,
> >
> > Paul Angus
> >
> > paul.an...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
> >
> >
> >
> > -Original Message-
> > From: Wido den Hollander [mailto:w...@widodh.nl]
> > Sent: 18 May 2016 08:37
> > To: Giles Sirett ; dev@cloudstack.apache.org
> > Subject: RE: Migrating CloudStack content from download.cloud.com
> >
> >
> > > Op 17 mei 2016 om 10:34 schreef Giles Sirett <
> giles.sir...@shapeblue.com
> > >:
> > >
> > >
> > > This is a MAJOR problem and needs to be figured out before the current
> > download site is removed - @Raja - have Citrix committed to it being
> there
> > another year ?
> > >
> > > It is my understanding that Cloudstack relies on this download at
> > > initial build/startup and then periodically if people do things like
> > > build a new zone
> > >
> > > So, users environments aren't going to stop if its pulled, but nobody
> > > would be a able to build/install cloudstack and it may cause issues as
> > > and when users make config changes
> > >
> > > The problem is, for new builds, its hard coded : you start the  Sec
> > > Storage VM, CloudStack will try to download the built in template from
> > > download.cloud.com
> > >
> > > My understanding is that its simple db  change to make once an
> > > environment is running (exisiting users) but *may* require a code
> > > patch to fix the initial install
> > >
> > > #notideal
> > >
> > > Really, this should be maintained by ASF/ the project as its key to
> > > the software working, however my understanding is it involves binaries
> > > which ASF is never keen on (and may be some 3rd party binaries) - so
> > > that just wont happen
> > >
> > >
> > >
> > > Apt-get is controlled by Wido et al (for which we all owe him a massive
> > thanks)  - but you are right, it is a 3rd party dependency and arguably a
> > SPOF.  But, if ASF wont host binaries, we're always going to have this
> > issue.
> > >
> >
> > Fully agree with you. I'am happy to host this, but for the project it is
> a
> > danger. The domain name should be controlled by the project.
> >
> > > So, we could patch the code to point somewhere else - but where ? - by
> > > definition its got to be something maintained by a 3rd party
> > >
> > >
> > > We had this debate some time ago when talking about the repositories.
> We
> > (ShapeBlue) maintain a repo for our customers, which wev'e always opened
> up
> > as public. However, there were concerns about having a company domain
> name
> > (which I understand) - so apt-get became our preferred repo.
> > >
> > >
> > > Thoughts on how to fix this:
> > >
> > > 1. if ASF would allow us to create the host entry
> > > download.cloudstack.org. Its under their domain, but with the site
> > > being with a 3rd party it could be allowed
> > >
> >
> > I think that would be the best. A CNAME pointing to
> cloudstack.apt-get.eu
> > for now might be enough.
> >
> > > 2. maybe Citrix could commit to pointing the current DNS entry to a
> > > new location (would be simplest but may be legally complex and relies
> > > on ongoing goodwill)
> > >
> > > 3. make a mod to allow users to choose the download location on
> > > install. We can then maintain apt-get. To remove the SPOF, we could
> > > then get the templates copied to a number of 3rd party locations and
> > > allow people to choose which one they use
> > >
> > >
> > >
> > >
> > > Kind Regards
> > > Giles
> > >
> > >
> > > giles.sir...@shapeblue.com
> > > www.shapeblue.com
> > > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue
> > >
> > >
> > >
> > > -Original Message-
> > > From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On
> > Behalf Of Will Stevens
> > > Sent: 16 May 2016 18:59
> > > To: dev@cloudstack.apache.org
> > > Cc: Wido den Hollander 
> > > Subject: Re: Migrating CloudStack content from download.cloud.com
> > >
> > > @Ian, yes, but I think there is more to it than that.  We can change it
> > going forward and we can move everything from there over to a new domain.
> > > I believe the problem is with all of the existing ACS or CCP installs
> > out there currently pointing at the download.cloud.com URL, so when it
> > goes down, those installs have to be updated.
> > >
> > > Maybe I don't understand exactly, but that is the impression I am
> > getting 

Re: Migrating CloudStack content from download.cloud.com

[Erik Weber]

We build and distribute systemvm templates, technically you could use the
same template.

It will contain some bits and bytes you don't need, but enough to test your
cloud.


Erik

Den tirsdag 17. mai 2016 skrev Giles Sirett 
følgende:

> This is a MAJOR problem and needs to be figured out before the current
> download site is removed - @Raja - have Citrix committed to it being there
> another year ?
>
> It is my understanding that Cloudstack relies on this download at initial
> build/startup and then periodically if people do things like build a new
> zone
>
> So, users environments aren't going to stop if its pulled, but nobody
> would be a able to build/install cloudstack and it may cause issues as and
> when users make config changes
>
> The problem is, for new builds, its hard coded : you start the  Sec
> Storage VM, CloudStack will try to download the built in template from
> download.cloud.com
>
> My understanding is that its simple db  change to make once an environment
> is running (exisiting users) but *may* require a code patch to fix the
> initial install
>
> #notideal
>
> Really, this should be maintained by ASF/ the project as its key to the
> software working, however my understanding is it involves binaries which
> ASF is never keen on (and may be some 3rd party binaries) - so that just
> wont happen
>
>
>
> Apt-get is controlled by Wido et al (for which we all owe him a massive
> thanks)  - but you are right, it is a 3rd party dependency and arguably a
> SPOF.  But, if ASF wont host binaries, we're always going to have this
> issue.
>
> So, we could patch the code to point somewhere else - but where ? - by
> definition its got to be something maintained by a 3rd party
>
>
> We had this debate some time ago when talking about the repositories. We
> (ShapeBlue) maintain a repo for our customers, which wev'e always opened up
> as public. However, there were concerns about having a company domain name
> (which I understand) - so apt-get became our preferred repo.
>
>
> Thoughts on how to fix this:
>
> 1. if ASF would allow us to create the host entry download.cloudstack.org.
> Its under their domain, but with the site being with a 3rd party it could
> be allowed
>
> 2. maybe Citrix could commit to pointing the current DNS entry to a new
> location (would be simplest but may be legally complex and relies on
> ongoing goodwill)
>
> 3. make a mod to allow users to choose the download location on install.
> We can then maintain apt-get. To remove the SPOF, we could then get the
> templates copied to a number of 3rd party locations and allow people to
> choose which one they use
>
>
>
>
> Kind Regards
> Giles
>
>
> giles.sir...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
> -Original Message-
> From: williamstev...@gmail.com  [mailto:
> williamstev...@gmail.com ] On Behalf Of Will Stevens
> Sent: 16 May 2016 18:59
> To: dev@cloudstack.apache.org 
> Cc: Wido den Hollander >
> Subject: Re: Migrating CloudStack content from download.cloud.com
>
> @Ian, yes, but I think there is more to it than that.  We can change it
> going forward and we can move everything from there over to a new domain.
> I believe the problem is with all of the existing ACS or CCP installs out
> there currently pointing at the download.cloud.com URL, so when it goes
> down, those installs have to be updated.
>
> Maybe I don't understand exactly, but that is the impression I am getting
> from this thread.  Can this be confirmed?
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw
> @CloudOps_
>
> On Mon, May 16, 2016 at 1:38 PM, Ian Rae >
> wrote:
>
> > Hey guys, who controls apt-get.eu and given the (rather concerning)
> > level of dependency on the operation of the download.cloud.com - would
> > it not make sense to use a domain that is under the control of party
> > whose alignment with CloudStack will not shift. I hesitate to
> > implicate the red tape of Apache Foundation, but perhaps the fabled
> > CloudStack alliance organization would be a good way to handle this
> > long term.
> >
> > On Mon, May 16, 2016 at 1:32 PM, Raja Pullela
> > > wrote:
> > > Paul,
> > >
> > > trust me, it won’t be go away overnight.  We are talking to Citrix
> > > and
> > requested them to keep it active for another year.
> > >
> > > Once we have the content copied over (I will work with Wido and
> > > verify
> > this) to cloudstack.apt-get.eu and update the documentation (user
> > guides update and create a wiki to show how an existing installation
> > can fixed to point to new URLs) we don’t have a dependency on “
> download.cloud.com” –
> > right?  sorry, if I am missing something here?   

Re: [DISCUSS] Moving to Java8

[Erik Weber]

It only means that we are dropping support for newer ACS versions.
It most likely won't get into 4.9, which means 14.04 will be supported a
few more weeks/months.

We could mention in the 4.9 RN that for the next release (call it 5.0
because of the change?) will only be supported by $xyz distribution versjons

-- 
Erik

On Fri, May 13, 2016 at 9:10 PM, Wido den Hollander  wrote:

> I am in favor of Java 8, but it means we would drop Ubuntu 14.04 support.
>
> That would make life a bit easier though, since Ubuntu 16.04 has systemd
> and 14.04 still has sysvinit and that make packaging a problem.
>
> > Op 13 mei 2016 om 19:10 schreef Rohit Yadav :
> >
> >
> > All,
> >
> >
> > I've started some work [pr] that aims to adapt CloudStack to recent
> changes in the environments and the ecosystem:
> >
> >
> > - Java8, Spring 4.x
> >
> > - SystemD
> >
> > - MariaDB and MySQL
> >
> > - Reduce distro provided package dependency
> >
> > - Packaging, CI and testing
> >
> >
> > These are long term goals but I've identified some concrete goals:
> >
> >
> > - Migrate to Java8 both for building codebase and running CloudStack
> (mgmt server, usage, agent etc)
> >
> > - Migrate to Spring 4.x as 3.x is not supported to work with Java7
> >
> > - Fix CI and packaging to use Java8
> >
> > - Reduce distro specific package dependency such as Tomcat, since we're
> already using Jetty (maven-jetty-plugin) during development we can use
> embedded Jetty for mgmt server(s) as well
> >
> > - Update systemvm template to include Java8 JRE
> >
> > - Update packaging to support systemd (CentOS7+ has some systemd support
> and thanks to Wido's recent PR we would have systemd support for debian
> packages in future too)
> >
> > - Optimize JVM options for long running mgmt server(s), agent(s) and
> usage server(s) to run on JRE8
> >
> >
> > I've sent a [pr] to show some initial progress in this regard where
> we've some outstanding issues but we're able to build/run/test with Java8 +
> Spring 4.x and TravisCI has been fixed to use JDK8 as well.
> >
> >
> > Testing in general would be a huge requirement for this initiative,
> especially testing of all the plugins. Java7 has EOL-ed and Java9 is around
> the corner; we've seen good amount of security and memory issues with
> Java7/6 and Tomcat6.x; therefore it seems necessary to work on above as we
> move towards a LTS release in upcoming months.
> >
> >
> > Request for comments, suggestions and guidance. Thanks.
> >
> >
> > [pr] https://github.com/apache/cloudstack/pull/1546
> >
> >
> > Regards.
> >
> > Regards,
> >
> > Rohit Yadav
> >
> > rohit.ya...@shapeblue.com
> > www.shapeblue.com
> > 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> > @shapeblue
>

Re: hidden configuration items

[Erik Weber]

On Sat, May 7, 2016 at 8:09 AM, Nathan Johnson  wrote:

> If you hit the /client/console endpoint with a vmid, it sends you back some
> data that contains a link to a the console proxy VM and passes an encrypted
> json payload that has the user, password and port for a vnc connection.
> Normally this is meant to load in an iframe.  We want to decrypt this
> response to direct a VNC client to the appropriate host / port / user /
> pass and bypass use of the console proxy VM.  The key and iv appear to be
> stored in the configuration table under the names security.encryption.key
> and security.encryption.iv, but as they are hidden we cannot get these
> credentials via the listConfigurations endpoint as-is.  So my question is:
>
> What would be the most appropriate way to open up the possibility of
> showing “hidden” configuration items via this API to our middleware?  Some
> sort of entry in a config file somewhere?  An entry in the configuration
> table itself?  Or is there some other way to get this information I’m
> looking for?
>
>
Just tested:

mysql> update configuration set category='Secure' where name in
('security.encryption.iv', 'security.encryption.key');

(default) > list configurations name=security.encryption.iv

count = 1

configuration:

+--++++

| category |  name  | value  |
description   |

+--++++

|  Secure  | security.encryption.iv |  | base64
encoded IV data |

+--++++


-- 
Erik

Re: hidden configuration items revisited

[Erik Weber]

Rajani is right, I didn't look at the value in db, just the category.

-- 
Erik

On Tue, May 10, 2016 at 8:30 AM, Rajani Karuturi <raj...@apache.org> wrote:

> 'Hidden' and 'Secure' are both encrypted in db only difference being hidden
> values are not shown.
> you could just change the category in configuration table.
>
> ~Rajani
>
> On Mon, May 9, 2016 at 10:56 PM, Erik Weber <terbol...@gmail.com> wrote:
>
> > listConfiguration returns unencrypted values for Secure items, but they
> > need to be stored encrypted in the db.
> >
> > You'd need to check If those values ever change, If they don't you may
> try
> > encrypting the value and change category to Secure
> >
> > Erik
> >
> > Den mandag 9. mai 2016 skrev Nathan Johnson <njohn...@ena.com> følgende:
> >
> > > Erik Weber <terbol...@gmail.com <javascript:;>> wrote:
> > >
> > > > I believe Kishan suggested that you could change those Hidden config
> > > items
> > > > to Secure (an existing category), as Secure items are returned with
> the
> > > > listConfiguration API.
> > >
> > > This is chicken and egg.  I need the unencrypted values so I can
> decrypt
> > > other payloads.  I need the keys plaintext, one way or another.
> > >
> >
>

Re: hidden configuration items revisited

[Erik Weber]

listConfiguration returns unencrypted values for Secure items, but they
need to be stored encrypted in the db.

You'd need to check If those values ever change, If they don't you may try
encrypting the value and change category to Secure

Erik

Den mandag 9. mai 2016 skrev Nathan Johnson <njohn...@ena.com> følgende:

> Erik Weber <terbol...@gmail.com <javascript:;>> wrote:
>
> > I believe Kishan suggested that you could change those Hidden config
> items
> > to Secure (an existing category), as Secure items are returned with the
> > listConfiguration API.
>
> This is chicken and egg.  I need the unencrypted values so I can decrypt
> other payloads.  I need the keys plaintext, one way or another.
>

Re: hidden configuration items revisited

[Erik Weber]

I believe Kishan suggested that you could change those Hidden config items
to Secure (an existing category), as Secure items are returned with the
listConfiguration API.

I don't know if you can do an in-place switch, or if the value has to be
encrypted first for it to work, but you should be able to test that in a
test environment.

-- 
Erik

On Mon, May 9, 2016 at 3:53 PM, Nathan Johnson  wrote:

> Kishan Kavala  wrote:
>
> > Nathan,
> >   You can use "Secure" category instead of "Hidden". Config items with
> "Secure" category are encrypted and also included in listConfigurations API
> response.
>
> The data that I need (specifically security.encryption.iv and
> security.encryption.key) are already marked “Hidden".  These are the keys
> that are used to encrypt the response that I need to decrypt in the
> middleware.  The configuration item I’m proposing to add is a boolean, so
> that doesn’t make sense to be “Secure” either.  Unless I’m
> misunderstanding?
>
> Thanks for the reply
>
> Nathan
>
>
> >
> > ~kishan
> >
> > -Original Message-
> > From: Nathan Johnson [mailto:njohn...@ena.com]
> > Sent: 08 May 2016 22:01
> > To: dev@cloudstack.apache.org
> > Subject: hidden configuration items revisited
> >
> > I would like to get some feedback for a proposed addition of a feature
> > that would allow “Hidden” configuration items to be returned from the
> > listConfigurations endpoint.
> >
> > 1) There will be a new optional parameter for listConfigurations called
> > showhidden .  Defaults to false.  Existing behavior is preserved unless
> > showhidden is set to true.
> >
> > 2) There is a now configuration item, com.cloud.allowshowhidden , which
> > defaults to false.  This must be set to true in order for showhidden to
> > be allowed.  If showhidden=true is passed and
> > com.cloud.allowshowhidden=false, an InvalidParameterValueException is
> > thrown.
> >
> > So the web UI would still hide hidden configuration items regardless of
> > the state of com.cloud.allowshowhidden since it will not be passing
> > showhidden=true.  The main value of this would be from API
> > implementations / middleware, which is what our front-end talks to
> > instead of directly to cloudstack management server.
> >
> > Obviously there is an explicit reason hidden configuration items are not
> > displayed via the API at present.  The Hidden configuration items contain
> > some very sensitive data, such as private keys etc.  I would like to
> > submit a pull request that would make sense to everyone and still be
> > secure by default and not open up pandora’s box so to speak.  I have this
> > working in our lab, but I wanted to get a bit of feedback before
> > submitting a PR.
> >
> > So several questions:
> >
> > 1) Would it make sense for com.cloud.allowshowhidden to be a “Hidden”
> > configuration item?  The up side of this is that you could not toggle
> > this value from the API.  Marking it hidden means that a rogue root admin
> > api key holder could not grant themselves more access.  The down side is
> > that I’m not sure how to easily change this value outside of manually
> > going into the database and changing it, and one should hope that root
> > admin api key holders are well trusted.  Currently I have this
> > implemented as an “Advanced” configuration item.
> >
> > 2) I picked com.cloud.allowshowhidden out of my hat.  Is there a more
> > appropriate name that I should use?
> >
> >
> >
> >
> > DISCLAIMER
> > ==
> > This e-mail may contain privileged and confidential information which is
> > the property of Accelerite, a Persistent Systems business. It is intended
> > only for the use of the individual or entity to which it is addressed. If
> > you are not the intended recipient, you are not authorized to read,
> > retain, copy, print, distribute or use this message. If you have received
> > this communication in error, please notify the sender and delete all
> > copies of this message. Accelerite, a Persistent Systems business does
> > not accept any liability for virus infected mails.
>
>
>

Re: Incorrect system vm templates for master build.

[Erik Weber]

AFAIK it hasn't been necessary to update the systemvm template yet, that is
probably why it still shows as 4.6.0.

-- 
Erik

On Thu, Apr 28, 2016 at 12:04 PM, Bharat Kumar 
wrote:

> Hi All,
>
> looks like the systemvm templates are not getting built correctly in
> http://jenkins.buildacloud.org/job/build-systemvm64-master.
>
> The build version is in correctly set to 4.6,  Im not sure but i think the
> build version in
> /etc/cloudstck-release is also getting wrongly set inside the template.
>
> Can any one please fix this. I do not have access to jenkins.
>
> Thanks,
> Bharat.
>
>
>
>
>
>
> DISCLAIMER
> ==
> This e-mail may contain privileged and confidential information which is
> the property of Accelerite, a Persistent Systems business. It is intended
> only for the use of the individual or entity to which it is addressed. If
> you are not the intended recipient, you are not authorized to read, retain,
> copy, print, distribute or use this message. If you have received this
> communication in error, please notify the sender and delete all copies of
> this message. Accelerite, a Persistent Systems business does not accept any
> liability for virus infected mails.
>

[ANNOUNCE] New committer: Simon Weller

[Erik Weber]

The Project Management Committee (PMC) for Apache CloudStack
has asked Simon Weller to become a committer and we are pleased to
announce that they have accepted.


Being a committer allows many contributors to contribute more
autonomously. For developers, it makes it easier to submit changes and
eliminates the need to have contributions reviewed via the patch
submission process. Whether contributions are development-related or
otherwise, it is a recognition of a contributor's participation in the
project and commitment to the project and the Apache Way.

Please join me in congratulating Simon

--Erik
on behalf of the CloudStack PMC

Up to date hypervisor support matrix

[Erik Weber]

There has been quite some differences between what features that
are supported on different hypervisors.

Does anyone know If the feature support matrix is up to date? In particular
I am interested in what features we do (and don't) support with KVM

Erik

Re: [ANNOUNCE] Open source distributed virtual machine scheduling platform

[Erik Weber]

Cool stuff! You might want to announce this on the marketing@ list as well
for further exposure :-)

-- 
Erik

On Tue, Apr 26, 2016 at 10:59 PM, Gabriel Beims Bräscher <
gabrasc...@gmail.com> wrote:

> Hello CloudStack community members (@dev and @users),
>
> This email is meant to announce the publication of a project on Github that
> provides a distributed virtual machine scheduling platform that can be
> easily integrated with Apache CloudStack (ACS). The project is available at
> [1], you can find a detailed explanation of the idea of the project, its
> aspirations, basic concepts, installation and uninstallation processes and
> other information at [2]. Also, if you want to know more about the
> Autonomiccs and its creators, you can access the link [3].
>
> The code that was opened at Github is part of a bigger system that has the
> goal of managing a cloud computing environment autonomously. All of that is
> being developed and used in my Ph. D. thesis and the masters’ thesis of
> some colleagues. The formalization of that component will be published at
> the 12th IEEE World Congress on Services (SERVICES 2016) at San Francisco
> USA.
>
> You can see the stats of our code at [4] and [5]. Right now we only have
> ~40% of code test coverage. However, we intend to increase that value to
> ~60% until next week and ~90% until the end of June.
>
> To give you a picture of what we are preparing for the future, we can
> highlight the following goals for this year (You can find others short term
> goals at [6]):
>
>-
>
>Integrate our platform [1] with a multi-agent system (MAS) platform, in
>order to facilitate the development of agents. Currently, we are using
>Spring-integration to “emulate” and an agent life cycle; that can
> become a
>problem when needing to add more agents and they start to communicate
> with
>each other. Therefore, we will integrate the platform in [1] with JADE
> [7];
>-
>
>Today the metrics about the use of resource are not properly gathered by
>ACS; in order to develop more accurate predictions we need to store
>resource usage metrics. Also, those metrics have to be gathered in a
>distributed way without causing service degradation. For that and a few
>other reasons (you can send us an email so we can provide you more
>details), we are developing an autonomic monitoring platform that will
>integrate with the system available in [1];
>-
>
>We also foresee the need to develop a better way to visualize the cloud
>environment, a way to detect hot spots (pods and hosts) with higher
>resource usage trends (VMs trends). We see the need to change the rustic
>view of the environment with tables for a better suitable one for humans
>(this is a surprise that we intend to present at the CCCBR).
>
> We hope you like the software and that it meets your expectations. If it
> does not suffice all of your needs, let’s work together to improve it. If
> you have any doubts or suggestions please send us an email; we will reply
> it as fast as we can. Also, critics that can help us improve that platform
> are very welcome.
>
> [1] https://github.com/Autonomiccs/autonomiccs-platform
>
> [2] https://github.com/Autonomiccs/autonomiccs-platform/wiki
>
> [3] http://autonomiccs.com.br/
>
> [4] http://jenkins.autonomiccs.com.br/
>
> [5] http://sonar.autonomiccs.com.br/
>
> [6] https://github.com/Autonomiccs/autonomiccs-platform#project-evolution
>
> [7] http://jade.tilab.com/
>
>
> Cheers, Gabriel.
>

Re: [DISCUSS] Emeritus Committer Status

[Erik Weber]

On Wed, Apr 20, 2016 at 2:26 PM, John Burwell 
wrote:

> Erik,
>
> The following is the response I received from infra about managing
> emeritus committers:
>
> commit bits are...binary bits, they can be 1 or they can be 0. We
> don’t
> operate with trinary bits here, sorry
>
> If you want to have emeritus committers, your best bet is to
> remove them
> from the ldap group and keep a log in your pmc dir of their names.
>
> So, we need to manage a separate list of emeritus committers.  Personally,
> I don’t find that too onerous as I doubt we will have people moving between
> active and emeritus very often.
>
>
I agree, as long as the process is documented and followed as part of
removing their commit bit, it should be fine.


-- 
Erik

Re: [DISCUSS] Emeritus Committer Status

[Erik Weber]

On Tue, Apr 19, 2016 at 11:42 PM, John Burwell 
wrote:

> All,
>
> As I am sure many have observed, we have a large number of committers [1]
> who are no longer active.  Currently, we no status that continues to
> recognize someone’s committer merit while allowing them to declare inactive
> in the project.  To address this gap, I am proposed amending our project
> bylaws [2] as follows:
>
>
+1 to introduce emeritus status


> 2.3.4  A committer is considered "emeritus" by sending their declaration
> to priv...@cloudstack.apache.org.
>   An emeritus committer may return to "active" status by sending their
> declaration to priv...@cloudstack.apache.org priv...@cloudstack.apache.org>.
>   No vote is required for a committer change from “emeritus" to “active"
> status.
>
>
What exactly does going emeritus mean?

Removal of commit bit/access on the account? Disabling/removal of account?
I am -1 for the latter, as people might have used their apache.org email
address elsewhere or might be committers elsewhere disallowing us from
doing this, but I can be +1 for removing karma/commit bit.



> 2.3.5 "Active committters" are all non-emeritus committers.
>
> These clauses were inspired by the Apache Cocoon [3] bylaws [4].  To be
> clear, a committer never loses their merit, and only a committer can decide
> to go emeritus.  Since merit is never lost, a emeritus committer may return
> to active status at anytime by simply informing the PMC of their intention
> to be active again.  No one can require that committer change to emeritus
> status.
>
> On the website, we would place emeritus committers in a separate section —
> allowing users to more easily identify those that are actively
> participating in the project.
>
>
I am not sure how we keep this updated in an automated way. If we remove
emeritus members from the LDAP group, we have a way to fetch active ones,
but no way to fetch inactive/emeritus.

Haven't asked infra, but perhaps it could be possible to add an emeritus
ldap group or something like that

-- 
Erik

Fwd: Advice for community participation to lower tension

[Erik Weber]

This was recently sent to ComDev (d...@community.apache.org) and I feel it
is worth sharing.

Cheers,
Erik

-- Forwarded message --
From: Niclas Hedhman 
Date: Sat, Apr 9, 2016 at 3:50 AM
Subject: Advice for community participation to lower tension
To: d...@community.apache.org


Everyone,
recently there was some tension/friction in a community, and I posted the
following advice to everyone to better get along. Not only did the
community members responded positively, but I also got pinged privately to
make this available publicly, so here it is, and I will let the wider
community do with it what it sees fit...


First a few general guidelines;
  a. Assume that the other party agrees more than disagrees with you. We
tend to leave out agreements and focus on differences. Sometime this is
forgotten and escalation becomes absurd for no rational reason.

  b. When in doubt, assume that you are interpreting the message wrongly
and kindly ask for verification that you understood a particular topic well.

  c. When writing, assume that every sentence will be misinterpreted.
Review and try to reformulate to be as clear as possible.

  d. Use a submissive tone in all writing. Instead of the strong "In my
opinion, we must..." or the quite neutral "I think we should...", try to
use "Maybe we should consider..." or "Another idea that we could..."

   e. If you disagree strongly with an email sent, tag it Important, then
put it aside. Read it half a day later again. Put it aside. Read it again
next day, and then it is easier to write a balanced and inviting response,
instead of the initial vitriol that flows through us when we get upset. I
found that sometimes a response wouldn't be necessary, as the importance
was actually much lower than originally perceived, and I would be able to
work "with", instead of "against", a given change.

  f. Be forgiving and accept different priorities. The other person is not
out to get you or attack your work. More often than not, it is one of the
above (a-d) that are failing, or that the other person prioritize some
aspect higher than you do. Sometimes, this requires compromises, sometimes
not and the different priorities can co-exist.


Most communities at Apache consists of level-headed, reasonable people, who
have a strong vested interest in its Apache project. This interest, often
passion, is both the source of tension, but it is also what unites the
people within the community. It is easy to forget the vast amount of
agreement that exists, and get upset over relatively small disagreements.
Ability to put that aside, or downplay the importance, will ensure a
harmonious project.

Face-to-Face is excellent way to eliminate disagreements, but that is often
not practical. Consider Skype or Google Hangout, just for the social aspect
of being part of this community. It should not be formal, and the
invitation should go out to everyone, perhaps someone want to make a short
presentation of what he/she is doing, to have some "structure", but that
might not be needed either. Once we have a face to the words, and a general
idea how that person is socially, we are much more capable to interact by
email.


Cheers
--
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: Apache Jira rights for the ACS project

[Erik Weber]

On Tue, Apr 19, 2016 at 10:38 PM, Simon Weller  wrote:

> All,
>
>
> What is the correct way to request some additional rights on the Apache
> Jira instance?
>
> I'd like to be able to assign some issues to myself (and other members of
> my team).
>
>
I believe the general way is to state your username and what you need
access to, then someone with karma will grant you the rights necessary :-)

-- 
Erik

Re: [DISCUSS] ACS 4.9 systemvmtemplate

[Erik Weber]

Regarding packer, I believe cosmic has done most of that. See
https://github.com/MissionCriticalCloud/systemvm-packer/blob/master/README.md


Erik

Den tirsdag 19. april 2016 skrev Rohit Yadav 
følgende:

> Hi all,
>
> Will and I had some discussions around systemvm template on one of the
> PRs, I wanted to bring the discussion here on dev@.
>
> Provided we've some features merged before the freeze date in May, we will
> need to build a new systemvm-template with likely following new packages
> (assuming the feature PRs get merged):
>
> -  Zebra and related packages required by OSPF stuff from Abhi
>
> -  Strongswan required by strongswan-vpn PR from Jayapal
>
> To reduce scope, I suggest we still use Debian7 as base. As soon as these
> PRs get merged, we can create early systemvmtemplates in order to have them
> available for early testing (and against other PRs).
> Will raised questions around where and how to build them -- I suppose we
> can reuse the systemvmtemplate builder Jenkins jobs (or create a new one if
> that's not working/broke) and we can use community-maintained hosting
> places to host them, I don't know if ASF can provide us any place to host
> them (S3, servers etc.). Comments, questions?
>
> For long term (likely 4.10/LTS), I hope to have following work we can do
> around systemvm templates:
>
> -  Try to reduce systemvm template and systemvm.iso size
>
> -  Migrate to Debian 8 based base-template, newer packages and
> kernel
>
> -  Fix systemvm.iso init scripts (cloud early script,
> password-server script etc.) to be systemd compatible
>
> -  Evaluate and migrate Python scripts to using Python3 (if
> possible that would be great as more distros are moving to use Python 3.x
> as default)
>
> -  Migrate to using Java8 JRE (both for systemvm agents and mgmt.
> server)
>
> -  Migrate the systemvm build system to use packer with KVM,
> instead of using veewee/VirtualBox
>
> Regards.
>
> Regards,
>
> Rohit Yadav
>
> rohit.ya...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>

Re: PRs for 4.9 Release

[Erik Weber]

On Thu, Apr 7, 2016 at 6:15 PM, Will Stevens 
wrote:

> I know this is not how this usually works, but I need to crowd source some
> info to be more effective.
>
> I am slowly getting things rolling for the 4.9 release.  My CI is chugging
> away and I have a queue of PRs to get tested, so I will be getting through
> them as quickly as I can.  I have finally gotten to where I have a
> relatively steady stream of merges going in and I am working through final
> logistics on a whole bunch.
>
> I would like some help prioritizing PRs that we feel MUST get into 4.9.
> There are almost 200 PRs open right now so it is not realistic for me to
> expect to get them all into the 4.9 release simply due to the number of CI
> hours needed.
>
> If you know of PRs that you think are important to get in, please reply
> with a link to the Github PR so I can get them into my active list.
>
> One more thing...
>
> If you have any extra hardware available that is not currently being used
> and you are willing to help with the CI effort, please email me and I will
> get you setup so you can contribute to testing.  I would like to try to get
> a distributed network of CI environments working to better test the ACS
> code base, so even if you only have the hardware free for 2 weeks, we can
> make use of it.  I can help you get the hardware up and running ready for
> testing in a couple hours.
>
> Thanks you for the support...
>
>
Regarding bubble, would it be possible to make a jenkins job that prebuilds
rpms? that would speed up the start a bit, since compiling cloudstack takes
quite a bit.

I might be able to look at such task, but wanted to check if anyone else
has done or are considering to do something similar.

testing out some bubbles now, might be able to help testing a week or so
from now.

-- 
Erik

Re: Introduction

[Erik Weber]

That's why I added 'or someone else' :-)

Anyway, it's great to see the increased activity in the community these
days, not just from Accelerite, but from everyone!

-- 
Erik

On Fri, Apr 8, 2016 at 1:15 PM, Will Stevens <williamstev...@gmail.com>
wrote:

> While I know we all want these answers, I doubt the 'new guy' is going to
> be able to speak to that. :P
>
> Welcome. I look forward to working with you.
> On Apr 8, 2016 1:58 AM, "Erik Weber" <terbol...@gmail.com> wrote:
>
> On Fri, Apr 8, 2016 at 6:58 AM, Rashmi Dixit <rashmi_di...@accelerite.com>
> wrote:
>
> > Hello!
> >
> > I am Rashmi Dixit and have recently joined the CloudPlatform team in
> > Accelerite. I have worked on a hybrid cloud management solution
> supporting
> > hypervisors such as KVM, Xen, VMware, HyperV and public clouds such as
> EC2.
> > My areas of interest are User Interface, networking.
> >
> > I am really looking forward to contributing on CloudStack.
> >
> >
> Welcome!
>
> We see a lot of Accelerite people contributing on the mailing list, with
> PRs etc. these days, but I guess I am not the only one wondering what
> Accelerite is planning for the future.
>
> Is this something you, or someone else, could say something about?
>
> Where do you see ACP/ACS in five years? Any specific major
> plans/feature/improvements you could share? Will the majority (or all?) of
> new features/improvements you develop be upstreamed or are we going to see
> diverged products?
>
>
> All the best,
>
> Erik
>

Re: Introduction

[Erik Weber]

On Fri, Apr 8, 2016 at 6:58 AM, Rashmi Dixit 
wrote:

> Hello!
>
> I am Rashmi Dixit and have recently joined the CloudPlatform team in
> Accelerite. I have worked on a hybrid cloud management solution supporting
> hypervisors such as KVM, Xen, VMware, HyperV and public clouds such as EC2.
> My areas of interest are User Interface, networking.
>
> I am really looking forward to contributing on CloudStack.
>
>
Welcome!

We see a lot of Accelerite people contributing on the mailing list, with
PRs etc. these days, but I guess I am not the only one wondering what
Accelerite is planning for the future.

Is this something you, or someone else, could say something about?

Where do you see ACP/ACS in five years? Any specific major
plans/feature/improvements you could share? Will the majority (or all?) of
new features/improvements you develop be upstreamed or are we going to see
diverged products?


All the best,

Erik

Re: [ACP Doctor] What is it?

[Erik Weber]

I downloaded it, but I believe the license restricts me from redistributing
it.

There's not a whole lot of stuff it does, here is a screenshot of the help
[1]
I tried passing '--tune' and '--troubleshoot', but it didn't do anything
besides creating a rather empty log

That said, I believe there is a use case for such tooling to help users
tune, troubleshoot and manage their CloudStack installations.

[1]
https://www.dropbox.com/s/9jskksl5dcjn7v9/Screenshot%202016-04-07%2012.02.38.png?dl=0


-- 
Erik

On Thu, Apr 7, 2016 at 10:23 AM, Daan Hoogland 
wrote:

> except that there is no link on that page to the scripts
>
> On Thu, Apr 7, 2016 at 6:32 AM, ilya  wrote:
>
> > Wow, a whole one page site dedicated to this endeavor :)
> >
> > On 4/6/16 9:22 PM, Will Stevens wrote:
> > > FYI, It does still seem to be freely available:  http://ccpdoctor.com/
> > >
> > > *Will STEVENS*
> > > Lead Developer
> > >
> > > *CloudOps* *| *Cloud Solutions Experts
> > > 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > > w cloudops.com *|* tw @CloudOps_
> > >
> > > On Thu, Apr 7, 2016 at 12:11 AM, ilya 
> > wrote:
> > >
> > >> Thanks for explanation Ian and Will.
> > >>
> > >> Much appreciated.
> > >>
> > >> On 4/5/16 8:33 PM, Ian Rae wrote:
> > >>> I don't believe this is freely available, rather is a tool Citrix
> > >> developed
> > >>> for helping troubleshoot CCP customer deployments. I would imagine
> that
> > >>> Accelerite owns this tool now and it is likely available if you are
> an
> > >> ACP
> > >>> customer, but not necessarily for ACS users.
> > >>>
> > >>> Probably best for Accelerite to comment.
> > >>>
> > >>> On Tuesday, 5 April 2016, Will Stevens 
> wrote:
> > >>>
> >  It used to be CCP Doctor and it is not in ACS from my understanding.
> > >> It is
> >  a set of scripts that will do basic validation of a CloudStack
> setup.
> > >> It
> >  does things like verify the system VMs are running and the
> > connectivity
> > >> is
> >  working between all of the systems.  It also does some checking to
> > make
> >  sure the versions of software is correct and checks some things in
> the
> > >> DB
> >  as well.  It also collects a whole crap ton of logs and database
> dumps
> > >> (i
> >  think) and zips them up for easy transfer to support so they can
> get a
> >  solid feel for your setup.
> > 
> >  It also has 'suggestions' for things you can do to fix different
> > >> aspects of
> >  your setup.  Things like setting 'ulimit' to 'unlimited' and will
> give
> > >> you
> >  the command to run.  It also lets you pass a 'fix' flag and it will
> >  automagically make all the changes for you.  I am too paranoid to
> have
> >  actually used the fix flag because I was always using this in
> > production
> >  environments and I am a little too risk averse to let a script do
> > >> anything
> >  for me (unless I wrote it).
> > 
> >  Does that answer your question?  It should be freely available and
> you
> >  should be able to run it against ACS, so you should be able to try
> it
> >  out...
> > 
> >  It is a pretty useful tool to be honest.  Especially if you are
> >  troubleshooting an environment you didn't setup.
> > 
> >  *Will STEVENS*
> >  Lead Developer
> > 
> >  *CloudOps* *| *Cloud Solutions Experts
> >  420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> >  w cloudops.com *|* tw @CloudOps_
> > 
> >  On Tue, Apr 5, 2016 at 5:28 PM, ilya  >  > wrote:
> > 
> > > Saw ACP Doctor in CCP release notes from Accelerite.
> > >
> > > Curious what it is, is it integrated into cloudstack or collection
> of
> > > shell scripts?
> > >
> > > Thanks
> > > ilya
> > >
> > 
> > >>>
> > >>>
> > >>
> > >
> >
>
>
>
> --
> Daan
>

Re: Introduction

[Erik Weber]

Welcome :-)

Den mandag 28. mars 2016 skrev Boris Stoyanov 
følgende:

> Hi CloudStack,
>
> My name is Boris Stoyanov (Bobby) and today is my first day @ShapeBlue.
> I’m based in Sofia, Bulgaria. I will be taking the role of Software
> Engineer in Test, and as you may have guessed I’ll mostly focus on testing
> CloudStack. I have about 10 years of experience in testing, which I’ve
> mostly spend in doing test automation frameworks and deployment automation.
> I’m new to the CloudStack business and I have a lot to learn, but I hope
> I’ll get up to speed in short time. Looking forward to working with you!
>
> Best Regards,
> Bobby.
> Regards,
>
> Boris Stoyanov
>
> boris.stoya...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>

Re: Migrating CloudStack content from download.cloud.com

[Erik Weber]

One of the issues as far as I know is that as Apache CloudStack we have to
be strict with what we distribute. Meaning, we won't be able to push
noredist stuff, which is a pity.

Erik

Den lørdag 26. mars 2016 skrev Ian Rae  følgende:

> Does Apache provide such hosting services? It seems that the Apache
> infrastructure is very restrictive, perhaps we should ask whether they can
> provide reliable hosting for templates and other downloads.
>
> If Apache is ruled out as an option I recommend we have the community
> contribute the hosting (happy to volunteer) but the URL should be a
> community URL and not specific to a commercial vendor. It should probably
> be mirrored geographically as well.
>
> Ian
>
> On Saturday, 26 March 2016, Ian Duffy >
> wrote:
>
> > I could be completely wrong here, but wasn't there some specific closed
> > source citrix magic added to the templates at downloads.cloud.com that
> was
> > Cloud Platform specific?
> >
> > Ideally, this stuff should be hosted on an Apache Cloudstack
> > infrastructure or atleast the main community source (
> > cloudstack.apt-get.eu, shapeblue repo, etc.).
> >
> > On 25 March 2016 at 15:00, Sebastien Goasguen  
> > > wrote:
> >
> > >
> > > > On Mar 25, 2016, at 10:24 AM, Raja Pullela <
> > raja.pull...@accelerite.com  >
> > > wrote:
> > > >
> > > > @Sebastien,  thanks for the feedback.  please note that the goal of
> > this
> > > exercise was not to impact any users during this migration and hence
> the
> > > efforts to place the content at a location where we could move it to.
> > > Since Wido is ok with hosting the content on 'cloudstack.apt-get.eu',
> it
> > > is even better.  I will work with Wido on the next steps.
> > > >
> > >
> > > Ok cool.
> > >
> > > We had other threads about avoiding company specific URL in docs. So
> > let’s
> > > definitely avoid that.
> > >
> > >
> > > > @Ilya,  'cloud.com' is not getting transferred.
> > > >
> > > > Best,
> > > > Raja
> > > > Senior Manager, Product Development
> > > > Accelerite,
> > > > www.accelerite.com
> > > >
> > > > -Original Message-
> > > > From: Sebastien Goasguen [mailto:run...@gmail.com 
> ]
> > > > Sent: Friday, March 25, 2016 1:57 PM
> > > > To: dev@cloudstack.apache.org  
> > > > Subject: Re: Migrating CloudStack content from download.cloud.com
> > > >
> > > 
> > >  Citrix has been hosting   "download.cloud.com"  for  quite  some
> > > time  now
> > >  and  it holds  the  System Templates for all the releases and
> some
> > > tools.
> > >  Going forward,  this  content  needs  to  be  moved  from
> > >  "download.cloud.com".So, we will be moving  this content  to
> > >  "cloudstack.accelerite.com".I  will also be  updating  the
> > > links in the
> > >  documentation  to reflect
> > > >
> > > > Raja, I am going to give this a strong -1
> > > >
> > > > We talked about these sorts of things before and it is not
> appropriate.
> > > >
> > > >
> > > >
> > >  these  changes and will provide an update  once the  content  move
> > >  is complete.
> > > 
> > >  @Wido, if you could also copy this content to
> > >  "cloudstack.apt-get.eu"  that will be great.  I can provide you
> the
> > > details in a separate email.
> > > >>>
> > > >>> Super! If you have a rsync source I will set it up.
> > > >>>
> > > >
> > > > @Wido, I think we need to host the sysVM on apt-get.eu and let that
> be
> > > the primary source and links in the docs.
> > > >
> > > >
> > > >>> Wido
> > > >>>
> > > 
> > >  Best,
> > >  Raja
> > >  Senior Manager, Product Development, Accelerite,
> > >  www.accelerite.com
> > > 
> > > 
> > > 
> > > 
> > >  DISCLAIMER
> > >  ==
> > >  This e-mail may contain privileged and confidential information
> > >  which is the property of Accelerite, a Persistent Systems
> business.
> > >  It is intended only for the use of the individual or entity to
> which
> > >  it is addressed. If you are not the intended recipient, you are
> not
> > >  authorized to read, retain, copy, print, distribute or use this
> > >  message. If you have received this communication in error, please
> > > notify the sender and delete all copies of this message.
> > >  Accelerite, a Persistent Systems business does not accept any
> > >  liability for virus infected mails.
> > > >
> > > >
> > > >
> > > >
> > > > DISCLAIMER
> > > > ==
> > > > This e-mail may contain privileged and confidential information which
> > is
> > > the property of Accelerite, a Persistent Systems business. It is
> intended
> > > only for the use of the individual or entity to which it is addressed.
> If
> > > you are not the intended recipient, you are not authorized to read,
> > 

Re: [VOTE] Move 'apache/cloudstack' -> 'apache-cloudstack/cloudstack'

[Erik Weber]

+1

Den fredag 18. mars 2016 skrev Will Stevens 
følgende:

> We are discussing this proposal in 3 or 4 threads, so I will not try to
> recap everything.  Instead I will try to give a brief overview of the
> problem and a proposal for solving it.
>
> *Problem:*
> The Apache CloudStack community needs additional github permissions in
> order to integrate CI for the purpose of maintaining code quality.  The ASF
> does not have enough granular control via the 'apache' github organization
> to give the 'apache/cloudstack' repository the needed permissions.
>
> *Proposal:*
> Transfer ownership of the 'apache/cloudstack' mirrored repository out of
> the 'apache' github organization into the 'apache-cloudstack' github
> organization (which I have already setup and started inviting users to).
> Both members of the ACS community and the ASF board will have 'owner'
> permissions on this new organization.  This will allow for permissions to
> be applied specifically to the 'apache-cloudstack' organization and not
> have to be applied to the entire 'apache' organization.
>
> By transferring ownership, all of the PRs will be copied to the new
> repository and redirects will be created on github from 'apache/cloudstack'
> to 'apache-cloudstack/cloudstack'.
>
> The developer workflow and commit workflow will remain unchanged.  The
> canonical ASF repository (git://git.apache.org/cloudstack.git) will remain
> the source of truth and commits will be made to that repository.
>
> Please ask if anything is unclear or needs to be better defined in order
> for you to cast a vote.
>

[POLL] Interest for EU based event/collab

[Erik Weber]

[Cross posted to users@ and dev@]

As you may be aware, a conference has been announced in Brazil later this
year.

I guess there are more than me having a hard time travelling that far and
long, so I would like to check the interest for an EU based event.

Unless someone comes up with a big money jar it won't be as fancy as the
previous ones.

If you could fill out this poll[1] and/or respond to this email, that would
be great.

[1] https://no.surveymonkey.com/r/CX3K5T3


-- 
Erik

Re: External fork of Cloudstack (was Re: [GitHub] cloudstack pull request: Is the project attempting a fork on Githu...)

[Erik Weber]

On Thu, Mar 17, 2016 at 4:52 PM, Chris Mattmann  wrote:

>
> >> The other thing is - is the new Cloudstack GitHub organization the
> >> result of a subset of the PMC going off and doing this -
> >
> >I am not sure why you say subset. Let’s try to avoid polemics.
>
> I’m not trying to attack.
>
>
This is not the result of people getting together and saying 'hey, we
should fork and work somewhere else, that'd be fun!', but rather
'hey, we are currently unable to do what we need to do, and none of our
attempts of getting assistance have resulted in anything. what can we do?'.

On January 27th 2016, Schuberg Philis (SBP), a company with many CloudStack
contributors/committers/pmcs, announced that they are 'jumping ship,
forking the code and going their own way'.  (that's my wording, not theirs)

Take a look at our git commit history before and after that date. Notice
anything?
Most, if not all, are trivial commits to fix typos, simple mistakes etc.
and not code changes.

This may be rude to everyone else, but the fact is that after 4.5 SBP
(there are a few exceptions) has done more or less everything when it comes
to testing code and gatekeeping the code base. And they did a very good job
at it.
Frankly I am surprised they even coped with it that long.

Apache CloudStack now has a fork (Cosmic), that's not bound by ASF policies
and it's lack of progress when it comes to providing the tools necessary.

When (or if -- with their own governing they don't have to call it a
specific version) SBP release an official version of Cosmic, it would
surprise me if not a lot of CloudStack users would atleast try it out.
I am pretty sure that I am going to.

And wha-bang, there (potentially) goes your community, because there
already is a better option out there.



> I asked a simple question - how many/who in the Apache CloudStack PMC
> is intent on using this new Cloudstack GitHub organization? Not an
> attack, a question that I still don’t have an answer to.
>
>
The answer would most likely be 'anyone and everyone'.
Contrary to what you might believe, this is being done to /help/
CloudStack, not hurt it. Atleast that is my intention by participating.

In case you are unfamiliar with Apache CloudStack, it is a beast.
Unlike many typical ASF projects you cannot just unpack the tarball, run
'make test', wait a few minutes and have it properly tested.
Testing Apache CloudStack requires a broad variety of physical hardware,
network appliances, storage solutions and least but most importantly pretty
much every hypervisor that is being used out there.

A subset of the test tasks we have take multiple hours to run and only
tests a small fraction of the total codebase.

Pre 4.6, the Apache CloudStack community had a little to loose discipline
on committing to the codebase.
Testing was optional, and hardly done.

We had multiple versions that had major flaws in them, discovered right
after release as people tried to use it -- even for the most basic
operations.

For the 4.6 release we decided that from now on, every commit would have to
be looked through by two different persons, saying they approve it, and
tested by a minimum of one.

And it worked, the voting process improved, we released rapidly and with
far less issues than previously (no software is bug free after all).

As mentioned, we require that code changes (be it improvements, fixes or
new features) are tested before they are allowed to be committed.

Which means that anyone wanting to interact (with code) have to do it
theirselves at the moment, and that is _NOT_ an easy task.
Which again means that no matter how good your intention is, your PR is not
going be merged.
What kind of Community treatment is that?


The way I see it there is only one solution to this -- we need better
testing, and to automate that we need more access to GitHub.

There are two ways to do that;
1) By being granted certain permissions to the apache/cloudstack repository.
2) By doing it somewhere else where we have those permissions.

Will Stevens asked infra [1] for a small subset of permissions -- none of
which should be any real risk for disasters, and got rejected.
That rules out option #1.

This turned out to be a long, and emotional email, please don't take any
grunts personally -- they are not meant to be.

[1] https://issues.apache.org/jira/browse/INFRA-11429


-- 
Erik

Re: [POLL] Interest for EU based event/collab

[Erik Weber]

Hi Giles,

Berlin is great!

Has there been any discussions about a specific date yet? Personally I have
some vacation plans in that time frame (not that it should matter for the
event).

I agree that combing the efforts we have is a good thing, I am hoping for
something bigger than a traditional UG at some point as it is hard to
defend the costs for a 3-4 hour event.

-- 
Erik



On Wed, Mar 16, 2016 at 4:22 PM, Giles Sirett <giles.sir...@shapeblue.com>
wrote:

> Erik
>
> I've responded to your survey (don’t know how useful my response will be,
> I've said "yes" to everything)
>
>
> One idea: we have a quarterly meeting of the Cloudstack EU UG.
> We got 50 along to the last one. It’s a different audience to the usual
> CCC attendees (more users than devs)
>
> For the next one (early June), we're planning on having it in Berlin
>
> Andre and the folks from BitGroup are taking the lead on it
>
> It would seem perfectly logical to me to combine anything we (i.e. the
> community) do with one of these UG's - gain more critical mass more quickly
> and make it more attractive to potential sponsors
>
> I'm not sure how far down the path Andre et al are with logistics and
> whether the idea of making this into a bigger thing would scare him, but it
> may be worth you two syncing on this
>
> We only have these meetings quarterly, the one after June would clash with
> Brasil so likely not to happen
>
>
>
> Kind Regards
> Giles
>
>
>
> [image: ShapeBlue] <http://www.shapeblue.com>
> Giles Sirett
> CEO ,  ShapeBlue
> d:  *+44  20 3603 0541 | s: +44 203 603 0540*
> <+44%20%2020%203603%200541%20%7C%20s:%20+44%20203%20603%200540>  |  m:
> *+44 7961112055* <+44%207961112055>
> e:  *giles.sir...@shapeblue.com | t: *
> <giles.sir...@shapeblue.com%20%7C%20t:>  |  w:  *www.shapeblue.com*
> <http://www.shapeblue.com>
> a:  53 Chandos Place, Covent Garden London WC2N 4HS UK
> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
> Services India LLP is a company incorporated in India and is operated under
> license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a
> company incorporated in Brasil and is operated under license from Shape
> Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of
> South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is
> a registered trademark.
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error.
>
>
> -Original Message-
> From: Erik Weber [mailto:terbol...@gmail.com]
> Sent: 16 March 2016 13:20
> To: dev <dev@cloudstack.apache.org>; us...@cloudstack.apache.org
> Subject: [POLL] Interest for EU based event/collab
>
> [Cross posted to users@ and dev@]
>
> As you may be aware, a conference has been announced in Brazil later this
> year.
>
> I guess there are more than me having a hard time travelling that far and
> long, so I would like to check the interest for an EU based event.
>
> Unless someone comes up with a big money jar it won't be as fancy as the
> previous ones.
>
> If you could fill out this poll[1] and/or respond to this email, that
> would be great.
>
> [1] https://no.surveymonkey.com/r/CX3K5T3
>
>
> --
> Erik
> Find out more about ShapeBlue and our range of CloudStack related services:
> IaaS Cloud Design & Build
> <http://shapeblue.com/iaas-cloud-design-and-build//> | CSForge – rapid
> IaaS deployment framework <http://shapeblue.com/csforge/>
> CloudStack Consulting <http://shapeblue.com/cloudstack-consultancy/> | 
> CloudStack
> Software Engineering
> <http://shapeblue.com/cloudstack-software-engineering/>
> CloudStack Infrastructure Support
> <http://shapeblue.com/cloudstack-infrastructure-support/> | CloudStack
> Bootcamp Training Courses <http://shapeblue.com/cloudstack-training/>
>

Re: github organisation cloudstack

[Erik Weber]

On Wed, Mar 16, 2016 at 8:46 PM, Will Stevens  wrote:

> If we use this I think it's main purpose should be to facilitate CI and
> integration testing of the apache/cloudstack repo.
>
> The first hurdle in using this repo for CI work is the fact that none of
> the open PRs from apache/cloudstack are available in the
> cloudstack/cloudstack repo.



I'd say we tackle that problem once we have a working and bulletproof CI.
In the meantime we can either make dummy PRs or copy some from the ASF org
to run in the CI.

As long as we have concensus, I would imagine that we could ask
contributors to send PRs here instead when the time comes?

-- 
Erik

Re: [POLL] Interest for EU based event/collab

[Erik Weber]

I appreciate the offer but plan on spending the days dipping in a pool
somewhere in Greece at that time.

However, I do hope that the event is successful, and that there might
become a wish for a later event (Winter? b).
That is still far ahead and something we can pick up later though.

-- 
Erik



On Wed, Mar 16, 2016 at 8:54 PM, Walter, André <andre.wal...@bitgroup.de>
wrote:

> Hi Erik,
>
>
>
> we are heading for 16th of June from 13:00 -17:30 CET (I am working
> together with Steve to finalize the speakers/agenda) and you are more than
> welcome J.
>
>
>
> Best regards.
> Andre
>
>
>
> *Von:* Erik Weber [mailto:terbol...@gmail.com]
> *Gesendet:* Mittwoch, 16. März 2016 20:51
> *An:* Giles Sirett
> *Cc:* dev@cloudstack.apache.org; Walter, André; Steve Roles
> *Betreff:* Re: [POLL] Interest for EU based event/collab
>
>
>
> Hi Giles,
>
> Berlin is great!
>
> Has there been any discussions about a specific date yet? Personally I
> have some vacation plans in that time frame (not that it should matter for
> the event).
>
> I agree that combing the efforts we have is a good thing, I am hoping for
> something bigger than a traditional UG at some point as it is hard to
> defend the costs for a 3-4 hour event.
>
> --
>
> Erik
>
>
>
>
>
> On Wed, Mar 16, 2016 at 4:22 PM, Giles Sirett <giles.sir...@shapeblue.com>
> wrote:
>
> Erik
>
> I've responded to your survey (don’t know how useful my response will be,
> I've said "yes" to everything)
>
>
> One idea: we have a quarterly meeting of the Cloudstack EU UG.
> We got 50 along to the last one. It’s a different audience to the usual
> CCC attendees (more users than devs)
>
> For the next one (early June), we're planning on having it in Berlin
>
> Andre and the folks from BitGroup are taking the lead on it
>
> It would seem perfectly logical to me to combine anything we (i.e. the
> community) do with one of these UG's - gain more critical mass more quickly
> and make it more attractive to potential sponsors
>
> I'm not sure how far down the path Andre et al are with logistics and
> whether the idea of making this into a bigger thing would scare him, but it
> may be worth you two syncing on this
>
> We only have these meetings quarterly, the one after June would clash with
> Brasil so likely not to happen
>
>
>
> Kind Regards
> Giles
>
>
>
> [image: ShapeBlue] <http://www.shapeblue.com>
>
> *Giles Sirett*
>
> *CEO*
>
> *, *
>
> *ShapeBlue*
>
> *d: *
>
> *+44  20 3603 0541 | s: +44 203 603 0540*
> <+44%20%2020%203603%200541%20%7C%20s:%20+44%20203%20603%200540>
>
>  |
>
> *m: *
>
> *+44 7961112055* <+44%207961112055>
>
> *e: *
>
> *giles.sir...@shapeblue.com | t: * <giles.sir...@shapeblue.com%20%7C%20t:>
>
>  |
>
> *w: *
>
> *www.shapeblue.com* <http://www.shapeblue.com>
>
> *a: *
>
> 53 Chandos Place, Covent Garden London WC2N 4HS UK
>
> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
> Services India LLP is a company incorporated in India and is operated under
> license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a
> company incorporated in Brasil and is operated under license from Shape
> Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of
> South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is
> a registered trademark.
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error.
>
>
>
> -Original Message-
> From: Erik Weber [mailto:terbol...@gmail.com]
> Sent: 16 March 2016 13:20
> To: dev <dev@cloudstack.apache.org>; us...@cloudstack.apache.org
> Subject: [POLL] Interest for EU based event/collab
>
> [Cross posted to users@ and dev@]
>
> As you may be aware, a conference has been announced in Brazil later this
> year.
>
> I guess there are more than me having a hard time travelling that far and
> long, so I would like to check the interest for an EU based event.
>
> Unless someone comes up with a big money jar it won't be as fancy as the
> previous ones.
>
> If you could fill out this poll[1] and/or respond to this email,

Re: github organisation cloudstack

[Erik Weber]

On Tue, Mar 15, 2016 at 11:07 PM, Daan Hoogland 
wrote:

> devs,
>
> There is a github organisation called cloudstack, to which we have more
> control then to the apache/cloudstack repo on github. We need to decide as
> community what to do with it.
>
> What are we going to do in this new organisation?
>

How about we test out different ways of improving our CI/other automation
tasks, without the 'pressure' we have with the official repos?
I.e. there is no pressure to get things merged, just test things out.


> Will we let/ask Schuberg Philis to put cosmic in there?
>

No offence, but why would we do that? Cosmic != CloudStack. They already
have what looks like a healthy github organization.
If they want to help improve the CloudStack organization then fine, but
lets not mix Cosmic into this.


> Will be ask/let Will to run upr to it (so we don't depend on the
> foundation)?
>

I don't see why not, let Will, SB, SBP, Accelerite (I have no clue how to
spell it right yet), or whoever wants to, do automated testing on it.
We need to figure out how we should grant access in a systematic way, but
as Will explained in a different thread -- the permissions needed are
non-intrusive and imho we should be generous handing them out to whoever
wants/needs, and revert that grant if necessary


> How will we sink it from/to apache or the apache github organisation?
>

I guess we still need to commit things to git-wip.a.o to keep doing commits
the apache way, that would keep the ASF github fork in sync.

-- 
Erik

Re: [PROPOSAL] - Reference Guide for CloudStack configuration parameters

[Erik Weber]

Looking forward to it, after about 5 years with CloudStack there are still
configuration parameters I don't have the slightest clue what is for.

-- 
Erik

On Mon, Mar 14, 2016 at 11:36 AM, Rajsekhar K 
wrote:

> Thanks, Pierre-Luc.
>
> I think we can create a new Reference Guide with this information, which
> will be a single point of reference to learn about the Apache CloudStack
> configuration parameters. I think we can use the wiki for collaborating on
> this document. I think the wiki will be helpful in sharing our thoughts,
> collecting input,  and reviewing the content.
>
> Thanks,
> Rajsekhar
>
> On Mon, Feb 22, 2016 at 9:36 PM, Pierre-Luc Dion 
> wrote:
>
> > Good Initiative Rajsekhar !
> >
> > I think this document should go into the admin-guide [1]. For sure the
> wiki
> > is easier to start with :-)
> >
> > Thanks !
> >
> > PL
> >
> >
> > On Tue, Feb 16, 2016 at 4:49 AM, Rajsekhar K 
> > wrote:
> >
> > > Hi, All,
> > >
> > > Thanks for your responses. I am sure we will be able to create a
> complete
> > > reference guide for the CloudStack parameters.
> > >
> > > I think I can create a wiki page that explains this effort and publish
> > this
> > > list of categories there. I think it will be easier for you to review
> the
> > > list then.
> > >
> > > Will let you know after I create this wiki page.
> > >
> > > Thanks,
> > > Rajsekhar
> > >
> > > On Mon, Feb 15, 2016 at 5:07 PM, Daan Hoogland <
> daan.hoogl...@gmail.com>
> > > wrote:
> > >
> > > > I like the idea but shouldn't it be part of the source code and
> > extracted
> > > > from there? What is the need to have it in a separate wiki?
> > > >
> > > > On Mon, Feb 15, 2016 at 9:18 AM, Rohit Yadav <
> > rohit.ya...@shapeblue.com>
> > > > wrote:
> > > >
> > > > > Nice, maybe put this on our cwiki so others can collaborate than do
> > > this
> > > > > over a word doc?
> > > > >
> > > > > Regards.
> > > > >
> > > > >
> > > > > [image: ShapeBlue] 
> > > > > Rohit Yadav
> > > > > Software Architect ,  ShapeBlue
> > > > > d:  * | s: +44 203 603 0540* <%7C%20s:%20+44%20203%20603%200540>
> |
> > > m:
> > > > > *+91 8826230892* <+91%208826230892>
> > > > > e:  *rohit.ya...@shapeblue.com | t: *
> > > > >   |  w:  *www.shapeblue.com*
> > > > > 
> > > > > a:  53 Chandos Place, Covent Garden London WC2N 4HS UK
> > > > > Shape Blue Ltd is a company incorporated in England & Wales.
> > ShapeBlue
> > > > > Services India LLP is a company incorporated in India and is
> operated
> > > > under
> > > > > license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is
> a
> > > > > company incorporated in Brasil and is operated under license from
> > Shape
> > > > > Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The
> > Republic
> > > of
> > > > > South Africa and is traded under license from Shape Blue Ltd.
> > ShapeBlue
> > > > is
> > > > > a registered trademark.
> > > > > This email and any attachments to it may be confidential and are
> > > intended
> > > > > solely for the use of the individual to whom it is addressed. Any
> > views
> > > > or
> > > > > opinions expressed are solely those of the author and do not
> > > necessarily
> > > > > represent those of Shape Blue Ltd or related companies. If you are
> > not
> > > > the
> > > > > intended recipient of this email, you must neither take any action
> > > based
> > > > > upon its contents, nor copy or show it to anyone. Please contact
> the
> > > > sender
> > > > > if you believe you have received this email in error.
> > > > >
> > > > >
> > > > > On 14-Feb-2016, at 5:37 AM, Rajsekhar K  >
> > > > wrote:
> > > > >
> > > > > Hi, All,
> > > > >
> > > > > This is part of the effort to create a Reference Guide for
> CloudStack
> > > > > configuration parameters. This guide intends to provide a single
> > point
> > > of
> > > > > reference for the configuration parameters that we use in
> CloudStack.
> > > > Each
> > > > > parameter will be treated as a topic in this guide.
> > > > >
> > > > > I am planning to document the following information for each
> > parameter:
> > > > >
> > > > >
> > > > >- Name and description of the parameter.
> > > > >- List of features that the users can configure using the
> > parameter.
> > > > >- Changes in the behavior of each parameter when users provide
> > low,
> > > > >optimal, and high values to the parameters.
> > > > >- Warnings, notes, and limitations for each parameter.
> > > > >- Example for each parameter - Explaining the parameter with the
> > > help
> > > > >of scenarios.
> > > > >- Impact of each configuration parameter on APIs.
> > > > >- Scope of the parameter - global, zone-level, or cluster-level.
> > > > >- Dependencies among the configuration parameters.
> > > > >- Category to which the parameter belongs.
> > > 

Re: [CCCBR] CCC São Paulo

[Erik Weber]

Great, I'll see if I can do some magic to attend.

Do you know if there are any other conferences in São Paulo that week?

-- 
Erik

On Fri, Mar 11, 2016 at 6:34 PM, Marco Sinhoreli <
marco.sinhor...@shapeblue.com> wrote:

> Hello community,
>
> I have a pleasure to announce the CCC São Paulo will be realized in 29-30
> September in São Paulo – Brazil in an  great auditorium at USP.  This
> auditorium has capacity to 1000 attendants and we are planning to use 3
> rooms for parallel tracks.
>
> The prospect plan for sponsors and the website will be ready within next
> days and, ASAP it is ready, I will back to you all.  Also, we are talking
> with hotels to have some discount to the community from outside São Paulo.
>
> About the website, when it is online, I will ask to redirect
> cloudstackcollab.org to it.
>
> About the tickets for the event, our plan is to have a symbolic value,
> around US$ 30, so that people have access and participate with our
> community of discussions about the project.
>
> I want to say: welcome for you all and I hope it will be a very great
> event!
>
> See you in Brazil in September!
>
> *Marco Sinhoreli*
>
> Consultant Manager
>
> marco.sinhor...@shapeblue.com
>
> mobile: +55 21 98276 3636
>
>
>
> Praia de Botafogo 501, bloco 1 - sala 101 – Botafogo
>
> Rio de Janeiro, RJ - Brazil - CEP 22250-040
>
> office: + 55 21 2586 6390 | fax: +55 21 2586 6002
>
> http://www.shapeblue.com/ | twitter: @shapeblue
> Find out more about ShapeBlue and our range of CloudStack related services:
> IaaS Cloud Design & Build
>  | CSForge – rapid
> IaaS deployment framework 
> CloudStack Consulting  | 
> CloudStack
> Software Engineering
> 
> CloudStack Infrastructure Support
>  | CloudStack
> Bootcamp Training Courses 
>

Re: Results of a IPv6 brainstorm day

[Erik Weber]

On Thu, Mar 10, 2016 at 10:31 PM, Wido den Hollander  wrote:

>
> > Op 10 maart 2016 om 21:15 schreef John Burwell <
> john.burw...@shapeblue.com>:
> >
> >
> > Wido,
> >
> > Curious if you have been able to make any progress on this work. Have
> you been
> > able to move it forward? If not, what kind of help would you need?
> >
>
> Yes. Not so much in code inside CloudStack, but mainly in figuring out
> DHCPv6
> stuff and searching for the right components.
>
> The DHCPv6 part is something that I would like to see handled by Kea.
> Blogged
> about my tests with Kea:
> http://blog.widodh.nl/2016/02/isc-kea-dhcpv6-server/
>
>
AFAIK dnsmasq should support DHCPv6 leases based on MAC-addresses as well,
should ease the transition a bit to not have to switch the software inside
the VR.

-- 
Erik

Re: [PROPOSAL] Minimum Viable CI Integration

[Erik Weber]

I guess the appropriate channel would be to create a jira ticket for INFRA:
https://issues.apache.org/jira/browse/INFRA

-- 
Erik

On Mon, Mar 7, 2016 at 11:18 PM, Will Stevens  wrote:

> This is kind of what I was expecting.  Do you know who I would be
> contacting?  The permissions required are VERY minimal AND they have
> already given the 'TravisCI' application the same permissions as we need
> for this.
>
> How did we get the TravisCI application enabled and the permissions
> accepted for that integration?
>
> I have been trying to thinking of ways to potentially work the system from
> that side.  The main issue I have with this approach is that it is not a
> single application that we want to give permission to.  Ideally, we would
> give each individual/organization who is contributing a CI environment
> their own token.  In that case, we would have to register the CI of each
> party as their own CI integration.
>
> Here are some ideas I have as a 'work around' to the problem:
>
> 1) Register a single upr CI application with Github and have the apache
> guys enable the integration.  This will give the application a single
> access token.  I can then compile upr with the access token embedded into
> the binary.  I don't like this approach and I feel we would probably be
> violating some ToS somewhere.
>
> 2) Provide a web server implementation that each CI party can use to
> register their own CI endpoint as a Github application integration.  Then
> we have the apache guys enable each of them (which will be a harder sell to
> them), but then each CI party will get their own token and will be able to
> post back as themselves.  This is also nice because if someone is not a
> good community member and misbehaves, their integration can be revoked
> without it affecting everyone else who has a CI integration.
>
> 3) Provide a single web server implementation that is registered as a
> Github Application Integration.  This implementation is then approved by
> the apache guys for the cloudstack repo.  This web server implementation
> (let's call it upr_server) keeps our one and only access token.  I then
> modify the upr command line tool to take a token that is provided by the
> upr_server when a CI party registers on the upr_server website.  The
> upr command
> will actually target the upr_server box when posting statuses, etc, which
> will essentially proxy the calls on to Github using the token that was
> approved for the integration.
>
> I think that 3) is probably the cleanest solution and would reduce our
> chances of getting banned by someone for being too cheeky.  It is a whole
> lot of trouble for nothing, but if they are going to be a stick in the mud
> about this and not allow access tokens to anything other than official
> github supported integrations, then I will have to make that work...
>
> Ideas?  Thoughts?  Rants?  :P
>
> *Will STEVENS*
> Lead Developer
>
> *CloudOps* *| *Cloud Solutions Experts
> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> w cloudops.com *|* tw @CloudOps_
>
> On Mon, Mar 7, 2016 at 4:12 PM, Remi Bergsma 
> wrote:
>
> > Hi Will,
> >
> > This is the main problem: there’s no one except Apache Infra with access
> > to the Github CloudStack repo. Even committers have to push to Apache
> git,
> > which is mirrored to Github. We can’t close a PR, set a label, change a
> > title or whatever basic operation. You can ask them for a token. When I
> (as
> > the release manager) asked for any more permission than an anonymous user
> > has it was kindly refused. I really hope you’ll have more luck but I
> > wouldn’t count on it.
> >
> >
> >
> > Regards,
> > Remi
> >
> >
> > On 07/03/16 19:10, "williamstev...@gmail.com on behalf of Will Stevens"
> <
> > williamstev...@gmail.com on behalf of wstev...@cloudops.com> wrote:
> >
> > >The main thing we have to sort out with this type of integration (as it
> is
> > >today) is the distribution of access tokens with the correct permissions
> > on
> > >the apache/cloudstack github repo.  The required permissions are very
> > >limited, but I don't know if we have access to create new tokens.  If we
> > >don't then I will have to develop an application integration workaround
> to
> > >make it easier for the people with access to the apache/cloudstack repo
> to
> > >give the people running CI integrations access to update statuses (like
> > the
> > >current travis integration).
> >
> >
> >
> >
> >
> > >If you have questions or feedback, please don't be shy.
> > >
> > >*Will STEVENS*
> > >Lead Developer
> > >
> > >*CloudOps* *| *Cloud Solutions Experts
> > >420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
> > >w cloudops.com *|* tw @CloudOps_
> > >
> > >On Mon, Mar 7, 2016 at 12:36 PM, Bharat Kumar <
> > bharat.ku...@accelerite.com>
> > >wrote:
> > >
> > >> Hi guys,
> > >>
> > >> I am also working on the similar reporting problem, here is what i did
> > >>
> > >> link to the report 

Re: [DISCUSS] Request for comments: Out-of-band Management for CloudStack (new feature)

[Erik Weber]

Sounds like a decent addition to me, +1

-- 
Erik

On Thu, Mar 3, 2016 at 11:43 AM, Rohit Yadav 
wrote:

> Hi all,
>
> I want to propose this new feature for CloudStack, to support out-of-band
> management for CloudStack.
>
> In practice, most hosts have a out-of-band management such as iLO or iDRAC
> (that can support IPMI 2.0 for example). The idea is to allow admins to
> access this out-of-band management interface. Initially power-state related
> operations will be supported such as power on/off/reset etc. and a
> background service to synchronize the power states of the out-of-band
> management enabled hosts.
>
> Please have a look at the FS and share your feedback on the same:
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Out-of-band+Management+for+CloudStack
>
> For testing this feature, I’ve created this tool/library that is a fake
> ipmi server that can be run as a standalone server/tool and also importable
> to write Marvin tests: https://github.com/bhaisaab/ipmisim
>
> Thanks and regards.
> PS. I’ll be demoing this feature in today’s CSEUG meetup in London
>
> [image: ShapeBlue] 
> Rohit Yadav
> Software Architect ,  ShapeBlue
> d:  * | s: +44 203 603 0540* <%7C%20s:%20+44%20203%20603%200540>  |  m:
> *+91 8826230892* <+91%208826230892>
> e:  *rohit.ya...@shapeblue.com | t: *
>   |  w:  *www.shapeblue.com*
> 
> a:  53 Chandos Place, Covent Garden London WC2N 4HS UK
> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
> Services India LLP is a company incorporated in India and is operated under
> license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a
> company incorporated in Brasil and is operated under license from Shape
> Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of
> South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is
> a registered trademark.
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error.
>
>
> Find out more about ShapeBlue and our range of CloudStack related services:
> IaaS Cloud Design & Build
>  | CSForge – rapid
> IaaS deployment framework 
> CloudStack Consulting  | 
> CloudStack
> Software Engineering
> 
> CloudStack Infrastructure Support
>  | CloudStack
> Bootcamp Training Courses 
>

Re: marvin functional test cases or junits for the api 'deployVirtualMachine' and 'resizeVolume'

[Erik Weber]

Are anyone able to help Prakash out with the testing?


-- 
Erik

On Mon, Feb 29, 2016 at 7:50 PM, B Prakash  wrote:

> I am looking for marvin functional test cases or junits for the api
> 'deployVirtualMachine' and 'resizeVolume'.  Please could someone share this
> info?
>
> Thanks and regards,
>
> Prakash
>

Re: [DISCUSS] Keeping system vms up to date

[Erik Weber]

On Mon, Feb 22, 2016 at 8:58 PM, Rene Moser <m...@renemoser.net> wrote:

> Erik
>
> On 02/22/2016 01:50 PM, Erik Weber wrote:
> > Adding a boilerplate in the install/admin docs that says "If you have no
> > other tools in place to handle system vm updates, consider enabling this
> > option: x.y.z" is good enough for me.
> > This is supposed to be a way for all those who don't have any
> other/better
> > means of doing this, not a mandatory/forced way of doing it for everyone
> > else.
>
> Sounds good. :)
>
>
> >> I would like to see an api for download and update latest system-vm
> >> template. AFAIK this is still not solved (without touching DB) to update
> >> system-vm templates having same version.
>
> What do you think about security updating system VM templates?
> Up-to-date system vm templates would be needed anyway.
>
> >> This way it would be up to the user to handle the upgrade and to think a
> >> bit further we could also define a rollback scenario (use previous
> >> template).
> >>
> >>
> > This thread is ment to discuss varies ways to achieve the goal, I did not
> > mean to propose a single way of doing it.
> > Pushing an ansible inventory script (that works with all major ACS
> > hypervisors) and a playbook is another option.
>
> It is a shame but I have no experience with "other hypervisors" with
> ACS, just VMware. :( How are KVM/XEN different in VRs then VMware, isn't
> there a VR accessible by SSH (by so called "linklocal" IP) from ACS
> management node?
>

No, with vmware you use a routable network that is directly accessible from
the mgmt server, but for xenserver and kvm we use a link local network
(169.254.x.x), that is not wired to any physical interface.

Connection to system vms is done by using the actual hypervisor as a SSH
jumpstation.
I think I actually hacked your dynamic inventory script at one time to
support this, I can see if I can find it again.

-- 
Erik

Re: [DISCUSS] Hiding the instance name from users

[Erik Weber]

Xenserver in this case.

-- 
Erik

Den tirsdag 23. februar 2016 skrev ilya <ilya.mailing.li...@gmail.com>
følgende:

> There is no good reason i am aware of.
>
> CloudStack was designed under a premise it will be ran by Cloud hosting
> and not enterprise. Hence there was not much emphasis on cloudstack
> instance name VS display name.
>
> With that said, down the road a feature has been added only to VMware to
> enable display name in vCenter.
>
> What hypervisors are you running?
>
> On 2/23/16 12:41 AM, Erik Weber wrote:
> > Hi,
> >
> > Before I file a bug I'd like to check if anyone know a good reason for
> > hiding the instance name, that is the typical i-2-123-VM name, from
> users?
> >
> > There are cases where an error returns the instancename rather than
> > name/uuid, and this is confusing when users have no means to map that to
> > something they know.
> >
> > Example log where instance name is used:
> >
> > Failed to attach volume myvolume to VM mymachine; Device 1 is used in VM
> > i-2-123-VM"}
> >
> > If you do operations manually, or one by one then it is easy to correlate
> > it to your last action, but couple this with any kind of automation where
> > you do things in parallell and it becomes a nightmare to figure out of.
> >
> > Opinions?
> >
>

Re: [ANNOUNCE] New committer: Rafael Weingartner

[Erik Weber]

Congrats Rafael :-)

On Tue, Feb 23, 2016 at 9:19 AM, Daan Hoogland 
wrote:

> The Project Management Committee (PMC) for Apache CloudStack
> has asked Rafael Weingartner to become a committer and we are pleased to
> announce that they have accepted.
>
> Rafael is part a hacking group in the south of Brasil and has been active
> as contributor of code and as reviewer. He had been accepted a few months
> ago but I totally forgot to make this announcement. My apologies to both
> him and the community for the tardiness of this announcement.
>
> Being a committer allows many contributors to contribute more
> autonomously. For developers, it makes it easier to submit changes and
> eliminates the need to have contributions reviewed via the patch
> submission process. Whether contributions are development-related or
> otherwise, it is a recognition of a contributor's participation in the
> project and commitment to the project and the Apache Way.
>
> Please join me in congratulating Rafael
>
> --Daan Hoogland
> on behalf of the CloudStack PMC
>

Re: [DISCUSS] Hiding the instance name from users

[Erik Weber]

That would be excellent Nuno!

Thanks for the search tip :-)


-- 
Erik

On Tue, Feb 23, 2016 at 9:53 AM, Nuno Tavares <n.tava...@tech.leaseweb.com>
wrote:

> Hi Erik,
>
> We also had this problem, and we patched CS to show it on the details.
> Nevertheless, I believe the API will allow you to filter by instance_name.
> An example of that is that you can actually search by the instance name in
> the UI.
>
> I'm going to ask our wizards to push this mainstream, if they didn't do it
> already.
>
> -NT
>
>
> Kind regards,
>
> Nuno Tavares
> Senior DevOps Infra Specialist
> LeaseWeb Technologies B.V.
>
> T: +31 20 316 0235
> M:
> E: n.tava...@tech.leaseweb.com
> W: http://www.leaseweb.com
>
> Luttenbergweg 8, 1101 EC Amsterdam, Netherlands
>
>
> 
> From: Erik Weber [terbol...@gmail.com]
> Sent: Tuesday, February 23, 2016 9:41 AM
> To: dev
> Subject: [DISCUSS] Hiding the instance name from users
>
> Hi,
>
> Before I file a bug I'd like to check if anyone know a good reason for
> hiding the instance name, that is the typical i-2-123-VM name, from users?
>
> There are cases where an error returns the instancename rather than
> name/uuid, and this is confusing when users have no means to map that to
> something they know.
>
> Example log where instance name is used:
>
> Failed to attach volume myvolume to VM mymachine; Device 1 is used in VM
> i-2-123-VM"}
>
> If you do operations manually, or one by one then it is easy to correlate
> it to your last action, but couple this with any kind of automation where
> you do things in parallell and it becomes a nightmare to figure out of.
>
> Opinions?
>
> --
> Erik
>

[DISCUSS] Hiding the instance name from users

[Erik Weber]

Hi,

Before I file a bug I'd like to check if anyone know a good reason for
hiding the instance name, that is the typical i-2-123-VM name, from users?

There are cases where an error returns the instancename rather than
name/uuid, and this is confusing when users have no means to map that to
something they know.

Example log where instance name is used:

Failed to attach volume myvolume to VM mymachine; Device 1 is used in VM
i-2-123-VM"}

If you do operations manually, or one by one then it is easy to correlate
it to your last action, but couple this with any kind of automation where
you do things in parallell and it becomes a nightmare to figure out of.

Opinions?

-- 
Erik

Re: [DISCUSS] Keeping system vms up to date

[Erik Weber]

On Mon, Feb 22, 2016 at 1:18 PM, Rene Moser  wrote:

> Hi
>
> I don't like the idea cloudstack management handles the "apt-get update
> && apt-get upgrade" (I am -1 for this solution) or at least I would like
> to disable it by configuration, if we go this direction.
>

It should by no means be mandatory, and wether or not it should be default
on is up for debate.
I have no strong opinion about the latter.

Adding a boilerplate in the install/admin docs that says "If you have no
other tools in place to handle system vm updates, consider enabling this
option: x.y.z" is good enough for me.

This is supposed to be a way for all those who don't have any other/better
means of doing this, not a mandatory/forced way of doing it for everyone
else.


We use ansible (what a surprise) to update the VR and also add some
> custom patches to it. We have a dynamic inventory getting all the VR
> with linklocal IP as ssh host and regulary run playbooks to these VRs
> running by a jenkins job.
>
> This sounds a bit kind of a hack at the beginning but it has the
> advantage that we are able to run the very same playbooks also against
> our test and stage cloud. Which gives a good feeling.
>
> I would like to see an api for download and update latest system-vm
> template. AFAIK this is still not solved (without touching DB) to update
> system-vm templates having same version.
>
> This way it would be up to the user to handle the upgrade and to think a
> bit further we could also define a rollback scenario (use previous
> template).
>
>
This thread is ment to discuss varies ways to achieve the goal, I did not
mean to propose a single way of doing it.
Pushing an ansible inventory script (that works with all major ACS
hypervisors) and a playbook is another option.

-- 
Erik

Re: [DISCUSS] Keeping system vms up to date

[Erik Weber]

We are comparing different sources, I was comparing the 'official' e.g. the
documented template, not the one regularely built by jenkins.

-- 
Erik


On Mon, Feb 22, 2016 at 1:11 PM, Remi Bergsma <rberg...@schubergphilis.com>
wrote:

> It _must_ be lying :-)
>
> When I install a systemvm from this last build:
>
> http://jenkins.buildacloud.org/job/build-systemvm64-master/lastBuild/artifact/tools/appliance/dist/systemvm64template-master-4.6.0-xen.vhd.bz2
>
>
> It has 4.6.0 version, but /etc/cloudstack-version shows it was built today.
>
> cat /etc/cloudstack-release
> Cloudstack Release 4.6.0 Mon Feb 22 09:33:04 UTC 2016
>
> Regards,
>
> Remi
>
>
>
>
>
>
> On 22/02/16 12:23, "Erik Weber" <terbol...@gmail.com> wrote:
>
> >On Mon, Feb 22, 2016 at 11:42 AM, Remi Bergsma <
> rberg...@schubergphilis.com>
> >wrote:
> >
> >> Hi Erik,
> >>
> >> The version might not change, but Jenkins builds new ones every night
> with
> >> latest OS patches:
> >> http://jenkins.buildacloud.org/job/build-systemvm64-master/
> >>
> >> Option 1) and 3) will work once we allow more space on the systemvm
> >> template for it to actually handle installing stuff. You then also
> assume
> >> they have internet acces, which may not be true.
> >>
> >>
> >If they aren't accessible from the internet then securing them isn't as
> >important either.
> >You still have to factor in the internal risk, but that is generally far
> >lower than the external risk.
> >
> >In cases where it is accessible from the internet, but does not have
> >outgoing access to the internet you're up for a treat.
> >
> >
> >
> >> Option 2) I think we already do that?
> >>
> >>
> >
> >Unless the web server is lying to me, then no:
> >eriweb@eriweb:~$ curl -Is
> >
> http://cloudstack.apt-get.eu/systemvm/4.6/systemvm64template-4.6.0-kvm.qcow2.bz2
> >| grep Last-Modified
> >Last-Modified: Mon, 09 Nov 2015 11:30:30 GMT
> >
> >
> >You can always upload a new template and replace it (a global config like
> >> systemvm.minversion or so exists). This will require to reboot all
> routers
> >> currently.
> >>
> >>
> >Sure I know that, but to replace the whole system vm just to update glibc,
> >haproxy or what have you seems a bit extreme.
> >
> >My intention for this thread was to figure out if we can provide
> cloudstack
> >users a way to ensure their system vms are kept up to date.
> >It should be optional so that more advanced users or those without
> internet
> >etc. don't run into issues because of it, while still keeping all those
> >small clouds that 'just works' safe and secure.
> >
> >--
> >Erik
>

Re: [DISCUSS] Keeping system vms up to date

[Erik Weber]

On Mon, Feb 22, 2016 at 11:42 AM, Remi Bergsma 
wrote:

> Hi Erik,
>
> The version might not change, but Jenkins builds new ones every night with
> latest OS patches:
> http://jenkins.buildacloud.org/job/build-systemvm64-master/
>
> Option 1) and 3) will work once we allow more space on the systemvm
> template for it to actually handle installing stuff. You then also assume
> they have internet acces, which may not be true.
>
>
If they aren't accessible from the internet then securing them isn't as
important either.
You still have to factor in the internal risk, but that is generally far
lower than the external risk.

In cases where it is accessible from the internet, but does not have
outgoing access to the internet you're up for a treat.



> Option 2) I think we already do that?
>
>

Unless the web server is lying to me, then no:
eriweb@eriweb:~$ curl -Is
http://cloudstack.apt-get.eu/systemvm/4.6/systemvm64template-4.6.0-kvm.qcow2.bz2
| grep Last-Modified
Last-Modified: Mon, 09 Nov 2015 11:30:30 GMT


You can always upload a new template and replace it (a global config like
> systemvm.minversion or so exists). This will require to reboot all routers
> currently.
>
>
Sure I know that, but to replace the whole system vm just to update glibc,
haproxy or what have you seems a bit extreme.

My intention for this thread was to figure out if we can provide cloudstack
users a way to ensure their system vms are kept up to date.
It should be optional so that more advanced users or those without internet
etc. don't run into issues because of it, while still keeping all those
small clouds that 'just works' safe and secure.

-- 
Erik

Re: [DISCUSS] Keeping system vms up to date

[Erik Weber]

On Mon, Feb 22, 2016 at 10:36 AM, Nux!  wrote:

> Hi Erik,
>
> Legit worry point.
>
> IMHO the updates of the VR and so on should be the job of whoever runs the
> cloud, just like it's the same person's job to keep the HVs up to date.
>

Well, to some point I agree, but we should do our best to reduce that need
IMHO. The hypervisor is under your control and is something you supply to
CloudStack.
The only reference a lot of people have to the system vm is that they do
the initial seeding (from a provided template in most cases), and that is
that.

In general you don't need to do much inside the system vms, and I fear that
there are a lot of clouds out there with uber old system vms because people
don't generally think about how they are exposed.

At minimum we should write something about it, e.g. "How to make sure your
system vm is up to date and secure" and possibly provide some options on
how to achieve that. Currently I don't think there's a single sign that you
have to worry about it at all.



>

I'm sure it's possible to get all the VRs registered in some sort of
> ansible/puppet thingy and keep track of them this way.
>
>
Sure, atleast ansible support dynamic inventory.


> Regarding up to date VM templates, I think part of the problem is solved
> as Jenkins is building 4.6 frequently:
> http://jenkins.buildacloud.org/job/build-systemvm64-master/
>
> It might just be a matter of uploading those to cloudstack.apt-get.eu.
>

That would solve 2)

-- 
Erik

[DISCUSS] Keeping system vms up to date

[Erik Weber]

As of 4.6 or so, we don't really need to distribute new system vm templates
all that often, and that is great for upgrades, but less so from a security
perspective.

With the current approach we ship old system vm templates, with out of date
packages, and there is currently no good out of the box way to handle that.

There is a few ways to handle it, including, but not limited to:

1) Introduce a configuration value that specifies if you want to run
apt-get update && apt-get upgrade on boot. This slows down deployments and
will only get worse as times passes and there are more packages to update.
An alternative is to specify a list of packages we _HAVE_ to keep updated
and only update those.

2) Package new system vms for all releases, but not bump the version number
(or introduce a patch version number). This is ment to ensure that new
cloud deployments are somewhat up to date, but won't update existing ones
nor ensure that the deployment is kept up to date.

3) Add an optional? cronjob that does apt-get update && apt-get upgrade,
the downside is that you risk having some downtime for certain services.

4) A combination of the previous 3.

And most likely other options I haven't thought of.

I feel we need to address this somehow or else we risk ending up as a very
negative headliner when the right (or wrong) bug/exploit gets out and takes
down a bunch of clouds..

-- 
Erik

Re: [Propose][New Feature] Storage Snapshots

[Erik Weber]

Volume backup only works if you rely on a single volume.

Any system using LVM (or dynamic disks in Windows) that spans more than one
volume is going to have problems using Volume Snapshots.
Or cases where your application stores data in different disks, perhaps
your data and your journal are laying on different volumes but you need
them to be consistent.

And so on.

-- 
Erik

On Fri, Feb 5, 2016 at 5:57 PM, Syed Mushtaq 
wrote:

> Paul,
>
> When you say actual backups, how would it be different from the Volume
> Snapshots that exist currently. My understanding is that Backups end up in
> Sec Storage whereas Snapshots are just a point-in-time state of your volume
> which can be restored back correct?
>
> -Syed
>
>
> On Fri, Feb 5, 2016 at 11:23 AM, Paul Angus 
> wrote:
>
> > Hi Syed,
> >
> > As I understand it, the SolidFire plugin will export the snapshot to
> > secondary storage if the user requests a template from the snapshot or
> > wants to download the snapshot from the cloud. This is a good, pragmatic
> > approach and yes Mike the SolidFire storage is super reliable and
> snapshots
> > on SolidFire arrays take up next to no space. BUT I think that we are
> > talking about a more general purpose API, and other storage systems may
> not
> > be as awesome as Mike's. That's my concern. Also, the time to transfer
> for
> > say 1TB to move from primary to sec storage and then create a VM template
> > out of it may be too long for users.
> >
> > @Mike I don’t think 'we' use the term volume snapshot for backup, it's
> > just that users want to do backups and a volume snapshot is the only type
> > of snapshot that copies the disk elsewhere and can be scheduled.
> >
> > I'm 'pondering' the implications of enabling actual backups (through
> > recognised backup providers) and the user requirements around them
> > (particularly restoration use cases) as a separate thread of work.
> >
> >
> >
> >
> >
> > [image: ShapeBlue] 
> > Paul Angus
> > VP Technology ,  ShapeBlue
> > d:  *+44 203 617 0528 | s: +44 203 603 0540*
> > <+44%20203%20617%200528%20%7C%20s:%20+44%20203%20603%200540>  |  m:
> > *+44 7711 418784* <+44%207711%20418784>
> > e:  *paul.an...@shapeblue.com | t: @cloudyangus*
> >   |  w:
> > *www.shapeblue.com* 
> > a:  53 Chandos Place, Covent Garden London WC2N 4HS UK
> > Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
> > Services India LLP is a company incorporated in India and is operated
> under
> > license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a
> > company incorporated in Brasil and is operated under license from Shape
> > Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of
> > South Africa and is traded under license from Shape Blue Ltd. ShapeBlue
> is
> > a registered trademark.
> > This email and any attachments to it may be confidential and are intended
> > solely for the use of the individual to whom it is addressed. Any views
> or
> > opinions expressed are solely those of the author and do not necessarily
> > represent those of Shape Blue Ltd or related companies. If you are not
> the
> > intended recipient of this email, you must neither take any action based
> > upon its contents, nor copy or show it to anyone. Please contact the
> sender
> > if you believe you have received this email in error.
> >
> >
> > -Original Message-
> > From: Syed Mushtaq [mailto:syed1.mush...@gmail.com]
> > Sent: 05 February 2016 15:31
> > To: dev@cloudstack.apache.org
> > Subject: Re: [Propose][New Feature] Storage Snapshots
> >
> > I think the terminology confusion comes from AWS where they do EBS
> > snapshots backed up to S3 and CloudStack sort of followed that. And as an
> > end user who is oblivious to the internals of my provider, my expectation
> > would be something similar to what AWS as that is my biggest reference
> > point.
> >
> > To your point Mike, I agree that a Primary Storage failure on SolidFire
> is
> > unlikely, there are other motivations for us to push data to secondary
> > storage. Primary storage (atleast for us) costs around 3 times as much as
> > secondary storage and snapshots on primary storage are rarely used
> > (especially for some of our customers who do daily backups).
> >
> >
> > On Fri, Feb 5, 2016 at 10:18 AM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> > > Some of the weirdness is around terminology.
> > >
> > > For most systems I've worked on, a snapshot and a backup are two
> > > completely different things (but CloudStack has traditionally used the
> > > term "volume snapshot" to mean backup).
> > >
> > > I will put in a SolidFire "plug" here and say, though, that if your
> > > primary storage is running on SolidFire that it is unlikely you'll
> > > encounter an issue where your primary storage goes offline (and you'll
> > > 

Re: [PROPOSAL] Freeze everything until we get CI

[Erik Weber]

I'd love to see this in the cloudstack repository.
Others might have an easier time getting access to hardware, and could use
it to help test releases/PR


Erik

Den fredag 29. januar 2016 skrev Bharat Kumar <bharat.ku...@citrix.com>
følgende:

> yes, we would be sharing it with the community and get this running in the
> ACS infra.
> Currently it can create a cloudstack test bed, runs tests and email the
> results.
>
> Here are some details on how this works and what is needed to set this up.
>
>   *   we use jenkins, cobbler, puppet and marvin to create cloudstack
> setup.
>   *   jenkins triggers the test runs, collects the test results and mails
> them.
>   *   cobbler is use to image the hosts and create Management server.
>   *   The management server is a VM and each time a test run is triggered
> we pull the latest code, build (dev setup) the MS and run it.
>   *   Need IPMI enabled servers to uses and Hosts in cloudstack setup.
> Cobbler installs the required OS on these hosts.
>   *   We use a XenServer to create management server VMs.
>
> The resources required to set this up.
>
>   *   We need two servers to host the VMs used in CI, one XenServer to
> host the Cloustack management servers and at least 3 IPMI enabled servers
> per cloudstack setup to run the BVTs.
>   *   some set of IPs (public and private IPs) and vlans.
>
> Once we have the resources in ACS infra we can start setting this up. But
> some work needs to
> be done to integrate this with the github to test and post the results in
> the PRs instead of mailing them.
>
> I think the best way to share it will be by implementing this in the ACS
> infra. Once we do this every one can pitch in, replicate and further
> contribute to this.
>
> Meanwhile i will commit the scripts to set this up and keep this going.
>
> Thanks,
> Bharat.
>
>
> On 28-Jan-2016, at 7:37 PM, Erik Weber <terbol...@gmail.com <javascript:;>
> <mailto:terbol...@gmail.com <javascript:;>>> wrote:
>
> Why not share it as is, then the community could help improving this,
> rather than this being a single company effort?
>
> --
> Erik
>
> On Thu, Jan 28, 2016 at 1:49 PM, Bharat Kumar <bharat.ku...@citrix.com
> <javascript:;><mailto:bharat.ku...@citrix.com <javascript:;>>>
> wrote:
>
> Hi All,
>
> I agree that we need to have a CI to deal with the large volume of PRs.
> The current travis CI is not good enough as it runs only simulator tests.
> We identified this issue and came up with a effective CI for automating
> test runs for a each PR. This is already functional, with few github
> integration aspects pending. We are internally stabilizing it before
> sharing it.
>
> We have been in touch with David Nalley ( CC’ed )  in making this
> operational for entire community using ACS infra.
>
>
> For your reference, here is the FS I have shared with the community
> earlier and also in this thread before, your feedback is welcome.
> (
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Test+bed+orchestrator+and+test+runner+to+enable+continuos+integration
> ).
>
> Thanks,
> Bharat.
>
>
>
>
> On 28-Jan-2016, at 4:26 PM, Rohit Yadav <rohit.ya...@shapeblue.com
> <javascript:;> rohit.ya...@shapeblue.com <javascript:;>>> wrote:
>
> All,
>
> I’m sorry to get to have the PRs merged without adhering to the strict
> testing requirements. While I think PRs were alright and it did not break
> anything, the way it was merged made people uncomfortable that there is
> some sort of haste in doing this fast which there is none.
>
> I’ll not repeat this and hope you understand that I never had any hidden
> agenda but to simply help people with some PRs.
>
> Regards.
>
> On 28-Jan-2016, at 11:36 AM, Sebastien Goasguen <run...@gmail.com
> <javascript:;> run...@gmail.com <javascript:;>>> wrote:
>
> Hi Folks,
>
> My proposal to freeze until we get CI was indeed due to seeing Rohit’s
> commit but was by no means a personal attack or judgment.
>
> We have lots of PR pending (as mentioned before by Remi) and we need
> people to help review and test.
> So thanks to Rohit.
>
> My only concerns were two fold:
>
> 1- We need  to keep to adhere to our release principles:
>
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up
>
> Hence I replied to some PR asking if they needed to be merged directly in
> master or not and wondered about the release branches.
>
> With so many releases in flight it is not yet clear to me where we start
> to apply a PR ?
>
> 2- We need to keep testing and post r

Re: Citrix CloudPltform Question-Hyper-V

[Erik Weber]

On Thu, Jan 28, 2016 at 11:41 PM, Pinnock Jr., Clifford R <
clifford.pinnoc...@ca.com> wrote:

> Hi.
>
> Here are logs
>
> dstk-svc=na.domain.com 
> ","_role":"Image"}},"name":"routing-9","hypervisorType":"Hyperv"}},"destTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"origUrl":"
> https://download.cloud.com/templates/4.5.1/systemvm64template-2015-05-14-4.5.1-hyperv.vhd.bz2","uuid":"8a54a66a-bafa-11e5-8210-005056aa1ca9","id":9,"format":"VHD","accountId":1,"checksum":"70ab1d60c578156561aa143443003f81","hvm":false,"displayText":"SystemVM
> Template
> (HyperV)","imageDataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"b40338b6-f5c8-351a-8d28-2a0e7b9433b8","id":4,"poolType":"SMB","host":"pa-winfilesvr","path":"/HVPrimary1","port":445,"url":"SMB://pa-winfilesvr/HVPrimary1/?ROLE=Primary=b40338b6-f5c8-351a-8d28-2a0e7b9433b8"}},"name":"routing-9","hypervisorType":"Hyperv"}},"executeInSequence":false,"options":{},"wait":10800}}]
> }
>
> 2016-01-28 14:28:36,009 DEBUG [c.c.a.m.DirectAgentAttache]
> (DirectAgent-13:ctx-ad8f51b8) (logid:774b885f) Seq 5-2841208414917361734:
> Executing request
>
> 2016-01-28 14:28:36,017 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-13:ctx-ad8f51b8) (logid:d1d35783) POST request to
> https://10.102.0.91:8250/api/HypervResource/org.apache.cloudstack.storage.command.CopyCommand
> with contents
> {"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/1/9/","origUrl":"
> https://download.cloud.com/templates/4.5.1/systemvm64template-2015-05-14-4.5.1-hyperv.vhd.bz2","uuid":"8a54a66a-bafa-11e5-8210-005056aa1ca9","id":9,"format":"VHD","accountId":1,"checksum":"70ab1d60c578156561aa143443003f81","hvm":false,"displayText":"SystemVM
> Template
> (HyperV)","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"cifs://
> pa-winfilesvr.na.domain.com/HVSecondary1
> 
> ","_role":"Image"}},"name":"routing-9","hypervisorType":"Hyperv"}},"destTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"origUrl":"
> https://download.cloud.com/templates/4.5.1/systemvm64template-2015-05-14-4.5.1-hyperv.vhd.bz2","uuid":"8a54a66a-bafa-11e5-8210-005056aa1ca9","id":9,"format":"VHD","accountId":1,"checksum":"70ab1d60c578156561aa143443003f81","hvm":false,"displayText":"SystemVM
> Template
> (HyperV)","imageDataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"b40338b6-f5c8-351a-8d28-2a0e7b9433b8","id":4,"poolType":"SMB","host":"pa-winfilesvr","path":"/HVPrimary1","port":445,"url":"SMB://pa-winfilesvr/HVPrimary1/?ROLE=Primary=b40338b6-f5c8-351a-8d28-2a0e7b9433b8"}},"name":"routing-9","hypervisorType":"Hyperv"}},"executeInSequence":false,"options":{},"contextMap":{"job":"job-22/job-5552","logid":"d1d35783"},"wait":10800}
>
> 2016-01-28 14:28:36,022 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-13:ctx-ad8f51b8) (logid:d1d35783) Sending cmd to
> https://10.102.0.91:8250/api/HypervResource/org.apache.cloudstack.storage.command.CopyCommand
> cmd
> data:{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/1/9/","origUrl":"
> https://download.cloud.com/templates/4.5.1/systemvm64template-2015-05-14-4.5.1-hyperv.vhd.bz2","uuid":"8a54a66a-bafa-11e5-8210-005056aa1ca9","id":9,"format":"VHD","accountId":1,"checksum":"70ab1d60c578156561aa143443003f81","hvm":false,"displayText":"SystemVM
> Template
> (HyperV)","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"cifs://
> pa-winfilesvr.na.domain.com/HVSecondary1
> 
> ","_role":"Image"}},"name":"routing-9","hypervisorType":"Hyperv"}},"destTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"origUrl":"
> https://download.cloud.com/templates/4.5.1/systemvm64template-2015-05-14-4.5.1-hyperv.vhd.bz2","uuid":"8a54a66a-bafa-11e5-8210-005056aa1ca9","id":9,"format":"VHD","accountId":1,"checksum":"70ab1d60c578156561aa143443003f81","hvm":false,"displayText":"SystemVM
> Template
> (HyperV)","imageDataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"b40338b6-f5c8-351a-8d28-2a0e7b9433b8","id":4,"poolType":"SMB","host":"pa-winfilesvr","path":"/HVPrimary1","port":445,"url":"SMB://pa-winfilesvr/HVPrimary1/?ROLE=Primary=b40338b6-f5c8-351a-8d28-2a0e7b9433b8"}},"name":"routing-9","hypervisorType":"Hyperv"}},"executeInSequence":false,"options":{},"contextMap":{"job":"job-22/job-5552","logid":"d1d35783"},"wait":10800}
>
> 2016-01-28 14:28:36,110 DEBUG [c.c.h.h.r.HypervDirectConnectResource]
> (DirectAgent-13:ctx-ad8f51b8) (logid:d1d35783) POST response is
> [{"org.apache.cloudstack.storage.command.CopyCmdAnswer":{"result":false,"details":"org.apache.cloudstack.storage.command.CopyCommand
> failed on exception, Could not find a part of the path '\\
> pa-winfilesvr.na.domain.com 
> \HVSecondary1\template\tmpl\1\9'.","newData":null,"contextMap":{}}}]
>
> 2016-01-28 

Re: Citrix CloudPltform Question-Hyper-V

[Erik Weber]

Is your management server running on linux or windows?

If it is on linux I guess you could CIFS mount it and use the regular
system vm install method from [1], but use the appropriate version.
If it is on windows I have no idea, never used cloudstack in combination
with windows/hyper-v before, someone else might have though.

-- 
Erik

On Thu, Jan 28, 2016 at 11:26 PM, Pinnock Jr., Clifford R <
clifford.pinnoc...@ca.com> wrote:

> Hi.
>
> I am with a Citrix partner and we are trying to deploy CloudPlatform
> integrated with Hyper-V, all is well except we get exceptionCould not find
> a part of the path /”secondary”tmpl/1/9 when creating the system vm’s. The
> thing is how are we supposed to get the system vm template onto the
> secondary if it is SMB and we can’t mount it onto management? Any thoughts
> on this issue would be appreciated.
>
>
>
> *Clifford Pinnock Jr.*
> Principal, Platform Engineer
>
> CA Technologies | 160 Bridge St Hartfield Executive Pk | East Windsor, CT
> 06088-9548
> Mobile: +1 860 861 6744 | clifford.pinnoc...@ca.com
>
> [image: CA] [image: Twitter]
> [image: Slideshare]
> [image: Facebook]
> [image: YouTube]
> [image: LinkedIn]
> [image:
> Google+] [image: Google+]
> 
>
>
>

Re: [PROPOSAL] Freeze everything until we get CI

[Erik Weber]

Why not share it as is, then the community could help improving this,
rather than this being a single company effort?

-- 
Erik

On Thu, Jan 28, 2016 at 1:49 PM, Bharat Kumar 
wrote:

> Hi All,
>
> I agree that we need to have a CI to deal with the large volume of PRs.
> The current travis CI is not good enough as it runs only simulator tests.
> We identified this issue and came up with a effective CI for automating
> test runs for a each PR. This is already functional, with few github
> integration aspects pending. We are internally stabilizing it before
> sharing it.
>
> We have been in touch with David Nalley ( CC’ed )  in making this
> operational for entire community using ACS infra.
>
>
> For your reference, here is the FS I have shared with the community
> earlier and also in this thread before, your feedback is welcome.
> (
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Test+bed+orchestrator+and+test+runner+to+enable+continuos+integration
> ).
>
> Thanks,
> Bharat.
>
>
>
>
> On 28-Jan-2016, at 4:26 PM, Rohit Yadav > wrote:
>
> All,
>
> I’m sorry to get to have the PRs merged without adhering to the strict
> testing requirements. While I think PRs were alright and it did not break
> anything, the way it was merged made people uncomfortable that there is
> some sort of haste in doing this fast which there is none.
>
> I’ll not repeat this and hope you understand that I never had any hidden
> agenda but to simply help people with some PRs.
>
> Regards.
>
> On 28-Jan-2016, at 11:36 AM, Sebastien Goasguen > wrote:
>
> Hi Folks,
>
> My proposal to freeze until we get CI was indeed due to seeing Rohit’s
> commit but was by no means a personal attack or judgment.
>
> We have lots of PR pending (as mentioned before by Remi) and we need
> people to help review and test.
> So thanks to Rohit.
>
> My only concerns were two fold:
>
> 1- We need  to keep to adhere to our release principles:
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up
>
> Hence I replied to some PR asking if they needed to be merged directly in
> master or not and wondered about the release branches.
>
> With so many releases in flight it is not yet clear to me where we start
> to apply a PR ?
>
> 2- We need to keep testing and post results of tests.
>
> Currently it is manual and but there has been a strong guarantee in the
> last releases that the PR where not going to break things.
> While I agree that some PR are small and *should* not break things,
> history has shown that even small unrelated things *somehow* can affect the
> behavior of cloudstack.
>
> So I proposed a freeze because:
>
> - Remi stepped down as RM and we don’t have an official RM yet.
> - The code has reached a solid state and we don’t want to do anything that
> changes that
> - We have a proposal for LTS on the floor
> - We still don’t have CI.
>
> So my standpoint is that we focused in the last 6 months on getting our
> release principles right (pending LTS principles), code has stabilized and
> we can release. Awesome.
>
> Now is probably a good time to concentrate our limited resources on
> figuring out automated CI.
>
> - For instance as far as I know Travis is bonkers…(reports green but does
> not do anything)
> - And with citrix stepping out, we need to take control of the jenkins
> slaves (some of which are on AWS and still paid by Citrix…)
>
> My email while triggered by seeing Rohit’s commits, was not a judgement or
> critic of his actions, so let’s not get into a personal argument here.
>
> -Sebastien
>
> On Jan 28, 2016, at 11:00 AM, Rohit Yadav 
> wrote:
>
> So, since some have directly (over IM etc) or indirectly have thrown
> allegations on me since I merged most of the PRs.
> Here is a list of those 12 PRs and answers on why they were merged on
> case-by-case basis.
> Please keep any further replies technical and to the specific PR, please
> point out and revert if needed:
>
> 1. https://github.com/apache/cloudstack/pull/1288
>
> Enough LGTMs, JS related change and fix tested with UI screenshot from
> Remi. I personally looked at the diff and therefore then merged.
>
> 2. https://github.com/apache/cloudstack/pull/1274/files
>
> Enough LGTMs, a simple NPE fix one-liner. I personally thought we can
> cheat here and given Travis/Jenkins passed I merged it.
>
> 3. https://github.com/apache/cloudstack/pull/1261/files
>
> Enough LGTMs, the diff only removed unused variable leading to change in
> the constructor definition. Explicit integration tests are not necessary as
> it’d simply dead-code removal and as the simulator smoke tests passed with
> Travis/Jenkins passed so I merged it.
>
> 4. https://github.com/apache/cloudstack/pull/1048
>
> Enough LGTMs. This change is related to a marvin test itself where it adds
> 2 new test methods — so no need