alas, iocage, I knew him well && wherefore art thou, iocage?

[Dave Cottlehuber]

Hey all,

iocage has hit a sweet spot for jail management, including the jail
properties directly into the dataset. Even in it's current form is super
useful. With an ansible module [1] as well it's delightfully
automatable. A big thank-you to all who have contributed!

However the current repo reads: **No longer supported. iocage is being
rewritten in a different language. **

so, 3 questions:

1. can we the community, fork the current version somewhere and continue
maintaining it within the ports tree under the same sysutils/iocage
name? This would allow those of us who are already using iocage to
continue doing so. I assume iocage-ng developers are ok with that?

2. this is a low-volume list, assuming (1) is agreed, could we continue
using/sharing the same list, or do we need to split off?

3. for iocage-ng is it primarily a change of language (i.e. what drove
this) and are there any thoughts about compatibility with current
iocage, especially around configuration and settings? It would be a
shame to end up with 2 almost-compatible solutions in the long run, and
I'd love to follow some of the discussion and development around this at
a level more than just waiting for commits to land if that's practical.

[1] https://github.com/fractalcells/ansible-iocage
[2] despite a zealous adherence to erlang in my private life

A+
Dave
With apologies to Yorick for stealing his line in the subject, and Romeo
for sidelining him.

—
Dave Cottlehuber

[Brandon Schneider]

> 1. can we the community, fork the current version somewhere and continue
> maintaining it within the ports tree under the same sysutils/iocage
> name? This would allow those of us who are already using iocage to
> continue doing so. I assume iocage-ng developers are ok with that?
>
> 2. this is a low-volume list, assuming (1) is agreed, could we continue
> using/sharing the same list, or do we need to split off?
>

No we are not ok with that. If you fork, it will be your own thing :) Which includes not being on the same mailing list, git repo or Twitter. You're totally able to fork as the license is there for that reason, but it's not reasonable to expect me to give up the keys I'm still using ;)

> 3. for iocage-ng is it primarily a change of language (i.e. what drove
> this) and are there any thoughts about compatibility with current
> iocage, especially around configuration and settings? It would be a
> shame to end up with 2 almost-compatible solutions in the long run, and
> I'd love to follow some of the discussion and development around this at
> a level more than just waiting for commits to land if that's practical.

Well I don't intend to have 2 almost-compatible solutions. I'm going to forge my own path. Not looking backwards is another key decision with the rewrite.

You can see some of the discussion here: https://github.com/iocage/iocage/commit/3f394561a3dde55cd3ac7911be313c5df5865183

Lots of decisions being made and many more reasons have emerged from the latest hackathon iXsystems just had. Go has been the final choice of language. So a single binary for iocage will remain. That is the latest news so far.

>
> [1] https://github.com/fractalcells/ansible-iocage
> [2] despite a zealous adherence to erlang in my private life
>

It's always something! Heh.



Thanks for your interest!

- Brandon

[Dave Cottlehuber]

On Fri, 15 Apr 2016, at 22:25, Brandon Schneider wrote:
> > 1. can we the community, fork the current version somewhere and continue
> > maintaining it within the ports tree under the same sysutils/iocage
> > name? This would allow those of us who are already using iocage to
> > continue doing so. I assume iocage-ng developers are ok with that?
> >
> > 2. this is a low-volume list, assuming (1) is agreed, could we continue
> > using/sharing the same list, or do we need to split off?
>
> No we are not ok with that. If you fork, it will be your own thing :)
> Which includes not being on the same mailing list, git repo or Twitter.
> You're totally able to fork as the license is there for that reason, but
> it's not reasonable to expect me to give up the keys I'm still using ;)

Thanks Brandon for the clarification. I don't want to get on anybody's
toes, hence asking. I understand your reasoning & that's fine with me.

As I'm not really familiar with the ports tree, what is the right thing
to do there? I'm guessing there's no intention on your part to do
anything major with the existing port, in its shell form. Do I need to
rename iocage all the way through the source & into the ports tree, or
is there some sensible middle ground here? e.g. crucible seems to be
available as a name.

> > 3. for iocage-ng is it primarily a change of language (i.e. what drove
> > this) and are there any thoughts about compatibility with current
> > iocage, especially around configuration and settings? It would be a
> > shame to end up with 2 almost-compatible solutions in the long run, and
> > I'd love to follow some of the discussion and development around this at
> > a level more than just waiting for commits to land if that's practical.
>
> Well I don't intend to have 2 almost-compatible solutions. I'm going to
> forge my own path. Not looking backwards is another key decision with the
> rewrite.

> You can see some of the discussion here:
> https://github.com/iocage/iocage/commit/3f394561a3dde55cd3ac7911be313c5df5865183

Thanks. I'm looking forwards to the point where I can contribute to the
new version, and eventually migrate over too.

A+
Dave

[punos...@gmail.com]

On Tuesday, April 12, 2016 at 3:09:35 AM UTC-4, Dave Cottlehuber wrote:

Hey all,

iocage has hit a sweet spot for jail management, including the jail
properties directly into the dataset. Even in it's current form is super
useful. With an ansible module [1] as well it's delightfully
automatable. A big thank-you to all who have contributed!

However the current repo reads: **No longer supported. iocage is being
rewritten in a different language. **

so, 3 questions:

+1