[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [PATCH rhel6-branch] network: using more than one NICs (iSCSI) (#638131, #634016)

On 01/05/2011 04:47 PM, Chris Lumens wrote:
I don't think we intentionally meant to change the behavior from RHEL 5
to RHEL6.  At least, I don't remember us discussing that.  However, much
of this networking stuff is very subtle so it's entirely possible it got
changed without us ever knowing.

I think so.

This concept of the first network command in particular being somehow
magic is especially frustrating.  Do we document that behavior anywhere,
or is this just how things have always worked?

The latter I think, I guess people just didn't use installations
with more than one one devices activated in anaconda.

With that said, I think reverting back to RHEL 5 behavior is the right
thing to do.

Yes, I've opened new bug for it.

I noticed that the patchset is changing behaviour from 5.6 and 6.0
in the case
when network is not brought up before parsing ks. In 5.6 and 6.0
we would bring network up using first network command, whereas with
this patchset, it would be so only if --activate is present in the first
command. I will fix this so that if network is not up, --activate flag
(lack of it) is ignored and the device is activated.

This is fixed in new patchset just sent to a-d-l.

I really like the clarity of the --activate option, personally.  I'd be
all for us defining the future of the network command as so:

* Any network commands given without --activate will refer just to
   post-installation configuration.

* Any network commands given with --activate will refer both to
   install-time configuration as well as post-installation.

I think that should be flexible enough to cover all cases.
Unfortunately, getting us in position to do the above in RHEL is
difficult given that we have to have a transition period.  We can't just
switch it over, especially not for 6.1.

I agree. Perhaps we can dare to do it in Fedora?
The thing is that the change can have broad impact
I guess network command in ks can be used very often
and it'd affect significant amount of instances of its use:
- ks not fetched over network
- ks with different network configuration fetched over

Also, I can't stress enough how we need to thoroughly document this.


I sent new version of the patchset to a-d-l. Expected
behaviour is described here:


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]