Re: [ACS 4.3] RC update

[Erik Weber]

On Tue, Jan 21, 2014 at 10:41 PM, Animesh Chaturvedi <
animesh.chaturv...@citrix.com> wrote:

> Folks
>
> I don't see any outstanding blockers, the automation results were also
> published and seemed satisfactory.  I will process with building RC later
> today  I will also pull in few issues that were under discussion in
> security mailing list but later were identified as hardening issues
> (unencrypted passwords) and did not require to go through security process.
>
>

I haven't seen any automation tests for vmware?

-- 
Erik Weber

Re: [Proposal]CloudStack IAM plugin feature (CLOUDSTACK-5920)

[Erik Weber]

On Tue, Jan 21, 2014 at 10:57 PM, Prachi Damle wrote:

> Min and myself would like to propose an identity and access management
> plugin for CloudStack for the ACS 4.4 release.
>
> Here is the functional spec we have drafted for the first phase:
>
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+Identity+and+Access+Management+%28IAM%29+Plugin
>
> Currently CloudStack provides very limited IAM services and there are
> several drawbacks:
>
> - Offers few roles out of the box (user and admin) with prebaked access
> control. There is no way to create customized policies and permissions.
> - Some resources have access control baked into them. E.g., shared
> networks, projects etc.
> - We have to create special dedicateXXX APIs to grant permissions to
> resources.
> - Also it does not provide the flexibility to integrate with other RBAC
> implementations say using AD/LDAP
>
> Goal for this feature would be to address these limitations and offer true
> IAM services in a phased manner.
> As a first phase, we need to separate out the current access control into
> a separate component based on the standard IAM terminologies. Also we need
> to create an access check mechanism to be used by the API layer to avoid
> the checks scattered over the api/service layer. The read/listing APIs need
> to be refactored accordingly to consider the policy based access granting.
>
> Please provide feedback/suggestions anyone has.
>
>

Would love to see SAML 2.0 support, but any IAM solution is a good start :-)

-- 
Erik Weber

Re: Disks in ACS Vmware

[Erik Weber]

On Fri, Jan 31, 2014 at 7:46 AM, Girish Shilamkar wrote:

> Hello,
>
> In ACS KVM the volumes attached are seen as normal disk /dev/vda /dev/vdb
> and so on. But with vmware it seems Volume Groups are being used.
> The root device is /dev/mapper/VolGroup00-LogVol100 which previously it
> was /dev/hda.
> So now when I attach a new datadisk to vm running on vmware what device/vg
> is created ?
>
>

They should be added as sd[a-z], but your template might utilize LVM.

Run a 'dmesg | grep sd' and you should see your disks.
'sda' would be your first disk, 'sdb' the second etc.


-- 
Erik Weber

Re: [DISCUSS] api level access controll

[Erik Weber]

On Fri, Jan 31, 2014 at 12:00 PM, Daan Hoogland wrote:

> H,
>
> I git a question of an operator ad Schuberg Philis to crete a set of
> api keys and to have control over excatly what api calls are allowed
> for this set of keys. Does anybody else recognise this use case?
> already hacked it in? have an idea how to do it? has a reason why not
> to do it?
>
>

Having more flexibility with access control is something that I and the
company I work for appreciate.
I can also see several use cases for this, monitoring user that should only
be able to list stuff (but all stuff) et cetera.

-- 
Erik Weber

Re: Management server failed to start with master

[Erik Weber]

On Fri, Jan 31, 2014 at 10:29 PM, Rayees Namathponnan <
rayees.namathpon...@citrix.com> wrote:

> Hi All,
>
> Management server failed to start with latest master, observed below
> error; anyone faced this issue?
>
>
> java.lang.UnsupportedClassVersionError:
> org/apache/cloudstack/spring/module/web/CloudStackContextLoaderListener :
> Unsupported major.minor version 51.0 (unable to load




Do you have Java 7 installed? If not, try upgrading. If you do, verify that
it's being used.


-- 
Erik Weber

Re: Disks in ACS Vmware

[Erik Weber]

On Tue, Feb 4, 2014 at 8:14 AM, Girish Shilamkar  wrote:

> Thanks for the reply Erik.
>
> So sd[a-z] are the disks which will be added if default Centos template is
> used ?
>
>

sd[a-z] is the standard naming convention for scsi disk in Linux as far as
I know.
Vmware emulates a regular scsi controller and all consequent disks are
virtual scsi devices.

So yes, you should find all your disks as sd[a-z]+. Currently the limit in
vmware is 14 or something with 4.3, but the potential is much more.

-- 
Erik

Re: Cloudstack 4.3 Zone not deletable

[Erik Weber]

On Mon, Feb 10, 2014 at 6:36 AM, Tejas Gadaria wrote:

> Hi,
>
> I am not able to delete Zone. error is "The zone is not deletable because
> there are virtual machines running in this zone"
> but before deleting zone I have Deleted system VMs, Priamary & Secondary
> Storage, Host, Pod, Cluster & disabled Zone also. (not created virtual
> router at this point).
>
>

Are the vms expunged as well?


-- 
Erik

Fwd: System VM trouble with fresh CloudStack 4.2.1 and XenServer 6.2 SP1

[Erik Weber]

Sorry for cross posting, but I'm really out of ideas


I've just done a fresh installation of ACS 4.2.1 with XS 6.2 SP1 hosts.
Primary and secondary storage are on NFS.

ssvm and cpvm launches, as in they get created and starts, but for some
reason they do not seem to use/provision the systemvm.iso, and when looking
into the console the vm's are rather clean (no cloud-scripts or similar)
and without configured nics.

I have no idea why this happens, or how to troubleshoot it further, so any
advice are highly appreciated.

There are no errors or warnings in neither the MS log nor the SMlog on the
xenserver.

systemvm.iso resides in /usr/share/cloudstack-common/vms on the MS server
and /opt/xensource/packages/iso on the xenserver hosts.


-- 
Erik Weber

Re: [PROPOSAL] Granular Controller Support in CloudStack over VMware deployments

[Erik Weber]

I don't think this should be tied to the template, but rather the
instance/disk. A template could of course specify it's preferred controller.

I don't have a use case for it, but you could potentially want to use
different controllers for different disks. E.g. your ROOT-volume might be
on a high end SAN you want to utilize with PV-driver, whilst your
DATA-volume might be on an old NFS solution where you'll live fine with the
SAS or Parallel driver.


However, for the first release the most important part is that a selection
gets introduced.
Currently you cannot install Windows 8.1 or Windows 2012 R2 on VMware with
CloudStack, which is a showstopper for many (for us - so much that we
changed hypervisor).

-- 
Erik


On Mon, Feb 17, 2014 at 6:42 AM, Alex Huang  wrote:

> Sateesh,
>
> I think if you want to do this then it points to a larger change to
> templates.  Today, the templates carry no meta information.  This means
> templates should carry meta information regarding the os image and how to
> support it.  This should not specifically target vmware.  It can benefit
> all other hypervisors.  I know Anthony's also been working on something
> similar for XenServer.  I suggest you guys get together and think about the
> right approach to abstract this and how to pass this information to the
> hypervisor from the template.
>
> --Alex
>
> > -Original Message-
> > From: Sateesh Chodapuneedi [mailto:sateesh.chodapune...@citrix.com]
> > Sent: Sunday, February 16, 2014 8:48 PM
> > To: dev@cloudstack.apache.org
> > Subject: [PROPOSAL] Granular Controller Support in CloudStack over
> > VMware deployments
> >
> > Hi,
> >
> > I would like to add support for granular disk controller support for
> CloudStack
> > over VMware deployments.
> >
> > To access virtual disks, CD/DVD-ROM, and SCSI devices, a virtual machine
> > uses storage controllers.
> >
> > Virtual storage controllers appear to a virtual machine as different
> types of
> > controllers of type IDE or SCSI. Further SCSI controllers can be
> classified into 4
> > sub types, as below
> > BusLogic Parallel
> > LSI Logic Parallel,
> > LSI Logic SAS
> > VMware Paravirtual SCSI
> >
> > Currently CloudStack supports following combinations only.
> > DATA volumes - SCSI controller (LSI Logic Parallel) - Hard coded in
> source
> > code, no option for user to edit/choose the controller type
> > ROOT volumes - IDE or SCSI (LSI Logic Parallel) - Baed on value of
> global
> > configuration parameter "vmware.root.disk.controller"
> >
> > Currently the instances are deployed with the the LSI Parallel
> controller type.
> > This might result in failure to boot when attempting to deploy templates
> that
> > use the LSI SAS controller.
> >
> > CloudStack should provide administrator the means to choose the type of
> > disk controller (including sub types listed in introduction section
> above) for an
> > instance. The controller to be used by VM to access virtual disk
> (volume) can
> > decided for various reasons. Some of them are listed here,
> > *   Some controllers are optimized for best performance over specific
> > backend infrastructure like SAN. Ex: VMware Paravirtual SCSI
> > *Compatibility of some controllers with VM's virtual hardware
> version or
> > guest operating system.
> > *Operating system vendor recommendation and default set of drivers
> > distributed as part of operating system image. Ex: Windows 8.1 ISO
> doesn't
> > have Lsi Logic Parallel SCSI drivers by default. Hence a virtual disk
> attached to
> > this controller won't accessible during installation of OS using the ISO.
> >
> > CloudStack should provide administrator an option which auto detects the
> > recommended disk controller for the instance's guest operating system and
> > applicable virtual hardware version.
> > Kindly let me know your thoughts.
> >
> > JIRA ticket - CLOUDSTACK-4787
> >
> > Note:- Detailed Functional Specification is to be added at
> cwiki.apache.org
> > under 4.4 Design documents. Currently cwiki.apache.org is down. Waiting
> for
> > the site to come up to add the FS document.
> >
> > Regards,
> > Sateesh
>
>

Re: Xen Server Setup

[Erik Weber]

Log in on your ssvm and check that internet access works.

Erik
23. feb. 2014 20:38 skrev "Mo"  følgende:

> Hello,
>
> I am attempting to setup cloudstack on Xen Server, I have setup the traffic
> labels it seems all is well in that regard. The system VMs are running
> without issue and setup the way I would like them as follows:
>
> Public IP Addressx.x.x.x (omitted for obvious reasons)Private IP Address
> 10.4.234.151Link Local IP Address169.254.0.21
> I would like to know what I am doing wrong, as you can see I have a Private
> IP address and a public facing IP address, but, no internet access is
> provided within. Thus resulting in the inability to download the CentOS
> Template (which is it possible to obtain a NEWER template when installing
> Cloudstack).
>
> Also, I am not seeing ingrees/regress rules to allow inbound/outbound
> connections; so I am a little at a loss on how to resolve this.
>
> If someone could assist me and/or direct me in the right way that would be
> great.
>
> - Maurice
>

Re: Xen Server Setup

[Erik Weber]

You can access the console from your hypervisor (login: root/password) and
check. Does your mgmt network have internet access?

Erik
23. feb. 2014 20:52 skrev "Mo"  følgende:

> Erik,
>
> As I stated in my first message, there is no access to the system VMs. I
> suspect I am not fully understanding how to input the subnets in correctly,
> public / private.
>
>
>
>
> On Sun, Feb 23, 2014 at 2:49 PM, Erik Weber  wrote:
>
>> Log in on your ssvm and check that internet access works.
>>
>> Erik
>> 23. feb. 2014 20:38 skrev "Mo"  følgende:
>>
>> > Hello,
>> >
>> > I am attempting to setup cloudstack on Xen Server, I have setup the
>> traffic
>> > labels it seems all is well in that regard. The system VMs are running
>> > without issue and setup the way I would like them as follows:
>> >
>> > Public IP Addressx.x.x.x (omitted for obvious reasons)Private IP Address
>> > 10.4.234.151Link Local IP Address169.254.0.21
>> > I would like to know what I am doing wrong, as you can see I have a
>> Private
>> > IP address and a public facing IP address, but, no internet access is
>> > provided within. Thus resulting in the inability to download the CentOS
>> > Template (which is it possible to obtain a NEWER template when
>> installing
>> > Cloudstack).
>> >
>> > Also, I am not seeing ingrees/regress rules to allow inbound/outbound
>> > connections; so I am a little at a loss on how to resolve this.
>> >
>> > If someone could assist me and/or direct me in the right way that would
>> be
>> > great.
>> >
>> > - Maurice
>> >
>>
>
>

Re: 4.4 Feature Freeze

[Erik Weber]

As a customer of several companies involved with cloudstack i must say that
having a reliable time schedule is more important than having feature X.
We've been waiting for 4.3 since we discovered a bug that got fixed in 4.3
but not in 4.2 branch and rendered us unable to use that version.

If 4.3 had held it's schedule we would've been rolling almost one month
ago, instead we are still wasting time waiting for a supported version.

If 4.4 now were to be postponed and an important bug appears in 4.3 with a
fix in 4.4 it would have me thinking about moving to other solutions if i
know that it'll be 5-6 months before release.

Erik
 27. feb. 2014 20:57 skrev "Mike Tutkowski" 
følgende:

> I'm not sure I would say that not moving the feature-freeze date is a
> penalty, but it does have consequences for customers...as does the fact
> that we miss our release deadlines consistently.
>
> If you are working on a feature that hasn't been advertised to your
> customers via a roadmap or some other mechanism, then it doesn't really
> matter, I suppose, if you release that feature today or, say, four months
> from now when the next release comes out.
>
> However, many of us work under the direction of a roadmap that has been
> made visible to our customers. In such an environment, these customers do
> expect when you tell them feature X will be out in, say, 4.3 that it does,
> in fact, come out in 4.3 and not four months later in 4.4.
>
> I just wanted to point this out because I've seen in several e-mails over
> the past year the following idea: If a feature doesn't make it into this
> release, no big deal - it can be put in the next release.
>
> While technically true, this does not take into consideration customer
> expectations around feature-release dates.
>
> Personally, I'd rather push a feature-freeze date back by a couple weeks
> than make customers (of mine or anyone else's) wait another 1/3 of a year
> or more for the feature(s) in question.
>
> At some point, however, we need to conduct a retrospective to uncover why
> we are not hitting our deadlines. Perhaps the deadlines are too tight?
> Perhaps there is a process issue missing (or in place) that prevents us
> from doing so? etc.
>
> Thanks!
>
>
> On Wed, Feb 26, 2014 at 8:21 PM, John Kinsella  wrote:
>
> > I don't see not moving the freeze date as a penalty.  If a feature
> doesn't
> > make the current deadline, it moves to the next release, which is still a
> > few months away. For significant issues, it's not uncommon for us to
> allow
> > them in late.
> >
> > What we have a stronger need for than shifting a date, by several orders
> > of magnitude, is understanding why the RC process took so long and what
> we
> > can do in the future to make that not so painful.
> >
> > For the record I'm +0 on moving the feature freeze date.
> >
> > John
> >
> > On Feb 26, 2014, at 7:10 PM, Ram Ganesh  wrote:
> >
> > > I share it too. Many developers in the community went out of their way
> > to get a cleaner RC and thereby impacting their feature development
> > efforts. We shouldn't be penalizing them with this 2 week's feature
> freeze
> > schedule
> > >
> > > Thanks,
> > > RamG
> > >
> > >> -Original Message-
> > >> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> > >> Sent: 27 February 2014 03:00
> > >> To: dev@cloudstack.apache.org
> > >> Subject: RE: 4.4 Feature Freeze
> > >>
> > >> Mike I share your opinion most of us have been pretty much on 4.3
> until
> > >> now, and pushing out the release seems reasonable. As I called out in
> > earlier
> > >> mail the feature proposal date was not called out for 4.4 and as such
> > giving
> > >> little extra room seems reasonable.
> > >>
> > >> Animesh
> > >>
> > >>> -Original Message-
> > >>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com]
> > >>> Sent: Wednesday, February 26, 2014 7:29 AM
> > >>> To: dev@cloudstack.apache.org
> > >>> Subject: Re: 4.4 Feature Freeze
> > >>>
> > >>> I think we're having this discussion after every release because
> we're
> > >>> beginning to realize that a four-month release cycle has not been
> very
> > >>> realistic for us yet.
> > >>>
> > >>> The main issue I encounter is our month-long RC cycle where I spend a
> > >>> bunch of time validating the RC and (during that timeframe) less time
> > >>> developing for the next release as I had initially planned.
> > >>>
> > >>> Perhaps instead of extending the cycle we could consider ways to
> > >>> actually meet the schedule on a consistent basis. That would be fine,
> > as
> > >> well.
> > >>>
> > >>>
> > >>> On Wed, Feb 26, 2014 at 8:04 AM, Hugo Trippaers 
> > >>> wrote:
> > >>>
> >  -1 on postponing the feature freeze. We are having this discussion
> >  after every release, however we agreed to do a 4 month cycle so
> >  let's stick
> > >>> to it.
> > 
> >  If there are important features that are currently being developed
> >  but might not make this cut-off date we 

Re: 4.4 Feature Freeze

[Erik Weber]

Of course, as a customer there might be specific feature that I'd really
want to get released as planned.
And well, I'm not saying it's not possible to be flexible with a date or
two in specific cases.
I'm a bit more worried that postponing becomes the norm, e.g. that all
future versions always get delayed,
which in turn delays the next version. Before you know it you're down to
three releases per year.

As a customer, and service provider, having a bug free and stable
environment is more important
than having the hottest new features out there. Of course they're always
welcome, but if I have to choose
between 'über feature X but 2 months delayed' and 'fixes that critical bug
you have on time' I'll take the latter
one any day.

And before anyway says it, we could of course roll our own versions, and
just use the latest RC, but that'd
be problematic for support contracts.

Erik


On Fri, Feb 28, 2014 at 6:59 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:

> Personally I'm not at much risk of missing a deadline if it's still two
> weeks out. I was thinking more along the lines that others - who have been
> hard at work on 4.3 RC testing, as well - might miss their deadlines.
>
> I can see your point of view, Erik. In my case, it's the opposite:
> customers would rather have feature X from SolidFire sooner rather than
> wait another 1/3 of a year.
>
>
> On Fri, Feb 28, 2014 at 7:40 AM, Erik Weber  wrote:
>
> > As a customer of several companies involved with cloudstack i must say
> that
> > having a reliable time schedule is more important than having feature X.
> > We've been waiting for 4.3 since we discovered a bug that got fixed in
> 4.3
> > but not in 4.2 branch and rendered us unable to use that version.
> >
> > If 4.3 had held it's schedule we would've been rolling almost one month
> > ago, instead we are still wasting time waiting for a supported version.
> >
> > If 4.4 now were to be postponed and an important bug appears in 4.3 with
> a
> > fix in 4.4 it would have me thinking about moving to other solutions if i
> > know that it'll be 5-6 months before release.
> >
> > Erik
> >  27. feb. 2014 20:57 skrev "Mike Tutkowski" <
> mike.tutkow...@solidfire.com>
> > følgende:
> >
> > > I'm not sure I would say that not moving the feature-freeze date is a
> > > penalty, but it does have consequences for customers...as does the fact
> > > that we miss our release deadlines consistently.
> > >
> > > If you are working on a feature that hasn't been advertised to your
> > > customers via a roadmap or some other mechanism, then it doesn't really
> > > matter, I suppose, if you release that feature today or, say, four
> months
> > > from now when the next release comes out.
> > >
> > > However, many of us work under the direction of a roadmap that has been
> > > made visible to our customers. In such an environment, these customers
> do
> > > expect when you tell them feature X will be out in, say, 4.3 that it
> > does,
> > > in fact, come out in 4.3 and not four months later in 4.4.
> > >
> > > I just wanted to point this out because I've seen in several e-mails
> over
> > > the past year the following idea: If a feature doesn't make it into
> this
> > > release, no big deal - it can be put in the next release.
> > >
> > > While technically true, this does not take into consideration customer
> > > expectations around feature-release dates.
> > >
> > > Personally, I'd rather push a feature-freeze date back by a couple
> weeks
> > > than make customers (of mine or anyone else's) wait another 1/3 of a
> year
> > > or more for the feature(s) in question.
> > >
> > > At some point, however, we need to conduct a retrospective to uncover
> why
> > > we are not hitting our deadlines. Perhaps the deadlines are too tight?
> > > Perhaps there is a process issue missing (or in place) that prevents us
> > > from doing so? etc.
> > >
> > > Thanks!
> > >
> > >
> > > On Wed, Feb 26, 2014 at 8:21 PM, John Kinsella 
> wrote:
> > >
> > > > I don't see not moving the freeze date as a penalty.  If a feature
> > > doesn't
> > > > make the current deadline, it moves to the next release, which is
> > still a
> > > > few months away. For significant issues, it's not uncommon for us to
> > > allow
> > > > them in 

Re: Looking for test folks on the community!

[Erik Weber]

On Thu, Feb 27, 2014 at 7:00 AM, Raja Pullela wrote:

> Hi,
>
> Can you please respond if you are actively involved or looking get
> involved in testing 4.4 Release?
>


We'll be testing, but it's hard to give exact figures up front.

-- 
Erik

Re: [DISCUSS] realhostip.com going away

[Erik Weber]

On Fri, Feb 28, 2014 at 9:27 PM, John Kinsella  wrote:

> Folks: Recently the PMC was informed that the realhostip.com DNS service
> that ACS currently uses by default as part of the console proxy will be
> disbanded this summer.
>
> We've been informed the realhostip service will be shut down June 30th,
> 2014, so we have approximately 4 months to mitigate this.
>
> Here's my thoughts on how to proceed, in order of priority:
>
> * Make the transition as smooth as possible for current ACS users. Need to
> create clear documentation in the wiki that we can point to on how to
> migrate an existing ACS installation from using realhostip.com to a
> user's own certificate and resolver. I see section 16.4.2 in the 4.2 admin
> guide talks about this, but I think we can improve a bit. e.g. the current
> docs don't make it clear that a wildcard cert is required. Once we have a
> transition guide in place, I intend to announce to users@ and announce@along 
> with the social media paths. This isn't private, but I'd rather not
> announce until we have a clear, tested easy to follow transition guide to
> make this as painless as possible for folks. I'm working on this and will
> update after testing.
> * If at all possible, I'd really like to get something big and visible
> into the 4.3 documentation warning users about this.
> * For 4.4, we should no longer be using SSL/realhostip for console proxy.
> We're expecting some patches to address this, I'll update this thread once
> they hit and/or a Jira issue is created.
>
> Open to any thoughts/suggestions.
>
>
I don't know the reasoning, but if it's due to lack of funding/resources we
could be willing to take ownership over the service.
We've been discussing internally to change to our own white labeled service
instead of relying on realhostip.com, and we might as well contribute that
back if
it's wanted.


-- 
Erik

Re: [QUESTION]db unavailable recovery

[Erik Weber]

Except if your db is the issue and all your management servers die.

-- 
Erik
3. mars 2014 15:48 skrev "Wido den Hollander"  følgende:

>
>
> On 03/03/2014 03:29 PM, Daan Hoogland wrote:
>
>> H,
>>
>> is it normal behavior that cloudstack won't reconnect to the db if it
>> has been down while cloudstack was running? I would expect a
>> reconnect. Or is there a rationale for not attempting a reconnect?
>>
>>
> It doesn't and that's normal. Since CS relies on the DB it simply kills
> itself if it looses connection.
>
> Normally you have multiple Management servers running, so loosing one
> shouldn't be a problem.
>
> There is a old thread about this on the dev@ list explaining it all.
>
> Wido
>

Re: [DISCUSS] realhostip.com going away

[Erik Weber]

How is security being handled in HTTP mode?


-- 
Erik


On Wed, Mar 5, 2014 at 2:43 AM, Amogh Vasekar wrote:

> Hello,
>
> I have created a review request at : https://reviews.apache.org/r/18759/
> that partially address the issue. It has a link to the wiki describing the
> changes in detail.
>
> Thanks,
> Amogh
>
> On 3/3/14 8:58 AM, "John Kinsella"  wrote:
>
> >I talked with some of the Citrix folk over the weekendŠtheir position is
> >they think they¹d be doing the community a disfavor by passing the torch,
> >so-to-speak, and I agree with them [1].
> >
> >From what I understand, the patches that are going to be proposed will
> >remove HTTPS completely and encrypt over http. That said, I haven¹t seen
> >anything yet, so until we see something we¹re guessing. I¹m waiting a few
> >more days to see what¹s proposed.
> >
> >John
> >1: I¹m sharing conversations with individuals, so take this as hearsay
> >not official comment from Citrix.
> >
> >On Mar 2, 2014, at 8:15 AM, Paul Angus
> >mailto:paul.an...@shapeblue.com>> wrote:
> >
> >There are a few issues with the current console proxy setup, not least of
> >which is the need to have internet access to resolve
> >realhostip.com in the first place - so console
> >proxy can't work if you don't have internet access on your client.  I
> >have configured alternative realhostip.com setups
> >for clients - and quite a lot of work goes into creating the
> >infrastructure (and certs) to support changing to a user managed
> >certificate.
> >
> >Sooo, is it at all possible to secure communications with the console
> >proxy, without having to rely on ANY outside entity?
> >
> >Testing alone is going to be a pain, if a full ssl cert setup is required
> >to use console proxy..
> >
> >Regards
> >
> >Paul Angus
> >Cloud Architect
> >S: +44 20 3603 0540 | M: +447711418784 | T: CloudyAngus
> >paul.an...@shapeblue.com
> >
> >-Original Message-
> >From: Amogh Vasekar [mailto:amogh.vase...@citrix.com]
> >Sent: 28 February 2014 23:05
> >To: dev@cloudstack.apache.org
> >Subject: Re: [DISCUSS] realhostip.com going away
> >
> >
> >
> >On 2/28/14 2:03 PM, "Nux!"  wrote:
> >
> >There's also the problem of the certificate. It comes bundled in ACS as
> >far as I can tell.. When does it expire?
> >
> >notBefore=Feb  3 03:30:40 2012 GMT
> >notAfter=Feb  7 05:11:23 2017 GMT
> >
> >Need Enterprise Grade Support for Apache CloudStack?
> >Our CloudStack Infrastructure
> >Support offers
> >the best 24/7 SLA for CloudStack Environments.
> >
> >Apache CloudStack Bootcamp training courses
> >
> >**NEW!** CloudStack 4.2.1
> >training
> >18th-19th February 2014, Brazil.
> >Classroom
> >17th-23rd March 2014, Region A. Instructor led,
> >On-line
> >24th-28th March 2014, Region B. Instructor led,
> >On-line
> >16th-20th June 2014, Region A. Instructor led,
> >On-line
> >23rd-27th June 2014, Region B. Instructor led,
> >On-line
> >
> >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.
> >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 is a registered trademark.
> >
> >Stratosec - Compliance as a Service
> >o: 415.315.9385
> >@johnlkinsella
> >
>
>

Re: [DISCUSS] realhostip.com going away

[Erik Weber]

I planned on looking at the Lua part of PowerDNS for this :-)

-- 
Erik Weber
7. mars 2014 22:48 skrev "Nux!"  følgende:

> On 07.03.2014 21:30, Chiradeep Vittal wrote:
>
>> You should require 1 record for the ACTUAL public IP used by the
>> ConsoleProxy VM.
>>
>
> I know, but if the VM is destroyed or an additional one is spawned it
> could have ANY IP.. I mean, I really don't want to track this kind of
> stuff, doesn't "scale".
> Maybe the Java DNS server could be replaced by Powerdns+pipe backend, will
> have to dig into this.
>
> --
> Sent from the Delta quadrant using Borg technology!
>
> Nux!
> www.nux.ro
>

RE: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU support for XenServer.

[Erik Weber]

Anything that's hard coded is potentially a problem to change for a user.

You can take a somewhat similar view on the vmware disk controller issue
(cloudstack-4787 iirc) , where it is hard coded what to use, and changing
it to ui based has taken a couple of versions and is still not fixed. Which
is why i would vote against any hard coded value that could and should
either be dynamic or user specified.

Regards,
Erik Weber
12. mars 2014 16:24 skrev "Stephen Turner" 
følgende:

> Does anyone else have a view on this? I'm not familiar with the code base
> yet, so am I worrying about nothing?
>
> --
> Stephen Turner
>
>
> -Original Message-
> From: Stephen Turner [mailto:stephen.tur...@citrix.com]
> Sent: 11 March 2014 16:13
> To: dev@cloudstack.apache.org
> Cc: Sanjay Tripathi
> Subject: RE: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU support
> for XenServer.
>
> Thanks for your reply, Sanjay. I understand that it's only K1 and K2 cards
> at the moment, but when they add more, do we really want to have to edit
> the code to match? What is the notification process by which we know there
> are new types? Does the user have to upgrade CloudStack to get access to
> the new types? In contrast, if we could use the current list from the
> server, we don't have to worry about it: it will just keep itself up to
> date.
>
> --
> Stephen Turner
>
>
> -Original Message-
> From: Sanjay Tripathi
> Sent: 11 March 2014 16:05
> To: Stephen Turner; dev@cloudstack.apache.org
> Subject: RE: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU support
> for XenServer.
>
> Hi Stephen,
>
> As of now, there are 2 GPU cards available in market i.e. NVIDIA GRID K1
> and K2 cards. These card supports 5 different configurations of vGPUs which
> we call as vGPU types (for details:
> http://www.nvidia.com/object/virtual-gpus.html).  In future, if this list
> grows, then we'll add a separate table similar to guest_os table, which
> will have the list of supported vGPU types.
>
> Also, the table "vgpu_types" has the entries of different vGPU types
> supported in hosts managed by CloudStack.
>
> --Sanjay
>
> -Original Message-
> From: Stephen Turner
> Sent: Tuesday, March 11, 2014 5:54 PM
> To: dev@cloudstack.apache.org
> Cc: Sanjay Tripathi
> Subject: RE: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU support
> for XenServer.
>
> I see that the change has been pushed already, but I'm a bit concerned
> about there being a hard-coded list of vGPU types in the class GPU. I
> anticipate that Nvidia or other vendors will add more vGPU types later, and
> this will require us to keep up with the list. Is there a way we can use
> the list of vGPU types returned from the servers instead?
>
> --
> Stephen Turner
>
>
>
> -Original Message-
> From: ASF Subversion and Git Services [mailto:nore...@reviews.apache.org]
> On Behalf Of ASF Subversion and Git Services
> Sent: 11 March 2014 10:10
> To: Koushik Das; Devdeep Singh; Alex Huang
> Cc: Sanjay Tripathi; ASF Subversion and Git Services; cloudstack
> Subject: Re: Review Request 17889: CLOUDSTACK-4762: Enabling vGPU support
> for XenServer.
>
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/17889/#review36769
> ---
>
>
> Commit c7d31fe288b13ff4f0f046f83f9eb4a9c2bf06c5 in cloudstack's branch
> refs/heads/master from Sanjay Tripathi [
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=c7d31fe ]
>
> CLOUDSTACK-4760 : Enabling GPU support for XenServer.
> CLOUDSTACK-4762 : Enabling VGPU support for XenServer.
>
> This feature is to enable the GPU-passthrough and vGPU functionality, with
> the help of this feature, admins/users will be able to leverage the GPU
> graphics unit power by deploying a virtul machine with GPU or vGPU support
> or by changing the service offering of an existing VM at any later point of
> time. There GPU/vGPU enabled VMs are able to run graphical applications.
> For now, this feature is only supported with XenServer hypervisor but can
> be extended to add the support of other hypervisors.
>
>
> - ASF Subversion and Git Services
>
>
> On Feb. 27, 2014, 12:35 p.m., Sanjay Tripathi wrote:
> >
> > ---
> > This is an automatically generated e-mail. To reply, visit:
> > https://reviews.apache.org/r/17889/
> > ---
> >
> > (Updated Feb. 27, 2014, 12:35 p.

Re: [DISCUSS] realhostip.com going away

[Erik Weber]

On Fri, Mar 7, 2014 at 9:39 PM, Nux!  wrote:

> On 07.03.2014 20:28, John Kinsella wrote:
>
>> Soo...I'd recommend against something like Nux's suggestion below. I've
>> only looked briefly at VirtualDNS.java, and it looks fine from a
>> glance, but I'm willing to bet I can a) DOS it, and b) use it for a
>> reflection attack. I could be wrong, don't really have time to look
>> closely, but based on it looking like the design pattern for a basic
>> UDP server, I wouldn't recommend the community to build a network of
>> those.
>>
>
> I'd love not having to run that java DNS server, but the alternative is to
> add records for all IPs that I am going to use for guest network, which I
> imagine will keep increasing in time and this would be difficult and
> probably messy.
> Isn't realhostip service that Java thing now? How is the name translation
> done, if not?
>
>

Here's a first try at a PowerDNS lua script that provides a similar feature
to realhostip.com.
It's not been heavily tested, so I'd recommend to keep it out of production
environments as of now

https://github.com/terbolous/powerdns-cloudstack-proxy-dns


-- 
Erik Weber

Re: [VOTE] Apache CloudStack 4.3.0 (seventh round)

[Erik Weber]

That would require a whole other way of upgrading though. Having to restart
all system vms every week or two is not something i would look forward to.

On the other side, with more releases it wouldn't be that big issue to miss
a freeze date, and with fewer new features / improvements it should
hopefully require less fixes.

-- 
Erik Weber
12. mars 2014 22:53 skrev "Daan Hoogland" 
følgende:

> If we produce a new feature per week, why not?
>
> On Wed, Mar 12, 2014 at 10:34 PM, Mike Tutkowski
>  wrote:
> > There has to be some minimum boundary, though, right? Otherwise we might
> as
> > well release every week. :)
> >
> >
> > On Wed, Mar 12, 2014 at 3:10 PM, Daan Hoogland  >wrote:
> >
> >> Steve,
> >>
> >> As I have suggested before, we shoud not lengthen releas periods but
> >> shorten them. I highly object to the idea of enlarging the window and
> >> the release. It will pnly make relasing more difficult.
> >>
> >> with n releases there are n*(n-1) potential conficts of the simlest
> >> kind and n*(n-1)(n-2) potential conflicts of a slightly mor complex
> >> kind... The higher n ... do the math. The more we postpone a feature
> >> freeze the higher n will get. And that is only talking of features.
> >> not about the simpler fixes that are added.
> >>
> >> postponing when we have difficulty releasing quality makes no sense.
> >>
> >> kind regards,
> >> Daan Hoogland
> >>
> >> On Wed, Mar 12, 2014 at 9:46 PM, Steve Wilson 
> >> wrote:
> >> > I think it was suggested multiple times that we push out the 4.4
> freeze
> >> > date because the 4.3 work has been lagging.  I think this is just
> another
> >> > indicator we need to evaluate our release cadence as a community.
> >> >
> >> > That being said, I don¹t think we want to hold 4.3 any further.  This
> >> must
> >> > be the best tested RC in the history of software at this point.
>  Unless
> >> > someone finds a new showstopper (that wasn¹t in the previous 6
> builds!)
> >> > then let¹s get this puppy out! :-)
> >> >
> >> > -Steve
> >> >
> >> > On 3/12/14, 10:25 AM, "Mike Tutkowski" 
> >> > wrote:
> >> >
> >> >>I hate to point this out as I know we've been struggling to get 4.3
> out
> >> >>the
> >> >>door, but this week is probably not a great week to count votes for
> 4.3
> >> as
> >> >>it is the last week before 4.4 Feature Freeze.
> >> >>
> >> >>
> >> >>On Wed, Mar 12, 2014 at 11:09 AM, Wilder Rodrigues <
> >> >>wrodrig...@schubergphilis.com> wrote:
> >> >>
> >> >>> Hi guys and gals,
> >> >>>
> >> >>> Based on the findings after my first round of tests, I give a +1 to
> the
> >> >>> 4.3 RC
> >> >>>
> >> >>> Please, find below what I have tested so far:
> >> >>>
> >> >>> * Environment
> >> >>>   - Management Server: Debian 7 VM under VirtualBox
> >> >>>   - DevCloud: XenServer 6.2
> >> >>>   - MySQL: running on the DevCloud
> >> >>>   - System VM: Latest from
> >> >>>
> http://jenkins.buildacloud.org/view/4.3/job/cloudstack-4.3-systemvm/
> >> >>>
> >> >>> * Initial start-up
> >> >>>   - Everything seems to work fine
> >> >>>
> >> >>> * Zone
> >> >>>   - DNS1: 8.8.8.8
> >> >>>   - DNS2: 8.8.4.4
> >> >>>   - Hypervisor: XenServer
> >> >>>   - Guest CIDR: 10.1.2.0/24
> >> >>>   - Local Storage enabled: true
> >> >>>
> >> >>> * Public Traffic
> >> >>>   - 10.1.1.1 / 255.255.255.0 / 10.1.1.2 / 10.1.1.100
> >> >>>
> >> >>> * POD
> >> >>>   - 10.1.1.1 / 255.255.255.0 / 10.1.1.101 / 10.1.1.200
> >> >>>
> >> >>> * VLAN
> >> >>>   - 101 - 109
> >> >>>
> >> >>> * Host
> >> >>>   - Host Name: 178.237.34.120
> >> >>>   - Username: root
> >> >>>   - Password: blah
> >> >>>
> >> >>> * Secondary Storage
> >> >>>   - Provider: NFS
> >> >>>  

UI Plugins

[Erik Weber]

Hi,

Does anyone have any working UI Plugins they could share?

As a rather fresh want to be programmer, I find the example sparse and
would really appreciate any insight anyone could offer.

Regards,

Erik Weber

Re: UI Plugins

[Erik Weber]

Alex,

That's probably a good tutorial, but for Java plugins, not UI plugins.
They're written in javascript.

I'm referring to this:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/UI+Plugin+Tutorial


-- 
Erik Weber


On Mon, Mar 17, 2014 at 12:24 PM, Alex Hitchins  wrote:

> Erik,
>
> Ian Duffy has a rather good tutorial here :
> http://ianduffy.ie/cloudstack/CreatingAPlugin.pdf
>
>
>
>
> Regards
>
> Alex Hitchins
>
> D: +44 1892 523 587 | S: +44 2036 030 540 | M: +44 7788 423 969
>
> alex.hitch...@shapeblue.com
>
> -Original Message-
> From: Erik Weber [mailto:terbol...@gmail.com]
> Sent: 17 March 2014 07:28
> To: dev
> Subject: UI Plugins
>
> Hi,
>
> Does anyone have any working UI Plugins they could share?
>
> As a rather fresh want to be programmer, I find the example sparse and
> would really appreciate any insight anyone could offer.
>
> Regards,
>
> Erik Weber
> Need Enterprise Grade Support for Apache CloudStack?
> Our CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/> offers the best
> 24/7 SLA for CloudStack Environments.
>
> Apache CloudStack Bootcamp training courses
>
> **NEW!** CloudStack 4.2.1 training<
> http://shapeblue.com/cloudstack-training/>
> 18th-19th February 2014, Brazil. Classroom<
> http://shapeblue.com/cloudstack-training/>
> 17th-23rd March 2014, Region A. Instructor led, On-line<
> http://shapeblue.com/cloudstack-training/>
> 24th-28th March 2014, Region B. Instructor led, On-line<
> http://shapeblue.com/cloudstack-training/>
> 16th-20th June 2014, Region A. Instructor led, On-line<
> http://shapeblue.com/cloudstack-training/>
> 23rd-27th June 2014, Region B. Instructor led, On-line<
> http://shapeblue.com/cloudstack-training/>
>
> 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. 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 is a
> registered trademark.
>

Re: UI Plugins

[Erik Weber]

No problem,

I didn't know about it myself before I started to research ways to extend
CloudStack :-)

Still open for input from others if they have done anything with the UI
Plugin framework.

-- 
Erik Weber


On Mon, Mar 17, 2014 at 12:49 PM, Alex Hitchins  wrote:

> Ah, sorry. Not sure I've seen anything along those lines apart from that
> Wiki you referenced.
>
>
> Regards
>
> Alex Hitchins
>
> D: +44 1892 523 587 | S: +44 2036 030 540 | M: +44 7788 423 969
>
> alex.hitch...@shapeblue.com
>
> -Original Message-
> From: Erik Weber [mailto:terbol...@gmail.com]
> Sent: 17 March 2014 11:44
> To: dev
> Subject: Re: UI Plugins
>
> Alex,
>
> That's probably a good tutorial, but for Java plugins, not UI plugins.
> They're written in javascript.
>
> I'm referring to this:
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/UI+Plugin+Tutorial
>
>
> --
> Erik Weber
>
>
> On Mon, Mar 17, 2014 at 12:24 PM, Alex Hitchins <
> alex.hitch...@shapeblue.com
> > wrote:
>
> > Erik,
> >
> > Ian Duffy has a rather good tutorial here :
> > http://ianduffy.ie/cloudstack/CreatingAPlugin.pdf
> >
> >
> >
> >
> > Regards
> >
> > Alex Hitchins
> >
> > D: +44 1892 523 587 | S: +44 2036 030 540 | M: +44 7788 423 969
> >
> > alex.hitch...@shapeblue.com
> >
> > -Original Message-
> > From: Erik Weber [mailto:terbol...@gmail.com]
> > Sent: 17 March 2014 07:28
> > To: dev
> > Subject: UI Plugins
> >
> > Hi,
> >
> > Does anyone have any working UI Plugins they could share?
> >
> > As a rather fresh want to be programmer, I find the example sparse and
> > would really appreciate any insight anyone could offer.
> >
> > Regards,
> >
> > Erik Weber
> > Need Enterprise Grade Support for Apache CloudStack?
> > Our CloudStack Infrastructure Support<
> > http://shapeblue.com/cloudstack-infrastructure-support/> offers the best
> > 24/7 SLA for CloudStack Environments.
> >
> > Apache CloudStack Bootcamp training courses
> >
> > **NEW!** CloudStack 4.2.1 training<
> > http://shapeblue.com/cloudstack-training/>
> > 18th-19th February 2014, Brazil. Classroom<
> > http://shapeblue.com/cloudstack-training/>
> > 17th-23rd March 2014, Region A. Instructor led, On-line<
> > http://shapeblue.com/cloudstack-training/>
> > 24th-28th March 2014, Region B. Instructor led, On-line<
> > http://shapeblue.com/cloudstack-training/>
> > 16th-20th June 2014, Region A. Instructor led, On-line<
> > http://shapeblue.com/cloudstack-training/>
> > 23rd-27th June 2014, Region B. Instructor led, On-line<
> > http://shapeblue.com/cloudstack-training/>
> >
> > 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. 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 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. 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 is a
> registered trademark.
>

Re: [ANNOUNCE] Change of Apache CloudStack PMC Chair

[Erik Weber]

On Wed, Mar 19, 2014 at 9:51 PM, Chip Childers wrote:

> Per our project bylaws, we are changing our project's chair today!
>
> Over discussions during the last month the PMC had reached a consensus
> to recommend to the ASF board that Hugo Trippaers be accepted as the
> next Apache CloudStack PMC Chair / VP of Apache CloudStack.  As of
> today's ASF board meeting, this has been accepted and made official.
>
> Please join me in congratulating Hugo in his new role!
>



Congratulations Hugo, well done!

-- 
Erik Weber

Re: [4.4] can't start management server on centos6.5

[Erik Weber]

Got java7 installed?

Erik
26. mars 2014 20:18 skrev "Paul Angus"  følgende:

>  I created a repo from the RPMs Jenkins built, but the management server
> bombs out almost immediately when the service tries to start.
>
>
>
> Mar 26, 2014 6:20:18 PM org.apache.catalina.loader.WebappClassLoader
> validateJarFile
>
> INFO:
> validateJarFile(/usr/share/cloudstack-management/webapps/client/WEB-INF/lib/servlet-api-2.5-20081211.jar)
> - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class:
> javax/servlet/Servlet.class
>
> Mar 26, 2014 6:20:18 PM org.apache.catalina.loader.WebappClassLoader
> validateJarFile
>
> INFO:
> validateJarFile(/usr/share/cloudstack-management/webapps/client/WEB-INF/lib/tomcat-embed-core-7.0.30.jar)
> - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class:
> javax/servlet/Servlet.class
>
> Mar 26, 2014 6:20:19 PM org.apache.tomcat.util.modeler.Registry
> registerComponent
>
> SEVERE: Null component
> Catalina:type=JspMonitor,name=jsp,WebModule=//localhost/client,J2EEApplication=none,J2EEServer=none
>
> Mar 26, 2014 6:20:19 PM org.apache.catalina.startup.HostConfig
> deployDirectory
>
> SEVERE: Error deploying web application directory client
>
> java.lang.UnsupportedClassVersionError:
> org/apache/cloudstack/spring/module/web/CloudStackContextLoaderListener :
> Unsupported major.minor version 51.0 (unable to load class
> org.apache.cloudstack.spring.module.web.CloudStackContextLoaderListener)
>
>
>
> any ideas?
>
>
>
>
>
> Regards,
>
>
>
> Paul Angus
>
> *Senior Consultant / Cloud Architect*
>
> [image: cid:image003.png@01CEF0F0.9C9104D0]
>
>
>
> S: +44 20 3603 0540 <+442036030540> | M: +4 <+447968161581>47711418784 |
> T: @CloudyAngus
>
> paul.an...@shapeblue.com | www.shapeblue.com | 
> Twitter:@shapeblue
>
> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
>
>
>  Need Enterprise Grade Support for Apache CloudStack?
> Our CloudStack Infrastructure 
> Supportoffers the 
> best 24/7 SLA for CloudStack Environments.
>
> Apache CloudStack Bootcamp training courses
>
> **NEW!** CloudStack 4.2.1 training
> 18th-19th February 2014, Brazil. 
> Classroom
> 17th-23rd March 2014, Region A. Instructor led, 
> On-line
> 24th-28th March 2014, Region B. Instructor led, 
> On-line
> 16th-20th June 2014, Region A. Instructor led, 
> On-line
> 23rd-27th June 2014, Region B. Instructor led, 
> On-line
>
> 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. 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 is a
> registered trademark.
>

Re: [4.4] build failing at awsapi

[Erik Weber]

Believe I've had a similar problem, ended up downloading them manually from
another mirror.

Erik Weber
1. apr. 2014 17:41 skrev "Paul Angus"  følgende:

>  Hi I'm getting the following errors when building 4.4 noredist:
>
>
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile
> (default-compile) on project cloud-awsapi: Compilation failure: Compilation
> failure:
>
> [ERROR] error: error reading
> /root/.m2/repository/org/codehaus/woodstox/wstx-asl/3.2.4/wstx-asl-3.2.4.jar;
> error in opening zip file
>
> [ERROR] error: error reading
> /root/.m2/repository/org/apache/axis2/mex/1.5.4/mex-1.5.4-impl.jar; error
> in opening zip file
>
> [ERROR] error: error reading
> /root/.m2/repository/org/apache/axis2/axis2-mtompolicy/1.5.4/axis2-mtompolicy-1.5.4.jar;
> error in opening zip file
>
> [ERROR] error: error reading
> /root/.m2/repository/org/apache/ws/commons/axiom/axiom-dom/1.2.10/axiom-dom-1.2.10.jar;
> error in opening zip file
>
> [ERROR] error: error reading
> /root/.m2/repository/commons-lang/commons-lang/2.3/commons-lang-2.3.jar;
> error in opening zip file
>
>
>
> It seems to be being caused by one repo:  shibboleth.internet2.edu  which
> has moved/removed its maven repo, so returns a webpage instead of a pom or
> a jar.
>
>
>
> I can't find a way to blacklist shibboleth.internet2.edu
>
>
>
> Any ideas anyone?
>
>
>
> Regards
>
>
>
> Paul Angus
>
> *Senior Consultant / Cloud Architect*
>
>
>
> [image: cid:image002.png@01CE1071.C6CC9C10]
>
>
>
> S: +44 20 3603 0540 <+442036030540> | M: +4 <+447968161581>47711418784 |
> T: @CloudyAngus
>
> paul.an...@shapeblue.com | www.shapeblue.com | 
> Twitter:@shapeblue<https://twitter.com/>
>
> ShapeBlue Ltd, 53 Chandos Place, Covent Garden, London, WC2N 4HS
>
>
>  Need Enterprise Grade Support for Apache CloudStack?
> Our CloudStack Infrastructure 
> Support<http://shapeblue.com/cloudstack-infrastructure-support/>offers the 
> best 24/7 SLA for CloudStack Environments.
>
> Apache CloudStack Bootcamp training courses
>
> **NEW!** CloudStack 4.2.1 training<http://shapeblue.com/cloudstack-training/>
> 18th-19th February 2014, Brazil. 
> Classroom<http://shapeblue.com/cloudstack-training/>
> 17th-23rd March 2014, Region A. Instructor led, 
> On-line<http://shapeblue.com/cloudstack-training/>
> 24th-28th March 2014, Region B. Instructor led, 
> On-line<http://shapeblue.com/cloudstack-training/>
> 16th-20th June 2014, Region A. Instructor led, 
> On-line<http://shapeblue.com/cloudstack-training/>
> 23rd-27th June 2014, Region B. Instructor led, 
> On-line<http://shapeblue.com/cloudstack-training/>
>
> 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. 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 is a
> registered trademark.
>

Re: Script executed when an instance is just deployed

[Erik Weber]

On Fri, Apr 4, 2014 at 1:58 PM, mathieu herbert wrote:

> Hi,
> In my company, we would like to execute a script at the end of the
> deployment process (Jar).
>
> How can we include this script in the deployment process?
>
> Do you have any documentation about this subject?
>
> Thank you.




If it's ok to run your script from within the vm you could add user-data
functionality to your templates on firstboot, and
pass the script that way.


-- 
Erik Weber

Re: [Announce] New Committer: Lucian Paul (Nux)

[Erik Weber]

On Mon, Apr 7, 2014 at 9:32 PM, Giles Sirett wrote:

> The Project Management Committee (PMC) for Apache CloudStack has
> asked Lucian Paul (Nux)  to become a committer and we are pleased to
> announce
> that he has accepted.
>


Congratulations!

-- 
Erik Weber

Re: Problem with VMware CloudStack SSVM Agent

[Erik Weber]

Could you check wich java version it has installed?
>From the error message I'd interpret it as it's trying to run java7 code on
java6 jre.

-- 
Erik Weber


On Tue, Apr 8, 2014 at 1:39 AM, Soheil Eizadi  wrote:

> I am trying to bring up CloudStack 4.4 on vSphere 5.1, I cannot get the
> Agent to run on SSVM, here is the error:
>
>  =templateProcessor mtu=1500 eth2ip=10.48.15.100
> eth2mask=255.255.255.0 gateway=10.48.15.1 public.network.device=eth2
> eth0mask=0.0.0.0 eth0ip=0.0.0.0 eth1ip=10.48.15.49 eth1mask=255.255.255.0
> mgmtcidr=10.48.15.0/24 localgw=10.48.15.1 private.network.device=eth1
> eth3ip=10.48.15.33 eth3mask=255.255.255.0 storageip=10.48.15.33
> storagenetmask=255.255.255.0 storagegateway=10.48.15.1
> internaldns1=10.48.2.11 internaldns2= dns1=10.48.2.11 dns2=
>
> Exception in thread "main" java.lang.UnsupportedClassVersionError:
> com/cloud/agent/AgentShell : Unsupported major.minor version 51.0
>
> at java.lang.ClassLoader.defineClass1(Native Method)
>
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
>
> at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
>
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
>
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
>
> at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
>
> at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
>
> at java.security.AccessController.doPrivileged(Native Method)
>
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
>
> at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
>
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
>
> at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
>
> Could not find the main class: com.cloud.agent.AgentShell.  Program will
> exit.
>
>
>
> Here is the SSVM diags:
>
> root@s-22-VM:/var/log/cloud# /usr/local/cloud/systemvm/ssvm-check.sh
>
> 
>
> First DNS server is  10.48.2.11
>
> PING 10.48.2.11 (10.48.2.11): 56 data bytes
>
> 64 bytes from 10.48.2.11: icmp_seq=0 ttl=63 time=1.423 ms
>
> 64 bytes from 10.48.2.11: icmp_seq=1 ttl=63 time=0.338 ms
>
> --- 10.48.2.11 ping statistics ---
>
> 2 packets transmitted, 2 packets received, 0% packet loss
>
> round-trip min/avg/max/stddev = 0.338/0.881/1.423/0.543 ms
>
> Good: Can ping DNS server
>
> 
>
> Good: DNS resolves download.cloud.com
>
> 
>
> ERROR: NFS is not currently mounted
>
> Try manually mounting from inside the VM
>
> NFS server is  eth2
>
> ping: unknown host
>
> WARNING: cannot ping nfs server
>
> routing table follows
>
> Kernel IP routing table
>
> Destination Gateway Genmask Flags Metric RefUse
> Iface
>
> 10.48.15.0  0.0.0.0 255.255.255.0   U 0  00
> eth1
>
> 10.48.15.0  0.0.0.0 255.255.255.0   U 0  00
> eth2
>
> 10.48.15.0  0.0.0.0 255.255.255.0   U 0  00
> eth3
>
> 0.0.0.0 10.48.15.1  0.0.0.0 UG0  00
> eth2
>
> 
>
> Management server is 10.48.15.10. Checking connectivity.
>
> Good: Can connect to management server port 8250
>
> 
>
> ERROR: Java process not running.  Try restarting the SSVM.
>

Re: [EVENTS] CloudStack Collaboration Conference Europe, Budapest Nov 19-21

[Erik Weber]

Will it be in connection with another conference like apachecon?

Erik Weber
8. apr. 2014 18:03 skrev "Sebastien Goasguen" 
følgende:

> Hi folks,
>
> While some of us are in Denver for CloudStack collaboration conference, I
> wanted to announce the next conference in Europe.
>
> CCC will be in Budapest on November 19-21.
>
> Mark your calendars and plan on joining for another exciting event,
>
> Cheers,
>
> -Sebastien

Re: [Proposal] Integrating Apache Stratos with Apache CloudStack.

[Erik Weber]

On Tue, Apr 8, 2014 at 9:41 PM, Nguyen Anh Tu  wrote:

> Dear guys,
>
> It's not really a full proposal right now, I just wanna bump a thread to
> discuss about working on integrating Stratos to CloudStack. Chris Snow and
> I are working on the design process. Keep update soon!
>
> Chris, could you keep update on this thread?
>



Would be great to see! +1

-- 
Erik Weber

Re: interactions Cloudstack Vmware

[Erik Weber]

On Wed, Apr 9, 2014 at 1:44 PM, Mohamed Ali Saidi <
saidi.mohamed.ali...@gmail.com> wrote:

> Hello,
>
> I'm searching in the internet for interaction issues (Ports, protocol ,...
> ) between cloudstack and vmware (vcenter,..) but i can't find any helpful
> docs.
>
>

I believe most of the traffic happens on HTTPS to vcenter.
we put the vcenter in our management network, so didn't really have to
puzzle with openings.


-- 
Erik Weber

Re: OpenSSL vunerability (bleedheart)

[Erik Weber]

Shouldn't the parts using realhostip.com be using ssl? Atleast pre 4.3?

Erik
9. apr. 2014 18:47 skrev "Marcus"  følgende:

> Maybe the console? I haven't used that in forever, does it do SSL?
>
> On Wed, Apr 9, 2014 at 10:31 AM, Nux!  wrote:
> > On 09.04.2014 17:21, Marcus wrote:
> >>
> >> Should just pull in the latest and work, if we're talking about
> >> building a fresh system vm.
> >>
> >> Do we even have any services running in the system vm that require an
> >> update?  We don't do SSL termination with haproxy for load balancers
> >> (yet), and I don't think that the apache web stuff for
> >> userdata/passwords is ssl, is it? From what I've seen, SSH doesn't
> >> even use the OpenSSL libs... I'm trying to think of a service that
> >> would be affected. We definitely want to push the latest, but I'm just
> >> wondering what actual urgency there should be for users to update
> >> their system vms.
> >
> >
> > Yes, that is actually a good point. I thought by the panic of the devs
> that
> > there is obviously stuff running there that is exposed to the interwebs.
> > It'd be nice if there wasn't any. :)
> >
> >
> > Lucian
> >
> > --
> > Sent from the Delta quadrant using Borg technology!
> >
> > Nux!
> > www.nux.ro
>

Re: 4.3 system vm template job failing in jenkins

[Erik Weber]

What is the proper way to update the systemvm-template? I already have
systemvm-xenserver-4.3 registered as I've upgraded from 4.2.1, should I
delete that first or use another name?

-- 
Erik Weber


On Thu, Apr 10, 2014 at 11:01 PM, Rayees Namathponnan <
rayees.namathpon...@citrix.com> wrote:

> This is fixed in commit
> https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=commit;h=0965fdb9f8f3cad8629761884eab16b2503cca1a
>
> New templates available at
> http://jenkins.buildacloud.org/job/build-systemvm64-master/
>
> Regards,
> Rayees
>
>
> -Original Message-
> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com]
> Sent: Thursday, April 10, 2014 9:21 AM
> To: dev@cloudstack.apache.org
> Cc: Wido den Hollander (w...@widodh.nl); Hugo Trippaers
> Subject: RE: 4.3 system vm template job failing in jenkins
>
> May be this can be a quick hackathon in collab. Copying Wido and Hugo
>
> > -Original Message-
> > From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
> > Sent: Thursday, April 10, 2014 9:18 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: 4.3 system vm template job failing in jenkins
> >
> > On 10/04/14 5:24 pm, "Nux!"  wrote:
> >
> > >On 10.04.2014 11:17, Abhinandan Prateek wrote:
> > >> I have tried with both the options now i.e. -qq and by removing
> > >> "DEBIAN_PRIORITY=critical², The pop up does not go away breaking
> > >> the build job.
> > >>
> > >> Guys, find the solution !
> > >>
> > >> -abhi
> > >
> > >
> > >This sort of works for me:
> > >
> > >(I'm downgrading to the vulnerable version)
> > >
> > >root@v-45-VM:~# aptitude install libssl1.0.0=1.0.1e-2+deb7u4 The
> > >following packages will be DOWNGRADED:
> > >   libssl1.0.0
> > >0 packages upgraded, 0 newly installed, 1 downgraded, 0 to remove and
> > >34 not upgraded.
> > >Need to get 0 B/3,027 kB of archives. After unpacking 52.2 kB will be
> > >freed.
> > >Preconfiguring packages ...
> > >dpkg: warning: downgrading libssl1.0.0:i386 from 1.0.1e-2+deb7u6 to
> > >1.0.1e-2+deb7u4
> > >(Reading database ... 24354 files and directories currently
> > >installed.) Preparing to replace libssl1.0.0:i386 1.0.1e-2+deb7u6
> > >(using
> > >.../libssl1.0.0_1.0.1e-2+deb7u4_i386.deb) ...
> > >Unpacking replacement libssl1.0.0:i386 ...
> > >Setting up libssl1.0.0:i386 (1.0.1e-2+deb7u4) ...
> > >
> > >root@v-45-VM:~# "DEBIAN_FRONTEND=noninteractive apt-get install -y
> > >-qq --force-yes libssl1.0.0 Preconfiguring packages ...
> > >(Reading database ... 24354 files and directories currently
> > >installed.) Preparing to replace libssl1.0.0:i386 1.0.1e-2+deb7u4
> > >(using
> > >.../libssl1.0.0_1.0.1e-2+deb7u6_i386.deb) ...
> > >Unpacking replacement libssl1.0.0:i386 ...
> > >Setting up libssl1.0.0:i386 (1.0.1e-2+deb7u6) ...
> > >Checking for services that may need to be restarted...done.
> > >Checking init scripts...
> > >
> > >Restarting services possibly affected by the upgrade:
> > >[ ok ] Restarting OpenBSD Secure Shell server: sshd.
> > >[ ok ] Stopping NTP server: ntpd.
> > >[ ok ] Starting NTP server: ntpd.
> > >[ ok ] Stopping daemon monitor: monit.
> > >[ ok ] Starting daemon monitor: monit.
> > >
> > >Services restarted successfully."
> > >
> > >I tried disabling the $post script, but apparently there is no way to
> > >do this in Debian.
> > >
> >
> > Is it possible for someone on the thread to test it out. I can get
> > back to this tomorrow.
> >
> > -abhi
> > >
>
>

Re: [ANNOUNCE] Paul Angus as a committer

[Erik Weber]

12. apr. 2014 04:49 skrev "Sebastien Goasguen"  følgende:
>
> We are pleased to announce that Paul Angus was invited to be a committer
on the Apache Cloudstack project and that he accepted,
>
> Join us in welcoming and congratulating Paul Angus,
>
> -Sebastien on behalf of the CloudStack PMC

Congratulations!  :-)

-- 
Erik Weber

Re: Role based access control using XACML and SAML over rest for cloud

[Erik Weber]

On Tue, Apr 29, 2014 at 8:46 AM, Priya Sharma  wrote:

>  Hi All,
>
> I am pursing MTech and my MTech project is “Role based access control
> using XACML and SAML over rest for cloud”.
>
> I am familiar with role based access control, XACML, SAML ,but not aware
> how all this work in cloud. My aim is to implement the role based access
> control for cloud ,I  am interested in cloud security.
>
> I am familiar with Linux environment, Java technology.
>
> Herein I am attaching the architecture diagram, I initially came up with.
>
> Any suggestion in the diagram and how to implement role based access
> control will be helpful.
>
>
>



Can't really help you with your question, but  just want to let you know
that attachments are stripped on the mailing list.


-- 
Erik Weber

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

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 edit the database to change the URL,
>> > > > you can trust them to change it to anything. Just document a known
>> > > > list of good template locati

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

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

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: 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: [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: [DISCUSS] Retirement of midonet plugin

[Erik Weber]

Sounds good :-)


Erik

man. 27. mar. 2017 kl. 18.03 skrev Will Stevens :

> 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"  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
> >  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 <
> > 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 process RM should make this information
> > available to
> >   

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: 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: [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: 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&cachePrepStmts=true&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'
>
> 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: 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: 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: [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: 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: 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  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  
> 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: 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: 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: 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: 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: [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: 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: 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: 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: [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: [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: 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.
>

VPC Site to Site VPN CIDR RFC1918

[Erik Weber]

http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Installation_Guide/vpn.html#site-to-site-vpnstates:


   - *CIDR list*: The guest CIDR list of the remote subnets. Enter a CIDR
   or a comma-separated list of CIDRs. Ensure that a guest CIDR list is not
   overlapped with the VPC’s CIDR, or another guest CIDR. The CIDR must be
   RFC1918-compliant.


I'm not a network guy, so excuse the question if it's obvious, but if a
customer only has public ip's on their end, why is rfc1918 required?


-- 
Erik Weber

Re: VPC Site to Site VPN CIDR RFC1918

[Erik Weber]

Great to hear. We're not seeing that as we're only trying to add one cidr
range, but all fixes are appreciated :-)

Hope someone might come up with some more info about the limitation as time
passes.

Regards,

Erik Weber


On Wed, May 21, 2014 at 12:32 PM, Alex Hitchins wrote:

> Erik,
>
> I can't answer your question however though as you raise it I'd let you
> know; I'm working on an issue with the comma separated list. Currently it
> is failing as it's incorrectly validating the string.
>
> https://issues.apache.org/jira/browse/CLOUDSTACK-6667
>
>
> Alex Hitchins | 07788 423 969 | 01892 523 587
>
> -Original Message-
> From: Erik Weber [mailto:terbol...@gmail.com]
> Sent: 21 May 2014 11:14
> To: dev
> Subject: VPC Site to Site VPN CIDR RFC1918
>
>
> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Installation_Guide/vpn.html#site-to-site-vpnstates
> :
>
>
>- *CIDR list*: The guest CIDR list of the remote subnets. Enter a CIDR
>or a comma-separated list of CIDRs. Ensure that a guest CIDR list is not
>overlapped with the VPC’s CIDR, or another guest CIDR. The CIDR must be
>RFC1918-compliant.
>
>
> I'm not a network guy, so excuse the question if it's obvious, but if a
> customer only has public ip's on their end, why is rfc1918 required?
>
>
> --
> Erik Weber
>
>

Re: VPC Site to Site VPN CIDR RFC1918

[Erik Weber]

I understand that, but what my client wants is to connect public ips
instead of rfc1918 on one of the sides.

e.g. one network has 10.0.1.0/24 and ip 1.2.3.4
the other has 50.0.1.0/24 and ip 50.0.0.1

but cloudstack currently does not let you do that, because it expects cidrs
to be rfc1918. see log excerpt:

2014-05-21 12:30:42,326 WARN  [c.c.u.n.NetUtils]
(API-Job-Executor-7:job-3072 ctx-bf3922b1) cidr 50.0.1.0/24 is not RFC 1918
compliant
2014-05-21 12:30:42,335 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-7:job-3072) Unexpected exception while executing
org.apache.cloudstack.api.command.user.vpn.CreateVpnCustomerGatewayCmd
com.cloud.exception.InvalidParameterValueException: The customer gateway
guest cidr list 50.0.1.0/24 is invalid guest cidr!
at
com.cloud.network.vpn.Site2SiteVpnManagerImpl.createCustomerGateway(Site2SiteVpnManagerImpl.java:176)

I'm wondering if this is a bug/lacking feature, or intended.
As I initially said I'm not a network guy, so there might be perfectly good
reasons this shouldn't be allowed.

But if it's a bug/lacking feature it would be great to know so that I could
file a ticket for it.

-- 
Erik Weber


On Wed, May 21, 2014 at 2:09 PM, Daan Hoogland wrote:

> Erik,
>
> The vpn let's you connect to all the computers in the network on the
> other site on their private adresses. This means that you can give the
> cidr of the remote network in the definition on vpn connection.
>
> one network has 10.0.1.0/24 and ip 1.2.3.4
> the other has 10.0.2.0/24 and ip 4.3.2.1
>
> on the first you define endpoint/gateway 4.3.2.1 with cidr 10.0.1.0/24
> and you make it passive
> on the second you define the adresses of the first and stat is without
> the passive function
> now you can ping a machine with address 10.0.1.123 from a machine with
> ip 10.0.2.246
>
> Of course you can do this to an external network as well, which makes
> far more sense.
>
> On Wed, May 21, 2014 at 12:14 PM, Erik Weber  wrote:
> >
> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Installation_Guide/vpn.html#site-to-site-vpnstates
> :
> >
> >
> >- *CIDR list*: The guest CIDR list of the remote subnets. Enter a CIDR
> >or a comma-separated list of CIDRs. Ensure that a guest CIDR list is
> not
> >overlapped with the VPC’s CIDR, or another guest CIDR. The CIDR must
> be
> >RFC1918-compliant.
> >
> >
> > I'm not a network guy, so excuse the question if it's obvious, but if a
> > customer only has public ip's on their end, why is rfc1918 required?
> >
> >
> > --
> > Erik Weber
>
>
>
> --
> Daan
>

Re: VPC Site to Site VPN CIDR RFC1918

[Erik Weber]

Site to site vpn.

I'm not in control of the 50.0.1 network, but the client is.

Basically the use case is that they want to secure the traffic to their
cloud vms, and are fortunate enough to not have to use rfc1918  on their
network.

I guess we could work around it by terminating the vpn on our equipment and
access it as a private gateway instead, but I'd prefer to use the
technology that we so braverly tell our clients about.

Erik
21. mai 2014 17:05 skrev "Daan Hoogland"  følgende:

> Are you creating a site to site vpn or connecting to an external network?
>
> On Wed, May 21, 2014 at 5:02 PM, Daan Hoogland 
> wrote:
> > Erik, If it doesn't work it is probably been blocked on purpose but I
> > don't see why it is. I don't know your use case either and it seems an
> > unlikely one. But if the 50.0.1 net is out of your control you maybe
> > should be able to configure this. So I would say it is a bug/lack of
> > feature. I'll look into the code for the place the error is generated.
> >
> > in short: file a ticket
> >
> > On Wed, May 21, 2014 at 2:34 PM, Erik Weber  wrote:
> >> I understand that, but what my client wants is to connect public ips
> >> instead of rfc1918 on one of the sides.
> >>
> >> e.g. one network has 10.0.1.0/24 and ip 1.2.3.4
> >> the other has 50.0.1.0/24 and ip 50.0.0.1
> >>
> >> but cloudstack currently does not let you do that, because it expects
> cidrs
> >> to be rfc1918. see log excerpt:
> >>
> >> 2014-05-21 12:30:42,326 WARN  [c.c.u.n.NetUtils]
> >> (API-Job-Executor-7:job-3072 ctx-bf3922b1) cidr 50.0.1.0/24 is not RFC
> 1918
> >> compliant
> >> 2014-05-21 12:30:42,335 ERROR [c.c.a.ApiAsyncJobDispatcher]
> >> (API-Job-Executor-7:job-3072) Unexpected exception while executing
> >> org.apache.cloudstack.api.command.user.vpn.CreateVpnCustomerGatewayCmd
> >> com.cloud.exception.InvalidParameterValueException: The customer gateway
> >> guest cidr list 50.0.1.0/24 is invalid guest cidr!
> >> at
> >>
> com.cloud.network.vpn.Site2SiteVpnManagerImpl.createCustomerGateway(Site2SiteVpnManagerImpl.java:176)
> >>
> >> I'm wondering if this is a bug/lacking feature, or intended.
> >> As I initially said I'm not a network guy, so there might be perfectly
> good
> >> reasons this shouldn't be allowed.
> >>
> >> But if it's a bug/lacking feature it would be great to know so that I
> could
> >> file a ticket for it.
> >>
> >> --
> >> Erik Weber
> >>
> >>
> >> On Wed, May 21, 2014 at 2:09 PM, Daan Hoogland  >wrote:
> >>
> >>> Erik,
> >>>
> >>> The vpn let's you connect to all the computers in the network on the
> >>> other site on their private adresses. This means that you can give the
> >>> cidr of the remote network in the definition on vpn connection.
> >>>
> >>> one network has 10.0.1.0/24 and ip 1.2.3.4
> >>> the other has 10.0.2.0/24 and ip 4.3.2.1
> >>>
> >>> on the first you define endpoint/gateway 4.3.2.1 with cidr 10.0.1.0/24
> >>> and you make it passive
> >>> on the second you define the adresses of the first and stat is without
> >>> the passive function
> >>> now you can ping a machine with address 10.0.1.123 from a machine with
> >>> ip 10.0.2.246
> >>>
> >>> Of course you can do this to an external network as well, which makes
> >>> far more sense.
> >>>
> >>> On Wed, May 21, 2014 at 12:14 PM, Erik Weber 
> wrote:
> >>> >
> >>>
> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Installation_Guide/vpn.html#site-to-site-vpnstates
> >>> :
> >>> >
> >>> >
> >>> >- *CIDR list*: The guest CIDR list of the remote subnets. Enter a
> CIDR
> >>> >or a comma-separated list of CIDRs. Ensure that a guest CIDR list
> is
> >>> not
> >>> >overlapped with the VPC’s CIDR, or another guest CIDR. The CIDR
> must
> >>> be
> >>> >RFC1918-compliant.
> >>> >
> >>> >
> >>> > I'm not a network guy, so excuse the question if it's obvious, but
> if a
> >>> > customer only has public ip's on their end, why is rfc1918 required?
> >>> >
> >>> >
> >>> > --
> >>> > Erik Weber
> >>>
> >>>
> >>>
> >>> --
> >>> Daan
> >>>
> >
> >
> >
> > --
> > Daan
>
>
>
> --
> Daan
>

Re: VPC Site to Site VPN CIDR RFC1918

[Erik Weber]

The documentation says something else, excerpt:
" The difference from Remote VPN is that Site-to-site VPNs connects entire
networks to each other, for example, connecting a branch office network to
a company headquarters network. In a site-to-site VPN, hosts do not have
VPN client software; they send and receive normal TCP/IP traffic through a
VPN gateway.".

Assuming that both sides is under cloudstack control is just odd and makes
no sense.

I'll file a ticket whenever I find the time, but still appreciate input :-)

Erik Weber
22. mai 2014 00:16 skrev "Daan Hoogland"  følgende:

> I guess you shouldn't use the site to site vpn but just a vpn. I am
> not sure how to configure that but you should just create an active
> (client side) vpn to the external network. I see no reason why it
> should't work. the site to site assumes you have both sides in
> cloudstack and thus with rfc1918 networks.
>
> On Wed, May 21, 2014 at 6:10 PM, Erik Weber  wrote:
> > Site to site vpn.
> >
> > I'm not in control of the 50.0.1 network, but the client is.
> >
> > Basically the use case is that they want to secure the traffic to their
> > cloud vms, and are fortunate enough to not have to use rfc1918  on their
> > network.
> >
> > I guess we could work around it by terminating the vpn on our equipment
> and
> > access it as a private gateway instead, but I'd prefer to use the
> > technology that we so braverly tell our clients about.
> >
> > Erik
> > 21. mai 2014 17:05 skrev "Daan Hoogland" 
> følgende:
> >
> >> Are you creating a site to site vpn or connecting to an external
> network?
> >>
> >> On Wed, May 21, 2014 at 5:02 PM, Daan Hoogland  >
> >> wrote:
> >> > Erik, If it doesn't work it is probably been blocked on purpose but I
> >> > don't see why it is. I don't know your use case either and it seems an
> >> > unlikely one. But if the 50.0.1 net is out of your control you maybe
> >> > should be able to configure this. So I would say it is a bug/lack of
> >> > feature. I'll look into the code for the place the error is generated.
> >> >
> >> > in short: file a ticket
> >> >
> >> > On Wed, May 21, 2014 at 2:34 PM, Erik Weber 
> wrote:
> >> >> I understand that, but what my client wants is to connect public ips
> >> >> instead of rfc1918 on one of the sides.
> >> >>
> >> >> e.g. one network has 10.0.1.0/24 and ip 1.2.3.4
> >> >> the other has 50.0.1.0/24 and ip 50.0.0.1
> >> >>
> >> >> but cloudstack currently does not let you do that, because it expects
> >> cidrs
> >> >> to be rfc1918. see log excerpt:
> >> >>
> >> >> 2014-05-21 12:30:42,326 WARN  [c.c.u.n.NetUtils]
> >> >> (API-Job-Executor-7:job-3072 ctx-bf3922b1) cidr 50.0.1.0/24 is not
> RFC
> >> 1918
> >> >> compliant
> >> >> 2014-05-21 12:30:42,335 ERROR [c.c.a.ApiAsyncJobDispatcher]
> >> >> (API-Job-Executor-7:job-3072) Unexpected exception while executing
> >> >>
> org.apache.cloudstack.api.command.user.vpn.CreateVpnCustomerGatewayCmd
> >> >> com.cloud.exception.InvalidParameterValueException: The customer
> gateway
> >> >> guest cidr list 50.0.1.0/24 is invalid guest cidr!
> >> >> at
> >> >>
> >>
> com.cloud.network.vpn.Site2SiteVpnManagerImpl.createCustomerGateway(Site2SiteVpnManagerImpl.java:176)
> >> >>
> >> >> I'm wondering if this is a bug/lacking feature, or intended.
> >> >> As I initially said I'm not a network guy, so there might be
> perfectly
> >> good
> >> >> reasons this shouldn't be allowed.
> >> >>
> >> >> But if it's a bug/lacking feature it would be great to know so that I
> >> could
> >> >> file a ticket for it.
> >> >>
> >> >> --
> >> >> Erik Weber
> >> >>
> >> >>
> >> >> On Wed, May 21, 2014 at 2:09 PM, Daan Hoogland <
> daan.hoogl...@gmail.com
> >> >wrote:
> >> >>
> >> >>> Erik,
> >> >>>
> >> >>> The vpn let's you connect to all the computers in the network on the
> >> >>> other site on their private adresses. This means that you can give
> the
> >> >>> cidr of the remote network in the definition on vpn connection.
> &

Re: VPC Site to Site VPN CIDR RFC1918

[Erik Weber]

We have no problem getting s2s to connect if the 'other end' from cs point
of view is within rfc1918.
Our problem is purely related to the limitation of only allowing rfc1918
networks on the other end.

Erik Weber


On Thu, May 22, 2014 at 10:21 AM, Daan Hoogland wrote:

> I ran a test with a colleague this week connecting two cs vpcs. this works.
>
> On Thu, May 22, 2014 at 6:05 AM, Sanjeev Neelarapu
>  wrote:
> > In site-to-site vpn both sides need not to be under cloudstack control.
> Only one site can be under cs control.
> >
> > -Original Message-
> > From: Erik Weber [mailto:terbol...@gmail.com]
> > Sent: Thursday, May 22, 2014 4:23 AM
> > To: dev
> > Subject: Re: VPC Site to Site VPN CIDR RFC1918
> >
> > The documentation says something else, excerpt:
> > " The difference from Remote VPN is that Site-to-site VPNs connects
> entire networks to each other, for example, connecting a branch office
> network to a company headquarters network. In a site-to-site VPN, hosts do
> not have VPN client software; they send and receive normal TCP/IP traffic
> through a VPN gateway.".
> >
> > Assuming that both sides is under cloudstack control is just odd and
> makes no sense.
> >
> > I'll file a ticket whenever I find the time, but still appreciate input
> :-)
> >
> > Erik Weber
> > 22. mai 2014 00:16 skrev "Daan Hoogland" 
> følgende:
> >
> >> I guess you shouldn't use the site to site vpn but just a vpn. I am
> >> not sure how to configure that but you should just create an active
> >> (client side) vpn to the external network. I see no reason why it
> >> should't work. the site to site assumes you have both sides in
> >> cloudstack and thus with rfc1918 networks.
> >>
> >> On Wed, May 21, 2014 at 6:10 PM, Erik Weber 
> wrote:
> >> > Site to site vpn.
> >> >
> >> > I'm not in control of the 50.0.1 network, but the client is.
> >> >
> >> > Basically the use case is that they want to secure the traffic to
> >> > their cloud vms, and are fortunate enough to not have to use rfc1918
> >> > on their network.
> >> >
> >> > I guess we could work around it by terminating the vpn on our
> >> > equipment
> >> and
> >> > access it as a private gateway instead, but I'd prefer to use the
> >> > technology that we so braverly tell our clients about.
> >> >
> >> > Erik
> >> > 21. mai 2014 17:05 skrev "Daan Hoogland" 
> >> følgende:
> >> >
> >> >> Are you creating a site to site vpn or connecting to an external
> >> network?
> >> >>
> >> >> On Wed, May 21, 2014 at 5:02 PM, Daan Hoogland
> >> >>  >> >
> >> >> wrote:
> >> >> > Erik, If it doesn't work it is probably been blocked on purpose
> >> >> > but I don't see why it is. I don't know your use case either and
> >> >> > it seems an unlikely one. But if the 50.0.1 net is out of your
> >> >> > control you maybe should be able to configure this. So I would
> >> >> > say it is a bug/lack of feature. I'll look into the code for the
> place the error is generated.
> >> >> >
> >> >> > in short: file a ticket
> >> >> >
> >> >> > On Wed, May 21, 2014 at 2:34 PM, Erik Weber 
> >> wrote:
> >> >> >> I understand that, but what my client wants is to connect public
> >> >> >> ips instead of rfc1918 on one of the sides.
> >> >> >>
> >> >> >> e.g. one network has 10.0.1.0/24 and ip 1.2.3.4 the other has
> >> >> >> 50.0.1.0/24 and ip 50.0.0.1
> >> >> >>
> >> >> >> but cloudstack currently does not let you do that, because it
> >> >> >> expects
> >> >> cidrs
> >> >> >> to be rfc1918. see log excerpt:
> >> >> >>
> >> >> >> 2014-05-21 12:30:42,326 WARN  [c.c.u.n.NetUtils]
> >> >> >> (API-Job-Executor-7:job-3072 ctx-bf3922b1) cidr 50.0.1.0/24 is
> >> >> >> not
> >> RFC
> >> >> 1918
> >> >> >> compliant
> >> >> >> 2014-05-21 12:30:42,335 ERROR [c.c.a.ApiAsyncJobDispatcher]
> >> >> >> (API-Job-Executor-7:job-3072) Unexpected exception while
> >> >> 

Re: Proxy Console (RealhostIP Retired) Question

[Erik Weber]

If the domain names aren't resolving, it would be easier to help you if you
revealed your actual zone data and provided some dig / dns captures.

Do other records for the same domain resolve, e.g. foo.cloud.domain.tld?


Erik Weber


On Thu, May 22, 2014 at 1:46 PM, Mo  wrote:

> Alex,
>
> I understood how to upgrade SSL, however; that's not the issue at hand. The
> issue is I am looking for a guide to correctly setup a DNS Zone to allow
> the console to work. As I mentioned in my first update, I have the
> following:
>
> 192-168-1-1.cloud.domain.tldINA192.168.1.1 (reverted to
> private IP to mask my actual IPs)
>
> I have done that for each of my public facing IP addresses within my DNS
> zone for the particular domain in question. However, in doing so, I am not
> showing this to be resolving; thus resulting me being in a stand still
> unable to continue setting up instances.
>
> Any help would be greatly appreciated.
>
> - mo
>
>
> On Thu, May 22, 2014 at 6:00 AM, Alex Hitchins  >wrote:
>
> > Hello Mo,
> >
> > You can see our guide here :
> >
> http://shapeblue.com/cloudstack/how-to-mitigate-openssl-heartbleed-vulnerability-in-apache-cloudstack/
> >
> >
> >
> >
> > Alex Hitchins | 07788 423 969 | 01892 523 587
> >
> > -Original Message-
> > From: Mo [mailto:m...@daoenix.com]
> > Sent: 22 May 2014 02:15
> > To: us...@cloudstack.apache.org; dev
> > Subject: Proxy Console (RealhostIP Retired) Question
> >
> > Hello:
> >
> > I am attempting to find more information (read: step by step) how to
> > correct the issue that came to be when realhostip was retired.
> >
> > The links I saw suggested I setup the following for every IP address in
> my
> > DNS Zone:
> >
> > 192-168-1-1.cloud.domain.tldINA192.168.1.1
> >
> > I have done that for ALL my IPs. Restarted my named/bind service. Not
> only
> > am I not obtaining an A record with this configuration, but I am also
> still
> > unable to proceed in getting console access as it states it's unable to
> > resolve the DNS.
> >
> > All my other DNS resolves without issue, please note; 192.x is just an IP
> > address I tossed in this e-mail for general purposes, I am utilizing
> public
> > subnets.
> >
> > I have also purchased an SSL certificate went through all of that too, if
> > someone could point me in the right direction or perhaps offer ideas
> > (alternates) that would be fantastic.
> >
> > Thanks,
> > Mo
> >
> >
>

Re: Network IDS in VPC

[Erik Weber]

What prevents root from revealing and using the domain admin api / secret
Key?

Erik
22. mai 2014 15:54 skrev "Marcus"  følgende:

> I've always viewed the permissions to be additive, if a domain admin has
> the ability to set up network sniffing on the VPC I'd imagine the root
> admin should be able to as well. Although perhaps not. Even though they
> have unfettered access to destroy all vms, networks, zones, the root admin
> may not have access to the VM hosts, and may not already have access to the
> VMs themselves if the root passwords are not known. This would introduce a
> vector whereby a root admin without host access could spin up a network and
> vm for a tenant and see their traffic where they'd normally only be able to
> if they had access to the root passwords of the tenant's instances or the
> hosts. I imagine the overwhelming majority of root admins have host or
> network access, but not all. In the end I'm not sure such an untrusted user
> should be a root admin, as there are many other attack vectors (such as
> downloading a tenant's volume). Perhaps I'm missing the point.
>
> It would certainly be easier to implement from an orchestration perspective
> on the router. The collection could happen on the router, but the storage
> of the packet data probably not, and for the analysis it seems kind of
> dangerous to run more user-accessible tools on a system that is supposed to
> be locked down.  Especially since it would likely be a web service of some
> sort running on the public interface. IDS software setup and maintenance is
> pretty involved, I'm not sure the CS community would be interested in
> maintaining that. We generally promote the virtual router as an appliance,
> and so I think we'd need to maintain that software install on the router.
> These (along with the migration issues) are the reasons why I was leaning
> toward a 'sniffer net', where the users could have what they'd normally
> have in a datacenter with a 'port mirror', and they can decide how to
> collect and analyze the data.
>
>
> On Thu, May 22, 2014 at 2:34 AM, Daan Hoogland  >wrote:
>
> > Marcus, you mention a permission issue that triggers the though:
> > should a root admin be allowed? I think not. This brings up extra
> > requirements on the IAM, does it?
> >
> > I would implement the functionality on the router.
> >
> > On Thu, May 22, 2014 at 6:42 AM, Marcus  wrote:
> > > I really like the lower overhead of just port mirroring from one of the
> > > router's interfaces to an instance interface host-side, but I really
> > > dislike the affinity it creates between the router and the listener,
> and
> > > all of the complications it creates for host maintenance and
> migrations.
> > It
> > > may also require that whomever creates a network or vms on a network
> with
> > > this permission be a domain admin, since it has the ability to see
> > > everything on the wire for the whole VPC.
> > >
> > >
> > > On Wed, May 21, 2014 at 4:25 PM, Marcus  wrote:
> > >
> > >> Hi guys,
> > >>Not sure if this has been discussed before, but we are getting
> > feature
> > >> requests for an IDS or packet-sniffing/monitoring capability. I have a
> > >> prototyped idea of how to do this (manual config), but would like some
> > >> input.
> > >>
> > >> We create a network offering or network capability/detail that is
> > >> specifically a 'sniffer net'. This would be relatively simple, and
> just
> > do
> > >> two things:
> > >>
> > >> 1) when network is added to VPC, spin up a simple daemon on the VPC
> > router
> > >> that does traffic mirroring (netsniff-ng or daemonlogger are debian
> > >> packages) from the public interface to the 'sniffer net' interface.
> > >>
> > >> 2) disables mac learning on the bridges created for the sniffer net,
> so
> > >> that an IDS system can come up in this net and see all of the mirrored
> > >> traffic. It wouldn't handle making the IDS appliance, that would be up
> > to
> > >> the customer, it would simply create a network that enables traffic
> > >> monitoring for the VPC.
> > >>
> > >> I think we'd prefer any VMs brought up in this network to live on the
> > same
> > >> host as the router for performance reasons, but that's probably not an
> > >> immediate requirement. I dislike the idea of trying to run an actual
> > >> capture saved to the VPC router, or an IDS software on the VPC router
> > that
> > >> would need to be updated.
> > >>
> > >> We could also run traffic mirroring from the VPC router's interface
> > >> directly to another VM's interface, host side (daemonlogger -i vpcintf
> > -o
> > >> idsintf), but it would need to be on the same host.
> > >>
> > >>
> > >>
> > >>
> >
> >
> >
> > --
> > Daan
> >
>

Re: VPC Site to Site VPN CIDR RFC1918

[Erik Weber]

Filed ticket https://issues.apache.org/jira/browse/CLOUDSTACK-6747 for it
:-)


-- 
Erik Weber


On Fri, May 23, 2014 at 12:24 AM, Chiradeep Vittal <
chiradeep.vit...@citrix.com> wrote:

> Seems reasonable to relax this constraint.
>
> From: Erik Weber mailto:terbol...@gmail.com>>
> Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <
> dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>
> Date: Thursday, May 22, 2014 at 1:40 AM
> To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <
> dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>>
> Subject: Re: VPC Site to Site VPN CIDR RFC1918
>
> We have no problem getting s2s to connect if the 'other end' from cs point
> of view is within rfc1918.
> Our problem is purely related to the limitation of only allowing rfc1918
> networks on the other end.
>
> Erik Weber
>
>
> On Thu, May 22, 2014 at 10:21 AM, Daan Hoogland  <mailto:daan.hoogl...@gmail.com>>wrote:
>
> I ran a test with a colleague this week connecting two cs vpcs. this works.
>
> On Thu, May 22, 2014 at 6:05 AM, Sanjeev Neelarapu
> mailto:sanjeev.neelar...@citrix.com>> wrote:
> > In site-to-site vpn both sides need not to be under cloudstack control.
> Only one site can be under cs control.
> >
> > -Original Message-
> > From: Erik Weber [mailto:terbol...@gmail.com]
> > Sent: Thursday, May 22, 2014 4:23 AM
> > To: dev
> > Subject: Re: VPC Site to Site VPN CIDR RFC1918
> >
> > The documentation says something else, excerpt:
> > " The difference from Remote VPN is that Site-to-site VPNs connects
> entire networks to each other, for example, connecting a branch office
> network to a company headquarters network. In a site-to-site VPN, hosts do
> not have VPN client software; they send and receive normal TCP/IP traffic
> through a VPN gateway.".
> >
> > Assuming that both sides is under cloudstack control is just odd and
> makes no sense.
> >
> > I'll file a ticket whenever I find the time, but still appreciate input
> :-)
> >
> > Erik Weber
> > 22. mai 2014 00:16 skrev "Daan Hoogland"  <mailto:daan.hoogl...@gmail.com>>
> følgende:
> >
> >> I guess you shouldn't use the site to site vpn but just a vpn. I am
> >> not sure how to configure that but you should just create an active
> >> (client side) vpn to the external network. I see no reason why it
> >> should't work. the site to site assumes you have both sides in
> >> cloudstack and thus with rfc1918 networks.
> >>
> >> On Wed, May 21, 2014 at 6:10 PM, Erik Weber  <mailto:terbol...@gmail.com>>
> wrote:
> >> > Site to site vpn.
> >> >
> >> > I'm not in control of the 50.0.1 network, but the client is.
> >> >
> >> > Basically the use case is that they want to secure the traffic to
> >> > their cloud vms, and are fortunate enough to not have to use rfc1918
> >> > on their network.
> >> >
> >> > I guess we could work around it by terminating the vpn on our
> >> > equipment
> >> and
> >> > access it as a private gateway instead, but I'd prefer to use the
> >> > technology that we so braverly tell our clients about.
> >> >
> >> > Erik
> >> > 21. mai 2014 17:05 skrev "Daan Hoogland"  <mailto:daan.hoogl...@gmail.com>>
> >> følgende:
> >> >
> >> >> Are you creating a site to site vpn or connecting to an external
> >> network?
> >> >>
> >> >> On Wed, May 21, 2014 at 5:02 PM, Daan Hoogland
> >> >> mailto:daan.hoogl...@gmail.com>
> >> >
> >> >> wrote:
> >> >> > Erik, If it doesn't work it is probably been blocked on purpose
> >> >> > but I don't see why it is. I don't know your use case either and
> >> >> > it seems an unlikely one. But if the 50.0.1 net is out of your
> >> >> > control you maybe should be able to configure this. So I would
> >> >> > say it is a bug/lack of feature. I'll look into the code for the
> place the error is generated.
> >> >> >
> >> >> > in short: file a ticket
> >> >> >
> >> >> > On Wed, May 21, 2014 at 2:34 PM, Erik Weber  <mailto:terbol...@gmail.com>>
> >> wrote:
> >> >> >> I understand that, but what my client w

Re: Review Request 22093: VPC's VR missing public NIC eth1

[Erik Weber]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22093/#review44481
---



engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java
<https://reviews.apache.org/r/22093/#comment78894>

There's a typo in the where clause. vland_id should be vlan_id


- Erik Weber


On May 30, 2014, 9 p.m., daan Hoogland wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22093/
> ---
> 
> (Updated May 30, 2014, 9 p.m.)
> 
> 
> Review request for cloudstack and Marcus Sorensen.
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> VPC's VR missing public NIC eth1 as reported by Andrija Panic. fix by 
> updating on upgrade
> 
> 
> Diffs
> -
> 
>   engine/schema/src/com/cloud/upgrade/dao/Upgrade421to430.java 7e26132 
> 
> Diff: https://reviews.apache.org/r/22093/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> daan Hoogland
> 
>

Re: [DISCUSS] Release 4.4

[Erik Weber]

On Wed, Jun 11, 2014 at 5:30 PM, Hugo Trippaers  wrote:

> Hey all,
>
> I’m getting somewhat concerned about the 4.4 release. We don’t seems to be
> able to get the 4.4 branch in shape for a release candidate and meanwhile
> master is diverging further and further. We also know that once we hit the
> RC phase we will probably need a sizable number of iterations to eventually
> ship the release. Based on past experience, if we keep up like this we will
> have another release that will actually be released way after the feature
> freeze for the next release (July 18). Probably leaving us in the same bad
> spot for the next release.
>
> I tried to come up with a number of solutions that could rectify the
> situation and help the release move forward, but i can’t think of any. Save
> for some options that might be considered extreme ideas. One the the more
> prominent ideas in my mind at the moment is skipping the 4.4 release all
> together and combine it with the next planned release (whether its 5.0 or
> 4.5). This would require a community effort to focus on quality in the next
> month and basically freeze the master for features and have a community
> wide push for quality to get the next release out on schedule.
>
>

What happens if that release doesn't make its desired time frame? Skip that
too and wait for 4.6 / 5.1 / 6.0?
If any drastic choices were to be made, I'd prefer that the next release
(4.5 / 5.0) either gets postponed, or skipped.
A major version bump with API changes could possibly warrant such drastic
change in my opinion.



> But before i go on and shout out even more drastic ideas, what do you
> think about the current 4.4 release. How close do you feel that we are to
> having a releasable product?
>
>
As a non developer I can only comment based on what I experience on the
mailing list, but this seems to be a repeating problem..
And something should probably be done to prevent this from being a / the
problem every release.


-- 
Erik Weber

Re: Implementation of DNS Provider for Bind

[Erik Weber]

On Fri, Jun 13, 2014 at 7:08 AM, Silvano Buback  wrote:

> Hi there,
>
> I work at Globo.com, a media company in Brazil. Here we use a cloudstack
> private network with an advanced zone setup (isolated vlans).
>
> For some couple of reasons, the name of virtual machine needs to be
> available not only on virtual router network context, but on our internal
> DNS servers.
>
> Our proposal is integrate cloudstack (v 4.5) with DNS server (Bind server)
> thru an open source API written by globo.com called DNSAPI. More info at
> https://github.com/globocom/Dns-Api.
>
> To make this implementation of DNS provider, we based our plugin on
> "dns-notifier", but we had to add more classes for our implementation.
>
> * DnsAPINetworkDAO to manage the networkDomain for each network.
>
> * DnsAPIVirtualMachineDAO to manage DNS records for vms.
>
> * DnsAPIElement, this class implements the provider itself.
>
> * DnsAPIResource, implements all communications with DNSAPI
> (ServerResource).
>
> Besides this classes, another one was necessary to the call to
> DnsAPIResource and return the answer, and one API command was created to
> configure the provider in Zone.
>
>
> Above a video that show you how everything was integrated.
>
>
> https://www.youtube.com/watch?v=fAB53T_NZMI
>
>

I like it, and it seems to be rather straight forward to add other DNS
providers as well, if they are based on your DNS API.

-- 
Erik Weber

Re: [DISCUSS] [PROPOSAL] Implementation of DNS Provider for Bind (for 4.5)

[Erik Weber]

On Fri, Jun 13, 2014 at 7:21 AM, Silvano Nogueira Buback <
silv...@corp.globo.com> wrote:

> Hi there,
>
>
> I work at Globo.com, a media company in Brazil. Here we use a cloudstack
> private network with an advanced zone setup (isolated vlans).
>
> For some couple of reasons, the name of virtual machine needs to be
> available not only on virtual router network context, but on our internal
> DNS servers.
>
> Our proposal is integrate cloudstack (v 4.5) with DNS server (Bind server)
> thru an open source API written by globo.com called DNSAPI. More info at
> https://github.com/globocom/Dns-Api.
>
> To make this implementation of DNS provider, we based our plugin on
> "dns-notifier", but we had to add more classes for our implementation.
>
> * DnsAPINetworkDAO to manage the networkDomain for each network.
> * DnsAPIVirtualMachineDAO to manage DNS records for vms.
> * DnsAPIElement, this class implements the provider itself.
> * DnsAPIResource, implements all communications with DNSAPI
> (ServerResource).
>
> Besides this classes, another one was necessary to the call to
> DnsAPIResource and return the answer, and one API command was created to
> configure the provider in Zone.
>
> Above a video that show you how everything was integrated.
>
> https://www.youtube.com/watch?v=fAB53T_NZMI
>
> We really appreciate all your comments about our implementation,
>


replying in the right thread this time :-)

I like the idea and the fact that the backend is available as open source.
That should make it pretty straight forward to convert it to other DNS
solutions (PowerDNS for me).

- What happens if there is a conflict?
- Does it require / assume that the domain is non-existant on the DNS
servers?
- How does cleanup handle additional records added outside of CloudStack?

-- 
Erik Weber

Re: [security] The case of the open dns resolver

[Erik Weber]

On Mon, Jun 23, 2014 at 12:31 PM, Nux!  wrote:

> Hi,
>
> Today I've been bitten again by the $subject and complaints were sent to
> my hoster's abuse email address; apparently someone used my VR in a DDOS
> attack.
> It is my fault as I knew about this issue, but I'd like to throw the blame
> on Cloudstack. :)
>
> So, the VR is accepting DNS requests from everybody on the interwebs and
> this should be changed, imho.
>
> I see there are already iptables rules concerning port 8080 of the VR and
> only the public IP ranges are allowed. Why isn't this the case for port 53
> as well?
>
> I have placed this script in my VR's rc.local, but it's not kosher at all.
>
> # disallows global DNS traffic and only allows it from the cloud public
> subnets
> for i in `iptables-save |grep 8080|awk '{print $4}'`; do iptables -I INPUT
> -s $i -p tcp -m tcp --dport 53 -j ACCEPT; iptables -I INPUT -s $i -p udp -m
> udp --dport 53 -j ACCEPT; done
> iptables -D INPUT -i eth0 -p udp -m udp --dport 53 -j ACCEPT
> iptables -D INPUT -i eth0 -p tcp -m tcp --dport 53 -j ACCEPT
>
> This could be greatly improved and added in the official tree.
> Currently I'm getting the subnets by checking which IPs the 8080 rules
> apply, how can I retrieve this information in a more elegant way?
>


Which version are you running?

On a 4.3 installation I see no iptables rules that allow it on the public
interface, and testing it externally fails due to the default DROP rule.


-- 
Erik Weber

Re: [ACS43] backporting of issues

[Erik Weber]

Lovely,

Thank you Daan :-)

Erik
25. juni 2014 15:53 skrev "Daan Hoogland" 
følgende:

> Sebastien,
>
> CLOUDSTACK-6747, entered by Erik Weber a while ago and discussed on
> some list (this or user@ or both) has some implementation in master
> now. We are running 4.3 and though we would prefer to go to 4.4 it
> might be worthwhile backporting it to 4.3.1
>
> Do you have a ..-forward policy for your release or some other staging
> strategy?
>
> regards,
> --
> Daan
>

Re: Build error

[Erik Weber]

Old Python installed?

Not sure what the required version is, what version do you have installed?

Erik
3. juli 2014 14:52 skrev "Mohamed Ali Saidi" 
følgende:

>  Hi,
>
> I'm trying to build Coudstack and i got this error:
>
>   File "/home/cloudstack/tools/apidoc/gen_toc.py", line 223
> with file(out, 'w') as f:
> ^
> SyntaxError: invalid syntax
>
> any idea?
>
> regards,
>

Re: [DISCUSS] [PROPOSAL] Implementation of DNS Provider for Bind (for 4.5)

[Erik Weber]

To push that choice over to the operator you could add it as a
global/zone/network option.

As an operator i would prefer to have my own logic to handle cleanup, but
this varies for everyone hence the option :-)

Erik
3. juli 2014 21:45 skrev "Silvano Nogueira Buback" 
følgende:

> Hi guys,
>
> I think you are busy because 4.4 release tasks, but I'm worried about
> the time to 4.5 feature freeze. I put the documentation of feature in wiki
> as requested and I hoped people read there and make some comments here.
>
> To help, I will put design issues that are in document, one by one, and we
> can discuss in this thread. After each discussion I will change the
> document.
>
>I have one question about removing DNS domain when network has been
> deleted. In my current implementation I remove DNS domain when network is
> removed. But if the DNS domain is shared with another network or maybe is a
> dns domain used outside ACS this can be a problem. What I can do with DNS
> domain when network is removed:
>
>1. Keep the current implementation. Always deleted DNS domain when
>network is removed (works well if the ACS is the only manager for the
> DNS
>(one network domain per network).
>2. Remove DNS domain only if the domain was created by ACS. This can be
>a problem if someone put records after ACS creation.
>3. Remove DNS domain only if there is no more records there. Maybe DNS
>domain can stay forever there because an inconsistency that keep only
> one
>record.
>
>
> Which one is the best?
>
> []'s,
>
> Silvano Buback
>
>
>
> On Thu, Jun 26, 2014 at 11:34 AM, Silvano Nogueira Buback <
> silv...@corp.globo.com> wrote:
>
> > Thank you David.
> >
> > I put design documents on wiki:
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Bind+and+PowerDNS+integration+by+Globo+DNSAPI
> .
> > I create an issue https://issues.apache.org/jira/browse/CLOUDSTACK-6998
> > too.
> >
> > I look forward to hearing your feedbacks.
> >
> > []'s,
> >
> > Silvano Buback
> >
> >
> > On Wed, Jun 25, 2014 at 5:50 PM, David Nalley  wrote:
> >
> >> On Wed, Jun 25, 2014 at 4:38 PM, Silvano Nogueira Buback
> >>  wrote:
> >> > Hi guys,
> >> >
> >> >I finish the first version of design document:
> >> >
> >>
> https://docs.google.com/document/d/1kbPQJrBC87ZtR-t7LwHFDzAmT436ShtjwKE84FVfByM/pub
> >> > .
> >> >
> >> >Someone could give me access to put design documents in wiki?
> Bellow
> >> the
> >> > username of people work with Cloudstack in Globo.com and need access.
> >> >
> >> > snbuback silv...@corp.globo.com
> >> > daniel.simoes daniel.sim...@corp.globo.com
> >> > lokama - lok...@gmail.com
> >> >
> >> > Regards,
> >> >
> >> > Silvano Buback
> >> >
> >> >
> >> >
> >> > On Thu, Jun 19, 2014 at 11:29 AM, Silvano Buback 
> >> wrote:
> >> >
> >> >> Of course, I forgotten my account info:
> >> >> snbuback / silv...@corp.globo.com
> >> >>
> >>
> >>
> >> Done.
> >>
> >> --David
> >>
> >
> >
>

Re: Question about Global Settings

[Erik Weber]

We have midonet-specific settings in there, wouldn't that be vendor
specific? I'm totally unfamiliar with midonet, so I have to ask.

Erik
13. juli 2014 07:01 skrev "Mike Tutkowski" 
følgende:

> Hi,
>
> I'm doing a code review and had a question that I thought someone might be
> able to answer for me:
>
> Do we typically allow vendor-specific config values in Global Settings?
>
> Thanks!
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkow...@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> *™*
>

Re: Review Request 22863: CLOUDSTACK-6823 : First code drop for Brocade Network plugin to orchestrate Brocade VDX switches for L2 connectivity.

[Erik Weber]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/22863/#review47820
---



api/src/com/cloud/network/PhysicalNetwork.java
<https://reviews.apache.org/r/22863/#comment84043>

Looks like you removed the 'N' in L3VPN


- Erik Weber


On July 15, 2014, 9:16 p.m., Ritu  Sabharwal wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/22863/
> ---
> 
> (Updated July 15, 2014, 9:16 p.m.)
> 
> 
> Review request for cloudstack and Hugo Trippaers.
> 
> 
> Bugs: CLOUDSTACK-6823
> https://issues.apache.org/jira/browse/CLOUDSTACK-6823
> 
> 
> Repository: cloudstack-git
> 
> 
> Description
> ---
> 
> First code drop for Brocade Network plugin to orchestrate Brocade VDX 
> switches for L2 connectivity. Please create a new branch for Brocade plugin.
> 
> 
> Diffs
> -
> 
>   api/src/com/cloud/network/Network.java 885bffe 
>   api/src/com/cloud/network/Networks.java 1e4d229 
>   api/src/com/cloud/network/PhysicalNetwork.java 8cc214e 
>   api/src/org/apache/cloudstack/network/ExternalNetworkDeviceManager.java 
> e73f526 
>   client/WEB-INF/classes/resources/messages.properties b504a18 
>   client/WEB-INF/classes/resources/messages_zh_CN.properties 1ec4e95 
>   client/pom.xml 29fef4f 
>   client/tomcatconf/commands.properties.in d247aa0 
>   plugins/pom.xml b5e6a61 
>   setup/db/db/schema-440to450.sql 77445a9 
>   tools/apidoc/gen_toc.py 827d6bf 
>   ui/dictionary.jsp 9026a36 
>   ui/scripts/system.js 9a98a5c 
>   ui/scripts/ui-custom/zoneWizard.js 4091c03 
> 
> Diff: https://reviews.apache.org/r/22863/diff/
> 
> 
> Testing
> ---
> 
> • Create an isolated network; verify that the port-profile is created on 
> the Brocade switch.
> • Attach a VM to the network; verify that the VMs MAC address is 
> associated with the port profile of the network on the Brocade switch.
> • Delete VMs for an isolated network; verify that the VMs MAC address is 
> disassociated with the port profile of the network on the Brocade switch.
> • Delete the isolated network; verify that the port-profile is deleted 
> from the Brocade switch.
> 
> 
> File Attachments
> 
> 
> Diff for the existing cloudstack code
>   
> https://reviews.apache.org/media/uploaded/files/2014/06/23/8fc3cfb1-7a21-4714-98f3-6514cf54ba84__diff
> Patch file for Brocade functionality code
>   
> https://reviews.apache.org/media/uploaded/files/2014/06/26/92bb0014-a7b7-4f0b-97c9-018d615b658a__brocade-vcs.patch
> 
> 
> Thanks,
> 
> Ritu  Sabharwal
> 
>

Re: [ACS4.5] When is feature freeze?

[Erik Weber]

16. juli 2014 07:00 skrev "Mike Tutkowski" 
følgende:
>
> Hi,
>
> Does anyone know when feature freeze is for 4.5?
>
> I don't see 4.5 listed as a release in progress:
>
>
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Releases+in+Progress
>
> I thought feature freeze was supposed to be coming within a week or so.
>

July 19th according to Hugo in this mail

http://mail-archives.apache.org/mod_mbox/cloudstack-dev/201407.mbox/%3c69a41a0b-e75b-4d61-b8c9-06a9610a4...@apache.org%3E

Erik

Re: [VOTE] Apache Cloudstack 4.4.0

[Erik Weber]

Considering adding centos 7 and rhel 7 while at it.

Erik
17. juli 2014 00:32 skrev "Marcus"  følgende:

> Yes, thats it. I have no idea how these mappings are created, but we need
> to ensure that both upgrades and new installs work
>
>
> On Wed, Jul 16, 2014 at 3:25 PM, Amogh Vasekar 
> wrote:
>
> > Hi,
> >
> > It is probably due to missing mapping in guest_os_hypervisor table. I had
> > created default entries for KVM using :
> > http://bit.ly/1rrML8n
> >
> > I can add the missing mapping to it.
> >
> > Thanks,
> > Amogh
> >
> > On 7/16/14 2:08 PM, "Marcus"  wrote:
> >
> > >I have another big issue to report with 4.4 in testing these artifacts.
> I
> > >register a CentOS 6.5 template, and launch VMs for it on KVM, and the
> > >disks/nics are not virtio.
> > >
> > >It looks like it is due to the following commit, which changes how the
> KVM
> > >agent determines if a template is PV enabled. The
> 'getPlatformEmulator()'
> > >is empty. I have reopened the associated bug and commented on it.
> > >
> > > -DiskDef.diskBus diskBusType =
> > >getGuestDiskModel(vmSpec.getOs());
> > >+DiskDef.diskBus diskBusType =
> > >getGuestDiskModel(vmSpec.getPlatformEmulator());
> > >
> > >commit 02bd3d0671b0cde46f8aa7892f20aa0bb0d48d1c
> > >Author: Amogh Vasekar 
> > >Date:   Wed May 7 15:16:55 2014 -0700
> > >
> > >CLOUDSTACK-6358: As a part of supporting dynamic guest OS defined by
> > >user, removing the hard-coded dependencies.
> > >This patch is for KVM
> > >
> > >1. Local testing on KVM
> > >2. Successfully got up system VMs
> > >3. Successfully created a CentOS VM
> > >4. Snapshots are not supported for KVM
> > >
> > > Signed off by :- Nitin Mehta
> > >
> > >
> > >
> > >On Wed, Jul 16, 2014 at 2:57 PM, Alena Prokharchyk <
> > >alena.prokharc...@citrix.com> wrote:
> > >
> > >> Daan, during 4.4 testing, I found the following regression bug:
> > >>
> > >> https://issues.apache.org/jira/browse/CLOUDSTACK-7118
> > >>
> > >>
> > >> "Unable to expunge vms in error state"
> > >>
> > >> There is a workaround for it - I¹ve mentioned it in the bug - yet
> > >>ideally
> > >> I would prefer the fix to be cherry-picked from 4.4-forward:
> > >>
> > >> commit 822b38761f1655ef3d5d3648985a197f5c2c1262
> > >>
> > >>
> > >>
> > >> Thank you,
> > >> Alena.
> > >>
> > >> On 7/16/14, 4:47 AM, "Daan Hoogland"  wrote:
> > >>
> > >> >On Thu, Jul 3, 2014 at 1:41 AM, Marcus  wrote:
> > >> >> I tested this release with
> > >> >> cherry-picking 2ec7359b4eb501b0d9e80ed87af7a54938e9d505 from
> > >> >>4.4-forward.
> > >> >
> > >> >
> > >> >I have cherry-picked and pushed. I will address the last remaining
> > >> >issue by editting the pom.xml from build_asf.sh and roll out a new
> RC.
> > >> >
> > >> >Hope all of you have continued testing and have now more issues to
> > >> >block this release
> > >> >
> > >> >--
> > >> >Daan
> > >>
> > >>
> >
> >
>

Re: Setting cloudstack dev on windows7

[Erik Weber]

Do yourself a favor and drop spaces in the directory name, it makes the
world a lot easier most times.

Erik
23. juli 2014 07:27 skrev "Priyanka Deepala" 
følgende:

> I followed the same steps & added variable M2_HOME and specified the path
> as C:\Apache Maven\apache-maven-3.0.5. %M2_HOME%\bin is added to to PATH
> variable but still I'm getting the same error
>
>
> Regards
> Priyanka
>
>
> On Wed, Jul 23, 2014 at 10:37 AM, Rajani Karuturi <
> rajani.karut...@citrix.com> wrote:
>
> > What did you add to the PATH? did you miss M2_HOME/bin??
> >
> > FYI,
> > This came on the first page when googled for “cygwin maven windows”
> > http://www.mkyong.com/maven/how-to-install-maven-in-windows/
> >
> >
> >
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Setting+up+a+CloudStack+dev+environment+on+Windows
> > Step-8 has details on how to setup maven
> >
> > Please spend a little time on google.
> >
> >
> >
> > ~Rajani
> >
> >
> >
> > On 23-Jul-2014, at 10:27 am, Priyanka Deepala <
> > priyanka.deepal...@gmail.com>
> wrote:
> >
> > I Installed maven-3.0.5.src and specified the path in environment
> variable
> > PATH. When I'm trying to test it in  Cygwin shell by typing 'which mvn'
> it
> > is displaying as "no mvn in that path..So What should I do now??
> >
> >
>

Re: [DISCUSS][PROPOSAL] git workflow

[Erik Weber]

Must it start today, or when (if) the vote passes? Feature freeze for 4.5
has theoretically passed, so basically master branch should now be work in
progress towards a stable branch.

So I'd say; create a 'develop' branch off the current master.

Keep master as is, and only merge bugfixes until it is deemed stable and
4.5 is released.

4.6 development and new features goes into branches of 'develop'.

Erik
23. juli 2014 18:30 skrev "Sebastien Goasguen"  følgende:

>
> On Jul 23, 2014, at 12:21 PM, Nate Gordon  wrote:
>
> > Let me ask the question, why have master be develop and a release branch
> be
> > "master"? If we are going to follow gitflow, why not just stick with the
> > norm? If master is the development branch, it might not be stable. I
> think
> > the goal here is that we have an obvious stable branch. Anyone could come
> > check out master and have the latest useable.
>
> I am in favor of following the norm, so ideally master should be our
> stable branch (agreed).
>
> The issue is with the transition.
>
> Our latest releasable product is the 4.4 branch (4.4.0 tag), so ideally we
> could start a stable branch of this tag and build up bug fix releases all
> the way to 4.5 from there.
>
> But all features for 4.5 are already in master.
>
> So if we create a 'develop' branch of master and stabilize 'master' then
> develop is now started from a stable tag (4.4.0).
>
> So what's the best way to flip ? There is most likely some git magic that
> can we do.
>
>
> The new git workflow and the transition process need to be part of a
> proposal that we get consensus on.
>
> getting there :)
>
> -seb
>
> >
> > Also, I'm struggling to understand the benefit of cherry-pick. If you
> > completely squash history, you lose a tremendous amount of context,
> which I
> > use extensively to figure out why a bug is the way it is. Only knowing
> that
> > the branch was merged at a given point in time doesn't give any context.
> > Seeing the individual commit history of the branch helps to preserve the
> > rationale for why the code was written the way it was. In theory if every
> > change starts out as a branch (feature, hotfix, release), then why not
> just
> > merge the branch once it is in a good and acceptable state?
> >
> > I also agree with Mike that this will have to be a transition over time.
> It
> > will take some time to clean up master to the point where it can be
> > considered a solid stable branch. Possibly as part of the 4.5 release.
> >
> >
> > On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen 
> > wrote:
> >
> >>
> >> On Jul 23, 2014, at 11:38 AM, daan Hoogland 
> >> wrote:
> >>
> >>> Sebastien,
> >>>
> >>> It seems we can do what you are calling for is creating a branch
> >>> called 'release'. We can merge back into that branch from 4.4, master,
> >>> 4.3. I would like to see people that want a feature or bug fix in a
> >>> branch make a fork of that branch and when that fork is working do a
> >>> cherry-pick. The -forward concept is now used for that but it is
> >>> broken because more then for one piece of work there are commits on
> >>> it. This caused me conflicts during the release. Especially painfull
> >>> as not all was intended to get into the release. We can create this
> >>> 'release' branch now on the basis of 4.4 and start pulling in changes.
> >>
> >> Yes, that's what I am thinking about too, so +1
> >>
> >> Our master would become the -develop- in gitflow terms
> >> The release branch you mention would become the -master- in gitflow
> terms
> >>
> >> If we start now, indeed we can create 'release' from 4.4 release tag
> >> (voted and shipped).
> >>
> >> That means that to create 4.5 we will need to merge features back into
> >> 'release'. it might be messy because some of those features are already
> in
> >> our current master.
> >>
> >> But all of this will keep 'release' clean (we can keep track of bugs and
> >> features that are in it in CHANGES file etc..)
> >>
> >>
> >>> There is a question of control. Do we allow all committers to manage
> >>> the release? I am for that but can imagine not everybody is.
> >>>
> >>
> >> At first I would say that only the RM can commit to 'release'. As we get
> >> the CI in place  we could relax this and allow commits that pass the CI
> to
> >> get into 'release', but right now I would vote for a tighter control of
> >> 'release'.
> >>
> >>> rule number 1 will be: you are going to do something to the code, you
> >>> start by creating a branch.
> >>>
> >>> right?
> >>>
> >>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen 
> >> wrote:
> 
>  On Jul 23, 2014, at 11:19 AM, Sam Schmit 
> >> wrote:
> 
> > Hey everyone,
> >
> > I've been a developer for a handful of years and have had my share of
> > experience with different version control systems.  I've used (for
> >> better
> > or worse) Git, Perforce, Rational ClearCast, and SVN.
> >
> > Each of these solutions offers their own unique set of features,

Re: [DISCUSS][PROPOSAL] git workflow

[Erik Weber]

24. juli 2014 06:28 skrev "Rajani Karuturi" 
følgende:
>
> I agree with mike. I think we should start 4.5 from where master is now
> Also create a develop branch from master and continue future work for 4.6
there.
>
> I am not clear on how the release branches are going to be maintained.
> Are we saying we would create 4.5-RELEASE branch which is essentially
same as our current -FORWARD branch and continue cherry-picking?

After feature freeze or whenever it's decided to finish a release you
create a branch called release-version, e.g. release-4.6.

>From then on 'develop' focus is on 4.7 or whatever the next version is
called.

Whenever something gets merged to release-4.6 it should also get merged to
develop.

> I would prefer merges to cherry-picks.

A lot of the point in this workflow is visibility / traceability, so
merging should really be the way we work

> Also, I think we should allow committers to commit to the RELEASE branch
after discussing about it on dev@ and have RM closely monitor them.

If code is merged instead of cherry-picked it is easier to see / trace what
has happened , and potentially revert.

It is important though that RM's job isn't made much more difficult to
manage .

Erik

> Any commit intended for 4.5 RELEASE should be checked in after discussion
in the 4.5 Release branch and then merged to develop branch.
>
>
> ~Rajani
>
>
>
> On 24-Jul-2014, at 1:14 am, Mike Tutkowski 
wrote:
>
> > Per earlier e-mails, I don't think we want to start 4.5 where 4.4 left
off
> > and then merge features from develop into 4.5.
> >
> > Why don't we instead start 4.5 where master is now with the assumption
that
> > since we are past Feature Freeze for 4.5 that master is stable enough?
> >
> >
> > On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland 
> > wrote:
> >
> >> so to start formulate a proposal:
> >>
> >> all work shall be done in a new branch (it is advisable to prefix your
> >> branches with your id)
> >> when working, features will be cherry-picked/merged into the release
> >> branch they are for and next into master.
> >> hotfixes will be done in -hotfixes
> >>
> >> as transition we will
> >>
> >> rename 'master' to 'develop'
> >> branch a new 'master' from '4.4'
> >> branch '4.5' from the new 'master'
> >> merge any features from the new 'develop' to '4.5' and 'master'
> >>
> >>
> >>
> >> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen 
> >> wrote:
> >>>
> >>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen 
> >> wrote:
> >>>
> 
>  On Jul 23, 2014, at 12:21 PM, Nate Gordon 
> >> wrote:
> 
> > Let me ask the question, why have master be develop and a release
> >> branch be
> > "master"? If we are going to follow gitflow, why not just stick with
> >> the
> > norm? If master is the development branch, it might not be stable. I
> >> think
> > the goal here is that we have an obvious stable branch. Anyone could
> >> come
> > check out master and have the latest useable.
> 
>  I am in favor of following the norm, so ideally master should be our
> >> stable branch (agreed).
> 
>  The issue is with the transition.
> 
>  Our latest releasable product is the 4.4 branch (4.4.0 tag), so
ideally
> >> we could start a stable branch of this tag and build up bug fix
releases
> >> all the way to 4.5 from there.
> 
>  But all features for 4.5 are already in master.
> 
>  So if we create a 'develop' branch of master and stabilize 'master'
> >> then develop is now started from a stable tag (4.4.0).
> 
> >>>
> >>> *not* started from a stable tag, and merges will be tricky, no ?
> >>>
>  So what's the best way to flip ? There is most likely some git magic
> >> that can we do.
> 
> 
>  The new git workflow and the transition process need to be part of a
> >> proposal that we get consensus on.
> 
>  getting there :)
> 
>  -seb
> 
> >
> > Also, I'm struggling to understand the benefit of cherry-pick. If
you
> > completely squash history, you lose a tremendous amount of context,
> >> which I
> > use extensively to figure out why a bug is the way it is. Only
knowing
> >> that
> > the branch was merged at a given point in time doesn't give any
> >> context.
> > Seeing the individual commit history of the branch helps to preserve
> >> the
> > rationale for why the code was written the way it was. In theory if
> >> every
> > change starts out as a branch (feature, hotfix, release), then why
not
> >> just
> > merge the branch once it is in a good and acceptable state?
> >
> > I also agree with Mike that this will have to be a transition over
> >> time. It
> > will take some time to clean up master to the point where it can be
> > considered a solid stable branch. Possibly as part of the 4.5
release.
> >
> >
> > On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <
run...@gmail.com
> >>>
> > wrote:
> >
> >>
> >> On Jul 23, 2014

Re: [DISCUSS][PROPOSAL] git workflow

[Erik Weber]

24. juli 2014 08:39 skrev "Rajani Karuturi" 
følgende:
>
>
> Hi Daan,
> here is what i propose:
>
> 1. rename 'master' to 'develop’
> 2. branch a new 'master' from '4.4’
> 3. branch 'RELEASE-4.5' from the develop
> 4. merge 'RELEASE-4.5' to master once the release voting is done.
>
> RELEASE-4.6 branch should be off develop as all the feature branches
would be merged there before freeze for 4.6 and would be merged to master
when the release is voted.
>
> The other question I have is in the step:4. how are we going to manage
fixes to 4.5 post branch cut?  ( assuming no features as the freeze is done)

Sub releases, ie. 4.4.1,  is generally just hotfixes / bugfixes, yes? In
that case you can branch it off 'master' and merge back to master as a new
release after voting, and merge to develop if the fix is applicable there.

Erik
>
> ~Rajani
>
>
>
> On 24-Jul-2014, at 11:52 am, Daan Hoogland 
wrote:
>
> > Mike, Rajani,
> >
> > Sebastien's point was that the current 4.4 is the closest we have to a
> > releasable branch. I don't mind enting on master but it will require
> > more fixing. In general all of this will require some RM work of all
> > committers. Please ammend my little proposal if you will.
> >
> > On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
> >  wrote:
> >> I agree with mike. I think we should start 4.5 from where master is now
> >> Also create a develop branch from master and continue future work for
4.6 there.
> >>
> >> I am not clear on how the release branches are going to be maintained.
> >> Are we saying we would create 4.5-RELEASE branch which is essentially
same as our current -FORWARD branch and continue cherry-picking?
> >>
> >> I would prefer merges to cherry-picks.
> >> Also, I think we should allow committers to commit to the RELEASE
branch after discussing about it on dev@ and have RM closely monitor them.
> >> Any commit intended for 4.5 RELEASE should be checked in after
discussion in the 4.5 Release branch and then merged to develop branch.
> >>
> >>
> >> ~Rajani
> >>
> >>
> >>
> >> On 24-Jul-2014, at 1:14 am, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:
> >>
> >>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4
left off
> >>> and then merge features from develop into 4.5.
> >>>
> >>> Why don't we instead start 4.5 where master is now with the
assumption that
> >>> since we are past Feature Freeze for 4.5 that master is stable enough?
> >>>
> >>>
> >>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <
daan.hoogl...@gmail.com>
> >>> wrote:
> >>>
>  so to start formulate a proposal:
> 
>  all work shall be done in a new branch (it is advisable to prefix
your
>  branches with your id)
>  when working, features will be cherry-picked/merged into the release
>  branch they are for and next into master.
>  hotfixes will be done in -hotfixes
> 
>  as transition we will
> 
>  rename 'master' to 'develop'
>  branch a new 'master' from '4.4'
>  branch '4.5' from the new 'master'
>  merge any features from the new 'develop' to '4.5' and 'master'
> 
> 
> 
>  On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen 
>  wrote:
> >
> > On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen 
>  wrote:
> >
> >>
> >> On Jul 23, 2014, at 12:21 PM, Nate Gordon 
>  wrote:
> >>
> >>> Let me ask the question, why have master be develop and a release
>  branch be
> >>> "master"? If we are going to follow gitflow, why not just stick
with
>  the
> >>> norm? If master is the development branch, it might not be
stable. I
>  think
> >>> the goal here is that we have an obvious stable branch. Anyone
could
>  come
> >>> check out master and have the latest useable.
> >>
> >> I am in favor of following the norm, so ideally master should be
our
>  stable branch (agreed).
> >>
> >> The issue is with the transition.
> >>
> >> Our latest releasable product is the 4.4 branch (4.4.0 tag), so
ideally
>  we could start a stable branch of this tag and build up bug fix
releases
>  all the way to 4.5 from there.
> >>
> >> But all features for 4.5 are already in master.
> >>
> >> So if we create a 'develop' branch of master and stabilize 'master'
>  then develop is now started from a stable tag (4.4.0).
> >>
> >
> > *not* started from a stable tag, and merges will be tricky, no ?
> >
> >> So what's the best way to flip ? There is most likely some git
magic
>  that can we do.
> >>
> >>
> >> The new git workflow and the transition process need to be part of
a
>  proposal that we get consensus on.
> >>
> >> getting there :)
> >>
> >> -seb
> >>
> >>>
> >>> Also, I'm struggling to understand the benefit of cherry-pick. If
you
> >>> completely squash history, you lose a tremendous amount of
context,
>  which I
> >>> use extensively to fig

Re: [DISCUSS][PROPOSAL] git workflow

[Erik Weber]

This is out of my git league, but how do you handle minor versions that way?

Assuming 4.8.0 is the latest stable release and HEAD on master.

Then you want to release 4.4.1.

First of all can you develop bugfixes for 4.4 along the way, when both
develop and master HEAD might be hugely different?

Second, can you commit  behind HEAD? You don't want the 4.4.1 release
instead of 4.8.0 to be HEAD

Someone might have good solutions to this, but if not I would propose to
keep the release branches for future bugfixes.

Erik
25. juli 2014 06:02 skrev "Rajani Karuturi" 
følgende:

> On 24-Jul-2014, at 10:25 pm, Mike Tutkowski 
> wrote:
>
> > I believe I agree with these steps.
> >
> > A couple questions:
> >
> > Is 'master' simply always going to be equal to what's the most recent
> > version of the code that's in production?
>
> I think so. master will always be at the latest release and all the
> previous releases properly tagged. The release branches would be deleted
> once release is done.
>
> >
> > Also, would 'develop' be for 4.6 code then and 4.5 code would go directly
> > into RELEASE-4.5?
> >
>
> Yes. 4.6 work should be done on develop branch and any 4.5 bug fixes
> should be done on the 4.5 branch.
>
>
>
> ~Rajani
>
>
> >
> > On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi <
> > rajani.karut...@citrix.com> wrote:
> >
> >>
> >> Hi Daan,
> >> here is what i propose:
> >>
> >> 1. rename 'master' to 'develop’
> >> 2. branch a new 'master' from '4.4’
> >> 3. branch 'RELEASE-4.5' from the develop
> >> 4. merge 'RELEASE-4.5' to master once the release voting is done.
> >>
> >> RELEASE-4.6 branch should be off develop as all the feature branches
> would
> >> be merged there before freeze for 4.6 and would be merged to master when
> >> the release is voted.
> >>
> >> The other question I have is in the step:4. how are we going to manage
> >> fixes to 4.5 post branch cut?  ( assuming no features as the freeze is
> done)
> >>
> >> ~Rajani
> >>
> >>
> >>
> >> On 24-Jul-2014, at 11:52 am, Daan Hoogland 
> >> wrote:
> >>
> >>> Mike, Rajani,
> >>>
> >>> Sebastien's point was that the current 4.4 is the closest we have to a
> >>> releasable branch. I don't mind enting on master but it will require
> >>> more fixing. In general all of this will require some RM work of all
> >>> committers. Please ammend my little proposal if you will.
> >>>
> >>> On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
> >>>  wrote:
>  I agree with mike. I think we should start 4.5 from where master is
> now
>  Also create a develop branch from master and continue future work for
> >> 4.6 there.
> 
>  I am not clear on how the release branches are going to be maintained.
>  Are we saying we would create 4.5-RELEASE branch which is essentially
> >> same as our current -FORWARD branch and continue cherry-picking?
> 
>  I would prefer merges to cherry-picks.
>  Also, I think we should allow committers to commit to the RELEASE
> >> branch after discussing about it on dev@ and have RM closely monitor
> them.
>  Any commit intended for 4.5 RELEASE should be checked in after
> >> discussion in the 4.5 Release branch and then merged to develop branch.
> 
> 
>  ~Rajani
> 
> 
> 
>  On 24-Jul-2014, at 1:14 am, Mike Tutkowski <
> >> mike.tutkow...@solidfire.com> wrote:
> 
> > Per earlier e-mails, I don't think we want to start 4.5 where 4.4
> left
> >> off
> > and then merge features from develop into 4.5.
> >
> > Why don't we instead start 4.5 where master is now with the
> assumption
> >> that
> > since we are past Feature Freeze for 4.5 that master is stable
> enough?
> >
> >
> > On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <
> >> daan.hoogl...@gmail.com>
> > wrote:
> >
> >> so to start formulate a proposal:
> >>
> >> all work shall be done in a new branch (it is advisable to prefix
> your
> >> branches with your id)
> >> when working, features will be cherry-picked/merged into the release
> >> branch they are for and next into master.
> >> hotfixes will be done in -hotfixes
> >>
> >> as transition we will
> >>
> >> rename 'master' to 'develop'
> >> branch a new 'master' from '4.4'
> >> branch '4.5' from the new 'master'
> >> merge any features from the new 'develop' to '4.5' and 'master'
> >>
> >>
> >>
> >> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <
> run...@gmail.com
> >>>
> >> wrote:
> >>>
> >>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen  >
> >> wrote:
> >>>
> 
>  On Jul 23, 2014, at 12:21 PM, Nate Gordon <
> nate.gor...@appcore.com>
> >> wrote:
> 
> > Let me ask the question, why have master be develop and a release
> >> branch be
> > "master"? If we are going to follow gitflow, why not just stick
> >> with
> >> the
> > norm? If master is the development branch, it might no

Re: [DISCUSS][PROPOSAL] git workflow

[Erik Weber]

That seems to handle my concern :-)

Erik
25. juli 2014 13:16 skrev "Rajani Karuturi" 
følgende:

> branches will be deleted after the release or hotfix if you use the
> git-flow commands.
>
> This would be the flow for a hotfix:
> 1. branch off from the release tag on master. in this case it would be
> release/4.4.0
> 2. commit the fixes in hotfix/4.4.1
> 3. do the release
> 4. merge to develop
> 5. merge to master and update tags
> 6. delete hotfix branch
>
> But, I agree that there can be a problem when we wish to do 4.4.2 if we
> delete the hotfix branch
>
> may be we should use git-flow support instead of hotfix which doesn’t
> delete the branch
> http://stackoverflow.com/a/16866118/201514
>
> ~Rajani
>
>
>
> On 25-Jul-2014, at 12:31 pm, Daan Hoogland 
> wrote:
>
> > Rightful question Erik,
> >
> > Rajani mentioned that release branches will be deleted. This will only
> > happen once the release is no longer supported. Any hotfix branch will
> > still have to merged on that (and master possibly) until we stop
> > supporting that branch.
> >
> > On the other hand you can branch from any commit.
> >
> > btw 4.4.1 is a bad example of you as we will still maintain that
> > without gitflow. But it is valid for for instance 4.5.2 or 5.0.1.
> >
> > On Fri, Jul 25, 2014 at 8:04 AM, Erik Weber  wrote:
> >> This is out of my git league, but how do you handle minor versions that
> way?
> >>
> >> Assuming 4.8.0 is the latest stable release and HEAD on master.
> >>
> >> Then you want to release 4.4.1.
> >>
> >> First of all can you develop bugfixes for 4.4 along the way, when both
> >> develop and master HEAD might be hugely different?
> >>
> >> Second, can you commit  behind HEAD? You don't want the 4.4.1 release
> >> instead of 4.8.0 to be HEAD
> >>
> >> Someone might have good solutions to this, but if not I would propose to
> >> keep the release branches for future bugfixes.
> >>
> >> Erik
> >> 25. juli 2014 06:02 skrev "Rajani Karuturi"  >
> >> følgende:
> >>
> >>> On 24-Jul-2014, at 10:25 pm, Mike Tutkowski <
> mike.tutkow...@solidfire.com>
> >>> wrote:
> >>>
> >>>> I believe I agree with these steps.
> >>>>
> >>>> A couple questions:
> >>>>
> >>>> Is 'master' simply always going to be equal to what's the most recent
> >>>> version of the code that's in production?
> >>>
> >>> I think so. master will always be at the latest release and all the
> >>> previous releases properly tagged. The release branches would be
> deleted
> >>> once release is done.
> >>>
> >>>>
> >>>> Also, would 'develop' be for 4.6 code then and 4.5 code would go
> directly
> >>>> into RELEASE-4.5?
> >>>>
> >>>
> >>> Yes. 4.6 work should be done on develop branch and any 4.5 bug fixes
> >>> should be done on the 4.5 branch.
> >>>
> >>>
> >>>
> >>> ~Rajani
> >>>
> >>>
> >>>>
> >>>> On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi <
> >>>> rajani.karut...@citrix.com> wrote:
> >>>>
> >>>>>
> >>>>> Hi Daan,
> >>>>> here is what i propose:
> >>>>>
> >>>>> 1. rename 'master' to 'develop’
> >>>>> 2. branch a new 'master' from '4.4’
> >>>>> 3. branch 'RELEASE-4.5' from the develop
> >>>>> 4. merge 'RELEASE-4.5' to master once the release voting is done.
> >>>>>
> >>>>> RELEASE-4.6 branch should be off develop as all the feature branches
> >>> would
> >>>>> be merged there before freeze for 4.6 and would be merged to master
> when
> >>>>> the release is voted.
> >>>>>
> >>>>> The other question I have is in the step:4. how are we going to
> manage
> >>>>> fixes to 4.5 post branch cut?  ( assuming no features as the freeze
> is
> >>> done)
> >>>>>
> >>>>> ~Rajani
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 24-Jul-2014, at 11:52 am, Daan Hoogland 
> >>

Re: Unable to build cloudstack.

[Erik Weber]

Did you pull the branch or the tag?

Erik
25. juli 2014 21:18 skrev "Elapavuluri, Jaya" 
følgende:

> Hello,
>
> I had setup cloudstack 4.4 environment which was running fine.
>
> I recently did a git pull to get the updates after which when I tried to
> mvn clean install I was encountering with the following error.
>
> Failed to execute goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check
> (cloudstack-checkstyle) on project cloud-maven-standard: Execution
> cloudstack-checkstyle of goal
> org.apache.maven.plugins:maven-checkstyle-plugin:2.11:check failed: Plugin
> org.apache.maven.plugins:maven-checkstyle-plugin:2.11 or one of its
> dependencies could not be resolved: Failure to find
> org.apache.cloudstack:checkstyle:jar:4.4.1-SNAPSHOT in
> http://repository.apache.org/snapshots was cached in the local
> repository, resolution will not be reattempted until the update interval of
> apache.snapshots has elapsed or updates are forced -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the
> -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginResolutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR]   mvn  -rf :cloud-maven-standard
>
> Could someone please help out regarding this issue?
>
>

Re: [DISCUSS] git commit proces

[Erik Weber]

On Mon, Jul 28, 2014 at 1:22 PM, Daan Hoogland 
wrote:

> H,
>
> I see a lot of commits happening directly on the master branch. Yet
> there were no counter arguments against the proposed gitflow and the
> discussion around it. This leaves me with the idea that the thread is
> largely ignored by the community. It is my understanding that we
> agreed never to commit anything to master anymore that hasn't been
> first committed to a branch and is merged back to master (instead of
> cherry-picked). What mistake in thinking am I making here?
>
>

Not familiar with bylaws and the such, but wouldn't a change like this
require some sort of voting and potentially a more formal information?

Requiring everyone to read through a 50+ replies mail thread and comprehend
it could be a bit much.

I would suggest an updated document that explain the expected workflow.

-- 
Erik

[ACS44] KVM SystemVM template trouble

[Erik Weber]

Tried helping Soeren Malchow on irc today, with a new ACS44 installation.

The docs referenced ACS43 system templates from January, but even by using
the late June ones that got uploaded after the heartbleed incident it still
does not work.

The error message is: "Unsupported major.minor version 51.0" which points
to wrong java version installed.

The systemvm template is installed with openjdk-6

Manually upgrading it to openjdk-7-jre-headless seems to do the trick, but
only lasts for systemvm's lifetime (and not new ones), and is no permanent
fix.

Before I file a bug, could anyone help test the same on other hypervisors?
I don't really have a lab available, so I can't easily test on a lot of
installations.

To be clear, I'm not sure if this happens for both upgrades and new
installations, so please try with a clean installation first.

A proper fix is to release a new systemvm template with openjdk-7 and
updating docs, but as of yet I don't know if it applies to all hypervisors
or only KVM.


Thanks,

Erik

Re: [ACS44] KVM SystemVM template trouble

[Erik Weber]

On Tue, Jul 29, 2014 at 11:41 AM, Wido den Hollander  wrote:

>
>
> On 07/29/2014 02:44 AM, Erik Weber wrote:
>
>> Tried helping Soeren Malchow on irc today, with a new ACS44 installation.
>>
>> The docs referenced ACS43 system templates from January, but even by using
>> the late June ones that got uploaded after the heartbleed incident it
>> still
>> does not work.
>>
>>
> Have you tried the 4.4 templates found here: http://cloudstack.apt-get.eu/
> systemvm/4.4/
>
>

Not yet, as of the moment I'm more curious of which of our documentet
systemvm templates that needs to be changed.


Erik

Re: [ACS44][BUG] SystemVM not working on 4.4

[Erik Weber]

Changing subject as it's not only KVM related.

Am I the only one concerned about the fact that potentially every ACS44
installation, if installed according to doc, is broken?

The last day there's been atleast three people on IRC with similar symptoms
(system vms not working), one reverted to 4.3 before I could get him/her to
verify it to be the same problem, but two confirmed the java error.

The last one on irc to confirm the issue was an upgrade btw, so it's not
only new installations that has the issue.

Manually updating java on the ssvm and cpvm is a temporarily fix, but not a
good one in the long run.

Downloading the latest 4.4 template from jenkins and updating MySQL
manually seems to give good working system vms as far as I have tested.



Erik

On Tue, Jul 29, 2014 at 11:53 AM, Daan Hoogland 
wrote:

> given the move from java6 to j7; all
>
> On Tue, Jul 29, 2014 at 11:49 AM, Erik Weber  wrote:
> > On Tue, Jul 29, 2014 at 11:41 AM, Wido den Hollander 
> wrote:
> >
> >>
> >>
> >> On 07/29/2014 02:44 AM, Erik Weber wrote:
> >>
> >>> Tried helping Soeren Malchow on irc today, with a new ACS44
> installation.
> >>>
> >>> The docs referenced ACS43 system templates from January, but even by
> using
> >>> the late June ones that got uploaded after the heartbleed incident it
> >>> still
> >>> does not work.
> >>>
> >>>
> >> Have you tried the 4.4 templates found here:
> http://cloudstack.apt-get.eu/
> >> systemvm/4.4/
> >>
> >>
> >
> > Not yet, as of the moment I'm more curious of which of our documentet
> > systemvm templates that needs to be changed.
> >
> >
> > Erik
>
>
>
> --
> Daan
>

Re: [ACS44][BUG] SystemVM not working on 4.4

[Erik Weber]

Frankly I don't know, I didn't focus much on the management server logs.

It's easy to check if you're affected by checking the
/var/log/cloud/cloud.out on either the ssvm or cpvm for the version error.

Erik


On Tue, Jul 29, 2014 at 8:34 PM, Tanner Danzey  wrote:

> Is the behavior you are describing here followed by a
> "com.cloud.exception.AgentUnavailableException: Resource [Host:13] is
> unreachable: Host 13: Unable to start instance due to Unable to get answer
> that is of class com.cloud.agent.api.StartAnswer"? We upgraded from 4.3 and
> found this fun little nugget. Would you be able to advise how to do a
> manual MySQL template upgrade with 4.4 templates?
>
>
> On Tue, Jul 29, 2014 at 9:05 AM, Erik Weber  wrote:
>
> > Changing subject as it's not only KVM related.
> >
> > Am I the only one concerned about the fact that potentially every ACS44
> > installation, if installed according to doc, is broken?
> >
> > The last day there's been atleast three people on IRC with similar
> symptoms
> > (system vms not working), one reverted to 4.3 before I could get him/her
> to
> > verify it to be the same problem, but two confirmed the java error.
> >
> > The last one on irc to confirm the issue was an upgrade btw, so it's not
> > only new installations that has the issue.
> >
> > Manually updating java on the ssvm and cpvm is a temporarily fix, but
> not a
> > good one in the long run.
> >
> > Downloading the latest 4.4 template from jenkins and updating MySQL
> > manually seems to give good working system vms as far as I have tested.
> >
> >
> >
> > Erik
> >
> > On Tue, Jul 29, 2014 at 11:53 AM, Daan Hoogland  >
> > wrote:
> >
> > > given the move from java6 to j7; all
> > >
> > > On Tue, Jul 29, 2014 at 11:49 AM, Erik Weber 
> > wrote:
> > > > On Tue, Jul 29, 2014 at 11:41 AM, Wido den Hollander  >
> > > wrote:
> > > >
> > > >>
> > > >>
> > > >> On 07/29/2014 02:44 AM, Erik Weber wrote:
> > > >>
> > > >>> Tried helping Soeren Malchow on irc today, with a new ACS44
> > > installation.
> > > >>>
> > > >>> The docs referenced ACS43 system templates from January, but even
> by
> > > using
> > > >>> the late June ones that got uploaded after the heartbleed incident
> it
> > > >>> still
> > > >>> does not work.
> > > >>>
> > > >>>
> > > >> Have you tried the 4.4 templates found here:
> > > http://cloudstack.apt-get.eu/
> > > >> systemvm/4.4/
> > > >>
> > > >>
> > > >
> > > > Not yet, as of the moment I'm more curious of which of our documentet
> > > > systemvm templates that needs to be changed.
> > > >
> > > >
> > > > Erik
> > >
> > >
> > >
> > > --
> > > Daan
> > >
> >
>
>
>
> --
> *Tanner Danzey*
> Systems Engineer
> Northstar Technology Group
> arkan...@gmail.com / tanner.dan...@northstar-tg.com
> (701) 237-9096 x7122
>

Re: [DISCUSS] git commit proces

[Erik Weber]

I'm not sure this applies to hotfixes to previous versions, ie. not the
current master release.

The hotfix might not code wise apply to the current develop/master at all.

Assume that we one year from now, after releasing 4.5 and 4.6 using
gitflow, and are working towards a 4.7 in develop, we need to issue a
hotfix to 4.5 due to a security breach or similar. The issue could be gone
from develop because of refactoring or something else, but would still need
to be fixed for 4.5 (and 4.6 if the problem exists there) if that's still
supported.

which leads to my question; what's the support status for releases? how
long do we support them?

someone (can't remember the name), mentioned it could be used as a support
release/branch in gitflow terms.


Erik


On Tue, Jul 29, 2014 at 10:23 PM, Alena Prokharchyk <
alena.prokharc...@citrix.com> wrote:

> My understanding is - we should always merge the fixes to both *develop
> and *master branches. Merging to develop branch should be mandatory as
> that’s the place where automatic nightly builds + the regression tests are
> run against. That’s what the article from Daan’s email says:
>
> Master branch: "We consider origin/master to be the main branch where the
> source code of HEAD always reflects aproduction-ready state.”
>
> Develop branch: "We consider origin/develop to be the main branch where
> the source code of HEAD always reflects a state with the latest delivered
> development changes for the next release. Some would call this the
> “integration branch”. This is where any automatic nightly builds are built
> from. When the source code in the develop branch reaches a stable point
> and is ready to be released, all of the changes should be merged back into
> master"
>
> Only if the tests pass on *develop branch, the changes get merged to
> master branch.
>
> Daan, please confirm if that’s how we are planning to operate. This thread
> also brings another question: are we going to run automation/CI against
> both *develop/*master branches? On *develop to ensure that the branch is
> ready to be merged to master. And on *master to ensure that the code is
> production ready. And if we are planning to run it on both branches, how
> often should we do it on one vs another?
>
> -Alena.
>
>
>
> On 7/29/14, 1:06 PM, "sowmya samala"  wrote:
>
> >If a bug fix branch is cut off from Develop branch then all the current
> >changes like new feature merges, new enhancement/development of a future
> >release will also get merged to Master branch instead of a Release branch
> >once the bug fix branch is merged. Our motto about keeping Master is to
> >maintain a stable branch right and to my knowledge Develop branch is used
> >for parallel development.
> >
> >And for any production fixes, a hot fix branch should be created from a
> >stable branch like Master only. If it is a Release bug fix then the branch
> >should be created from Release branch and then merged{if we plan to commit
> >release bug fixes in a separate branch instead of a Release branch}.
> >
> >Please correct me if I am wrong in understanding.
> >
> >
> >On Tue, Jul 29, 2014 at 3:04 PM, Tanner Danzey 
> wrote:
> >
> >> Ah. I simply misunderstood. That sounds very reasonable to me.
> >>
> >>
> >> On Tue, Jul 29, 2014 at 1:59 PM, Alena Prokharchyk <
> >> alena.prokharc...@citrix.com> wrote:
> >>
> >> > Tanner,
> >> >
> >> > My question was about bugs happening not in production (the branch
> >>that
> >> is
> >> > already released). For those hot fix branches are needed - and that
> >> > described in the article. My question was about new bugs happening
> >>either
> >> > in the *developer branch or *release branch that hasn’t been released
> >> yet.
> >> > In CS “git commit” document we should clearly define the criteria for
> >>the
> >> > bugs requiring separate branch vs bugs that can be committed to the
> >> > *developer/*release branch directly.
> >> >
> >> > Thanks,
> >> > Alena.
> >> >
> >> > On 7/29/14, 11:53 AM, "Tanner Danzey"  wrote:
> >> >
> >> > >This seems like a reasonable use scenario, but is it not what the
> >> article
> >> > >located at @ http://nvie.com/posts/a-successful-git-branching-model/
> >> > >already describes?
> >> > >
> >> > >
> >> > >On Tue, Jul 29, 2014 at 1:45 PM, Alena Prokharchyk <
> >> > >alena.prokharc...@citrix.com> wrote:
> >> > >
> >> > >> I would rather say that the bug fix branch should be cut from
> >> *developer
> >> > >> branch, not master, then merged to *developer upon fixing so all
> >>the
> >> > >>tests
> >> > >> are run for the fix. Only after tests pass, the merge to master
> >>from
> >> > >> developer should be done. If the bug doesn’t require branching out
> >> (see
> >> > >> the proposed criteria in my other email), it should be fixed
> >>directly
> >> in
> >> > >> *developer branch. Nothing should go to the master branch directly
> >> > >> bypassing the developer branch.
> >> > >>
> >> > >> -Alena.
> >> > >>
> >> > >> On 7/29/14, 11:37 AM, "sowmya samala"  wrote:

Re: [ACS44][BUG] SystemVM not working on 4.4

[Erik Weber]

This is work in progress for a guide to fixing broken system vm's, but
please note that this currently has seen limited testing yet, so take any
precautions you can.
https://gist.github.com/terbolous/102ae8edd1cda192561c


The best thing you can do before upgrading is to download the new system vm
template, that way you won't have to mess around inside the old one. You
would still have to change some database values, but that's far less work.

Erik

On Wed, Jul 30, 2014 at 11:27 AM, Andrei Mikhailovsky 
wrote:

> Hello guys,
>
> I am planning to upgrade my ACS from version 4.2.1 to version 4.4 this
> weekend. Following the last disastrous upgrade from 4.2.1 to 4.3.0, which
> also related to the system vm issues, I would like to verify the required
> steps to have a _working_ ACS following upgrade to 4.4? Reading this thread
> it seems that the documentation is wrong/misleading and that people are
> having issues with system vms.
>
> Could some one post a working set of instructions to fix the system vm
> issue that people are having?
>
> Thanks
>
> Andrei
>
>
>
> - Original Message -
>
> From: "Erik Weber" 
> To: "dev" 
> Sent: Tuesday, 29 July, 2014 8:08:21 PM
> Subject: Re: [ACS44][BUG] SystemVM not working on 4.4
>
> Frankly I don't know, I didn't focus much on the management server logs.
>
> It's easy to check if you're affected by checking the
> /var/log/cloud/cloud.out on either the ssvm or cpvm for the version error.
>
> Erik
>
>
> On Tue, Jul 29, 2014 at 8:34 PM, Tanner Danzey  wrote:
>
> > Is the behavior you are describing here followed by a
> > "com.cloud.exception.AgentUnavailableException: Resource [Host:13] is
> > unreachable: Host 13: Unable to start instance due to Unable to get
> answer
> > that is of class com.cloud.agent.api.StartAnswer"? We upgraded from 4.3
> and
> > found this fun little nugget. Would you be able to advise how to do a
> > manual MySQL template upgrade with 4.4 templates?
> >
> >
> > On Tue, Jul 29, 2014 at 9:05 AM, Erik Weber  wrote:
> >
> > > Changing subject as it's not only KVM related.
> > >
> > > Am I the only one concerned about the fact that potentially every ACS44
> > > installation, if installed according to doc, is broken?
> > >
> > > The last day there's been atleast three people on IRC with similar
> > symptoms
> > > (system vms not working), one reverted to 4.3 before I could get
> him/her
> > to
> > > verify it to be the same problem, but two confirmed the java error.
> > >
> > > The last one on irc to confirm the issue was an upgrade btw, so it's
> not
> > > only new installations that has the issue.
> > >
> > > Manually updating java on the ssvm and cpvm is a temporarily fix, but
> > not a
> > > good one in the long run.
> > >
> > > Downloading the latest 4.4 template from jenkins and updating MySQL
> > > manually seems to give good working system vms as far as I have tested.
> > >
> > >
> > >
> > > Erik
> > >
> > > On Tue, Jul 29, 2014 at 11:53 AM, Daan Hoogland <
> daan.hoogl...@gmail.com
> > >
> > > wrote:
> > >
> > > > given the move from java6 to j7; all
> > > >
> > > > On Tue, Jul 29, 2014 at 11:49 AM, Erik Weber 
> > > wrote:
> > > > > On Tue, Jul 29, 2014 at 11:41 AM, Wido den Hollander <
> w...@widodh.nl
> > >
> > > > wrote:
> > > > >
> > > > >>
> > > > >>
> > > > >> On 07/29/2014 02:44 AM, Erik Weber wrote:
> > > > >>
> > > > >>> Tried helping Soeren Malchow on irc today, with a new ACS44
> > > > installation.
> > > > >>>
> > > > >>> The docs referenced ACS43 system templates from January, but even
> > by
> > > > using
> > > > >>> the late June ones that got uploaded after the heartbleed
> incident
> > it
> > > > >>> still
> > > > >>> does not work.
> > > > >>>
> > > > >>>
> > > > >> Have you tried the 4.4 templates found here:
> > > > http://cloudstack.apt-get.eu/
> > > > >> systemvm/4.4/
> > > > >>
> > > > >>
> > > > >
> > > > > Not yet, as of the moment I'm more curious of which of our
> documentet
> > > > > systemvm templates that needs to be changed.
> > > > >
> > > > >
> > > > > Erik
> > > >
> > > >
> > > >
> > > > --
> > > > Daan
> > > >
> > >
> >
> >
> >
> > --
> > *Tanner Danzey*
> > Systems Engineer
> > Northstar Technology Group
> > arkan...@gmail.com / tanner.dan...@northstar-tg.com
> > (701) 237-9096 x7122
> >
>
>