ace-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <marcel.offerm...@luminis.nl>
Subject Re: Use of ACE for a consumer application
Date Wed, 27 Mar 2013 21:52:06 GMT
Hello Dan,

On Mar 27, 2013, at 5:55 AM, Dan Gravell <elstensoftware@googlemail.com> wrote:

> Hi Marcel...
> 
>> - How many targets can ACE scale to? I have over 2000 new users each
>> month,
>>> and probably about 20,000 active users
>> 
>> Hard to tell exactly, but we've setup ACE in such a way that you can not
>> only create a single server for all the targets, but also create a master
>> server with several "relay" servers (which act like proxies) to spread the
>> load.
> 
> It wasn't just the serving-up of distros I was wondering about... it was
> stuff like the UI. One thing that took my notice was the targets column in
> the admin UI (the one on the far right). I haven't actually tried it yet so
> I don't know if that list is loaded lazily, or what. Does it show all
> targets that ever existed?

It is loaded lazily, but you are right that it's probably no longer practical to have such
a long list of targets and browse through them.

Probably in your case you don't care about the targets that much in the UI, so one thing you
could do is simply not display them there at all. We have some code in there to, based on
users and their rights, disable certain information.

>> It also depends a bit on the number of updates, size of bundles and how
>> often these targets poll for changes.
> 
> A new distro is produced once a fortnight. The maximum size of a distro is
> 35MB. I have control over the polling because I think I'll build the update
> UI into my app... but I would call the first time the update UI is shown
> and then when the user wanted to 'check for updates'.

Ok, and probably you're not updating every bundle every time either, right? So from a bandwidth
point of view that should still work.

>>> - How does target management work when users are behind common-or-garden
>>> ISPs with dynamic IPs etc? I don't really care about what each individual
>>> target is running, although it would be a nice feature to be able to
>>> remotely manage a given target. But this would be exceptional (maybe
>>> changing the logging on a particular user's target to diagnose some
>> problem)
>> 
>> Right now, ACE keeps track of each individual target, but it can be setup
>> so any new target registers automatically and gets a specific software
>> distribution.
> 
> What's this feature called and can I read about it anywhere?

We have a bundle that can be found in this project:

org.apache.ace.client.automation

It automatically registers new targets as they appear. That's one part of the solution. The
second part is making sure there is an association between a distribution that contains all
the software you want to deploy to such new targets and the new targets. Associations in ACE
have a left hand and right hand side. Both can use filter conditions to match entities. If
you normally create them using the web UI, you create 1 to 1 associations. If you use the
REST endpoint, you have more flexibility and can create an assocation that will have a filter
that matches all targets.

There is some documentation about that here:

http://ace.apache.org/user-doc/restapi.html

You should try to create a "distribution2target" with a leftEndpoint that matches your distribution
and a rightEndpoint that is an LDAP filter, something like: (name=*)

>> ACE uses a management agent, which polls the server using HTTP. So dynamic
>> IPs are no problem, and firewalls usually also not.
> 
> When you say 'polls'... any recurring 'poll' can be switched off, right? I
> just want to check for a new distro when the user asks for it (for now... I
> suppose a Chrome-like dream of fully automatic updates is one to consider).

Yes, see below for the link to the docs about this.

>>> - How can this work with an installer? Ideally I'd like to install my
>>> entire product when the user downloads it and not have a two stage
>>> installation
>> 
>> That is currently not supported, unfortunately, but it is definitely an
>> interesting use case that we should explore. We actually do have some
>> support for installing our deployment packages from a local filesystem, but
>> we cannot at this point make a seamless switch from local installation to
>> remote installation. I would not mind at all putting that on the roadmap
>> though.
> 
> My concern with two stage installers is that the user will become
> frustrated with another wait while the app initialises itself and downloads
> its latest code. Maybe it's a false fear. Maybe (I use IzPack) I can just
> write a plugin to the installer which contacts the ACE server...

I think you have a valid point, and it's worth seeing if ACE can support this in the future.

> Apps with ACE agents work fine offline, right? I don't want a SimCity style
> situation on my hands ;)

Yes, they do work off-line, no problems there.

>>> - My app runs a Jetty web server where the Update UI lies... how does
>> this
>>> work with ACE? Do I contact the ACE server API, or interact with the
>> agent
>>> bundles co-located on the same OSGi container?
>> 
>> The management agent by default has an embedded scheduler that
>> periodically polls the server. Instead of that scheduler, you can also
>> directly invoke the update task from OSGi (it is a service). So your update
>> UI could do that, and disable the scheduler.
> 
> Any links to docs for this? Or is this 'read the code'?

There is documentation for this on the website:

http://ace.apache.org/dev-doc/design/ace-deployment-strategies.html

>> I'm sure these answers have triggered more questions, so don't hesitate to
>> keep asking! :)
>> 
> 
> Will do, have done :)
> 
> Assume you're at EclipseCon, hope it's going well.

Yes, talking to lots of interesting people here, thanks!

Greetings, Marcel


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message