ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Willem Janssen <janwillem.jans...@luminis.eu>
Subject Re: [feedback] hurdles when working with ACE
Date Fri, 26 Feb 2016 12:13:58 GMT
Hi Bree,

Thanks for your elaborate feedback! This reply was lingering in my drafts for unknown reasons,
sorry for the delayed response.

> On 03 Feb 2016, at 19:28, Bree Van Oss <Bree.VanOss@myfuelmaster.com> wrote:
> 
> Following are a list of issues we have encountered with ACE (2.0.1) and a few suggestions.
> 
> Before getting into that, I’m curious if you guys have considered providing plugins
for one or more Deployment/Configuration Management platforms (e.g. Chef, Ansible, Salt)?
As I see it, ACE's primary value add is the ability to perform incremental, live updates to
an OSGi container. Would be awesome to leverage the larger communities that have grown up
around these toolsets.

Interesting thought; I’ve only limited experience with these other toolkits, so might I
ask how you would envision this? Let Ace interact with these platforms, or the other way around?

> Issues
> 
> UI's lack of support for concurrent workspace edits leads to conflicts in high-use environment
like our internal ACE server used to provision Testers' environments.
> 
> Current UI is clunky and unpredictable.

Totally agree. The UI is something we definitely should overhaul and improve upon.

> We've had difficulty using GoSH as a scripting language. It's syntax is non-obvious and
does not seem to follow any "standard" syntax metaphors.

Agreed. Our idea was to redesign the whole “client” API to more up-to-date standards.
This also would involve the way you interact with the repository models in ACE. Using Gogo
script is not on the roadmap for that, I can assure you that ;)

> We need a well defined/documented way to hook into the deployment lifecycle in the agent
to support (at least) the following.
> - Ability to execute code when deployment starts and/or completes (with success or failure).
> - Programatically abort a deployment attempt.
> - Define deployment windows (for example, to configure a deployment via the UI, but know
that the deployment won't start until the target is within the deployemnt window)

While this is currently possible with the Agent, it is not clearly documented. To be honest,
I do have a todo on my list that should describe most of your wishes. I’ve created https://issues.apache.org/jira/browse/ACE-537
as a “gentle” reminder.

> 
> Managing all the various config files has been problemattic. Often the same values are
replicated in multiple config files.

What do you exactly mean by this? The way that “tags” are used in the UI, or …?

> 
> We had to extend the ConnectionManager and ConnectionFactory (server and agent) to provide
support for HTTPS with PKCS#11

We do not support PKCS#11 out of the box. This might be a good thing to do. Also, the documentation
on using HTTPS is lacking at the moment. I’ve created  https://issues.apache.org/jira/browse/ACE-538
for this.

> Certificate validation should be implemented using PKIX trustmanager via Jetty. No custom
code should be required to do basic validation, revocation-checking, etc.

You are referring to the code in connection factory & the authentication? What custom
code are you referring to?

> 
> We have to clean our internal Dev/QA ACE instance every few weeks because the server
becomes unresponsive. Restarting ACE does not resolve the issue.
> - We're using CDS with around 150 artifacts in each distribution and around 10 and 20
targets at any given time, so I'm sure there's a lot of metadata, but it's frustrating to
deal with these performance issues.
> - We're very concerned that this issue will bite us in production. We will need to keep
at least two or tree releases in ACE and other than completely blowing ACE (OBR and bundle-cache)
away, we don't have a good mechanism to clean up old distributions.

Hm, that is seriously bad. We’ve put some effort in tuning and dealing with large repositories
(up to 100 targets with 1000+ artifacts) which yielded several improvements. We might want
to dive deeper into this. Are you willing to create an issue on JIRA with some details on
this so we are able to replicate this issue?

> Suggestions
> 
> UI/REST-API revamp
> - support multiple users performing concurrent updates

actually, that is supported, the only nasty thing is that you have to resolve conflicts by
hand. This is something we should improve on.

> Persistence revamp
> - support multi-user scenarios
> - support for Nexus as OBR

We’ve recently upgraded the default OBR version to Felix OBR, which supports the latest
OBR specification. I’ve to check if this would imply that you can support Nexus out of the
box.

> Rolling, file-based logging out of the box
> - Log target activity (deployment started/completed, results, etc)

Logging at the target or at the server? You can currently configure the number of entries
you want to retain in ACE; this would provide a rolling file-based logging.

> Deployment history
> - Via the UI

+1, definitely.

> Better support for config files when using CDS style deployment scenario
> - When using CDS, config files that have not changed are _always_ uploaded
> - Config files uploaded using CDS are not grouped like multiple versions of JARs are

Agreed. We should support the grouping of artifacts on all artifacts, not on bundles only.
The uploading of unchanged configuration files is something we need to look in to, it sounds
like a bug to me.

> Upgrade Jetty from 7 to latest (9.x)
> Upgrade Felix Dependency Manager

Both of these are part of the newly released Apache Ace 2.1.0.

> Provide a secure (HTTPS) configuration out of the box.

Fair point; we could include “snake oil” certificates for testing purposes out of the
box with instructions on how to use your own certificates. At least we should make it as easy
as possible to switch to HTTPS. I’ve created a JIRA issue (see above) for just that.

> Provide a way to "cascade delete" a distribution via the UI. Delete should remove the
distribution, related features and related artifacts, if they aren't being referenced by another
distribution.

Fair point.

> Migrate to Git from SVN to facilitate more community involvement

We’ve recently made some changes to ensure that you can use the Git mirror (see [1]) if
you’d like. Merging PRs is quite easy and straightforward to do.

> Consider developing ACE-based plugins for DevOps tools like Chef and Ansible.

As I wrote above, it is interesting to discuss this further, are you willing to share your
thoughts on this?


Thanks for your feedback,

--
Met vriendelijke groeten | Kind regards

Jan Willem Janssen | Software Architect
+31 631 765 814


My world is something with Amdatu and Apache

Luminis Technologies
Churchillplein 1
7314 BZ  Apeldoorn
+31 88 586 46 00

https://www.luminis.eu

KvK (CoC) 09 16 28 93
BTW (VAT) NL8170.94.441.B.01


Mime
View raw message