+1
On Thu, Apr 19, 2018 at 5:45 AM, Ilya Kasnacheev
wrote:
> Hello!
>
> I recommend inclusion of this change so that it can make way into 2.5.
>
> Regards,
>
> --
> Ilya Kasnacheev
>
> 2018-04-19 9:03 GMT+03:00 Petr Ivanov :
>
> > There is not much time left for Apache Ignite 2.5 release, so let
Hello!
I recommend inclusion of this change so that it can make way into 2.5.
Regards,
--
Ilya Kasnacheev
2018-04-19 9:03 GMT+03:00 Petr Ivanov :
> There is not much time left for Apache Ignite 2.5 release, so let’s move
> stage II of packaging architecture implementation (with additional spl
There is not much time left for Apache Ignite 2.5 release, so let’s move stage
II of packaging architecture implementation (with additional split scheme
discussion) to 2.6 scope.
Instead, I’d like to include DEB package to Apache Ignite 2.5 release.
Corresponding PR is already prepared [1].
Als
Copying anything manually to anywhere /usr (excluding /usr/local) is an
example of slackwarization that package users and creators try to avoid.
> By linux file hierarchy convention, home dir should be in /usr/lib
Citation needed! I bet you're interpreting it wrong, since I've listed a
random dir
> On 15 Apr 2018, at 10:19, Ilya Kasnacheev wrote:
>
> Hello!
>
> With existing binary archive, user can move directories from
> apache-ignite-fabric/libs/optional to apache-ignite-fabric/libs to activate
> them.
>
> But with RPM, user should not contemplate moving directories from
> /usr/lib
Hello!
With existing binary archive, user can move directories from
apache-ignite-fabric/libs/optional to apache-ignite-fabric/libs to activate
them.
But with RPM, user should not contemplate moving directories from
/usr/lib/apache-ignite/optional to /usr/lib/apache-ignite.
User lacks permissio
Current packages design (after installation) does not differ from binary
archive - everything works (except necessity to run service instead
ignite.sh) just the same way, including libs/optional.
Also, there can be issues with system JDK version by default, but every
problem will be in journalctl
Ilya,
Thanks for your inputs. The reason why we decided to split Ignite into
several packages mimics the reason why Java community introduced modular
subsystem for JDK. That's all about size. Ignite distribution is too big,
and we're trying to separate it into several components so that people can
2018-04-13 7:42 GMT+03:00 Peter Ivanov :
> On Thu, 12 Apr 2018 at 20:04, Ilya Kasnacheev
> wrote:
>
> >
> > Moreover I did not find a way to start service if default installed JVM
> is
> > Java 7 :( I understand it's EOL, still this is something that hit me.
>
>
> Apache Ignite >=2.4 does not sup
On Thu, 12 Apr 2018 at 20:04, Ilya Kasnacheev
wrote:
> Hello! I have tried your RPM scripts.
>
> First of all, I'm not sure that apache-ignite-core is a good name for
> package which contains the actual server node kit, and that apache-ignite
> is a good name for a package that will install every
I am not sure that an email thread of over 20 messages is a good medium to
discuss proposals. In Ignite, we create IEPs. Can you please summarize your
proposal there and send a link there? Please explain not only the change
itself, but the reason why we need it.
D.
On Thu, Apr 12, 2018 at 4:00 PM
Petr,
I wouldn't postpone this until 2.6 that will be out nor earlier than 3
months from now.
*Anton V.*, could review and sign off the changes? Not sure we have a
better person in the community who can do that.
--
Denis
On Thu, Apr 12, 2018 at 9:10 AM, Petr Ivanov wrote:
> If someone from PM
Hello! I have tried your RPM scripts.
First of all, I'm not sure that apache-ignite-core is a good name for
package which contains the actual server node kit, and that apache-ignite
is a good name for a package that will install everything (including cpp
bindings). How does other packages solve th
If someone from PMCы or Committers still sees necessity about including these
tasks into Apache Ignite 2.5 release, this is the last chance to do so.
Otherwise this task will be moved to at 2.6 release at least, or even moved to
backlog indefinitely.
> On 9 Apr 2018, at 19:08, Petr Ivanov wro
To top new RPM architecture off, update to release process is introduced — [1]
[2].
Both tasks (this one and IGNITE-7647) are ready for review and should be merged
simultaneously.
[1] https://issues.apache.org/jira/browse/IGNITE-8172
[2] https://github.com/apache/ignite-release/pull/1
> On
Hello!
Let me share my idea of how this shoud work. Splitting package into
sub-packages should be dependency-driven.
It means that all Ignite modules without dependencies or with small
dependencies (such as ignite-log4j) should be included in ignite-core. It
doesn't make sense to make a zillion R
> On 29 Mar 2018, at 12:32, Max Shonichev wrote:
>
>
>
> 1. About packaging/package.sh
>
> 1.1. I personally dislike the use of bashism, e.g. like reserved keywords,
> double '[[', double '((', but that's ok
> for targeted distro (RHEL/Centos). The only requirement is please add more
> comme
1. About packaging/package.sh
1.1. I personally dislike the use of bashism, e.g. like reserved keywords,
double '[[', double '((', but that's ok
for targeted distro (RHEL/Centos). The only requirement is please add more
comments in tough places
to improve code readability and maintanbility.
1.
Peter, great work!
I'll check up PR in the near time.
--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>
> We can either
> store files as is (as Cassandra does, see link below) in something
> that is called Generic Repository — this way we manage directory layouts
> ourselves and have more control over what is published and how
> or
> store files in prepared RPM / DEB repositories wh
I can start preparing DEB packages right after adding RPM build to nightly
release build (as an experiment / experience for future addition of packages
build into release process) basing on current RPM architecture.
I will create branch from IGNITE-7647, then.
> On 28 Mar 2018, at 10:06, Dmitr
Thanks, Petr!
I would love to test the package installation, but I can only do it on
Ubuntu. Do you know when will we be able to get the Debian instructions,
similar to this:
https://ignite.apache.org/download.cgi#rpm-package
D.
On Wed, Mar 28, 2018 at 12:01 AM, Petr Ivanov wrote:
> No, not y
No, not yet.
Currently we are discussing RPM packages only.
I want to get all feedback and possible errors working on RPM packages, so that
when we have stable agreed architecture and etc. I can recreate it in DEB
packages without necessity to fix bugs in both RPM and DEB packages
simultaneous
Petr,
I am confused. Do we already have Debian packages?
D.
On Tue, Mar 27, 2018 at 5:10 AM, Petr Ivanov wrote:
> Hi, Igniters!
>
>
> Here are some news on our RPM packages initiative.
>
> 1. I’ve finished preliminary developing of Stage II version of RPM
> packages [1]. Main “new feature” is
Hi, Igniters!
Here are some news on our RPM packages initiative.
1. I’ve finished preliminary developing of Stage II version of RPM packages
[1]. Main “new feature” is — split design. Also I’ve added package.sh script
for automating package building process which will help organise correspondi
I suppose that most everything if not all from libs/options will go to OPTIONAL
(I’d call it simply ‘apache-ignite-libs').
More precise lib selection (if something from optional would better to have in
core package) will be discussed right after preliminary split architecture
agreement.
> On
I like idea of keeping simple system of modules, so +1 from me.
Where optional libs (e.g Direct IO plugin) would be included, would it be
core or optional?
чт, 15 мар. 2018 г. в 22:09, Denis Magda :
> >
> > >
> > > How big would be a final core module?
> > Around 30M. Can be shrinked to ~15M if
>
> >
> > How big would be a final core module?
> Around 30M. Can be shrinked to ~15M if separate Visor and create it’s own
> package.
Guys, 30 vs 280M is a hge difference. I would agree with Petr and
propose the simplest modular system:
- core module that includes basic Ignite capabilit
*DEB package
> On 15 Mar 2018, at 10:35, Petr Ivanov wrote:
>
> Considering that DEV package for now is almost platform independent (its a
> java application more or less), that package will work almost on any
> DEB-based linux, including but not limited to Ubuntu, Debian, etc.
> The only res
Considering that DEV package for now is almost platform independent (its a java
application more or less), that package will work almost on any DEB-based
linux, including but not limited to Ubuntu, Debian, etc.
The only restriction is existence of systemctl (systemd) service manager — we
are dep
Will Debian package work for Ubuntu?
D.
On Wed, Mar 14, 2018 at 9:52 PM, Petr Ivanov wrote:
> Not a problem, rather nuisance. Also, when we will move to official
> repositories, there can be a problem from OS community.
>
> Concerning DEB packages — I plan to use RPM as base for DEB package bui
Not a problem, rather nuisance. Also, when we will move to official
repositories, there can be a problem from OS community.
Concerning DEB packages — I plan to use RPM as base for DEB package build
(package layout / install scripts) for speeding up things and excluding
possible duplication and
> On 14 Mar 2018, at 22:12, Denis Magda wrote:
>
> Petr,
>
> How big would be a final core module?
Around 30M. Can be shrinked to ~15M if separate Visor and create it’s own
package.
> As for the optional libs do you
> suggest installing them with a single command or each module can be
> ins
Peter,
I don't think the package size of 280M is going to be a problem at all, but
what you are suggesting can be an improvement down the road.
In the mean time, I think our top priority should be to provide packages
for Debian and Ubuntu. Having only RPMs is not nearly enough.
Agree?
D.
On We
Petr,
How big would be a final core module? As for the optional libs do you
suggest installing them with a single command or each module can be
installed separately?
--
Denis
On Wed, Mar 14, 2018 at 2:36 AM, vveider wrote:
> Hi, Igniters!
>
>
> Release 2.4 is almost there, at least binary part
> On 14 Mar 2018, at 12:46, Dmitry Pavlov wrote:
>
> Hi,
>
> Did not understand fully that splitted delivery means.
> Is it correct,that user will have install
> install ignite:core
> install ignite:opt_libs
> with separated commands?
It will be one command with several arguments, i.e.
yum
Hi,
Did not understand fully that splitted delivery means.
Is it correct,that user will have install
install ignite:core
install ignite:opt_libs
with separated commands?
Or there will be some aggregating package like ignite:full and several
options like ignite:core.
Sincerely,
Dmitriy Pavlov
ср
Hi, Igniters!
Release 2.4 is almost there, at least binary part of it, so I'd like to move
forward to further improve and widen AI delivery through packages.
As of now, Apache Ignite ships in RPM package weighing about 280M+ and, to
improve usability and significantly reduce required download siz
38 matches
Mail list logo