[xen-tools-dev] Filesystems and your project goals

Dmitry Nedospasov dmitry at nedos.net
Sun Jul 25 12:58:39 CEST 2010


Hey Stephane,

On Sat, Jul 24, 2010 at 09:53:32AM +0200, Stéphane Jourdois wrote:
 2) Moving make_fs_* options to conf is not as trivial as it could
> 3) I can't find a generic enough tool to create any filesystem. Do
> you think using parted would be a good idea (one more dependency...)
> ?

I'm not sure that it's that problematic now. Do you think so?

> 4) I'm not sure this is necessary/wanted for a 4.2 release.
> xen-tools is primarily for production use (please correct me if
> needed), where you don't use fancy filesystems anyway. btrfs should
> be added though.

Yes, i would say btrfs is the only thing missing in regard to file system
creation.

> Now some timeline questions :
> 
> 1) Is your goal to release 4.2 any time soon ?

Personally i thnk we need to tag our current tree with a Pre-RC. I'm really
satisfied with it so far. Especially when we commit the last fixes i.e.
the ones to sudo. (Will be testing that today, got distracted yesterday
;)

> 2) Should we stick to first TODO items ?

I think we should also go through the current TODOs in a seperate
thread. However, the 4.2 ones are almost done!

All that's left is:
1. xen-create-image man page overhaul:
2. Test and support more file system types.
3. Setup locales in the hooks?

@Stephane: didn't you fix 3. in your tree? It really would be enough of
just forcing the setting of a default locale in the locales script.
Though this isn't as trivial as it differs from distro to distro

> 3) Would you mind moving this filesystem item in 4.3 release goals ?

Like i said, BTRFs would be a nice thing to have in 4.2.

My dream, as someone who spent a lot of time getting the ubuntu distros
up-to-date, is that we move to "-common" hooks. We should talk about
this in a seperate thread. I think it's best we consider several ways of
how this should be done. In any case, /I think/ this is the most
important thing that *must* be done in the next big release.

Considering this is a big shift and quite the rewrite of atleast the
hooks, we should also consider calling it 5.0.

One other big chunk of patches that we want to merge to our tree are
Nathans's yum-based patches that he has been quietly hacking on in his
xen-tools tree [1].

> 4) I really think that Steve's aborted move to Xen::Tools was a
> necessary step in the project as it would provide a lot benefits :
>  - _really_ improve testing (as in 'make test'), as we can then test
> each perl function provided by the modules, and test
> functionalities, not only code styling issues,
>  - Permit a lot of code refactoring,
>  - Permit use of xen-tools in other frontends (as in a cute web page),
>  - Simplify code modification (4333 lines for xen-create-image...),
>  - Only implies non-visible changes, so no changes in the frontend,
> no compat issues,
>  - Last but not least, that is the current /perl way of doing
> things/, and adding those modules to perl CPAN would provide a great
> visibility for your project.

I like this idea :) though i'm not the biggest Perl guy in the world :)

Could you elaborate on how this would look though? Do you mean that we
should commit a Tools module to CPAN? Is there a Xen module? I wouldn't
mind helping, though you might have to suggest me some reading.

> Now, I am willing to implement this step, but only of course if you
> want me to do it. I estimate the work needed for about a couple of
> weeks. I imagine you'd want to release 4.2 before and then do this
> move for a 5.0+ release.

This might be worth doing along with the move to the common code. I
think both of these steps will greatly improve readability.

Actually since you are probably the better Perl-programmer of atleast
the people currently working on the project, maybe you should try to
attack this task.

I will gladly work on migrating to "-common" hooks.

> /me going to do some research about locales configuration in each
> supported distribution, now :-)

:P yeah actually, you make a good point when you say that widening our
userbase would be helpful, because i think there are a lot of silent
bugs like the locales one. I mean we aren't doing a true base-install
afterall and as such don't benefit from the completeness of those
installer scripts in the distros.

Thanks for the thoughts and discussion!

Greets,

D.

[1] http://gitorious.org/~nats/xen-tools/nats-xen-tools
-- 
Dmitry Nedospasov <dmitry at nedos.net> -- Twitter: @nedos


More information about the xen-tools-dev mailing list