On Tue, Aug 23, 2011 at 07:59:56AM -0500, Jim Perrin wrote:
On Mon, Aug 22, 2011 at 10:14 PM, Peter J. Pouliot <[1]peter@pouliot.net> wrote:
That's older packaging work we did for RHEL5. �Newer packages are being tested for RHEL6. �Currently there are MSFT contractors maintaining that specific channel in the SUSE OBS. The RHEL 6 Packages were built one of my other SUSE collegues and have not yet been integrated into that channel by the MSFT folks.Okay, so similar kit, just updated/newer versions. Fair enough.�
�
We can have additional discussion around LIS packaging as I am currently in process to bring control of this into the community instead, with an end goal of providing automated nightly builds/packaging for most distros.Automated/nightly build should in my opinion be a separate channel/repository all by itself. I would much prefer to see a 'stable known reliable' package set and a separate nightly build set.
Just to be clear, this is a high level of discussion. Your points are extremely valid, yet specific details, we can work out what should be offered as resources to enhance the development/adoption efforts.
�
> > � �Can these drivers be loaded (or be made to load) via the driver disk > � �option to the installer? � This could be a viable option, however integration into install media which utilizes the plus repo might be cleaner user experience not requiring additional user interaction or install time parameters.I understand this desire, but it runs somewhat counter to the mandate that CentOS strives to follow, of being 100% binary compatible with upstream. Basically anything that changes the installer away from a default should be done with extreme consideration, and while what you are pitching is good, I don't see/hear enough drive from the user community to warrant a change from the standard. The hyper-v usage (identified via googling hyper-v on [2]lists.centos.org) seems relatively low, so if I'm mistaken, please correct me.
�
Currently HyperV market share is on the rise, simple due to the fact that it is a cheaper alternative to VMware.
Currently it is estimated that it will reach 30% of overall hypervisor market by the end of the year.
One large segment of virtualization usage is currently rhel/epl on vmware. I specifically know of extremely large deployments (thousands of epl vms) currently evaluating HyperV and considering a hypervisor switch due to cost.
> > � �What license are these drivers covered under? GPL v2. The drivers are currently in staging on the mainline kernel. � My goal, note I am not speaking for the company of I work for (SUSE), or the company who pays for the room I sit in (MSFT), is to help get the work our team has done for the last five years integrated into all linux distributions.So long as they are GPLv2, and your company/code copyright holder is willing to provide something showing there's no danger of lawsuit/DMCA infringement for distribution I see no issues with providing them.
I'll look into this.
�
As you know politics can have a nasty way of working into everything. � This is my attempt at approaching this without any of the corporate politics involved. �I reach out as an individual looking to better the experience of linux on hyperv regardless of distro.Eh, my theory is that political arguing is for people who don't have work to do. I tend to lose interest during those sorts of discussions, because it's usually the end user who gets hurt.�
I agree.
�
So here's what I have to offer to assist in the process. � I run a complete datacenter (100+ servers, san, blades, etc), which I have FULL control of, outside of either corporate network. �I am willing to both provide and host resources for the community to make this occur. �In addition, we have recently built an openstack infrastructure upon hyperv which we are using as the basis for large scale testing of the LIS, I would like to include centos as part of this. �Also, I would like to possibily tie into any of the community processes for testing/validation to provide coverage to enable centos to run as a viable guest on hyperv. I know there has been heavy politics between MS and RH around this, and I know that politically RH is not likely to ever include the LIS. � That's why I'm asking for addition to centos-plus and the install media.� If it successfully goes into the mainline kernel, and there's a market for it I don't see why they wouldn't include it. The only reason I could think for them to deny it would be that it conflicts/competes with their own virtualization suite with KVM and RHEV.
I am not comfortable with the idea of adding it to the install media directly, but I'm not the one who produces that so I'll let others weigh in. I could see supplying it as a driver disk image, via the centosplus repo, or possibly a separate installer image similar to the server iso we used to ship. I'd like to hear some opinions from others on this.
I'm open to this idea as well. If it's a way for centos users to running on hyperv to install enlightened natively, i'm all for it.
�
I do not want to cause political unrest or for this to be taken out of context. �Once again, my goal is to help provide a better experience for linux users running on HyperV regardless of distro. �If I can reach out to the great opensource community and provide resources to assist in making this happen, hopefully we'll bypass any corporate political agenda, and end up with a win for linux users running on HyperV that was complete driven by the community and not by MSFT.So far I don't see any political unrest, and it's nice to see someone putting some effort into this. Interoperability works both ways in my mind, so thanks for the work you're doing� (now can we get some good GPL'd� MAPI libraries so I can talk to exchange easier? :-P)
hahaha, help me do this and that will be next on the list....
;)
�
Thanks for the time.Thanks for yours.
-- During times of universal deceit, telling the truth becomes a revolutionary act. George Orwell
References
Visible links
- mailto:peter@pouliot.net
- http://lists.centos.org/
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel