FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Edubuntu Development

 
 
LinkBack Thread Tools
 
Old 02-03-2010, 05:29 PM
Chris Lumens
 
Default time for instdata to die

We've got the Anaconda object, we've got KickstartData, why do we need
InstallData as well? The extensive, somewhat tested patch set at:

http://clumens.fedorapeople.org/instdata/

completely removes InstallData. Some of the attributes have gone away
entirely, and some have moved to other places. A lot of stuff has ended
up as a property on the Anaconda object which is going to make a lot of
other stuff easier for me in the future.

This is a lot to test. My plan is to either make a gigantic updates.img
or a local test build and compose. Then I'll put it through some basic
testing (text, graphical, kickstart, vnc, encryption all come to mind as
important).

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 02-04-2010, 06:12 AM
Hans de Goede
 
Default time for instdata to die

Hi,

On 02/03/2010 07:29 PM, Chris Lumens wrote:

We've got the Anaconda object, we've got KickstartData, why do we need
InstallData as well? The extensive, somewhat tested patch set at:

http://clumens.fedorapeople.org/instdata/

completely removes InstallData. Some of the attributes have gone away
entirely, and some have moved to other places. A lot of stuff has ended
up as a property on the Anaconda object which is going to make a lot of
other stuff easier for me in the future.

This is a lot to test. My plan is to either make a gigantic updates.img
or a local test build and compose. Then I'll put it through some basic
testing (text, graphical, kickstart, vnc, encryption all come to mind as
important).



I very much like the idea of killing instdata, I'm not so sure if I like
the solution of just moving bits over to the anaconda class though. For
some things this might make sense, but not so much for others.

The problem with instdata which moving its content over to anaconda does
not fix, is that we need access to it almost everywhere. So we keep on
passing references around. Much the same happens to for example
storage, be it either in the form of passing around instdata or anaconda
because we need it, or by passing it around itself.

All 3 (and others like bootloader) have 2 things in common:
1) There is only ever one of them.
2) There __init__ methods have no arguments
(other the references to the other 2)

I think it would be much better to untangle this whole mess by making
anaconda,, booty and storage singletons and there are likely other
candidates too.

Regards,

Hans

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 02-04-2010, 01:44 PM
Chris Lumens
 
Default time for instdata to die

> The problem with instdata which moving its content over to anaconda does
> not fix, is that we need access to it almost everywhere. So we keep on
> passing references around. Much the same happens to for example
> storage, be it either in the form of passing around instdata or anaconda
> because we need it, or by passing it around itself.
>
> All 3 (and others like bootloader) have 2 things in common:
> 1) There is only ever one of them.
> 2) There __init__ methods have no arguments
> (other the references to the other 2)
>
> I think it would be much better to untangle this whole mess by making
> anaconda,, booty and storage singletons and there are likely other
> candidates too.

This can certainly be addressed in a followup patch, but for the moment
I'm primarily concerned with getting rid of instdata. This whole area
is kind of a mess right now (consider that ksdata duplicates a lot of
stuff too, also look at how instdata and install classes are tangled up)
that's going to require further patch series to completely straighten
out.

One thing that I want to be sure of if we go the singleton route is that
we preserve the ability to import major sections of anaconda as python
modules outside running anaconda. This patch series makes it possible
to import storage from an external program, provided you first create an
Anaconda object. That's one big reason for making a bunch of things
properties, as well as some of the import cleanups I added.

If we do want to make things singletons, we need to make sure:

(1) Their __init__ methods don't create objects that may not be possible
to have in a normal python script. This could mean making more things
properties.

(2) We are very careful about where we import files that declare the
singletons.

(3) Removing references to the singletons from method arguments doesn't
make things more complicated.

Hopefully my intentions will be much more clear when I send my patch set
that moves anaconda into /usr/lib/python*.

So I'm not saying no. I'm saying let's be careful when doing it and
let's wait until after we've removed this big part from the picture.
Maybe more cleanups will start to be more obvious then.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 02-04-2010, 05:08 PM
Hans de Goede
 
Default time for instdata to die

Hi,

On 02/04/2010 03:44 PM, Chris Lumens wrote:

The problem with instdata which moving its content over to anaconda does
not fix, is that we need access to it almost everywhere. So we keep on
passing references around. Much the same happens to for example
storage, be it either in the form of passing around instdata or anaconda
because we need it, or by passing it around itself.

All 3 (and others like bootloader) have 2 things in common:
1) There is only ever one of them.
2) There __init__ methods have no arguments
(other the references to the other 2)

I think it would be much better to untangle this whole mess by making
anaconda,, booty and storage singletons and there are likely other
candidates too.


This can certainly be addressed in a followup patch, but for the moment
I'm primarily concerned with getting rid of instdata.


<snip lots of good stuff>

Ok, getting rid of instdata before making somethings singletons is fine
by me.

Regards,

Hans

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 02-04-2010, 08:02 PM
 
Default time for instdata to die

> This is a lot to test. My plan is to either make a gigantic updates.img
> or a local test build and compose. Then I'll put it through some basic
> testing (text, graphical, kickstart, vnc, encryption all come to mind as
> important).

I had to make two very small modifications to my patch set. After that,
all tests either succeed or fail in non-instdata ways that we already
know about. This is encouraging.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 02-05-2010, 11:42 PM
David Cantrell
 
Default time for instdata to die

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 4 Feb 2010, clumens@redhat.com wrote:


This is a lot to test. My plan is to either make a gigantic updates.img
or a local test build and compose. Then I'll put it through some basic
testing (text, graphical, kickstart, vnc, encryption all come to mind as
important).


I had to make two very small modifications to my patch set. After that,
all tests either succeed or fail in non-instdata ways that we already
know about. This is encouraging.


Ack on the whole set. Nothing jumped out at me and pychecker didn't seem to
mind the changes.

- --
David Cantrell <dcantrell@redhat.com>

Red Hat / Honolulu, HI

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAktsuwQACgkQ5hsjjIy1VkkKnwCg14UFdLZKpk 0Ba9pPiNesIOmI
AscAnRngC1Dyyf6eBfXWQUfMooCxWXLz
=ZG+t
-----END PGP SIGNATURE-----

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 11:41 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org