----- Original Message -----
On Mon, Nov 21, 2011 at 12:58:29PM +0200, Doron Fediuck wrote:
Hi Guys, Well, it looks like we've hit our first distro-diversion.
First of all, let's define the issues, and then see how we solve each one;
- Dimitrije is referring to vdsm's init script (including
vdsm-reg).
- What Jared is referring to is relevant to:
- Host installation process (AKA bootstrapping and registration)
- vdsm operations on host networking
I agree it will be better if we solve each issue using the same code for all distro's. Having said that, we need to see if it's an achievable task.
Taking Dimitrije's issue as an example, we hit the first conflict; Gentoo is using OpenRC by default (and has some BSD-style leftovers), while RedHat and Fedora are using their SysV-style implementation, which confirms to LSB. Also, some Fedora services are moving to systemd implementation. Obviously these implementations are not trivial to bridge. So where Fedora's script will have "Required-Start:" Gentoo will use a depend() function (see vixie-cron as a sample). So unless we find a magical bridge for init standards, we'll have to have several init scripts, and each distro will use it's own script. We can try and generalize it, to make sure distor's with similar implementations use the same script.
As for Jared's networking issues, I believe there's more room here to make the relevant code more flexible, by testing the needed files, and using what we find. Thus, we'll have all in the same codebase. You can start by taking a look at vdsm/netinfo.py in vdsm's git.
And, as mentioned by Daniel Berrange, Vdsm should probably be changed to be using netcf to configure host networking. I'm not sure if Gentoo has netcf back-end, though.
Actually we're thinking about NetworkManager, not netcf.
I'm sure that there are plenty of other Fedoraisms lurking in Vdsm. We would have to take them down one by one.
Dan. _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Mon, 2011-11-21 at 07:42 -0500, Ayal Baron wrote:
----- Original Message -----
On Mon, Nov 21, 2011 at 12:58:29PM +0200, Doron Fediuck wrote:
Hi Guys, Well, it looks like we've hit our first distro-diversion.
First of all, let's define the issues, and then see how we solve each one;
- Dimitrije is referring to vdsm's init script (including
vdsm-reg).
- What Jared is referring to is relevant to:
- Host installation process (AKA bootstrapping and registration)
- vdsm operations on host networking
I agree it will be better if we solve each issue using the same code for all distro's. Having said that, we need to see if it's an achievable task.
Taking Dimitrije's issue as an example, we hit the first conflict; Gentoo is using OpenRC by default (and has some BSD-style leftovers), while RedHat and Fedora are using their SysV-style implementation, which confirms to LSB. Also, some Fedora services are moving to systemd implementation. Obviously these implementations are not trivial to bridge. So where Fedora's script will have "Required-Start:" Gentoo will use a depend() function (see vixie-cron as a sample). So unless we find a magical bridge for init standards, we'll have to have several init scripts, and each distro will use it's own script. We can try and generalize it, to make sure distor's with similar implementations use the same script.
As for Jared's networking issues, I believe there's more room here to make the relevant code more flexible, by testing the needed files, and using what we find. Thus, we'll have all in the same codebase. You can start by taking a look at vdsm/netinfo.py in vdsm's git.
And, as mentioned by Daniel Berrange, Vdsm should probably be changed to be using netcf to configure host networking. I'm not sure if Gentoo has netcf back-end, though.
Actually we're thinking about NetworkManager, not netcf.
Does NetworkManager have an api or library level package that doesn't pull in all the UI bits? ovirt-node does not currently include NetworkManager packages at all and we don't want to pull anything that is going to pull in X or another UI.
Mike
I'm sure that there are plenty of other Fedoraisms lurking in Vdsm. We would have to take them down one by one.
Dan. _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Monday 21 November 2011 14:49:43 Mike Burns wrote:
On Mon, 2011-11-21 at 07:42 -0500, Ayal Baron wrote:
----- Original Message -----
On Mon, Nov 21, 2011 at 12:58:29PM +0200, Doron Fediuck wrote:
Hi Guys, Well, it looks like we've hit our first distro-diversion.
First of all, let's define the issues, and then see how we solve each one;
- Dimitrije is referring to vdsm's init script (including
vdsm-reg).
- What Jared is referring to is relevant to:
- Host installation process (AKA bootstrapping and registration)
- vdsm operations on host networking
I agree it will be better if we solve each issue using the same code for all distro's. Having said that, we need to see if it's an achievable task.
Taking Dimitrije's issue as an example, we hit the first conflict; Gentoo is using OpenRC by default (and has some BSD-style leftovers), while RedHat and Fedora are using their SysV-style implementation, which confirms to LSB. Also, some Fedora services are moving to systemd implementation. Obviously these implementations are not trivial to bridge. So where Fedora's script will have "Required-Start:" Gentoo will use a depend() function (see vixie-cron as a sample). So unless we find a magical bridge for init standards, we'll have to have several init scripts, and each distro will use it's own script. We can try and generalize it, to make sure distor's with similar implementations use the same script.
As for Jared's networking issues, I believe there's more room here to make the relevant code more flexible, by testing the needed files, and using what we find. Thus, we'll have all in the same codebase. You can start by taking a look at vdsm/netinfo.py in vdsm's git.
And, as mentioned by Daniel Berrange, Vdsm should probably be changed to be using netcf to configure host networking. I'm not sure if Gentoo has netcf back-end, though.
Actually we're thinking about NetworkManager, not netcf.
Does NetworkManager have an api or library level package that doesn't pull in all the UI bits? ovirt-node does not currently include NetworkManager packages at all and we don't want to pull anything that is going to pull in X or another UI.
Mike
+1 NetworkManager pulls in gnome, while it's net being used in many cases, especially in servers. As for netcf in Gentoo, there's not substantial support which will make it easy to work with.
I'm sure that there are plenty of other Fedoraisms lurking in Vdsm. We would have to take them down one by one.
Dan.
On Monday 21 November 2011 16:00:26 Doron Fediuck wrote:
On Monday 21 November 2011 14:49:43 Mike Burns wrote:
On Mon, 2011-11-21 at 07:42 -0500, Ayal Baron wrote:
----- Original Message -----
On Mon, Nov 21, 2011 at 12:58:29PM +0200, Doron Fediuck wrote:
Hi Guys, Well, it looks like we've hit our first distro-diversion.
First of all, let's define the issues, and then see how we solve each one;
- Dimitrije is referring to vdsm's init script (including
vdsm-reg).
- What Jared is referring to is relevant to:
- Host installation process (AKA bootstrapping and registration)
- vdsm operations on host networking
I agree it will be better if we solve each issue using the same code for all distro's. Having said that, we need to see if it's an achievable task.
Taking Dimitrije's issue as an example, we hit the first conflict; Gentoo is using OpenRC by default (and has some BSD-style leftovers), while RedHat and Fedora are using their SysV-style implementation, which confirms to LSB. Also, some Fedora services are moving to systemd implementation. Obviously these implementations are not trivial to bridge. So where Fedora's script will have "Required-Start:" Gentoo will use a depend() function (see vixie-cron as a sample). So unless we find a magical bridge for init standards, we'll have to have several init scripts, and each distro will use it's own script. We can try and generalize it, to make sure distor's with similar implementations use the same script.
As for Jared's networking issues, I believe there's more room here to make the relevant code more flexible, by testing the needed files, and using what we find. Thus, we'll have all in the same codebase. You can start by taking a look at vdsm/netinfo.py in vdsm's git.
And, as mentioned by Daniel Berrange, Vdsm should probably be changed to be using netcf to configure host networking. I'm not sure if Gentoo has netcf back-end, though.
Actually we're thinking about NetworkManager, not netcf.
Does NetworkManager have an api or library level package that doesn't pull in all the UI bits? ovirt-node does not currently include NetworkManager packages at all and we don't want to pull anything that is going to pull in X or another UI.
Mike
+1 NetworkManager pulls in gnome, while it's net being used in many cases, especially in servers. As for netcf in Gentoo, there's not substantial support which will make it easy to work with.
Clarifying my cryptic typos- netcf has no proper support in Gentoo. It will be helpful if vdsm takes a more generic approach.
On 11/21/2011 01:49 PM, Mike Burns wrote:
On Mon, 2011-11-21 at 07:42 -0500, Ayal Baron wrote:
Actually we're thinking about NetworkManager, not netcf.
Does NetworkManager have an api or library level package that doesn't pull in all the UI bits? ovirt-node does not currently include NetworkManager packages at all and we don't want to pull anything that is going to pull in X or another UI.
NetworkManager, at least in F16, is properly sub-packaged, GUI parts are separated into -gtk and -gnome subpackages.
Alan
Actually we're thinking about NetworkManager, not netcf.
Also note that NetworkManager doesn't currently support bridge creation which I thought was something we needed to do (and I assumed was why we were manually interacting with the 'old' network configuration method in the first place).
-Steve
On 11/21/2011 10:18 AM, Steve Gordon wrote:
Actually we're thinking about NetworkManager, not netcf.
Also note that NetworkManager doesn't currently support bridge creation which I thought was something we needed to do (and I assumed was why we were manually interacting with the 'old' network configuration method in the first place).
That is true, but my understanding is that the NM folks are working to close those gaps.
I've cc'd dcbw onto this thread to see if he has any comments
Dan, the thread starter is: http://lists.ovirt.org/pipermail/users/2011-November/000066.html In case you want the history here.
But in short, what we're discussing is whether or not to use NM or netcf directly for network manipulation, and my take is that NM is the way to go, but there are some gaps that need to be closed before we can get there like:
* bridge creation * better subpackaging for NM packages so that things like mobile provider data and wpa_supplicant aren't pulled in by default (mburns is filing a bug on this shortly)
What's the current status wrt NM on other distros? How prevalent is it and can we just standardize on it for things like Ubuntu, SLES, Debian, Gentoo, etc?
Perry
----- Original Message -----
From: "Doron Fediuck" dfediuck@redhat.com To: users@ovirt.org Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Monday, November 21, 2011 3:13:20 PM Subject: Re: [Users] ovirt-node on Gentoo
On Monday 21 November 2011 16:00:26 Doron Fediuck wrote:
On Monday 21 November 2011 14:49:43 Mike Burns wrote:
On Mon, 2011-11-21 at 07:42 -0500, Ayal Baron wrote:
Actually we're thinking about NetworkManager, not netcf.
Does NetworkManager have an api or library level package that doesn't pull in all the UI bits? ovirt-node does not currently include NetworkManager packages at all and we don't want to pull anything that is going to pull in X or another UI.
Mike
+1 NetworkManager pulls in gnome, while it's net being used in many cases, especially in servers. As for netcf in Gentoo, there's not substantial support which will make it easy to work with.
Clarifying my cryptic typos- netcf has no proper support in Gentoo. It will be helpful if vdsm takes a more generic approach.
Configuring the network is a difficult task. Taking a more generic approach means facing again the problems that NetworkManager found and resolved in the past.
Do you know any other (mature) project that is trying to fill in the gaps between the network configurations in the various distro? I'm worried that taking a generic approach we'll end up creating a small NetworkManager clone with a smaller scope (usable only for the vdsm tasks).
We could use our effort to improve NetworkManager where it's lacking of functionality/packaging. For example I've been waiting for the bridge support for a long time, I hope to see it soon.
On Monday 21 November 2011 19:12:36 Federico Simoncelli wrote:
----- Original Message -----
From: "Doron Fediuck" dfediuck@redhat.com To: users@ovirt.org Cc: "VDSM Project Development" vdsm-devel@lists.fedorahosted.org Sent: Monday, November 21, 2011 3:13:20 PM Subject: Re: [Users] ovirt-node on Gentoo
On Monday 21 November 2011 16:00:26 Doron Fediuck wrote:
On Monday 21 November 2011 14:49:43 Mike Burns wrote:
On Mon, 2011-11-21 at 07:42 -0500, Ayal Baron wrote:
Actually we're thinking about NetworkManager, not netcf.
Does NetworkManager have an api or library level package that doesn't pull in all the UI bits? ovirt-node does not currently include NetworkManager packages at all and we don't want to pull anything that is going to pull in X or another UI.
Mike
+1 NetworkManager pulls in gnome, while it's net being used in many cases, especially in servers. As for netcf in Gentoo, there's not substantial support which will make it easy to work with.
Clarifying my cryptic typos- netcf has no proper support in Gentoo. It will be helpful if vdsm takes a more generic approach.
Configuring the network is a difficult task. Taking a more generic approach means facing again the problems that NetworkManager found and resolved in the past.
Do you know any other (mature) project that is trying to fill in the gaps between the network configurations in the various distro? I'm worried that taking a generic approach we'll end up creating a small NetworkManager clone with a smaller scope (usable only for the vdsm tasks).
We could use our effort to improve NetworkManager where it's lacking of functionality/packaging. For example I've been waiting for the bridge support for a long time, I hope to see it soon.
Federico, Since I personally know the one who wrote most of the vdsm-ovirt/rhel integration bugs (not the code, just the bugs...) I'm fully aware of network complexity, and the impact of supporting several distro's.
This is exactly why I asked for a /generic/ approach, which will not pull in numerous packages which are distro or desktop-env specific.
Having said that, I can tell you that last night I did some more investigations in Gentoo, and I was pleasantly surprised to see the following:
emerge -DuNavt --with-bdeps=y --keep-going net-misc/networkmanager
These are the packages that would be merged, in reverse order:
Calculating dependencies... done! [ebuild N ] net-misc/networkmanager-0.8.4.0-r2 USE="bluetooth ppp -avahi -connection-sharing -dhclient -dhcpcd -doc -gnutls -nss -resolvconf" 1,634 kB [ebuild N ] net-misc/modemmanager-0.4 USE="policykit -doc -test" 435 kB
Total: 2 packages (2 new), Size of downloads: 2,069 kB
This means that network manager no longer pulls gnome-related packages, which is very good news. If this is the case in other distro's I think we can converge on this solution.
I guess we only need some input from Suse / Ubuntu people to see if it works for them as well.
This means that network manager no longer pulls gnome-related packages, which is very good news. If this is the case in other distro's I think we can converge on this solution.
mburns did a test on this yesterday and confirmed that on Fedora it also does not pull in Gnome/X, so it looks like on both Fedora/Gentoo we're good with NM.
Still hoping for dwilliams to chime in on my questions from yesterday on this thread :)
On Tuesday 22 November 2011 14:56:50 Perry Myers wrote:
This means that network manager no longer pulls gnome-related packages, which is very good news. If this is the case in other distro's I think we can converge on this solution.
mburns did a test on this yesterday and confirmed that on Fedora it also does not pull in Gnome/X, so it looks like on both Fedora/Gentoo we're good with NM.
Still hoping for dwilliams to chime in on my questions from yesterday on this thread :)
+1 (on both paragraphs...)
vdsm-devel@lists.stg.fedorahosted.org