Repo layout. We really need to make the call by Tuesday 2012/7/24.
by Robert Middleswarth
The current repo layout will have to change some to support the 3.1
release that might be happening on the 25th. We are going to have to
move stuff around to archive the 3.0 release as well as setup the 3.1
release in my option we can do it one of two ways. 1) Create an archive
folder and just copy 3.0 to it well we do the 3.1 release and keep the
same structure we have now. 2) Redo the layout to something that will
long term support version and be less confusing to people using the project.
Personally I think this is a good time to redesign. The existing 3.0
repo files are going to break when we move things around for the 3.1
release and we are going to need to make sure everything is in place.
Since we are going to have to disrupt thing already why not do a full
clean-up instead of just patch the current layout. Our current layout.
release/[stable|beta|nightly]/[binary|fedora|RHEL|src]/[16|17|18]
I recommend we switching to the following structure.
release/[3.0|3.1|3.2|stable|testing]/[nightly|beta|released]/[tools|fedora|RHEL|src]/[16|17|18|rawhide]
With symlinks for stable and testing point to the current version for
each. I also suggest a symlink called release/fedora-ovirt-latest.rpm
that points to the latest ovirt-release-*.rpm file.
Inside each version there will be a repo file that enables released
disables beta & nightly.
Since each repo file will simple reference everything by version number
each new release wont break old releases.
What does everyone think?
Thanks
Robert
11 years, 9 months
Minutes :: Infra team meeting 2012-07-17
by Karsten (quaid) Wade
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Minutes:
http://ovirt.org/meetings/ovirt/2012/ovirt.2012-07-17-14.00.html
Minutes (text):
http://ovirt.org/meetings/ovirt/2012/ovirt.2012-07-17-14.00.txt
Log:
http://ovirt.org/meetings/ovirt/2012/ovirt.2012-07-17-14.00.log.html
==============
#ovirt Meeting
==============
Meeting started by quaid at 14:00:06 UTC. The full logs are available at
http://ovirt.org/meetings/ovirt/2012/ovirt.2012-07-17-14.00.log.html .
Meeting summary
- ---------------
* oVirt Infra weekly meeting (quaid, 14:00:15)
* Roll call & howdy (quaid, 14:00:33)
* Agenda (quaid, 14:03:13)
* LINK:
http://wiki.ovirt.org/wiki/Infrastructure_team_meetings#2012-07-17
(quaid, 14:03:19)
* Welcome new maintainers (quaid, 14:06:29)
* How to handle donated hardware/VM hosts (quaid, 14:13:41)
* ACTION: eedri to test running jenkins job in parallel on different
nodes (eedri1, 14:26:51)
* AGREED: Start new Jenkins VMs with basic config and see where the
bottlenecks are (quaid, 14:36:57)
* ACTION: Getting Puppet running is a top priority (quaid, 14:39:17)
* ACTION: Research for service provider for a baremetal host for
automation tests and possible Jenkins VM slaves if room (quaid,
14:40:43)
* ACTION: quaid to get puppet.ovirt.org DNS (quaid, 14:43:26)
* ACTION: Ask on Board and arch@ mailing lists for a baremetal host
for automation tests (quaid, 14:47:40)
* ACTION: eedri1 bring discussion to infra@ about how to do
distributed Jenkins (quaid, 14:57:45)
* ACTION: quaid to get eedri1 sudo on linode01.ovirt.org (quaid,
15:06:17)
* ACTION: eedri to set up nighly jenkins job to collect lastest stable
rpms from all ovirt projects and copy to
ovirt.org/$JENKINS_HOME/rpms/$project (eedri1, 15:16:17)
* ACTION: discuss on infra@ about security concerns when allowing
gerrit patch jobs on jenkins (quaid, 15:23:28)
* ACTION: finalize rpms directory structure on ovirt.org, to match
Jenkiins/script needs/expectations (quaid, 15:24:14)
* ACTION: discuss on infra@ how to distribute builds - baremetal, VMS,
etc. (quaid, 15:28:20)
* ACTION: may still need a dedicated baremetal host somewhere; quaid
is asking around about budget, others can help define what we need &
research hosting providers (quaid, 15:29:21)
Meeting ended at 15:30:40 UTC.
Action Items
- ------------
* eedri to test running jenkins job in parallel on different nodes
* Getting Puppet running is a top priority
* Research for service provider for a baremetal host for automation
tests and possible Jenkins VM slaves if room
* quaid to get puppet.ovirt.org DNS
* Ask on Board and arch@ mailing lists for a baremetal host for
automation tests
* eedri1 bring discussion to infra@ about how to do distributed Jenkins
* quaid to get eedri1 sudo on linode01.ovirt.org
* eedri to set up nighly jenkins job to collect lastest stable rpms from
all ovirt projects and copy to ovirt.org/$JENKINS_HOME/rpms/$project
* discuss on infra@ about security concerns when allowing gerrit patch
jobs on jenkins
* finalize rpms directory structure on ovirt.org, to match
Jenkiins/script needs/expectations
* discuss on infra@ how to distribute builds - baremetal, VMS, etc.
* may still need a dedicated baremetal host somewhere; quaid is asking
around about budget, others can help define what we need & research
hosting providers
Action Items, by person
- -----------------------
* eedri1
* eedri1 bring discussion to infra@ about how to do distributed
Jenkins
* quaid to get eedri1 sudo on linode01.ovirt.org
* quaid
* quaid to get puppet.ovirt.org DNS
* quaid to get eedri1 sudo on linode01.ovirt.org
* may still need a dedicated baremetal host somewhere; quaid is asking
around about budget, others can help define what we need & research
hosting providers
* **UNASSIGNED**
* eedri to test running jenkins job in parallel on different nodes
* Getting Puppet running is a top priority
* Research for service provider for a baremetal host for automation
tests and possible Jenkins VM slaves if room
* Ask on Board and arch@ mailing lists for a baremetal host for
automation tests
* eedri to set up nighly jenkins job to collect lastest stable rpms
from all ovirt projects and copy to
ovirt.org/$JENKINS_HOME/rpms/$project
* discuss on infra@ about security concerns when allowing gerrit patch
jobs on jenkins
* finalize rpms directory structure on ovirt.org, to match
Jenkiins/script needs/expectations
* discuss on infra@ how to distribute builds - baremetal, VMS, etc.
People Present (lines said)
- ---------------------------
* eedri1 (124)
* quaid (104)
* mburns (54)
* RobertM (49)
* adamw (8)
* ovirtbot (7)
* mgoldboi (7)
* gestahlt (4)
* tjikkun_work (4)
* ewoud (2)
* ofrenkel (2)
* hitvx (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
- --
Karsten 'quaid' Wade ..... http://iquaid.org ..... gpg key: AD0E0C41
http://Fairy-TaleFarm.com .......................... Urban homestead
http://MicahForCouncil.org ................ Your advocate on council
http://SantaCruzPedicab.com .......... Sensible local transportation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFQBYXI2ZIOBq0ODEERAop7AJ9eDZ2JUxyZHuveVnxyT/E+wUr2+wCgy2PL
Z387maqgT18Fgi8EO5KQtpw=
=CLPl
-----END PGP SIGNATURE-----
11 years, 9 months
Help the team, starting as an apprentice.
by jdbjunior＠gmail.com
Hello everyone, I'm José Donizetti a brazilian software developer. And
got really interested on the oVirt project.
Would like to learn more, and help the team. What do I do to be start
as an apprentice?
Thanks.
11 years, 9 months
no [infra] prefix on infra mailing list emails
by Itamar Heim
most mailing lists i use prefix subject of emails with [mailing-list-name].
infra mailing list is missing this prefix.
my +1 to add it to infra mailing list, and asking others for their comments.
thanks,
Itamar
11 years, 9 months
Maintainers list
by Karsten 'quaid' Wade
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm asking the following people if you are interested in being a
maintainer of the Infrastructure project.
You are under no obligation to accept this request. I'm inviting you
because you've shown continuous interest, helpfulness, and capability.
But I know we are all busy, and sometimes the mark of a good leader is
to know when to say no to a leadership opportunity. Just let me know
if you'd like to be an Infra maintainer or not:
* Mike Burns
* Eyal Edri
* Itamar Heim
* Ewoud Kohl van Wijngaarden
* Robert Middleswarth
* Ofer Schreiber
* Karsten Wade
In addition, I'd like to invite Moran Goldboim to be the first person
to join us as a candidate for becoming a maintainer. Moran has been
doing infra work behind the scenes, so is only known to a few of us,
and he has recently expressed interest in being an Infra maintainer.
We haven't defined how to become a maintainer ... yet ... but when we
do, Moran can be the first person to go through the process, if he's
interested. :)
Thanks - Karsten
- --
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFQBF0U2ZIOBq0ODEERAtc8AJ92WVcuHPwLfzKdr3rm2BmhSFuO7QCdEbsD
9OxdnzGN5qS8cptPFPBR/Jk=
=/I2H
-----END PGP SIGNATURE-----
11 years, 9 months
Meeting minutes
by Dan Kenigsberg
Today we did have a meeting, and discussed the following points:
- We need a volunteer to extend vdsm's on-commit hook, so it runs functional
tests to. This requires installing vdsm.rpm as well as vdsm-tests.rpm,
starting vdsmd service, running the tests, and cleaning the host.
Robert M. suggested that we ask infra@ for help in writing and maintaining
this test, so here I am, CCing infra(a)ovirt.org.
- Saggi is planning a C API library, exposing gobjects, with a rest bridge (or
whatever) for client applications. I'm slightly appauled - I prefered the
simpler idea of API.py and REST binding, with which C/whatever clients can
interact.
- Adam documented the current xmlrpc api, with all its pecularities and
horrors. Prefers to keep it as a single document; I think it would be
easier to maintain if definition that are specific to an API call sit
on top the function definition. It would be harder to forget to update
one of them when you change the other. Admitedly, it requires some sed
preprocessing in order to extract a single human-readable document out
of this scattered info. Saggi votes for Adam.
- deepakcs: i just posted VDSM hook example for exploiting native
qemu-glusterfs options from VDSM. Wanted to know feedback onthe same and
alternative approach
- Saggi asks to ping qemu folks about the feature of specifying the full
qcow chain BZ#750801. We need it to reduce repository complexity
(currently we play with symlinks).
- Federico: storage domain v 3 , requires bleeding-edge upstream engine and
sanlock. http://wiki.ovirt.org/wiki/Storage_Domain_Versions
- probably more stuff that I've forgotten... please reply with more info
See ya all!
Dan.
11 years, 9 months
Repo structure and the upcoming 3.1 release.
by Robert Middleswarth
With 3.1 pending release we should think some about the structure of the
repo's and how we are going to handle the 3.1 release.and the retirement
of the 3.0 builds.
I think it would be bad to keep the 3.0 builds in the F16 folder. But I
also don't think we should remove the folder either.
This is the time to ask questions.
1) Do we want to make any changes to the layout?
2) How do we want to handle older versions?
3) Do want to keep the beta's around after the stable is moved to 3.1?
For now I suggest we do the following.
1) After 3.1 is released we move the stable 3.0 F16 builds in to
archive/3.0/f16 off the release folder.
2) Reserve Nightly for Jenkins builds of 3.2
3) clean out the 3.1 beta's Until we are ready to start testing 3.2
Does anyone else disagree with my idea's?
Does anyone else have what the feel is a better plan?
Thanks
Robert
11 years, 9 months
Jenkins and RHEL 6.2
by Robert Middleswarth
I see there are 2 RHEL 6.2 slaves added to Jenkins and I see they are
doing something with the engine? What are they actually doing since I
don't see any artifacts left over? How hard would it be to tweak the
existing ones to create .rpms?
Thanks
Robert
11 years, 9 months
