Hi all,
> I've reworked the same panel to support
> uploading and installing standard rpms and wrapper rpms, _somewhat_ similar
> to the Blades concept. Once we see the Blades docs we should be able to
> make our panel support uploading Blades as well.
>
> This means you may use the Mitel panel for downloading official Blades via
> the Internet from Mitel and our panel when you can't download from the
> Internet or want to perform a local Blade install.
OK, I just want to post some comments and thoughts for others to follow:
1) A blade is actually a rpm file that just verifies dependencies and
executes commands. The problem is, it's actually a rpm file. There is no
problem with this in the "present blade system" as there is only one source
of blades (Mitel's NOC) and the user doesn't really "see" the blade.
The problem is, if you try to make this more manually and independat from
Mitel, you need to send your client or post in the website the actual rpm
file AND the client will see is ended as .rpm
As we know, most users / cliets are not linux knownfull and will think:
God, I like this new server, it works wonders but there is no Xbill blade
that I want. My friend has Xbill installed in his RH 6.2 and he just needed
to download this xbil.i385.rpm from rpmfind or take it from his official CD.
Sure I can do the same.... what I'm trying to say is, using a "real" rpm file
when the source is not as controlled as is the situation now, would probably
mean a future problem.
This is not to say that using rpm gives you a lot of power AND using blades
will make "developers work" much easier. Maybe something as simple as
renaming the blade, like monitor-blade.rpm to monitor-blade.upd and
internally get it back to rpm would be enough BUT this needs a change in the
way blades are done or at least the way they are delivered "out of Mitel's
NOC"
2) What happens with those "server only - no intenet" servers? The blade
system needs to download some files during the install process, but, if you
are offline? Sending all the needed packages in one file allowed us to send
the file by email and let the client install the upd locally. This is not
possible with the blade format, as the rpm wrapper does not contain "real
data" and if you just bunch all toguether whats the difference with an
standard rpm?
Resuming, I beleive there are some weak points in the "blade standard" that
make it work great when you are tied to Mitel's NOC (or others) but not when
the process is more manual or the client doesn't have a permanent connection
to the Internet (actually a very common situation here in Spain)
Hope this just makes us think about it. I would really like to see some
comments to this from the "official" guys. I would be happy to adapt the upd
format or the update panel to reflect this but only if this issues are
addressed and discussed.
> We've got some internal testing and conferencing to complete. I'm sure we
> will be ready for devinfo testing in a day or two and Blades testing
> whenever we see some docs.
:))
See you.
--
Jaime Nebrera - [EMAIL PROTECTED]
--
Please report bugs to [EMAIL PROTECTED]
Please mail [EMAIL PROTECTED] (only) to discuss security issues
Support for registered customers and partners to [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Archives by mail and http://www.mail-archive.com/devinfo%40lists.e-smith.org
