Proposal: Make announce list reply-to users
Noticed a bunch of emails come through to annou...@ovirt.org in reply to other messages. I'm wondering if we should direct replies directly to users@ instead of back to announce@. This would leave announce@ a much lower traffic list with only real announcements. Mike ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: [ATN] vdsm yum install is missing pkg for centos & f18
On 09/30/2013 11:53 AM, Dan Kenigsberg wrote:
On Mon, Sep 30, 2013 at 04:11:56AM -0400, Eyal Edri wrote:
fyi,
as part of adding more verification jobs on vdsm, infra recently added a new
job [1] that installs vdsm.
currently that job is working only on f19 and fails on f18 and centos64[2]:
Are there any plans to fix this soon? how users are supposed to install vdsm if
those pkg are missing?
Eyal.
[1]http://jenkins.ovirt.org/job/vdsm_install_rpm_sanity_gerrit/label=fedora18/117/console
[2]
centos:
Error: Package: vdsm-4.12.0-149.git44993c6.el6.x86_64
(/vdsm-4.12.0-149.git44993c6.el6.x86_64)
Requires: selinux-policy-targeted >= 3.7.19-213
Installed: selinux-policy-targeted-3.7.19-195.el6_4.12.noarch
(@updates)
Thanks for reporting this issue. We must revert this part of
http://gerrit.ovirt.org/4220 ("One shot prepare")
The selinux requirement came since that patch moves the storage
reprository to a new location (/var/run/vdsm/storage) instead of the
trademark-offensive non-standard /rhev/data-center.
EL6.4 would not be able to use the new location with selinux enabled.
We have a much bigger issue with this change, as it breaks migration to
and from ovirt-3.3; solving this is in the works.
f18:
--> Running transaction check
---> Package dracut.x86_64 0:024-18.git20130102.fc18 will be updated
---> Package dracut.x86_64 0:024-25.git20130205.fc18 will be an update
---> Package vdsm.x86_64 0:4.12.0-149.git44993c6.fc18 will be installed
--> Processing Dependency: libvirt-daemon >= 1.0.2-1 for package:
vdsm-4.12.0-149.git44993c6.fc18.x86_64
--> Finished Dependency Resolution
Error: Package: vdsm-4.12.0-149.git44993c6.fc18.x86_64
(/vdsm-4.12.0-149.git44993c6.fc18.x86_64)
Requires: libvirt-daemon >= 1.0.2-1
Installed: libvirt-daemon-0.10.2.7-1.fc18.x86_64 (@updates)
libvirt-daemon = 0.10.2.7-1.fc18
Available: libvirt-daemon-0.10.2.2-3.fc18.x86_64 (fedora)
libvirt-daemon = 0.10.2.2-3.fc18
This is a known and unavoidable issue (since
http://gerrit.ovirt.org/11709 of Mar 28 2013). oVirt users on F18 would
have to obtain libvirt from virt-preview or compile it themselves.
We should simply disable the job on Fedora 18.
Mike
Dan.
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
Re: oVirt package names potentially collide with Fedora
Hi Martin
Thanks for the feedback, and I'll try to answer your questions with both
how we're tackling this now and how we want to approach it in the future.
On 09/12/2013 09:16 AM, Martin Sivak wrote:
Hi,
I noticed that we use -N.fcXX as our release string for packages
(ovirt-engine-3.3-1.fc19.noarch.rpm for example). The release number
should be unique for a given version and distribution, but our
packages are using the same naming as the official Fedora packages.
Why this can be an issue?
Imagine a situation when somebody (us or somebody from the community)
packages an ovirt component for Fedora. Official Fedora packages use
-N.fcXX in their N-V-R (name-version-release) string. At that time,
both ovirt and Fedora rpms
(ovirt-project--1.fc20.noarch.rpm) will have the same name
and contain the same code. They won't be identical, but will at least
probably behave the same way.
Then a Fedora release will approach and Fedora release engineers will
do a Mass rebuild
(https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild). They will
bump the release number of the Fedora package by one
(-2.fc20.noarch.rpm).
Now ovirt does a new upstream release (same code, but a dependency
will change for example) and bump the release number by one. At that
time, there will be two packages named
ovirt-project--2.fc20.noarch.rpm with a different content.
Yes, this would be a problem, but we've taken steps to avoid this. We
have rules in place with packages that are not built in Koji that they
when they update, they update the version, not the release. So the
existing package for oVirt would be
ovirt-project-3.3.0-1.fc19.noarch.rpm
The next one would be either of these:
ovirt-project-3.3.1-1.fc19.noarch.rpm (for a planned bug fix release)
ovirt-project-3.3.0.1-1.fc19.noarch.rpm (for an unplanned critical bug
fix update)
Thus, Fedora would have 3.3.0-2, but oVirt would provide either 3.3.1-1
or 3.3.0.1-1 avoiding the conflict you've mentioned.
FWIW, this is not actually an issue anyway (explained below after the
alternate solution)
Solution?
To make easier to debug these version clashes between upstream and
downstream packages I propose changing the %{dist} tag our build
system uses (globally) to "ovirt.fcXX". It will still indicate the
proper Fedora version, but will make it obvious that the packages
weren't built as official Fedora packages (in koji) but as "official"
ovirt packages in Jenkins. And it won't require changing single line
in any of our spec files.
This would be doable, but we don't really have a consistent build
mechanism (a problem that we're attempting to handle).
Alternate solution?
The best solution with regards to dist versioning would be to make it
mandatory to have all packages that need to export officially in
Fedora and take the Fedora rpms from Koji. The same probably applies
to other distributions we might support in the future.
Btw: We really should be building packages for Fedora on the proper
Fedora (in mock) to avoid issues caused by library and compiler
differences between our build system and Koji. If we are doing that
than all is well, but I just wanted to be sure.
Yes, I completely agree that packages should be built in Koji for fcXX
(and even the el6) builds. The reason that we don't do this today is
that we can't. There are build dependencies that we haven't been able
to get into Fedora for some of the components (gwt for ovirt-engine) and
some things just are not Fedora acceptable (ovirt-node-iso, ovirt-release).
We tried to put ovirt-engine in Fedora directly a while ago (3.0
timeframe), but ran into problems with gwt. We ended up with a stripped
down, crippled version that still is in Fedora today. The time is
probably ripe for another attempt to get gwt in and get oVirt in fedora
as well.
For ovirt-node-iso, this is basically an rpm containing a Fedora Remix
LiveCD iso. It's something we could conceivable put into Fedora, but
most people just take the bare iso and not the rpm and there is no good
distribution mechanism through Fedora for the ISO. Packaging it and
putting it in Fedora would make little sense.
ovirt-release is simply an rpm with our required repositories. My
understanding is that it would break packaging rules to include
references to external non-fedora repos. We include things like Gluster
repos (when new gluster is available but not yet in Fedora),
virt-preview repos (new virtualization components that aren't in the
current fedora), etc.
We have some other non-Fedora components (otopi, ovirt-host-deploy, api,
sdk, etc) that would probably fit in Fedora perfectly fine, but without
the ovirt-engine packages, there is little value in the effort.
Packaging them would be part of the overall ovirt-engine packaging effort.
Other components do actually exist in Fedora today. vdsm is built and
packaged through Koji and those builds are basically copied from Koji
into the ovirt.org repositories.
Re: Jenkins job for ovirt-iso-uploader and ovirt-image-uploader
On 09/11/2013 03:56 AM, Eyal Edri wrote: Hi Sandro, I assume we can create a new vm on rackspace to act as NFS server for the job, or even convert one of the existing jenkins slave vms to be one. any other thoughts from the infra team? Space -- we should either enforce that the job clean up after itself, or have some sort of cron job to clean up. One approach: jenkins job creates some sort of lockfile, removes it on finish cron job checks for lockfile if found, see how long it's been there, clean up if it's been too long if not, clean up nfs share Mike Also, you will need to get a power user for jenkins (for tools) in order to create new jobs for them as well. The process for that is sending email to this list & engine-devel to request it formally and get acks from the community. Eyal. - Original Message - From: "Sandro Bonazzola" To: "infra" Sent: Wednesday, September 11, 2013 9:31:36 AM Subject: Jenkins job for ovirt-iso-uploader and ovirt-image-uploader Hi, I would like to introduce a jenkins job for basic sanity testing of ovirt-iso-uploader and ovirt-image-uploader. For covering NFS upload it will be needed an NFS share where to upload the images, writable by an user having UID and GID of 36. For covering SSH uploads it would be needed also SSH access with a user having UID and GID of 36. For covering upload using the domain id it would be needed a running ovirt-engine instance. The space needed for the images may be little: sample ovf provided by ovirt-image-uploader is ~2kb and for the iso image any non empty file should be enough. The uploaded images will be deleted by the job after running. Is it possible for infra to provide the needed services? Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: rebasing for oVirt 3.3.1?
On 09/09/2013 09:28 AM, Itamar Heim wrote: On 09/09/2013 04:19 PM, Mike Burns wrote: On 09/09/2013 08:17 AM, Itamar Heim wrote: with 3.3.0 coming soon, one of the questions I heard is "what about 3.3.1" considering the number of patches fox bugs that went into master branch since since we branched to stabilize 3.3.0. i.e., most of the work in master branch has been focused on bug fixes) so my suggestion is for 3.3.1 that we rebase from master, then move to backporting patches to that branch for the rest of 3.3 time frame. while this poses a small risk, i believe its the best course forward to making ovirt 3.3 a more robust and stable version going forward. this is mostly about ovirt-engine, and probably vdsm. for the other projects, its up to the maintainer, based on risk/benefit. I have no objections as long as we're not taking features into the 3.3.1 release and we're not changing the package set. We had an issue with one of the 3.2.x updates where we pulled a change in vdsm that removed the vdsm-gluster package. As long as we're making every effort to avoid features and avoid packaging changes, then I'm happy. i think there is a feature or two, but i think the version would still be way better off with this, considering the ratio of patches that went into it. Ok, can we at least make sure we call them out so we can list them in announcement email? I do expect us to do a bit more testing on it than if we didn't rebase, but i think its worth it. (as a side note, i also think it will be worth while to release hosted-engine in async to beta testing / release). Yes, hosted-engine is something we had discussed as an async feature and there were no objections to it going async. Mike Mike thoughts? Thanks, Itamar ___ Arch mailing list a...@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: rebasing for oVirt 3.3.1?
On 09/09/2013 08:17 AM, Itamar Heim wrote: with 3.3.0 coming soon, one of the questions I heard is "what about 3.3.1" considering the number of patches fox bugs that went into master branch since since we branched to stabilize 3.3.0. i.e., most of the work in master branch has been focused on bug fixes) so my suggestion is for 3.3.1 that we rebase from master, then move to backporting patches to that branch for the rest of 3.3 time frame. while this poses a small risk, i believe its the best course forward to making ovirt 3.3 a more robust and stable version going forward. this is mostly about ovirt-engine, and probably vdsm. for the other projects, its up to the maintainer, based on risk/benefit. I have no objections as long as we're not taking features into the 3.3.1 release and we're not changing the package set. We had an issue with one of the 3.2.x updates where we pulled a change in vdsm that removed the vdsm-gluster package. As long as we're making every effort to avoid features and avoid packaging changes, then I'm happy. Mike thoughts? Thanks, Itamar ___ Arch mailing list a...@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: ovirt 3.3 nightly on centos
On 09/03/2013 12:57 PM, Ohad Basan wrote: - Original Message - From: "Mike Burns" To: "Ohad Basan" Cc: "Dave Neary" , "infra" Sent: Tuesday, September 3, 2013 6:31:23 PM Subject: Re: ovirt 3.3 nightly on centos On 09/02/2013 12:38 PM, Ohad Basan wrote: - Original Message - From: "Dave Neary" To: "Ohad Basan" Cc: "infra" Sent: Monday, September 2, 2013 7:35:09 PM Subject: Re: ovirt 3.3 nightly on centos Hi Ohad, That is what the RDO project does, I think it's OK for us to do this too. We should make sure we warn users when they're installing oVirt that some of the dependencies will upgrade certain core packages (libvirt, qemu, whatever else) and that this may break their support. In particular, we should make absolutely clear under what circumstances someone can run RHS as a storage back-end for oVirt (if we pull in Gluster 3.4 will that break their RHS?). Cheers, Dave. you're right. the least we could do is instruct the users about which extra repositories are mandatory for ovirt nightly installation. The repositories required should be the repos in the ovirt-release package. They're updated to include the glusterfs 3.4.0 repo. if you are referring to http://ovirt.org/releases/ovirt-release-fedora.noarch.rpm then it is not installable on centos. Error: Package: ovirt-release-fedora-8-1.noarch (/ovirt-release-fedora.noarch) Requires: fedora-release http://resources.ovirt.org/releases/ovirt-release-el.noarch.rpm Also, we should *not* be using nightly for the 3.3 livecd image. We should be using the beta repo. nightlies can (and probably do) have patches that were not approved for the 3.3 release. Beta is currently pointing to 3.3 (and will continue to until we have a 3.4 beta). I will try that. Mike On 09/02/2013 06:14 PM, Ohad Basan wrote: Hey during prepping ovirt live I am installing ovirt 3.3 nightly on a centos 6.4 machines I have discovered that I am missing tons of dependencies not found in the standard repo 1. gluster >=3.4 2. vdsm requires libvirt >= 0.10.2-18.el6_4.4 I get gluster from the gluster nightly repo I can get the libvirt from koji or something. but I think we shold provide these packages in our repository because currently it's just not installable. Ohad ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: ovirt 3.3 nightly on centos
On 09/02/2013 12:38 PM, Ohad Basan wrote: - Original Message - From: "Dave Neary" To: "Ohad Basan" Cc: "infra" Sent: Monday, September 2, 2013 7:35:09 PM Subject: Re: ovirt 3.3 nightly on centos Hi Ohad, That is what the RDO project does, I think it's OK for us to do this too. We should make sure we warn users when they're installing oVirt that some of the dependencies will upgrade certain core packages (libvirt, qemu, whatever else) and that this may break their support. In particular, we should make absolutely clear under what circumstances someone can run RHS as a storage back-end for oVirt (if we pull in Gluster 3.4 will that break their RHS?). Cheers, Dave. you're right. the least we could do is instruct the users about which extra repositories are mandatory for ovirt nightly installation. The repositories required should be the repos in the ovirt-release package. They're updated to include the glusterfs 3.4.0 repo. Also, we should *not* be using nightly for the 3.3 livecd image. We should be using the beta repo. nightlies can (and probably do) have patches that were not approved for the 3.3 release. Beta is currently pointing to 3.3 (and will continue to until we have a 3.4 beta). Mike On 09/02/2013 06:14 PM, Ohad Basan wrote: Hey during prepping ovirt live I am installing ovirt 3.3 nightly on a centos 6.4 machines I have discovered that I am missing tons of dependencies not found in the standard repo 1. gluster >=3.4 2. vdsm requires libvirt >= 0.10.2-18.el6_4.4 I get gluster from the gluster nightly repo I can get the libvirt from koji or something. but I think we shold provide these packages in our repository because currently it's just not installable. Ohad ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Enabled SpamAssassin for mailing list filtering pre-moderation
On 09/02/2013 03:41 PM, Dave Neary wrote: Hi all, I have just set up SpamAssassin for Mailman for all ovirt.org mailing lists - I will be checking in regularly to make sure that this change does not cause dropping of legitimate emails. If you send an email to the list and it doesn't get there, please mail me personally at dneary @redhat.com to let me know, and we'll adjust the spam level appropriately. I have trained all the lists with a corpus of ham and spam, so hopefully this will significantly lessen the moderation load. Let me know if you notice anything out of the ordinary on *any* ovirt.org lists, please! Thanks, Dave. Woot! thanks Dave. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: converting networking functional tests ci job
On 08/22/2013 09:03 AM, Giuseppe Vallarelli wrote: - Original Message - | From: "Eyal Edri" | To: "Giuseppe Vallarelli" | Cc: "infra" ovirt.org> | Sent: Thursday, August 22, 2013 1:38:13 PM | Subject: Re: converting networking functional tests ci job | | Hi Giuseppe, | | before converting that job to run per patch, | can you please elaborate on the jobs's profile: | | 1. how long will it run? Right now with the current tests it takes around 8 mins, but I got other 5/6 patches which add more of them. I expect around 10/12 min but it will grow over time as we add more functional tests. | 2. can it run in parallel to other jobs? It can run with vdsm unit tests but not with another instance of functional tests. Easy enough to do this. There are job throttling options that let you only run a single instance of the job per machine. It may be worthwhile to generate some small jenkins slaves for jobs like this that can be long running and cannot co-exist with multiple instances of itself. | 3. does it affect the slave (in terms of other jobs will fail on it..) It shouldn't affect the slave, but it's something that I experienced when NetworkManager was interfering with vdsm network code, basically we lost connection with the slave. It's something that unfortunately can happen. This is somewhat concerning if the slave loses it's connection with the jenkins master. We would need to monitor it closely so we can recover the machine asap after this type of failure | 4. how do you plan to differ between network commits and other commits? Not so long ago, if I recall correctly you proposed a tag-like mechanism so we can distinguish patchset that needs network functional tests and patchset that do not. Otherwise the other alternative might be to detect changes in the networking modules, if the patchset touches one of the network modules than this job is triggered the only downside is that we should keep track of the networking modules and probably add them manually when we create new networking modules. It is possible to do path-based decisions for this. Only run if the patch makes a change to files in /path/to/directory Thanks Giuseppe | | thanks, | | eyal. | | - Original Message - | > From: "Giuseppe Vallarelli" | > To: "infra" ovirt.org> | > Sent: Thursday, August 22, 2013 2:16:01 PM | > Subject: converting networking functional tests ci job | > | > Hello everybody! | > I've been able to create a good enough jenkins job config | > (kudos to dcaro as well :-)) for the vdsm functional networking | > tests. I think that the next step is to convert this per commit | > job on a per patch basis. I'm available for details/help in case | > of need. | > | > Right now the job is running on a fedora19 vm and during the process | > we need to disable network manager otherwise it conflicts with | > vdsm networking code. | > | > Thanks a lot, | > | > Giuseppe | > | > | > | > | > | > ___ | > Infra mailing list | > Infra@ovirt.org | > http://lists.ovirt.org/mailman/listinfo/infra | > | ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: New mailing list for the hooks
On 05/28/2013 09:30 AM, Fabian Deutsch wrote: Am Dienstag, den 28.05.2013, 16:26 +0300 schrieb Itamar Heim: On 05/28/2013 02:55 PM, Fabian Deutsch wrote: Am Montag, den 27.05.2013, 15:44 -0400 schrieb David Caro Estevez: Hi! We also need a new mailing list for the bugzilla hooks account, so we can modify/update the bugs. Hey, I joined in late - Is there some documentation on what is planned with the bz hooks? This would also be interesting for oVirt Node. i think the basics are: if bug-url exists, verify its format and that bug is visible. if bug-url exists, change to post on patch being posted and add a reference to the patch in the bug (external tracker ovirt-gerrit). if bug-url exists, and bug is in product 'ovirt', change bug to modified on patch merge. Itamar, thanks for the summary, nice work! Mike, +1 from me for also following the Bug-Url-commit-line-convention to also take advantage of this work. No objection from me. Greetings fabian ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: ovirt.apps service
On 05/22/2013 09:25 AM, Ewoud Kohl van Wijngaarden wrote: On Wed, May 22, 2013 at 08:20:03AM -0400, Kiril Nesenko wrote: I am going to install something similar to [1]. I have a ticket for it here [2] The question on which server do we want to deploy it ? I'd say linode01.ovirt.org for now since that's already our webserver. I think when we start to split linode01, we can move it together with the repos to resources.ovirt.org. Don't we already have the ability to run vms on the alterway servers? I'd say we shouldn't add anything new linode, if we can avoid it. Mike [1] https://apps.fedoraproject.org/ [2] https://fedorahosted.org/ovirt/ticket/49 ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Need a new gerrit repo for ovirt-node-plugin-vdsm
On 05/20/2013 03:05 PM, Itamar Heim wrote: On 05/20/2013 04:11 PM, Mike Burns wrote: On 05/19/2013 08:21 AM, Dan Kenigsberg wrote: On Fri, May 17, 2013 at 10:02:34AM -0400, Douglas Schilling Landgraf wrote: On 05/17/2013 07:31 AM, Mike Burns wrote: As part of the move to a more universal oVirt Node during the 3.3 time frame[1], a separate repo is needed for a plugin to allow oVirt Node to communicate with oVirt Engine [2]. In order to provide this plugin, I need a gerrit repo created and also need consensus on a name. Name proposal: ovirt-node-plugin-vdsm I would go with that one. me2, though I do not have a strong opinion or explanation. ok, let's go with that. I've already posted initial test packages on ovirt.org[1] with that name, so let's just go with that. repo created. mike - you currently have +2/merge rights. Can you give me push rights, too, so I can upload the initial code? Mike Mike [1] http://resources.ovirt.org/releases/node-base/beta/rpm/Fedora/18/noarch/ I'm rather indifferent to what we call this, so I figured I'd include the arch@ list to get feedback. Thanks Mike [1] http://www.ovirt.org/Features/Universal_Image [2] http://www.ovirt.org/Features/Node_vdsm_plugin ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Arch mailing list a...@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Need a new gerrit repo for ovirt-node-plugin-vdsm
On 05/19/2013 08:21 AM, Dan Kenigsberg wrote: On Fri, May 17, 2013 at 10:02:34AM -0400, Douglas Schilling Landgraf wrote: On 05/17/2013 07:31 AM, Mike Burns wrote: As part of the move to a more universal oVirt Node during the 3.3 time frame[1], a separate repo is needed for a plugin to allow oVirt Node to communicate with oVirt Engine [2]. In order to provide this plugin, I need a gerrit repo created and also need consensus on a name. Name proposal: ovirt-node-plugin-vdsm I would go with that one. me2, though I do not have a strong opinion or explanation. ok, let's go with that. I've already posted initial test packages on ovirt.org[1] with that name, so let's just go with that. Mike [1] http://resources.ovirt.org/releases/node-base/beta/rpm/Fedora/18/noarch/ I'm rather indifferent to what we call this, so I figured I'd include the arch@ list to get feedback. Thanks Mike [1] http://www.ovirt.org/Features/Universal_Image [2] http://www.ovirt.org/Features/Node_vdsm_plugin ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: List moderation
On 05/17/2013 12:06 PM, Itamar Heim wrote: On 05/17/2013 07:51 AM, Karsten 'quaid' Wade wrote: Hi: I just let through some messages from this list queue. Wondering if anyone else would like moderator access to help keep things flowing? We have this list set to hold for moderation, so we have the chance to intercept real messages from project members, as well as add their names to the accept filter. Wondering who else might want admin access? Should we add all the project maintainers? - Karsten ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra we really need a spam filter - the ratio in some of the lists is mostly spam, but i hate to lose the few users trying to register. +1 -- the number of moderated messages recently has increased dramatically. At least a global blacklist would be useful. It's not uncommon to get 3 messages held from the same user on 3 different lists, all of which are obviously spam. Mike ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Need a new gerrit repo for ovirt-node-plugin-vdsm
As part of the move to a more universal oVirt Node during the 3.3 time frame[1], a separate repo is needed for a plugin to allow oVirt Node to communicate with oVirt Engine [2]. In order to provide this plugin, I need a gerrit repo created and also need consensus on a name. Name proposal: ovirt-node-plugin-vdsm ovirt-node-plugin-engine ovirt-engine-node-plugin I'm rather indifferent to what we call this, so I figured I'd include the arch@ list to get feedback. Thanks Mike [1] http://www.ovirt.org/Features/Universal_Image [2] http://www.ovirt.org/Features/Node_vdsm_plugin ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Updates-Testing repo
oVirt Engine RPMS for the 3.2.2 update are uploaded to this repo. Thanks Mike On 05/08/2013 07:53 AM, Mike Burns wrote: A new repo is now available on resources.ovirt.org. It contains packages that are targeted to be shipped as updates to the current stable oVirt release. This repo is located at: http://resources.ovirt.org/releases/updates-testing/ New ovirt-release packages are also available that contain the repo (disabled by default). http://resources.ovirt.org/releases/ovirt-release-fedora-6-1.noarch.rpm http://resources.ovirt.org/releases/ovirt-release-el6-6-1.noarch.rpm Let me know if there are any questions. Thanks Mike ___ Announce mailing list annou...@ovirt.org http://lists.ovirt.org/mailman/listinfo/announce ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Updates-Testing repo
A new repo is now available on resources.ovirt.org. It contains packages that are targeted to be shipped as updates to the current stable oVirt release. This repo is located at: http://resources.ovirt.org/releases/updates-testing/ New ovirt-release packages are also available that contain the repo (disabled by default). http://resources.ovirt.org/releases/ovirt-release-fedora-6-1.noarch.rpm http://resources.ovirt.org/releases/ovirt-release-el6-6-1.noarch.rpm Let me know if there are any questions. Thanks Mike ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: publish_ovirt_rpms_nightly job
On 05/02/2013 08:41 AM, Kiril Nesenko wrote: - Original Message - From: "Mike Burns" To: "Kiril Nesenko" Cc: "infra" Sent: Thursday, May 2, 2013 3:36:46 PM Subject: Re: publish_ovirt_rpms_nightly job On 05/02/2013 08:30 AM, Kiril Nesenko wrote: Hello, I see the sometimes this job [1] fails because of this error: SSH: Disconnecting configuration [ovirt.org] ... ERROR: Exception when publishing, exception message [Failure] Any ideas ? Increase timeout maybe ? With no real basis -- there were space issues on resources.ovirt.org overnight. That could have caused issues with the publish. Mike Can we clean it ? Remove some old rpms etc. ? This is already done (by Eyal). There is a thread on infra already discussing how to mitigate this long term. Mike Eyal, David can you give persmissions to access resources.ovirt.org ? - Kiril [1] http://jenkins.ovirt.org/job/publish_ovirt_rpms_nightly/ - Kiril ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: publish_ovirt_rpms_nightly job
On 05/02/2013 08:30 AM, Kiril Nesenko wrote: Hello, I see the sometimes this job [1] fails because of this error: SSH: Disconnecting configuration [ovirt.org] ... ERROR: Exception when publishing, exception message [Failure] Any ideas ? Increase timeout maybe ? With no real basis -- there were space issues on resources.ovirt.org overnight. That could have caused issues with the publish. Mike [1] http://jenkins.ovirt.org/job/publish_ovirt_rpms_nightly/ - Kiril ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Need to add rbarry to ovirt-node-maintainers group in gerrit
On 04/19/2013 04:54 AM, Itamar Heim wrote: On 04/18/2013 05:47 PM, Joey Boggs wrote: On 04/18/2013 09:53 AM, Fabian Deutsch wrote: Am Donnerstag, den 18.04.2013, 16:52 +0300 schrieb Itamar Heim: On 04/16/2013 04:45 PM, Mike Burns wrote: Hi Itamar, Can you add rba...@redhat.com (cc'ed) to the ovirt-node-maintainers group please? Thanks Mike per governance guidelines, i need an ack from 3 maintainers of the relevant project: +1 from me fabian cc'ing the other two for their acks. Joey Boggs Fabian Deutsch Thanks, Itamar ack Ryan added to ovirt-node-maintainers group Thanks! ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Need to add rbarry to ovirt-node-maintainers group in gerrit
Hi Itamar, Can you add rba...@redhat.com (cc'ed) to the ovirt-node-maintainers group please? Thanks Mike ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: SSL
On 03/27/2013 12:34 PM, Karsten 'quaid' Wade wrote: We can get an SSL cert for each subdomain, or we can get a wildcard cert. My understanding is that it is more secure to use one-per-subdomain. Presuming we want the one-per model, what are the subdomains we need to get a cert for? gerrit.ovirt.org jenkins.ovirt.org resources.ovirt.org foreman.ovirt.org smartproxy.ovirt.org lists.ovirt.org etherpad? what about base ovirt.org (the wiki)? Mike - Karsten ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: releases reorganization
On 03/26/2013 12:15 PM, Alon Bar-Lev wrote: Hello Mike, I think that we should split the nightly between two: 1. nightly stable - the next z stream candidate. 2. nightly next - the next minor candidate. This will enable user to fetch pre-releases of z streams easily when setting up nightly repository. Currently as all going into same directory, having nightly repository pulls next minor with all its issues. What do you think? I have no strong objections other than the fact that I don't think we should be making so many changes in the released branches that require constantly updating packages in a nightly. If you think it's necessary, I don't object, though. As for the setup, this is more in Eyal and Ofer's domain I think. They maintain the deployment of rpms from jenkins into the nightlies. Mike Alon - Original Message - From: "Mike Burns" To: "infra" Sent: Monday, March 18, 2013 3:02:27 PM Subject: releases reorganization With the beta release of 3.2 EL6 rpms, I had to re-organize the releases area a bit. Previously, the stable, beta, and alpha directories were symbolic links to the top level 3.2 or 3.1 directories. Because EL6 is part of 3.2, but not considered "stable" yet, I needed a way to handle that. The result: Top level 3.1, 3.2, 3.3, etc directories contain src, iso, rpm, and tools directories. The rpm directory will contain *all* distributions that are available for that release, whether beta, alpha, or stable. releases ├── 3.2 │ ├── iso │ ├── rpm │ │ ├── EL │ │ │ └── 6 │ │ │ ├── i686 │ │ │ ├── noarch │ │ │ ├── repodata │ │ │ │ └── repomd.xml │ │ │ ├── SRPMS │ │ │ └── x86_64 │ │ └── Fedora │ │ ├── 17 -> ../../../3.1/rpm/Fedora/17 │ │ ├── 18 │ │ │ ├── i686 │ │ │ ├── noarch │ │ │ ├── repodata │ │ │ │ └── repomd.xml │ │ │ ├── SRPMS │ │ │ └── x86_64 │ │ └── 19 -> 18 │ ├── src │ └── tools The beta, alpha, and stable symlinks are now real directories containing symlinks for iso src and tools. The rpm directory contains symlinks to the appropriate stable release for the version. releases └── stable ├── iso -> /var/www/html/releases/3.2/iso ├── rpm │ └── Fedora │ ├── 17 -> /var/www/html/releases/3.1/rpm/Fedora/17 │ └── 18 -> /var/www/html/releases/3.2/rpm/Fedora/18 ├── src -> /var/www/html/releases/3.2/src └── tools -> /var/www/html/releases/3.2/tools releases ├── beta │ ├── iso -> ../3.2/iso │ ├── rpm │ │ ├── EL -> ../../3.2/rpm/EL │ │ └── Fedora -> ../../3.2/rpm/Fedora/ │ ├── src -> ../3.2/src │ └── tools -> ../3.2/tools I've made these changes already due to requests from some developers who couldn't find the EL6 rpms under 3.2. If we want to change this model, then let me know. Otherwise, I'll add this documentation to the wiki. Mike ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: releases reorganization
On 03/27/2013 08:46 AM, Mike Burns wrote: On 03/26/2013 12:15 PM, Alon Bar-Lev wrote: Hello Mike, I think that we should split the nightly between two: 1. nightly stable - the next z stream candidate. 2. nightly next - the next minor candidate. This will enable user to fetch pre-releases of z streams easily when setting up nightly repository. Currently as all going into same directory, having nightly repository pulls next minor with all its issues. What do you think? I have no strong objections other than the fact that I don't think we should be making so many changes in the released branches that require constantly updating packages in a nightly. If you think it's necessary, I don't object, though. As for the setup, this is more in Eyal and Ofer's domain I think. They maintain the deployment of rpms from jenkins into the nightlies. perhaps instead of nightly-stable, how about something like updates-testing? Mike Mike Alon - Original Message - From: "Mike Burns" To: "infra" Sent: Monday, March 18, 2013 3:02:27 PM Subject: releases reorganization With the beta release of 3.2 EL6 rpms, I had to re-organize the releases area a bit. Previously, the stable, beta, and alpha directories were symbolic links to the top level 3.2 or 3.1 directories. Because EL6 is part of 3.2, but not considered "stable" yet, I needed a way to handle that. The result: Top level 3.1, 3.2, 3.3, etc directories contain src, iso, rpm, and tools directories. The rpm directory will contain *all* distributions that are available for that release, whether beta, alpha, or stable. releases ├── 3.2 │ ├── iso │ ├── rpm │ │ ├── EL │ │ │ └── 6 │ │ │ ├── i686 │ │ │ ├── noarch │ │ │ ├── repodata │ │ │ │ └── repomd.xml │ │ │ ├── SRPMS │ │ │ └── x86_64 │ │ └── Fedora │ │ ├── 17 -> ../../../3.1/rpm/Fedora/17 │ │ ├── 18 │ │ │ ├── i686 │ │ │ ├── noarch │ │ │ ├── repodata │ │ │ │ └── repomd.xml │ │ │ ├── SRPMS │ │ │ └── x86_64 │ │ └── 19 -> 18 │ ├── src │ └── tools The beta, alpha, and stable symlinks are now real directories containing symlinks for iso src and tools. The rpm directory contains symlinks to the appropriate stable release for the version. releases └── stable ├── iso -> /var/www/html/releases/3.2/iso ├── rpm │ └── Fedora │ ├── 17 -> /var/www/html/releases/3.1/rpm/Fedora/17 │ └── 18 -> /var/www/html/releases/3.2/rpm/Fedora/18 ├── src -> /var/www/html/releases/3.2/src └── tools -> /var/www/html/releases/3.2/tools releases ├── beta │ ├── iso -> ../3.2/iso │ ├── rpm │ │ ├── EL -> ../../3.2/rpm/EL │ │ └── Fedora -> ../../3.2/rpm/Fedora/ │ ├── src -> ../3.2/src │ └── tools -> ../3.2/tools I've made these changes already due to requests from some developers who couldn't find the EL6 rpms under 3.2. If we want to change this model, then let me know. Otherwise, I'll add this documentation to the wiki. Mike ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Loop devices exhausted on fedora-vm02
On 03/18/2013 08:25 AM, Eyal Edri wrote: - Original Message - From: "Fabian Deutsch" To: infra@ovirt.org Sent: Monday, March 18, 2013 1:08:12 PM Subject: Loop devices exhausted on fedora-vm02 Hey, it seems that all loop devices on fedora-vm02 are taken: http://jenkins.ovirt.org/view/ovirt_node/job/ovirt-node-iso/671/console Could someone look into this? can you explain why it happens? (ovirt-node jobs?) maybe the job should add a cleanup step at end to release unused loop devices? Looking here [1] there are 2 iso build jobs that could be running on the host at the same time. We could throttle the jobs so that they can't run concurrently. We can also simply add something like max_loops=256 on the kernel commandline so that there are extra loop devices. We've seen this happen before, and livecd-tools is pretty good about cleaning up, even in failure scenarios (as long as you don't ctrl-c or kill -9 the job). But a single job uses a number of loop devices (3,4,5,6, not actually sure the number). It also uses lazy umounts in some cases meaning that there could be a couple loop devices in use that get cleaned up at a later point. The simplest fix for this would be to increase the default number of loop devices. Mike [1] http://jenkins.ovirt.org/computer/fedora18-vm02/ Thanks fabian ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
releases reorganization
With the beta release of 3.2 EL6 rpms, I had to re-organize the releases area a bit. Previously, the stable, beta, and alpha directories were symbolic links to the top level 3.2 or 3.1 directories. Because EL6 is part of 3.2, but not considered "stable" yet, I needed a way to handle that. The result: Top level 3.1, 3.2, 3.3, etc directories contain src, iso, rpm, and tools directories. The rpm directory will contain *all* distributions that are available for that release, whether beta, alpha, or stable. releases ├── 3.2 │ ├── iso │ ├── rpm │ │ ├── EL │ │ │ └── 6 │ │ │ ├── i686 │ │ │ ├── noarch │ │ │ ├── repodata │ │ │ │ └── repomd.xml │ │ │ ├── SRPMS │ │ │ └── x86_64 │ │ └── Fedora │ │ ├── 17 -> ../../../3.1/rpm/Fedora/17 │ │ ├── 18 │ │ │ ├── i686 │ │ │ ├── noarch │ │ │ ├── repodata │ │ │ │ └── repomd.xml │ │ │ ├── SRPMS │ │ │ └── x86_64 │ │ └── 19 -> 18 │ ├── src │ └── tools The beta, alpha, and stable symlinks are now real directories containing symlinks for iso src and tools. The rpm directory contains symlinks to the appropriate stable release for the version. releases └── stable ├── iso -> /var/www/html/releases/3.2/iso ├── rpm │ └── Fedora │ ├── 17 -> /var/www/html/releases/3.1/rpm/Fedora/17 │ └── 18 -> /var/www/html/releases/3.2/rpm/Fedora/18 ├── src -> /var/www/html/releases/3.2/src └── tools -> /var/www/html/releases/3.2/tools releases ├── beta │ ├── iso -> ../3.2/iso │ ├── rpm │ │ ├── EL -> ../../3.2/rpm/EL │ │ └── Fedora -> ../../3.2/rpm/Fedora/ │ ├── src -> ../3.2/src │ └── tools -> ../3.2/tools I've made these changes already due to requests from some developers who couldn't find the EL6 rpms under 3.2. If we want to change this model, then let me know. Otherwise, I'll add this documentation to the wiki. Mike ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: please create new repository ovirt-engine-sdk-ruby
On 03/14/2013 09:48 AM, Michael Pasternak wrote: On 03/14/2013 03:44 PM, Michael Pasternak wrote: On 03/14/2013 03:32 PM, Mike Burns wrote: On 03/14/2013 03:35 AM, Itamar Heim wrote: On 03/14/2013 08:14 AM, Michael Pasternak wrote: thanks. +1 from me as part of the sdk subproject we have. will give a few days to see if any special comments from others. Not a nack, but I'm curious if this could all be contained under the sdk repo that already exists. IOW, have a single sdk srpm the generates ruby, java, python, etc bindings? this is another alternative, but current sdk repo contains python bindings, not sure if someone seeking for the python sources need to get java/ruby/etc, as well. having single sdk rpm that installs ruby, java, python, etc bindings, not related to physical bindings repositories i guess, the question is do we want to have different bindings under same place, - this is not that common afaik. actually now when i'm thinking about this, gerrit works peer git repo/project, so sending different sources to the single repo ovirt-engine-sdk will be confusing, i.e people that would like to 'watch' sdk-java changes would not be able to differentiate them from the sdk-python/ruby/etc commits. Fair point. I'm fine with a separate repo. +1 ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: please create new repository ovirt-engine-sdk-ruby
On 03/14/2013 09:44 AM, Michael Pasternak wrote: On 03/14/2013 03:32 PM, Mike Burns wrote: On 03/14/2013 03:35 AM, Itamar Heim wrote: On 03/14/2013 08:14 AM, Michael Pasternak wrote: thanks. +1 from me as part of the sdk subproject we have. will give a few days to see if any special comments from others. Not a nack, but I'm curious if this could all be contained under the sdk repo that already exists. IOW, have a single sdk srpm the generates ruby, java, python, etc bindings? this is another alternative, but current sdk repo contains python bindings, not sure if someone seeking for the python sources need to get java/ruby/etc, as well. having single sdk rpm that installs ruby, java, python, etc bindings, not related to physical bindings repositories i guess, the question is do we want to have different bindings under same place, - this is not that common afaik. Not a single rpm, a single srpm with multiple subpackages for -python -java, -ruby. I had looked at libvirt, and they ship python bindings from the libvirt srpm. Further looks shows a number of other packages like ocaml-libvirt that aren't. Seems like it could go either way. /me doesn't object either way. Mike ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: please create new repository ovirt-engine-sdk-ruby
On 03/14/2013 03:35 AM, Itamar Heim wrote: On 03/14/2013 08:14 AM, Michael Pasternak wrote: thanks. +1 from me as part of the sdk subproject we have. will give a few days to see if any special comments from others. Not a nack, but I'm curious if this could all be contained under the sdk repo that already exists. IOW, have a single sdk srpm the generates ruby, java, python, etc bindings? ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: new mailing list request.
On 03/13/2013 09:29 PM, Mike Burns wrote: On 03/13/2013 01:51 PM, Karsten 'quaid' Wade wrote: On 03/13/2013 10:16 AM, Theron Conrey wrote: Building up the marketing group, I'm requesting a marketing@ mailing list be built. Let me know if you have any questions. Resist the list! Down with new lists! Do all work on arch@ and love it! Actually, no questions, +1 from me. +1 The process for an Infra maintainers (or anyone with sudo on lists.ovirt.org): http://www.ovirt.org/Creating_and_configuring_mailing_lists Presuming all +1s on this idea, does anyone else want to learn how or do this list creation? Otherwise, it's <5 min for me to do it. Oh, for giggles, shall we open a ticket? That helps us track and complete the request. http://fedorahosted.org/ovirt Infra folks - I'm not really thinking it's our role to approve the creation of lists, just to do the work. I think Theron's request is an obvious "yes" so I don't personally feel we need to ask for further permission. Was a pretty obvious yes to me, which is why i sent Theron here. Where is the optimal place to get project approval on new lists? board@ could be it, but arch@ seems like really the best one. Or should we just let people file a ticket and we only ask them to go get approval if it's unclear to us if it's an obvious yes? I think point people either to the ticketing (we should get a redirect or something setup so it's on an ovirt.org subdomain) or to infra@ (or maybe a frontend email address for the ticketing?). If we're unsure, we can ack s/ack/ask for details from the requester while we seek approval from the board or arch lists if necessary. Mike - Karsten ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: new mailing list request.
On 03/13/2013 01:51 PM, Karsten 'quaid' Wade wrote: On 03/13/2013 10:16 AM, Theron Conrey wrote: Building up the marketing group, I'm requesting a marketing@ mailing list be built. Let me know if you have any questions. Resist the list! Down with new lists! Do all work on arch@ and love it! Actually, no questions, +1 from me. +1 The process for an Infra maintainers (or anyone with sudo on lists.ovirt.org): http://www.ovirt.org/Creating_and_configuring_mailing_lists Presuming all +1s on this idea, does anyone else want to learn how or do this list creation? Otherwise, it's <5 min for me to do it. Oh, for giggles, shall we open a ticket? That helps us track and complete the request. http://fedorahosted.org/ovirt Infra folks - I'm not really thinking it's our role to approve the creation of lists, just to do the work. I think Theron's request is an obvious "yes" so I don't personally feel we need to ask for further permission. Was a pretty obvious yes to me, which is why i sent Theron here. Where is the optimal place to get project approval on new lists? board@ could be it, but arch@ seems like really the best one. Or should we just let people file a ticket and we only ask them to go get approval if it's unclear to us if it's an obvious yes? I think point people either to the ticketing (we should get a redirect or something setup so it's on an ovirt.org subdomain) or to infra@ (or maybe a frontend email address for the ticketing?). If we're unsure, we can ack for details from the requester while we seek approval from the board or arch lists if necessary. Mike - Karsten ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: New git repo for jenkins
On 03/06/2013 08:54 AM, Eyal Edri wrote: - Original Message - From: "Mike Burns" To: "Kiril Nesenko" Cc: infra@ovirt.org Sent: Wednesday, March 6, 2013 2:07:35 PM Subject: Re: New git repo for jenkins On 03/05/2013 05:29 AM, Kiril Nesenko wrote: Hi all, I think that we need to create new git repo for jenkins in our gerrit. This git will store jenkins jobs configuration, scripts etc. Not opposed, but what does this do for creating or changing existing jobs? Do we have to do it outside of jenkins? Do we simply make changes in a git checkout, submit them, then they get pushed live automatically? Let me try to explain. Currently the status is all job logic is written inside the job itself, this is bad practise, for a few reasons: Not all, but most (ovirt-node-iso* jobs runs a script file in it's source repository). The logic in the jenkins job is simply clean up and run. 1. no code review (job configuration is also only viewable and accessible to jenkins power-users/admins, not very "open source" approach) Agreed, though we can easily make the code read-only to non-power-users. 2. difficult to include usage of files (answer file for example for automating engine-setup) I haven't encountered this issue. I've had jobs before (though not in upstream oVirt) that pulled files from other jobs for this purpose. For example, a job that generates a file like "releases.txt" that contains mappings for something like "FDEVEL=19" FRELEASED=18", etc. which are then sourced in the other job 3. backup of code and revisions (sure there is the job config-history but that's really for troubleshooting the restoring jobs) 4. writing long complex code in bash/python inside a textbox is error prone and not convenient. I agree about writing code in a textbox like that, it's not ideal. I generally copy it out, edit it in an editor of my choice, then copy it back in. I have experience from the past 2 years of writing code for jenkins jobs that got complex and longer as the product evolved. today i use even more than one repository for running jobs in jenkins. the proposed change is to keep all code inside a git repo instead just inside jenkins jobs. it doesn't mean that every job that has 2-3 lines of code should go into the git, it means we have a choice, if the code gets too complex (like running engine-setup + engine-upgrade) then we can use git as the source for the code. OK, I think that's the right choice. I expect many jobs are simple automake builds that do thinks like: ./autogen make make install make rpms maybe with some slight changes. If there are more complex jobs, then yes, moving the code into something like git is probably worthwhile. It might not be necessary for ovirt-node to have a maintainer on the git repo though. I think our jobs are relatively simple enough to not need it. I intend to add some of the existing jobs that runs complex code into it, but not all of them. that's up to the job maintainer to decide. IOW, I think we need to map out exactly how things are supposed to get updated. I don't think we want people to have to change things in 3 different places. We'll end up with some changes in git that aren't in the live jenkins, some that aren't in git, but are live. Also, what about new job development? Is that done through jenkins and then somehow exported into the git repo? New jobs can take many iterations to get *right*. the way to use it in a job is by using the 'multiple scm plugin' which allows you to listen to more than one git repo for a job. you can see an example in the new setup+upgrade job knesenso is building now http://jenkins.ovirt.org/job/ovirt_engine_upgrade_stable_32_to_latest_32/configure OK, I can see how that works. I hadn't tried it previously. I know I haven't been involved, but was something like this[1] discussed or evaluated? [1] https://wiki.jenkins-ci.org/display/JENKINS/JobConfigHistory+Plugin as i mentioned, this plugin is good mainly for keeping track on who made change OK, I haven't used it, was just making sure we weren't re-inventing the wheel. Mike Thoughts ? Thanks, Kiril Nesenko Red Hat, Inc. www.redhat.com ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Gerrit triggers in jenkins not working?
On 03/06/2013 08:24 AM, Fabian Deutsch wrote: Am Mittwoch, den 06.03.2013, 08:20 -0500 schrieb Eyal Edri: - Original Message - From: "Fabian Deutsch" To: "Eyal Edri" Cc: infra@ovirt.org Sent: Wednesday, March 6, 2013 3:02:07 PM Subject: Re: Gerrit triggers in jenkins not working? Am Mittwoch, den 06.03.2013, 07:56 -0500 schrieb Eyal Edri: Can you be more specific? which job isn't triggered? In my case it's ovirt-node-devel which isn't triggered by gerrit. it is triggered, it was just on 'silient mode' so you didn't see it on gerrit. http://jenkins.ovirt.org/job/ovirt-node-devel/, probably as part of the migration phase so it wouldn't fail jobs. fixed now. Mh, but if you look at the last jobs (2174-2176) they were all started manually by me (and not by the corrspdongin gerrit patches 12755, 12759) 1273 was the last one trigger by a gerrit patch (12555). Or am I blind and just don't see the triggered jobs for the gerrit patches (12755, 12759)? It's possible some jobs were missed during the migration to the new jenkins server. I do see the latest patch you submitted (12765) triggered a build. I also re-set the "silent trigger" option which was set intentionally. Mike Greetings fabian - fabian eyal. - Original Message - From: "Fabian Deutsch" To: infra@ovirt.org Sent: Wednesday, March 6, 2013 2:24:06 PM Subject: Gerrit triggers in jenkins not working? Hey, coul dit be that the gerrit triggers in jenkins are currently not working? I observed that a new gerrit patchset doesn't trigger a jenkins job? Thanks fabian ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: New ideas to grow the community
On 03/04/2013 08:28 AM, Itamar Heim wrote: On 04/03/2013 12:41, Dave Neary wrote: * Consolidating developer lists (arch, vdsm-devel, enginer-devel, node-devel) into one main developer list to ensure that we get away from the "mass CC" phenomenon - I previously proposed updating list descriptions and renaming arch to devel, the difference between vdsm-devel and engine-devel (where developers talk) and arch (where they don't, much) has actually grown since then. i'm for renaming arch to devel and merging engine-devel and vdsm-devel into it. I'll let the node-devel chime in if they think its best to merge it as well or not. I would prefer not merging node-devel with arch/devel. Node is breaking away from being just an oVirt project, so having a separate devel list is good for us. I'll make sure that we include the general devel mailing list on oVirt related things, but in general, our stuff is much more node specific and not general ovirt related. * Figuring out how to make the users list more manageable. A few things come to mind: * Opening a forum, so that people don't feel overwhelmed with 50-100 emails a day +1 on opening a forum. +2 if it gets sent to a mailing list (could be forum@ rather than user@). ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: New git repo for jenkins
On 03/05/2013 05:29 AM, Kiril Nesenko wrote: Hi all, I think that we need to create new git repo for jenkins in our gerrit. This git will store jenkins jobs configuration, scripts etc. Not opposed, but what does this do for creating or changing existing jobs? Do we have to do it outside of jenkins? Do we simply make changes in a git checkout, submit them, then they get pushed live automatically? IOW, I think we need to map out exactly how things are supposed to get updated. I don't think we want people to have to change things in 3 different places. We'll end up with some changes in git that aren't in the live jenkins, some that aren't in git, but are live. Also, what about new job development? Is that done through jenkins and then somehow exported into the git repo? New jobs can take many iterations to get *right*. I know I haven't been involved, but was something like this[1] discussed or evaluated? [1] https://wiki.jenkins-ci.org/display/JENKINS/JobConfigHistory+Plugin Mike Thoughts ? Thanks, Kiril Nesenko Red Hat, Inc. www.redhat.com ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: New git repo for jenkins
On 03/05/2013 07:11 AM, Itamar Heim wrote: On 05/03/2013 14:07, Eyal Edri wrote: - Original Message - From: "Itamar Heim" To: "Kiril Nesenko" Cc: infra@ovirt.org Sent: Tuesday, March 5, 2013 2:05:30 PM Subject: Re: New git repo for jenkins On 05/03/2013 14:02, Kiril Nesenko wrote: Itamar, Can you create 'jenkins' repo for us in gerrit.ovirt.org ? Thanks, Kiril Nesenko Red Hat, Inc. www.redhat.com - Original Message - From: "Ohad Basan" To: "Kiril Nesenko" Cc: infra@ovirt.org Sent: Tuesday, March 5, 2013 1:14:38 PM Subject: Re: New git repo for jenkins - Original Message - From: "Kiril Nesenko" To: infra@ovirt.org Sent: Tuesday, March 5, 2013 12:29:28 PM Subject: New git repo for jenkins Hi all, I think that we need to create new git repo for jenkins in our gerrit. This git will store jenkins jobs configuration, scripts etc. Thoughts ? +1 great idea Thanks, Kiril Nesenko Red Hat, Inc. www.redhat.com ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra who would be its maintainers? i propose myself and dcaro for starts since we are the most active maintainers for jenkins jobs code currently. i believe someone from ovirt-node (mburns or fabiand) will also need +2 permissions. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra done. added eedri. did not find dcaro in gerrit users. waiting on feedback from ovirt-node folks. Fabian probably makes the most sense currently. Mike ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Etherpad down?
On 02/28/2013 01:41 PM, Karsten 'quaid' Wade wrote: On 02/28/2013 07:24 AM, Doron Fediuck wrote: http://etherpad-ovirtapps.rhcloud.com seems to have the etherpad service down. Can someone please help? I'm asking on #openshift, but they don't have any known open issues: https://openshift.redhat.com/app/status I don't think I have an sshkey loaded for that app so I can't go restart it. I reckon that's most likely the problem - it fell down and can't get back up without some help. I forget who setup that service, that's one we need to bring in to the fold of shared keys and control from the other project maintainers. IINM, Moran set it up. Here's my OpenShift key: ssh-rsa B3NzaC1yc2EDAQABAAACAQCiwdXXxIo5RxQuGDFmMIv/NXz/jhxsDxyuf7J3o/GdQDfp0QYIzpDjrNtIYq6wNUFRG/TNyY/HSujnY+rO62bNHRFtbGkx7oYHaqm6WTOz6Ic5CtCAJbxQYHyDov+Oq801r8kyrWRH1/jXhc76E0ddxh2i8Iw5xmknwqN9nU/ow0oaRbJqrGFFm/du2pZWOSDzsx6VUt4CaXR55M55QHwTPHOcycFu2U3EkBsniDAmMmmUcHrGtYA5neT8rKJ74Q3PFiC7MMZK/ge7YENtIB1QMpVZubsjqugYu3yBHUNs9f7fOZS/YF7tHl1S92r0KDxaq4BvBnW/5JdWdz7/6L9OexIQ7NTPyhxbX0Fmn7JOjT/AN+TUCz4WIGKp0hvG5QaP8Ttpfb6k4TUTtJcH9PgXaKsOFrLQX6LFBQFfiDogla/XMOgXdiZiQqeQ1mlxM04F7pZAcyMf7LqD6K6Uz0jodusRdK3ao5W4UMo7B0VGSUjEaEEcSDp1p4tvmx2Fi8lGfuROAIj5vI+ogEabZuBTTON0lDRjVQjqy9KUj4ckGLNq2nE8kagUhIvn9SLMXqjSA9A4ntfBZ+rlkMYcXJ6KRysE5aYgYbdXvJXy07E8adl+cOjSLoY/8rNUCujeXYCosXCtWkdKHJMMdwa4iRPMu52tLRD07H/uBQp7OFS2bw== kw...@terpsichore.fairy-talefarm.com Thanks - Karsten ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Jenkins alerts on infra list
I've noticed that the infra list has been somewhat inundated with Jenkins build failure notices recently. I wanted to ask whether infra is really the right place to get these notifications. In some cases, I think that it is the right place, but in most, I think it's not. Things like: check_disk_space_on_jenkins_slaves check_gerrit_ovirt_org and other jobs that are purely monitoring or slave maintenance jobs should report to infra. Other jobs that are sub-project oriented, I think, should alert a sub-project specific mailing list: ovirt-engine_create_rpms_fedora ovirt-engine_dao_unit_tests ovirt-engine-update_db_multiple_os etc... While I think infra should know when there are service problems (like a machine's disk is full, or a service is down), I don't think it's worthwhile for infra to be alerted for *every* failure of a job in jenkins. It's not the job of infra to make other sub-projects fix their builds, just to provide the jenkins service. I propose that all sub-project builds that send email to infra be diverted to the -patches mailing list. Thoughts? Mike ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: livecd-creator requires root
On 02/26/2013 09:08 AM, Eli Mesika wrote: - Original Message - From: "Ohad Basan" To: infra@ovirt.org Sent: Tuesday, February 26, 2013 3:54:39 PM Subject: livecd-creator requires root Hey I've started working on a jenkins job that generates a nightly ovirt-live image. the problem is is that it is using /usr/bin/livecd-creator to generate the iso and it looks like this program requires root to run does anyone have an idea? Yes , it claims to in https://fedoraproject.org/wiki/How_to_create_and_use_a_Live_CD?rd=How_to_create_and_use_Fedora_Live_CD We should be doing this already for the jenkins user for all jobs. ovirt-node is also built using livecd-creator and uses sudo to accomplish this. Mike I thought of granting a sudo permission for this specific binary. Seems to me as simple enough for that task Thanks, Ohad ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Process for removing spam users
This came up over the weekend and I handled it (somewhat). There was a user that was confirmed and got an account created on the wiki. Their user page was then made an advertisement for some SMS related thing that had nothing to do with oVirt. On request, I deleted the page and blocked the user[1]. As I've done very little wiki administration in the past, I wanted to make sure that we have a consistent process in place for handling situations like this in the future. Any thoughts? Mike [1] http://www.ovirt.org/Special:Block ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: New ideas to grow the community
On 02/24/2013 08:34 AM, Kiril Nesenko wrote: - Original Message - From: "Dan Kenigsberg" To: "Kiril Nesenko" Cc: infra@ovirt.org Sent: Sunday, February 24, 2013 3:20:01 PM Subject: Re: New ideas to grow the community On Sun, Feb 24, 2013 at 04:42:23AM -0500, Kiril Nesenko wrote: - Original Message - From: "Dan Kenigsberg" To: "Kiril Nesenko" Cc: infra@ovirt.org Sent: Sunday, February 24, 2013 11:25:41 AM Subject: Re: New ideas to grow the community On Sun, Feb 24, 2013 at 04:00:29AM -0500, Kiril Nesenko wrote: Hi team, I have few ideas regarding the project, any feedback will be appreciated ! ### IRC ### 1. I think that we should create new channels on irc, #ovirt is not enough. Would you explain why it's time to fork #ovirt? I do not see TOO much traffic or confusion there. I think that we need to prepare for the future and do things correctly. I think that this will help the project to grow. We should add: #ovirt-meeting - will be used for meetings only, need to add bot that will log the meetings meeting can generate a lot of temporary noise which can deter people from jumping in, so I would agree to create an ad-hoc channel for a meeting - but please update the main #ovirt topic to indicate where the meeting takes place. Nobody told users that they must/should attend meetings. If they want - they will attend. Why not ovirt-meeting ? I like this name. I don't mind the name - I just want the topic of #ovirt to remind me where have everybody's gone to. Good idea This was discussed very early on -- splitting off and having a -meeting channel. We didn't make the change at that time because there wasn't enough traffic on the channel to warrant having 2 channels. Also, having the meetings in the #ovirt channel can have the side-effect of drawing more people into the meetings that are just lurking in #ovirt. Currently, there are only 3 meetings[1] per week in the #ovirt channel, each lasting 1 hr or less, generally. IMO, moving 3 meetings out is not really going to help. Sure we need to update the wiki with a new place #ovirt-devel - will be used for devel discussions only Have users complained that there are to many technical discussions on #ovirt? I think that it's important to keep the devels near users until devels become a nuisance. Each discussions should be done in the right place. Maybe devel channel is not relevant for now, but still it will be nice to have it for a future. I think that spinning off #ovirt-devel is not "a thing done correctly". We may have to do it in the future, if users are tired of technical java discussions. Until this happens, we need to keep the guys who knows the most about the code near the guys who needs their support, in one happy channel. Yes I agree with you. I agree, lets not make this split until we have to. Mike #ovirt - general 2. Infra meetings should start with the following topic - New folks introductions (this is a tmp subject) In this topic we will let new folks to introduce themselves. ### Ovirt website ### 1. We should add link to the infra in - http://www.ovirt.org/Community It should be possible to navigate to http://www.ovirt.org/Infra from http://www.ovirt.org/Community . First thing someone that want to join the project will navigate to http://www.ovirt.org/Community , so it is very important to add link there. 2. Update - http://www.ovirt.org/Becoming_an_Infrastructure_team_member ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra [1] infra on Monday, node on Tuesday, Project on Wednesday. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Infra gerrit group and ovirt-release package ownership
On 02/21/2013 02:25 PM, Ewoud Kohl van Wijngaarden wrote: On Thu, Feb 21, 2013 at 01:09:18PM -0500, Mike Burns wrote: I was looking at a reported issue with the ovirt-release package (missing dependency) and found out that the gerrit repo for this is currently owned by the ovirt-docs team. I think it makes sense to change this ownership to a group that includes the infra team. I'm guessing this is my patch http://gerrit.ovirt.org/#/c/12114/. AFAICT, there isn't an Infra team currently in gerrit (or at least not one that I'm in). My proposal: * create an infra group in gerrit * add members of the infra team to this group * change ownership to ovirt-release from ovirt-docs to infra Thoughts, concerns? +1 We should also set up a simple jenkins job to build ovirt-release if there isn't one already. http://jenkins.ovirt.org/job/ovirt-release/ ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Infra gerrit group and ovirt-release package ownership
On 02/21/2013 01:42 PM, Alexander Rydekull wrote: For us that are new to ovirt and packages, procedures etc. What exactly is the point of the ovirt-release package and why is this something infra should do? (But other then getting the reasoning explained, I dont see a reason why we shouldnt do what is proposed.) ovirt-release is used to setup yum repos on a host. IOW, a user would run: yum install http://resources.ovirt.org/releases/ovirt-release-fedora.noarch.rpm on a F18 host, and then they get the ovirt-stable ovirt-beta and ovirt-alpha repo definitions. There is also an equivalent package for el6. The Infra team owns the layout of our releases on ovirt.org, so it would seem to make sense that Infra would own this. From an overhead perspective, the package is mostly stable with very few patches being posted. Mike On Thu, Feb 21, 2013 at 7:09 PM, Mike Burns <mailto:mbu...@redhat.com>> wrote: I was looking at a reported issue with the ovirt-release package (missing dependency) and found out that the gerrit repo for this is currently owned by the ovirt-docs team. I think it makes sense to change this ownership to a group that includes the infra team. AFAICT, there isn't an Infra team currently in gerrit (or at least not one that I'm in). My proposal: * create an infra group in gerrit * add members of the infra team to this group * change ownership to ovirt-release from ovirt-docs to infra Thoughts, concerns? Thanks Mike ___ Infra mailing list Infra@ovirt.org <mailto:Infra@ovirt.org> http://lists.ovirt.org/mailman/listinfo/infra -- /Alexander Rydekull ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Infra gerrit group and ovirt-release package ownership
I was looking at a reported issue with the ovirt-release package (missing dependency) and found out that the gerrit repo for this is currently owned by the ovirt-docs team. I think it makes sense to change this ownership to a group that includes the infra team. AFAICT, there isn't an Infra team currently in gerrit (or at least not one that I'm in). My proposal: * create an infra group in gerrit * add members of the infra team to this group * change ownership to ovirt-release from ovirt-docs to infra Thoughts, concerns? Thanks Mike ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Updating the F18 builders on jenkins.ovirt
On 02/14/2013 11:17 AM, Mike Burns wrote: On 02/14/2013 10:32 AM, Mike Burns wrote: Currently, we're seeing some strange build issues when building ovirt-node iso images in jenkins. I don't see the same issues on local machines, so I suspect that it's related to some selinux changes in Fedora 18. I'll be running a yum update on the machine shortly to see if that will fix the problem. Update is complete and the node is back online. Mike OK, so the issue we were seeing did not resolve itself.[1] Any objection to me giving temporary access to the F18 builder to an SELinux expert to look around? We're tracking the issue in a bug and the person looking to help needs access to the machine if we can give it. [2] FWIW, I've known Dan Walsh for years and he's widely considered one of the foremost SELinux experts around. Thanks Mike [1] Search for "policydb magic number" in http://jenkins.ovirt.org/view/ovirt_node/job/ovirt-node-iso-devel/1703/console [2] https://bugzilla.redhat.com/show_bug.cgi?id=894065 Thanks Mike ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Updating the F18 builders on jenkins.ovirt
On 02/14/2013 10:32 AM, Mike Burns wrote: Currently, we're seeing some strange build issues when building ovirt-node iso images in jenkins. I don't see the same issues on local machines, so I suspect that it's related to some selinux changes in Fedora 18. I'll be running a yum update on the machine shortly to see if that will fix the problem. Update is complete and the node is back online. Mike Thanks Mike ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Updating the F18 builders on jenkins.ovirt
Currently, we're seeing some strange build issues when building ovirt-node iso images in jenkins. I don't see the same issues on local machines, so I suspect that it's related to some selinux changes in Fedora 18. I'll be running a yum update on the machine shortly to see if that will fix the problem. Thanks Mike ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Vacation coverage: quaid
On Tue, 2013-01-22 at 17:40 -0800, Karsten 'quaid' Wade wrote: > All: > > I'm going to be on vacation from 25 Jan to 08 Feb, with a few days of > concentrated in-the-office on 31 Jan, 01 Feb (and a visit to FOSDEM > following that.) We should plan that I won't be available at all during > those two weeks. (I'll check in, I'll have a phone, but let's not rely > upon me for emergencies, OK?) > > This (and other reasons) prompted me to write down who is assigned to > what for this team: > > http://www.ovirt.org/Infrastructure_team_assignments > > Looking at what I may be the only person who can do: > > 1. Manage Linode via their dashboard. > 2. Manage Mailman - new lists, fixes, etc. > 3. Do obscure things on the Linode. > 4. Run ovirtbot. I can do the above in an emergency, but I don't have time to really volunteer as a point person. But if things break, then I can probably help. Mike > > Anything I'm missing? > > To address: > > 1. For Linode, I can add other users to give them full permissions to do > what I've been doing - restarting the VM, etc. Anyone interested, able, > or willing to do this? > > 2. For Mailman, anyone with ssh + sudo on Linode can do the usual tasks: > >http://www.ovirt.org/Creating_and_configuring_mailing_lists > > 3. Obscure Linode things should all be documented here: > >http://www.ovirt.org/Category:Infrastructure_documentation >http://www.ovirt.org/Category:Infrastructure_SOP > > 4. Anyone with ssh+sudo on linode01.ovirt.org can restart the bot: > >http://www.ovirt.org/Running_ovirtbot > > Result: if a few folks can volunteer to be Linode admins, then we'll > have complete coverage and backups for me while I'm not available. > > Final items on my mind: > > * Both sets of new servers are available, I'll be putting everyone's > sshkeys + sudo on those boxes so you can do work immediately on Jenkins > master and slaves. > > * Let's proceed with Jenkins migration work but we probably want to wait > until I'm back available before we actually migrate anything. > > * If you think you can handle e.g. Jenkins master migration entirely, we > just need to make sure someone @redhat.com will request and manage the > DNS change. > > * Dave offered to work on the Mailman migration plan so we can execute > that as soon as I'm back available. > > Thanks - Karsten > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
repo request process (was: Re: JRS CE rpm gerrtit project.)
On Mon, 2013-01-14 at 14:37 -0500, Eyal Edri wrote: > > - Original Message - > > From: "Karsten 'quaid' Wade" > > To: infra@ovirt.org > > Sent: Monday, January 14, 2013 8:45:32 PM > > Subject: Re: JRS CE rpm gerrtit project. > > > > On 01/14/2013 07:43 AM, Itamar Heim wrote: > > > On 01/14/2013 04:17 PM, Dave Neary wrote: > > >> Hi, > > >> > > >> On 12/20/2012 04:09 PM, Yaniv Dary wrote: > > >>> Hi, > > >>> I need to create a new oVirt project for the JRS CE rpm for > > >>> ovirt-reports. > > >>> I will put a make and spec for this package there. The rpm is > > >>> just for > > >>> packing their binaries sice they don't have rpm packaging. > > >>> Project name 'jasperreports-server-rpm'. > > >>> Can you create it please? > > >> > > >> Where do you need the project created, exactly, please? On Gerrit? > > >> In > > >> Bugzilla? On the wiki? For the wiki/website, you can add the > > >> details for > > >> the project yourself. If you need new mailing lists, then please > > >> specify > > >> the list name and description. > > >> > > >> Thanks! > > >> Dave. > > >> > > > > > > i don't think it needs a separate mailing list. > > > hopefully bugzilla wise can be with ovirt-reports. > > > +1 for creating a repo, will give a couple of days for others to > > > comment > > > before creating one. > > > > Side topic - are we happy with this process for requesting repos? > > I.e., > > sending email to the list vs. filing an infrastructure ticket in > > Trac. > > i think opening a ticket in trac + reason for repo is better. > as long as we'll receive an email on it to infra@ovirt.org. +1 on ticket if we can get emails to work correctly. In the past, I've moderated the emails that I've seen come in, but there was no option to allow all mails from trac to go through. If we get that solved, then tickets are definitely better. Mike > > > > > - Karsten > > -- > > Karsten 'quaid' Wade, Sr. Analyst - Community Growth > > http://TheOpenSourceWay.org .^\ http://community.redhat.com > > @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 > > > > > > ___ > > Infra mailing list > > Infra@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Kick-off meeting for new RackSpace-based hosts
On Thu, 2013-01-03 at 16:14 -0500, Eyal Edri wrote: > > - Original Message - > > From: "Karsten 'quaid' Wade" > > To: "infra" > > Sent: Thursday, January 3, 2013 9:02:56 PM > > Subject: Kick-off meeting for new RackSpace-based hosts > > > > We've got the agreement setup to use some new hosts at RackSpace, as > > provided by Red Hat IT. In order to start, RackSpace has a setup call > > where the points-of-contact (POCs) on our side meet the POCs on their > > side. We discuss escalation methods, ACLs, config details, etc. > > > > Anyone from oVirt Infra who may be involved in running those hosts is > > welcome to attend. We're trying to do this right away so we can start > > using the service. I've suggested either 9 or 11 am EST this coming > > Monday - just before or just after our weekly Infra meeting. > > > > Eedri - are you available at one of those times? I figure it's a 30 > > min > > call. > > Yes. please send me the call details when you have them. > I believe those servers can be used for: > 1. one or more server to be used as hypervisor to run jenkins slave vm with > multiple os's > 2. one physical server to be used for automatic testing of ovirt (adding > host,etc...) What about backups? Can we host that somewhere there? or do we have somewhere else for storing backups? Mike > > at least that i had in mind for now. > > thanks, > > Eyal. > > > > > Anyone else interested or I should reach out to? > > > > Thanks - Karsten > > -- > > Karsten 'quaid' Wade, Sr. Analyst - Community Growth > > http://TheOpenSourceWay.org .^\ http://community.redhat.com > > @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 > > > > > > ___ > > Infra mailing list > > Infra@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Wiki update help needed
On Thu, 2012-12-13 at 02:22 -0500, Vered Volansky wrote: > Hi, > > I'm updating the node wiki ( http://www.ovirt.org/Category:Node ) with the > actual current release, which is oVirt Node 2.5.5-0.1. > There was a link there to the package's tar: > http://ovirt.org/releases/stable/src/ovirt-node-2.5.1.tar.gz, only I need the > equivalent of it for 2.5.5, which is not under the same folder. > > Can someone put the tar there, or give me a good link? > Uploaded the 2.5.5 tarball. Mike > Thanks, > Vered > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Request power-user status for mom project in jenkins
On Tue, 2012-12-11 at 20:58 +0200, Dan Kenigsberg wrote: > On Tue, Dec 11, 2012 at 11:24:07AM -0500, Eyal Edri wrote: > > [adding engine-devel] > > > > usually there is an official vote on each new power user for jenkins, > > and as long as there are no objections it is approved. > > > > since i know you're a mom maintainer and familiar with jenkins, i vote +1. > > I trust Adam (who is mom's maintainer), and trust that he is capable of > becoming familiar with jenkins without causing pain to other users. > > +1 +1 > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: To /wiki or not to /wiki
On Wed, 2012-11-14 at 08:41 -0800, Karsten 'quaid' Wade wrote: > On 11/14/2012 08:33 AM, Vinzenz Feenstra wrote: > > Hi, > > > > What about using .htaccess or URL rewrite for solving this? > > Thanks, yes, that is the way we handle the change technically. With > OpenShift we'll use a .htaccess file. > > The question here is more of "should we make that change". > > Currently, the wiki follows the MediaWiki recommended format of having > /wiki in the URL. I'd drop /wiki completely if technically possible and if not, then use something like /ovirt or /o Mike > > - Karsten > > > regards, > > > > On 11/14/2012 05:18 PM, Karsten 'quaid' Wade wrote: > >> This is the best place for this discussion ... sort of.[1] > >> > >> This topic is slightly complex, I'll sort things here in to some > >> sections to help. > >> > >> == Background == > >> > >> With MediaWiki serving www.ovirt.org, that means we will be redirecting > >> away from (and no longer using) wiki.ovirt.org. > >> > >> MW is going to provide the top-level pages, and standard MW > >> configuration is to have everything appear after /wiki. It is not > >> impossible to change this, but it has 3 main caveats: > >> > >> 1. Some stuff is going to be a bit harder - we have to resolve > >> robots.txt and favicon.ico as not wiki articles, for example.[2] > >> > >> 2. We may get occasional bugs that people who use /wiki won't get. > >> > >> 3. mediawiki.org says, "this is not supported by the MediaWiki > >> developers. So if your scheme doesn't work with a new MediaWiki version, > >> you're on your own." > >> > >> Relevant sources: > >> > >> http://www.mediawiki.org/wiki/Manual:Wiki_in_site_root_directory > >> http://www.mediawiki.org/wiki/Manual:Short_URL/Apache > >> > >> == Options == > >> > >> A. All site URLs are in the form of http://ovirt.org/wiki/Page_name > >> > >> B. All site URLs are in the form of http://ovirt.org/w/Page_name > >> > >> C. All site URLs are in the form of http://ovirt.org/Page_name > >> > >> == My opinion == > >> > >> I like option C - I want to see clean URLs that hide implementation > >> details. > >> > >> My opinion on those concerns about upstream: that's open source. It's > >> hard to do anything without having problems unique or rare due to your > >> circumstances, getting bugs that others don't see who follow the > >> out-of-the-box installation, and to wonder if you won't be able to get > >> community support for the unusual configuration. > >> > >> As it happens, we've been running MediaWiki for the last year using the > >> EPEL RPM -- which is not supported by the MediaWiki developers. When I > >> went last Fall looking for help with something, #mediawiki told me to > >> get rid of the RPM and use the ZIP instead, then come back for help. > >> (The package maintainer (smooge) has been helpful in all cases instead, > >> so I've been able to avoid having to go to the upstream developers for > >> help again.) > >> > >> We have no guarantee that MediaWiki developers will support the > >> OpenShift quickstart. It also does not use the ZIP out-of-the-box > >> install, so it likely is unsupported. > >> > >> My conclusion here is, personally, I have to not care that we're going > >> to be unsupported, since being supported is actually worse. (I'd rather > >> run unsupported with a good RPM than supported with an unsigned ZIP.) > >> > >> Links from anywhere in the site that point to "the wiki" should point to > >> a landing page e.g. [[OVirt wiki]] that organizes the pages on the wiki, > >> exposing popular categories, etc. Thus, "the wiki" is not identified by > >> a specific URL, it is identified by the type of content on the page - is > >> it intended to be community documentation (a wiki) by it's category. > >> > >> == Footnotes == > >> > >> [1] I want to acknowledge as we start that part of Garrett's expertise > >> that he brings to oVirt is the human-computer interface skillset. That > >> may not be a skill that many others of us on this list have. Are there > >> some folks in the rest of oVirt development we can invite to this > >> discussion? UI or UX folks, for example? > >> > >> The reason why this matters is we want to separate our geeky-preferences > >> from the way things tend to work best for a broad range of humans. For > >> example, I love sub-domains, they work well for my brain - I'm so much > >> happier with lists.ovirt.org/mailman/... than www.ovirt.org/mailman... > >> But if Garrett told me that is not the best way to present the > >> information for a wide audience, I would have to give that opinion high > >> credence. Heck, I'm prepared to do some pretzel twists to make it > >> happen, based on that. (I've also always secretly loathed that MediaWiki > >> has the /wiki requirement.) > >> > >> [2] I suspect we can special-case them in the .htaccess file. > >> > >> > >> > >> ___ > >> Infra mailing list > >> Infra@ovirt.org > >> http://lists.ovirt.org/mailman/listi
Re: Wiki and Mailing Lists Outage -- 2012-11-14
On Wed, 2012-11-14 at 08:45 -0500, Doron Fediuck wrote: > Thanks Mike! > I suggest to have a cron alerting for no-space issues. We run logwatch which is supposed to highlight these issues, but I suspect that no one is actually reading the logwatch report. A separate cron job or monitoring service is also a possibility. Mike > > - Original Message - > > From: "Mike Burns" > > To: "board" , "infra" , "users" > > > > Sent: Wednesday, November 14, 2012 3:31:11 PM > > Subject: Wiki and Mailing Lists Outage -- 2012-11-14 > > > > We experienced an outage today in both the wiki and the mailing > > lists. > > > > * Wiki content was available throughout the outage, but attempts to > > login or edit received an error message about requiring cookies to be > > enabled. > > * All mails to the mailing list failed to show up on the lists, but > > also did not return rejection messages. > > > > Cause: > > > > This was caused by an "Out of Space" error on the host running both > > of > > these services. A temporary workaround was put in place to get both > > services up and running again. > > > > > > Action Taken: > > > > Remove the oldest gerrit backup (600MB) > > Remove some older non-functional ovirt-node-iso images and rpms from > > the > > releases (source remains there) > > > > Long term solution: > > > > Migrating these services away from a single host onto hosted > > solutions > > (OpenShift, AlterWay). > > > > Current Situation: > > > > Wiki is back up and running, login works as expected > > Lists are processing the backlog of emails since the outage began. > > At this time, it does not appear that any mail was lost due to the > > outage. > > > > > > Thanks for the patience and understanding > > > > Mike > > > > ___ > > Infra mailing list > > Infra@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > ___ > Board mailing list > bo...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/board ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: New ovirt-engine release (3.1.0-4) to fix bug 869457?
On Mon, 2012-11-12 at 12:35 +0100, Juan Hernandez wrote: > Hello, > > I would like to do a new minor release of ovirt-engine 3.1 in order to > fix bug 869457. > > The new release should include the following changes: > > packaging: Updated allinone plugin for new security mode > http://gerrit.ovirt.org/9146 > (cherry picked from commit c833bba55a19b2e2383d532b87c363a7895a8927) > > packaging: Minor bugfix release 3.1.0-4 > http://gerrit.ovirt.org/9147 > > Any objection? > > Assuming there is no objection who is responsible for doing the build > once the patches are merged? Who is responsible for uploading the new > RPMs to ovirt.org? Who is responsible for announcing the new release? Generally, each component has someone who does the builds. I believe it's generally Moran or Ofer for engine. Posting of the build is generally done by Ofer, but we have a couple other people who can do that as well. As for announcing, that's probably Ofer as well. What about QE for the new build? Is there going to be any testing of it prior to posting? Mike > > Regards, > Juan Hernandez > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Wiki and Mailing Lists Outage -- 2012-11-14
We experienced an outage today in both the wiki and the mailing lists. * Wiki content was available throughout the outage, but attempts to login or edit received an error message about requiring cookies to be enabled. * All mails to the mailing list failed to show up on the lists, but also did not return rejection messages. Cause: This was caused by an "Out of Space" error on the host running both of these services. A temporary workaround was put in place to get both services up and running again. Action Taken: Remove the oldest gerrit backup (600MB) Remove some older non-functional ovirt-node-iso images and rpms from the releases (source remains there) Long term solution: Migrating these services away from a single host onto hosted solutions (OpenShift, AlterWay). Current Situation: Wiki is back up and running, login works as expected Lists are processing the backlog of emails since the outage began. At this time, it does not appear that any mail was lost due to the outage. Thanks for the patience and understanding Mike ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: oVirtWiki uses cookies to log in users. You have cookies disabled. Please enable them and try again.
On Wed, 2012-11-14 at 03:47 -0500, Doron Fediuck wrote: > Something's wrong with the wiki, see $SUBJECT. > > I never had this issue before, so I checked Firefox settings just to be sure. > Nothing is blocking the cookies (I actually had the wiki's cookies, so I > removed and > retried, still no luck). Moving on to Chrome, I'm getting the same issue. > > Can someone please take a look? This was caused by an out of space error on the host running the wiki (and coincidentally, the host running mailing lists). The issue has been corrected and both are working now. Mike > > Thanks! > Doron > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Fwd: Re: [ovirt] #8: Automate git push of all repos to github.com
On Mon, 2012-10-29 at 16:55 +0100, Ewoud Kohl van Wijngaarden wrote: > On Sun, Oct 28, 2012 at 01:52:17PM -0700, Karsten 'quaid' Wade wrote: > > Those interested in mirroring of git repos on github.com, can you > > check/confirm things look fine? > > > > I don't think I've added other Infra team members as admins/managers on > > Trac? Remind me to do that ... > > I think we should remove https://github.com/oVirt/ovirt-node and rename > https://github.com/oVirt/Node. The latter already has forks while the > former doesn't (but isn't synced). Agreed, we should only have one and I'd prefer that it be Node since that was pre-existing and people are using it. Itamar, can we do the sync without names matching exactly? /me will keep Node up to date manually for now. Mike > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Draft of presentation for Barcelona
On Mon, 2012-11-05 at 16:16 -0800, Karsten 'quaid' Wade wrote: > On 11/04/2012 04:57 PM, Ewoud Kohl van Wijngaarden wrote: > > On Thu, Nov 01, 2012 at 10:47:41PM -0400, Mike Burns wrote: > >> I've posted a draft of the presentation for Barcelona [1]. I'd > >> appreciate it if you could give feedback to me in the next couple > >> days. > > My employer sponsors a jenkins build server, though we never formally > > finished this with a mention on the website and a proper hostname. Also > > I should fix ipv6 on it. But jenkins.ekohl.nl is donated by Oxilion. > > Definitely include that in the presentation. > > Would you like us to formally propose Oxilion as a sponsor? We can take > it to the Board similar to what we did for Alter Way. > Thanks guys, I'll try to incorporate these suggestions into the presentation. Mike > - Karsten > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Draft of presentation for Barcelona
Hey all, I've posted a draft of the presentation for Barcelona [1]. I'd appreciate it if you could give feedback to me in the next couple days. Thanks Mike [1] http://wiki.ovirt.org/w/images/e/eb/Ovirt-infrastructure-2012-11-09.pdf ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Reminder & agenda :: oVirt Infra weekly team sync :: 2012-10-15 1500 UTC
On Mon, 2012-10-15 at 16:24 +0200, Dave Neary wrote: > Hi, > > In the "Future developments", it would be good to talk about the move to > OpenShift for some services and AlterWay's oVirt based hosting for > others. I'm happy to give you more details about this. ACK, will definitely include this. > > Also, I think the key transition in the past 6 months has been to a > community-oriented infra team which Karsten has led - some of the > challenges we've had (and still have) are how to expose enough of the > infrastructure for someone to prove themselves, then allowing people a > sand-box to prove themselves further, and finally growing a community > team to handle project infrastructure. > Yes, would definitely talk about this in a recent improvements > Another interesting story I think people will be interested in is the > way we have been working on the website, publicly seeking comments, > developing a theme in the open (on GitHub, even), and are now deploying > the new site to OpenShift. Garrett's done a great job on this. Excellent thought. > > Cheers, > Dave. > > > > On 10/15/2012 01:39 PM, Mike Burns wrote: > > On Mon, 2012-10-15 at 04:09 -0400, Karsten Wade wrote: > >> Reminder that the NEW meeting time is upon us ... Monday 1500 UTC: > >> > >> date -d 'MONDAY 1100 EDT' > >> > >> If you have anything to add to the agenda, please edit the wiki and/or > >> email back here; > >> > >> == 2012-10-15 == > >> > >> ''Agenda'' > >> * MediaWiki & www > >> * Hosting > >> * Trac review > >> * Puppet > >> * Jenkings > >> * Gerrit > >> > > * Infra presentation at oVirt Workshop -- Barcelona > > > > I'm currently on the hook to give this presentation. I haven't started > > it yet, but my abstract is below. Any ideas/suggestions on things I > > should include/cover/concentrate on/gloss over? > > > > Thanks > > > > Mike > > > > > > > > oVirt Infrastructure Overview > > > > > > An overview of the various infrastructure tools and services available > > in the ovirt.org domain. We’ll discuss various aspects from how > > different tools are leveraged with a heavy focus on the use of Jenkins > > for build and test automation, Gerrit for source code management, and > > Puppet for configuring the various servers for different uses. We’ll > > also discuss how we grew the infrastructure from a just a couple of EC2 > > hosts to where we are today, to where we’re planning to go in the > > future. > > > > This is primarily geared toward people interested in how we go about > > managing and coordinating the various pieces of infrastructure in the > > oVirt site. It will range from high level discussion of what we're > > trying to accomplish to diving into some of the technical details. I'd > > like this talk to be very interactive, but will be prepared to present > > in the event there aren't a lot of questions. > > > > ___ > > Infra mailing list > > Infra@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Reminder & agenda :: oVirt Infra weekly team sync :: 2012-10-15 1500 UTC
On Mon, 2012-10-15 at 04:09 -0400, Karsten Wade wrote: > Reminder that the NEW meeting time is upon us ... Monday 1500 UTC: > > date -d 'MONDAY 1100 EDT' > > If you have anything to add to the agenda, please edit the wiki and/or email > back here; > > == 2012-10-15 == > > ''Agenda'' > * MediaWiki & www > * Hosting > * Trac review > * Puppet > * Jenkings > * Gerrit > * Infra presentation at oVirt Workshop -- Barcelona I'm currently on the hook to give this presentation. I haven't started it yet, but my abstract is below. Any ideas/suggestions on things I should include/cover/concentrate on/gloss over? Thanks Mike oVirt Infrastructure Overview An overview of the various infrastructure tools and services available in the ovirt.org domain. We’ll discuss various aspects from how different tools are leveraged with a heavy focus on the use of Jenkins for build and test automation, Gerrit for source code management, and Puppet for configuring the various servers for different uses. We’ll also discuss how we grew the infrastructure from a just a couple of EC2 hosts to where we are today, to where we’re planning to go in the future. This is primarily geared toward people interested in how we go about managing and coordinating the various pieces of infrastructure in the oVirt site. It will range from high level discussion of what we're trying to accomplish to diving into some of the technical details. I'd like this talk to be very interactive, but will be prepared to present in the event there aren't a lot of questions. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Wiki issue: Installing VDSM from rpm
On Wed, 2012-10-10 at 16:08 +0200, Ewoud Kohl van Wijngaarden wrote: > On Wed, Oct 10, 2012 at 09:45:44AM -0400, Mike Burns wrote: > > On Wed, 2012-10-10 at 09:29 -0400, Vered Volansky wrote: > > > The above wiki( http://wiki.ovirt.org/wiki/Installing_VDSM_from_rpm ) has > > > the following instruction: > > > wget http://www.ovirt.org/releases/nightly/fedora/16/ovirt-engine.repo -P > > > /etc/yum.repos.d/ > > > > > > 1. Need to change to the actual fedora 17 url. > > > 2. The updated url hasn't got ovirt-engine.repo in it. > > > > You can get vdsm directly from Fedora, yes. You can also get it from > > the ovirt.org repos. The .repo file no longer exists, but there is an > > ovirt-release rpm available. I've updated the wiki to reflect that. > > I think we should remove empty directories from the release overview and > the ovirt-release-*.rpm from the root. Those can only confuse the user. What directories are empty? I don't see any empty directories. As for the ovirt-release rpms, we intentionally put them in the top level so they're easy to access. Mike > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Wiki issue: Installing VDSM from rpm
On Wed, 2012-10-10 at 09:29 -0400, Vered Volansky wrote: > The above wiki( http://wiki.ovirt.org/wiki/Installing_VDSM_from_rpm ) has the > following instruction: > wget http://www.ovirt.org/releases/nightly/fedora/16/ovirt-engine.repo -P > /etc/yum.repos.d/ > > 1. Need to change to the actual fedora 17 url. > 2. The updated url hasn't got ovirt-engine.repo in it. You can get vdsm directly from Fedora, yes. You can also get it from the ovirt.org repos. The .repo file no longer exists, but there is an ovirt-release rpm available. I've updated the wiki to reflect that. Thanks for pointing this out. Mike > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: New meeting time proposal: 1500 UTC Monday [RFC]
On Tue, 2012-10-09 at 08:20 -0700, Karsten 'quaid' Wade wrote: > Based on the results I've received so far: > > http://whenisgood.net/nn5k2ww/results/y85zxa > > It looks as if 1500 UTC on Monday is the best time to meet. We can't get > Mike Burns at that time, but he isn't directly responsible for any of > the Infra team services - perhaps the minutes will suffice. > > For this new time - +1 or -1 ? The minutes should be fine. I'll attend when I can, and I'm usually on IRC so can be pinged directly if needed even when on another call. > > Thx - Karsten > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Release machinery for new oVirt project: MOM
On Wed, 2012-10-03 at 11:06 -0500, Adam Litke wrote: > Hi all, > > I am the maintainer of the MOM project which is a relatively recent addition > to > the oVirt family. I am looking for some information on how I can get MOM > tarballs to appear in www.ovirt.org/releases and what steps I need to take to > release official versions of MOM as part of oVirt releases (and standalone > releases as a base for the upstream Fedora package). Thanks in advance for > helping me with this! > The builds in releases/nightly are pulled from jenkins each night. So the process would be to get MOM builds configured in jenkins to get them into nightly. For the official releases, 3.1, 3.2, etc., You would coordinate the versions with the release manager (Ofer, cc'ed). He'll ensure that versions and rpms are uploaded correctly. Mike ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Meeting time adjustment
On Tue, 2012-10-02 at 07:48 -0700, Karsten 'quaid' Wade wrote: > For various reasons, the current Infra team meeting time doesn't seem to > be workable. I think there is general agreement on this, and that we > need a new meeting time. > > I created a mapping of the times I'm available, and you can paint in > your options here: > > http://whenisgood.net/nn5k2ww > > I suspect we're still looking for a narrow 2-hour window across the > first four days of the week. Just a note: 9:00 AM US Eastern is not an option. oVirt Node has their weekly on IRC at that time, so we'd have contention for the IRC channel. Mike > > - Karsten > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: the new oVirt website: live preview!
On Thu, 2012-09-20 at 21:30 +0800, Daniel Veillard wrote:
> On Thu, Sep 20, 2012 at 02:27:28PM +0200, Garrett LeSage wrote:
> > On 09/20/2012 08:17 AM, Daniel Veillard wrote:
>
> > > The vertical spacing between 2 paragraphs or bulleted items looks a
> > >tad bit too large to my eye compared to the spacing between lines.
> >
> > I adjusted the spacing so that the line rhythm was maintained on the
> > page. It's especially needed on pages like:
> >
> > http://mediawiki-garrett.rhcloud.com/OVirt_3.1_release_notes
> > (Which is a copy/paste of the wiki text from the official oVirt wiki.)
> >
> > I will probably tweak the fonts and text a bit further, especially
> > when we have another reskinned instance of MediaWiki (containing all
> > of the content from wiki.ovirt.org) up and running.
>
> okay, well it's use one person feedback and i don't claim any
> UI sense :-) but again the space left between the last bullet of
> Installer section and the title of the Tools session looks quite large to
> my eye (I can put a finger between the bottom of the '(' and the top of
> the T here), vertical space is scarce especially on new screens :-\
>
> >
> > > The top page and the Download page don't even tell what licence
> > >is applicable, IMHO that crucial information should be presented to
> > >the user between the time it hits the home page and the time he's told
> > >how to install it on Fedora 17.
> >
> > That's a great point.
> >
> > Is it enough to mention "ASL2.0" in the footer and link to a
> > licensing page, like the current oVirt.org website does? Or should
> > we say more?
>
> Saying it's OpenSource under "ASL2.0" with a link is sufficient sure !
>
> thanks Garrett :-)
>
> Daniel
See other part of this thread -- we have projects in oVirt that are
*not* ASL 2.0. ovirt-node is GPL2 and content on the site and wiki are
something else as well, iirc.
Mike
>
>
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
Re: [Engine-devel] No disk space in gerrit server?
On Fri, 2012-09-07 at 19:29 +0300, Itamar Heim wrote:
> On 09/07/2012 06:03 PM, Selvasundaram wrote:
> > The following error seems to be no disk space in gerrit server.
> >
> > Counting objects: 62, done.
> > Delta compression using up to 4 threads.
> > Compressing objects: 100% (23/23), done.
> > Writing objects: 100% (38/38), 9.28 KiB, done.
> > Total 38 (delta 9), reused 0 (delta 0)
> > error: unpack failed: error No space left on device
> > fatal: Unpack error, check server log
> > To gerrit.ovirt.org:ovirt-engine
> > ! [remote rejected] HEAD -> refs/for/master (n/a (unpacker error))
> > error: failed to push some refs to 'gerrit.ovirt.org:ovirt-engine'
> >
> >
> > --
> > Regards
> > Selvasundaram
> > ___
> > Engine-devel mailing list
> > engine-de...@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
>
> fixed.
> moving to infra
> anyone can take a stab at the backup process to do some cycling of this
> folder /home/gerrit2/backups/gerrit2-home?
I've used something like this before:
find /path/to/backup/directory -name 'backup_prefix*' -a -mtime +7 -exec
rm {} \;
This will wipe all backups older than 7 days.
Mike
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
Re: [DRAFT] Outage :: No disk space :: 2012-08-30
- Original Message - > Hi: > > I didn't really participate in this outage, so I thought others could > help us draft up notes about it. I put some barebones below. > > One outcome we need to look at is, what do people do when they > perceive > services are out? > > Of course, if the service is the wiki, they can't check that for what > to > do ... > > How do we communicate when major communication services of ovirt.org > are > down? IRC is great but not enough ... If we can arrange for a > reliable > third-party mail relay to alias a page to the Infra team, great, but > how > do we keep it from getting spam? > > Another angle to resolve is service monitoring so we know when things > go > out rather than waiting for service users to tell us. I got some > direct > emails from people (since the infra@ list wasn't working), but I was > unavailable and unaware of the problem until Robert called me when he > was working on fixing it. I don't mind getting pager alerts, as long > as > we can tune things so they are not crazy often. :) I think we should have multiple places that we notify. 1. IRC 2. wiki page 3. infra list 4. someplace on wordpress (preferably the main page). This should be sufficient long term (i.e. once we have a better hosting solution than just the kitchen sink box. I agree with getting service monitoring set up as well. We can even accomplish this to a certain extent with jenkins (and a separate non-jenkins cron job to monitor jenkins). Mike > > == What occurred == > > Even the doubled disk space on linode01.ovirt.ort (to 25 GB) wasn't > enough to last long. > > > == When == > > ? > > date -d "2012-08-30 UTC" > > == Affected services == > > lists.ovirt.org > wiki.ovirt.org > ovirt.org/.* > ovirtbot > Gerritt backup > Jenkins backup > [[What else?]] > > == Responses to take == > > * Get new hosting solution in place. > * Double current disk space before new hosting move, to give us room > to > breath. > * Work up a response place that is posted in the IRC topic or > somewhere > good so people know how to contact all of the Infra team when > something > is happening. > * New service need: monitoring server > > > -- > Karsten 'quaid' Wade, Sr. Analyst - Community Growth > http://TheOpenSourceWay.org .^\ http://community.redhat.com > @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 > > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Task tracker
- Original Message - > > > - Original Message - > > From: "Karsten (quaid) Wade" > > To: "infra" > > Sent: Friday, August 31, 2012 11:34:00 PM > > Subject: Task tracker > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Speak up if you disagree, but we could sure use a task tracker for > > the > > Infra team. > > > > seems like the best option for now, we're using Trac & Redmine mostly > in rhevm. > > and since this trac instance is up and running, i don't see a reason > why not to start using it. > > seems like trac supports import/export of tickets [1] so it > shouldn't be a problem to migrate in the future > to a different tracker. > > +1 > > [1] http://trac.edgewall.org/wiki/TracImport +1 on using this at least to start. Not ideal, given that it's not ovirt.org domain, but working right now wins in my book. We should keep our eyes/ears open for other solutions though. Side comment, if we want to deploy our own, it could be a good POC for someone looking to join the infra team. > > > One idea Mike suggested is, this Trac instance is gathering dust > > and > > available to take over (and re-customize): > > > > https://fedorahosted.org/ovirt > > > > We could start using this immediately, and switch in the future. It > > is > > Trac, I've had varied experience with it; I know how to admin it > > fairly well, and we can customize it to this team with minimal > > effort. > > (Nice to not have to invest too much in making a workflow.) My > > biggest > > concern right now would be running at a larger scale - what happens > > over time? What happens if other project teams want an integrated > > task > > tracker? (The latter would make project management and getting an > > organized release out the door easier.) > > > > I looked around at the current state of FOSS tools that are offered > > as > > a service, and didn't get too excited. > > > > http://www.hostedredmine.com/ > > https://ovirt-infra.teamlab.com > > > > I've also looked at teambox.com in the past, but their no-cost > > services are limited. (They also haven't released any timeline or > > roadmap about open sourcing the latest version, the older versions > > are > > FOSS; I haven't looked at what it would take to run the service > > ourselves.) > > > > There are several services that are FOSS and we could run > > ourselves, > > such as the above Trac and Redmine. > > > > I strongly urge us to avoid using services that are not FOSS. There > > are many competitive ones in the proprietary markets, and a few > > offer > > no-cost usage for open source projects. I get concerned about > > locking > > our data and workflows in to a particular vendor. I would rather > > pick > > the best-of FOSS and be a strong user to support more development > > on > > our choice. Unfortunately, this does limit our choices in what is > > offered as a service. +1000 > > > > - - Karsten > > - -- > > 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/ > > > > iD8DBQFQQR+42ZIOBq0ODEERArIbAKCN/uF+rlc9oH7tq4JoGtiDVeeCCQCgtGbW > > yJUUOowWAbcH1Z1K8LnLkFs= > > =/muc > > -END PGP SIGNATURE- > > ___ > > Infra mailing list > > Infra@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: vdsm hooks pages at ovirt.org
On Mon, 2012-08-20 at 09:38 -0400, Dan Yasny wrote: > > - Original Message - > > From: "Mike Burns" > > To: "Dan Yasny" > > Cc: infra@ovirt.org > > Sent: Monday, 20 August, 2012 4:32:01 PM > > Subject: Re: vdsm hooks pages at ovirt.org > > > > On Mon, 2012-08-20 at 08:59 -0400, Dan Yasny wrote: > > > > > > - Original Message - > > > > From: "Mike Burns" > > > > To: "Dan Yasny" > > > > Cc: infra@ovirt.org > > > > Sent: Monday, 20 August, 2012 3:32:50 PM > > > > Subject: Re: vdsm hooks pages at ovirt.org > > > > > > > > On Mon, 2012-08-20 at 08:23 -0400, Dan Yasny wrote: > > > > > > > > > > - Original Message - > > > > > > From: "Mike Burns" > > > > > > To: "Dan Yasny" > > > > > > Cc: infra@ovirt.org > > > > > > Sent: Monday, 20 August, 2012 3:19:29 PM > > > > > > Subject: Re: vdsm hooks pages at ovirt.org > > > > > > > > > > > > On Mon, 2012-08-20 at 07:03 -0400, Dan Yasny wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > I am working on a project to make the existing vdsm hooks > > > > > > > more > > > > > > > accessible and available. > > > > > > > > > > > > > > So in very short, for those who do not know, a vdsm hook is > > > > > > > a > > > > > > > script > > > > > > > that can be placed on ovirt hosts, and which will do some > > > > > > > custom > > > > > > > actions, vdsm cannot do out of the box. > > > > > > > > > > > > > > We have quite a few already in the repositories at > > > > > > > > > > > > http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=tree;f=vdsm_hooks;h=6f33db4079b250336fa1369771a63dce585e1d81;hb=HEAD > > > > > > > and the vdsm engineers are starting to turn these into > > > > > > > proper > > > > > > > RPMs > > > > > > > and push them into fedora, and then EPEL repos, however, > > > > > > > for > > > > > > > these > > > > > > > to be consumable, we also will need a description page for > > > > > > > each > > > > > > > hook, somewhere under ovirt.org/hooks or hooks.ovirt.org, > > > > > > > where > > > > > > > every hook can be downloaded, and have a description, > > > > > > > version > > > > > > > compatibility and a use case described. > > > > > > > > > > > > > > If you use gnome-shell, it would be something like > > > > > > > extensions.gnome.org, but of course, not quite the same, as > > > > > > > we > > > > > tend > > > > > > > to > > > > > > > a different kind of user. > > > > > > > > > > > > > > I would like to find out what will be required to do this, > > > > > > > as > > > > > > > soon > > > > > > > as > > > > > > > possible > > > > > > > > > > > > Cool stuff. > > > > > > > > > > > > Creating ovirt.org/hooks is pretty easy, hooks.ovirt.org is > > > > > > slightly > > > > > > more complex (but doable). > > > > > > > > > > /hooks is good enough for me, as long as it's easy to find and > > > > > manage > > > > > > > > ok, that will keep it within the current wordpress instance then, > > > > rather > > > > than something outside it. > > > > > > > > We can probably setup a separate redirect so that hooks.ovirt.org > > > > --> > > > > ovirt.org/hooks. > > > > > > > > > > works for me, when can we have it up and ready to be populated? > > > > Karsten? ^^ > > > > > > > > > > > > > > > > > > > > > > The big questions: > > > > > > * Who is doing the original design and content seeding? > > > > > > > > > > Myself, b
Re: vdsm hooks pages at ovirt.org
On Mon, 2012-08-20 at 08:59 -0400, Dan Yasny wrote: > > - Original Message - > > From: "Mike Burns" > > To: "Dan Yasny" > > Cc: infra@ovirt.org > > Sent: Monday, 20 August, 2012 3:32:50 PM > > Subject: Re: vdsm hooks pages at ovirt.org > > > > On Mon, 2012-08-20 at 08:23 -0400, Dan Yasny wrote: > > > > > > - Original Message - > > > > From: "Mike Burns" > > > > To: "Dan Yasny" > > > > Cc: infra@ovirt.org > > > > Sent: Monday, 20 August, 2012 3:19:29 PM > > > > Subject: Re: vdsm hooks pages at ovirt.org > > > > > > > > On Mon, 2012-08-20 at 07:03 -0400, Dan Yasny wrote: > > > > > Hi all, > > > > > > > > > > I am working on a project to make the existing vdsm hooks more > > > > > accessible and available. > > > > > > > > > > So in very short, for those who do not know, a vdsm hook is a > > > > > script > > > > > that can be placed on ovirt hosts, and which will do some > > > > > custom > > > > > actions, vdsm cannot do out of the box. > > > > > > > > > > We have quite a few already in the repositories at > > > > > > > > http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=tree;f=vdsm_hooks;h=6f33db4079b250336fa1369771a63dce585e1d81;hb=HEAD > > > > > and the vdsm engineers are starting to turn these into proper > > > > > RPMs > > > > > and push them into fedora, and then EPEL repos, however, for > > > > > these > > > > > to be consumable, we also will need a description page for each > > > > > hook, somewhere under ovirt.org/hooks or hooks.ovirt.org, where > > > > > every hook can be downloaded, and have a description, version > > > > > compatibility and a use case described. > > > > > > > > > > If you use gnome-shell, it would be something like > > > > > extensions.gnome.org, but of course, not quite the same, as we > > > tend > > > > > to > > > > > a different kind of user. > > > > > > > > > > I would like to find out what will be required to do this, as > > > > > soon > > > > > as > > > > > possible > > > > > > > > Cool stuff. > > > > > > > > Creating ovirt.org/hooks is pretty easy, hooks.ovirt.org is > > > > slightly > > > > more complex (but doable). > > > > > > /hooks is good enough for me, as long as it's easy to find and > > > manage > > > > ok, that will keep it within the current wordpress instance then, > > rather > > than something outside it. > > > > We can probably setup a separate redirect so that hooks.ovirt.org --> > > ovirt.org/hooks. > > > > works for me, when can we have it up and ready to be populated? Karsten? ^^ > > > > > > > > > > > > The big questions: > > > > * Who is doing the original design and content seeding? > > > > > > Myself, basing on the READMEs Shahar and other added to the hooks > > > > > > > * Who will own keeping things up to date going forward? > > > > > > We'll need a maintainer of course, depending on the amount of load, > > > initially that will probably be me, but ultimately - someone > > > dealing > > > with hooks in vdsm devel, or someone maintaining the rest of the > > > website > > > > It will probably need to be a combination. Website maintainers won't > > necessarily know the correct content to update, but having the > > content > > provided by developers and then updated would probably work. > > Perfect, that's what I meant > > > > > > > > > > > > > > It might make sense to initially put the content you want on a > > > > wiki > > > > page, and then transition it to a static page long term. > > > > > > I'd rather take it directly to a separate page - there's nothing > > > more > > > permanent than the temporary > > > > I would have proposed etherpad if that was already up and running, > > but > > it's not currently. I was purely proposing wiki as a very short term > > staging environment. > > I know, but once it's up there, the urgency gets taken away,
Re: vdsm hooks pages at ovirt.org
On Mon, 2012-08-20 at 08:23 -0400, Dan Yasny wrote: > > - Original Message - > > From: "Mike Burns" > > To: "Dan Yasny" > > Cc: infra@ovirt.org > > Sent: Monday, 20 August, 2012 3:19:29 PM > > Subject: Re: vdsm hooks pages at ovirt.org > > > > On Mon, 2012-08-20 at 07:03 -0400, Dan Yasny wrote: > > > Hi all, > > > > > > I am working on a project to make the existing vdsm hooks more > > > accessible and available. > > > > > > So in very short, for those who do not know, a vdsm hook is a > > > script > > > that can be placed on ovirt hosts, and which will do some custom > > > actions, vdsm cannot do out of the box. > > > > > > We have quite a few already in the repositories at > > > > http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=tree;f=vdsm_hooks;h=6f33db4079b250336fa1369771a63dce585e1d81;hb=HEAD > > > and the vdsm engineers are starting to turn these into proper RPMs > > > and push them into fedora, and then EPEL repos, however, for these > > > to be consumable, we also will need a description page for each > > > hook, somewhere under ovirt.org/hooks or hooks.ovirt.org, where > > > every hook can be downloaded, and have a description, version > > > compatibility and a use case described. > > > > > > If you use gnome-shell, it would be something like > > > extensions.gnome.org, but of course, not quite the same, as we > tend > > > to > > > a different kind of user. > > > > > > I would like to find out what will be required to do this, as soon > > > as > > > possible > > > > Cool stuff. > > > > Creating ovirt.org/hooks is pretty easy, hooks.ovirt.org is slightly > > more complex (but doable). > > /hooks is good enough for me, as long as it's easy to find and manage ok, that will keep it within the current wordpress instance then, rather than something outside it. We can probably setup a separate redirect so that hooks.ovirt.org --> ovirt.org/hooks. > > > > > The big questions: > > * Who is doing the original design and content seeding? > > Myself, basing on the READMEs Shahar and other added to the hooks > > > * Who will own keeping things up to date going forward? > > We'll need a maintainer of course, depending on the amount of load, > initially that will probably be me, but ultimately - someone dealing > with hooks in vdsm devel, or someone maintaining the rest of the > website It will probably need to be a combination. Website maintainers won't necessarily know the correct content to update, but having the content provided by developers and then updated would probably work. > > > > > It might make sense to initially put the content you want on a wiki > > page, and then transition it to a static page long term. > > I'd rather take it directly to a separate page - there's nothing more > permanent than the temporary I would have proposed etherpad if that was already up and running, but it's not currently. I was purely proposing wiki as a very short term staging environment. > > > > > As for the backend yum repo, that is pretty easily accomplished. We > > can > > simply have a separate area in the releases for current vdsm hooks. > > Can you elaborate please? Where will the actual RPMs be taken from? You tell me. My thought is that this will mirror the current versions in EPEL and/or Fedora. My thought is that this is considered stable. > > > I > > would assume that we'll want to keep that relatively stable and only > > update manually when new versions are released. We can also have > > something like an "unstable" repo where nightly builds of the > plugins > > are uploaded. > > That can stay with the fedora based vdsm repos, we want the real > consumables here IMO OK, our nightly build repos should suffice for this then. FWIW, this is already being done: http://ovirt.org/releases/nightly/rpm/Fedora/17/noarch/ As things get added into the vdsm git repo and spec file, they'll get auto-built nightly in jenkins and mirrored to this repository. Currently, this includes: faqemu, qemucmdline, and vhostmd. Mike > > > > > Mike > > > > > > > > Thanks, > > > Dan Yasny > > > ___ > > > Infra mailing list > > > Infra@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: vdsm hooks pages at ovirt.org
On Mon, 2012-08-20 at 07:03 -0400, Dan Yasny wrote: > Hi all, > > I am working on a project to make the existing vdsm hooks more > accessible and available. > > So in very short, for those who do not know, a vdsm hook is a script > that can be placed on ovirt hosts, and which will do some custom > actions, vdsm cannot do out of the box. > > We have quite a few already in the repositories at > http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=tree;f=vdsm_hooks;h=6f33db4079b250336fa1369771a63dce585e1d81;hb=HEAD > and the vdsm engineers are starting to turn these into proper RPMs and push > them into fedora, and then EPEL repos, however, for these to be consumable, > we also will need a description page for each hook, somewhere under > ovirt.org/hooks or hooks.ovirt.org, where every hook can be downloaded, and > have a description, version compatibility and a use case described. > > If you use gnome-shell, it would be something like > extensions.gnome.org, but of course, not quite the same, as we tend to > a different kind of user. > > I would like to find out what will be required to do this, as soon as > possible Cool stuff. Creating ovirt.org/hooks is pretty easy, hooks.ovirt.org is slightly more complex (but doable). The big questions: * Who is doing the original design and content seeding? * Who will own keeping things up to date going forward? It might make sense to initially put the content you want on a wiki page, and then transition it to a static page long term. As for the backend yum repo, that is pretty easily accomplished. We can simply have a separate area in the releases for current vdsm hooks. I would assume that we'll want to keep that relatively stable and only update manually when new versions are released. We can also have something like an "unstable" repo where nightly builds of the plugins are uploaded. Mike > > Thanks, > Dan Yasny > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: how to get files from jenkins.ovirt.org to www.ovirt.org
On Tue, 2012-07-31 at 14:02 -0400, Robert Middleswarth wrote: > On 07/31/2012 11:03 AM, Mike Burns wrote: > > On Tue, 2012-07-31 at 09:13 -0400, Robert Middleswarth wrote: > >> On 07/31/2012 08:51 AM, Eyal Edri wrote: > >>> - Original Message - > >>>> From: "Mike Burns" > >>>> To: "Eyal Edri" > >>>> Cc: "infra" > >>>> Sent: Tuesday, July 31, 2012 3:33:01 PM > >>>> Subject: Re: how to get files from jenkins.ovirt.org to www.ovirt.org > >>>> > >>>> On Tue, 2012-07-31 at 02:46 -0400, Eyal Edri wrote: > >>>>> Hi, > >>>>> > >>>>> after looking into the process and testing it via > >>>>> jenkins.ovirt.info, > >>>>> here is my proposal: > >>>>> > >>>>> 1. Nightly job [1] will collect rpms from all ovirt projects (other > >>>>> jenkins jobs that build rpms per commit). > >>>>> 1.1 all files will be kept in a flat dir under $WORKSPCE/rpms > >>>>> 1.2 using 'publish over ssh' [2] plugin the job will then copy > >>>>> files to their destination according to their names. [3] > >>>>> for e.g'ovirt-engine-3.1.0-3.fc17.noarch.rpm' ==> > >>>>> ovirt.org/var/www/html/releases/nightly/rpm/Fedora/17/noarch > >>>>> 'ovirt-engine-3.1.0-3.fc17.src.rpm' ==> > >>>>> ovirt.org/var/www/html/releases/nightly/rpm/Fedora/17/src > >>>>> 'ovirt-engine-3.1.0-3.bz2' ==> > >>>>> ovirt.org/var/www/html/releases/nightly/src' > >>>>> 1.3 publish ssh plugin can execute a command after its done > >>>>> copying > >>>>> the file, so all is left is to run 'createrepo' on the relevant > >>>>> dirs. > >>>>> [4] > >>>>> > >>>>> > >>>>> 2. a separate cron cleaning script needs to run on ovirt.org to > >>>>> delete > >>>>> old rpms and run createrepo. > >>>>> > >>>> Maybe upload to a non-published directory first, > >>>> like /home/jenkins/nightly, and have the cron job handle cleanup of > >>>> old > >>>> rpms, adding of new rpms, and running createrepo? > >>> sure, i've got not problem with that.. > >>> > >>> there is one thing i don't understand, and sorry if not an expert in yum: > >>> > >>> we say we want to keep history for X builds, will all versions be kept > >>> under one repository? > >>> so 'createrepo' will run on all versions in that directory? > >>> > >>> so running yum install file.verX will work even if the repo has a x+1 > >>> version? > >> If you look at existing repo's many of them will include old versions of > >> the package yum / create repo will simple use the latest version in the > >> repo that meets all the requirements. Example when we first moved from > >> vdsm 4.9 to 4.10 the repo's got really screwy until all the packages > >> were rebuilt. In that case the older 4.9 builds would get used until > >> all the packages were in place then the newer versions would get used. > > > > If we still want to keep multiple night's versions, then we can have the > > cron job run and create a new directory called: > > > > cd /var/www/html/releases > > mkdir nightly-$(date +%Y%m%d) > > # move all content from /home/jenkins to new nightly- directory > > ln -snf nightly-$(date +%Y%m%d) nightly > > rm -rf nightly-$(date -d "3 days ago" +%Y%m%d) > > > > Mike > Why recreate the wheel. www.hyperdrifter.com/software/tidy_rpm_cache.html > > Example usages: tidy-rpm-cache.py --dir=/tmp/packages --num-obsolete=3 Works for me... Mike > > Thanks > Robert > > > >>>> If not, how is the cron job going to cleanup old rpms? > >>>> > >>>> Uploading to a static location that isn't public (and is > >>>> under /home/jenkins) would make [3] and [4] unnecessary. I think I'd > >>>> rather avoid having a non-user with sudo and r/w on a publicly served > >>>> folder. > >>>> > >>> sounds right. > >
Re: Moving Jenkins master ASAP
Adding board list... I'm hoping with a wider audience, we might get additional feedback on hosting solutions. Mike On Tue, 2012-07-31 at 07:44 -0700, Karsten 'quaid' Wade wrote: > We need to pick a new hosting solution for jenkins.ovirt.org. > > One idea is for us to throw out some favorite hosting providers here, > and see if we can sort out what would be a good solution. > > Other ideas have been floated. > > Ideally, we'll get more hardware in the future via some hosting that > Red Hat is working on providing for projects. In the meantime ... > > Do any other sponsoring organizations have resources we can look in to? > > Once we pick something, we can move it all fairly quickly, I think. > Can we target the end of this week? Perhaps, if we don't run in to any > complications ... > > - Karsten > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: how to get files from jenkins.ovirt.org to www.ovirt.org
On Tue, 2012-07-31 at 09:13 -0400, Robert Middleswarth wrote: > On 07/31/2012 08:51 AM, Eyal Edri wrote: > > > > - Original Message ----- > >> From: "Mike Burns" > >> To: "Eyal Edri" > >> Cc: "infra" > >> Sent: Tuesday, July 31, 2012 3:33:01 PM > >> Subject: Re: how to get files from jenkins.ovirt.org to www.ovirt.org > >> > >> On Tue, 2012-07-31 at 02:46 -0400, Eyal Edri wrote: > >>> Hi, > >>> > >>> after looking into the process and testing it via > >>> jenkins.ovirt.info, > >>> here is my proposal: > >>> > >>> 1. Nightly job [1] will collect rpms from all ovirt projects (other > >>> jenkins jobs that build rpms per commit). > >>> 1.1 all files will be kept in a flat dir under $WORKSPCE/rpms > >>> 1.2 using 'publish over ssh' [2] plugin the job will then copy > >>> files to their destination according to their names. [3] > >>> for e.g 'ovirt-engine-3.1.0-3.fc17.noarch.rpm' ==> > >>> ovirt.org/var/www/html/releases/nightly/rpm/Fedora/17/noarch > >>> 'ovirt-engine-3.1.0-3.fc17.src.rpm' ==> > >>> ovirt.org/var/www/html/releases/nightly/rpm/Fedora/17/src > >>> 'ovirt-engine-3.1.0-3.bz2' ==> > >>> ovirt.org/var/www/html/releases/nightly/src' > >>> 1.3 publish ssh plugin can execute a command after its done > >>> copying > >>> the file, so all is left is to run 'createrepo' on the relevant > >>> dirs. > >>> [4] > >>> > >>> > >>> 2. a separate cron cleaning script needs to run on ovirt.org to > >>> delete > >>> old rpms and run createrepo. > >>> > >> Maybe upload to a non-published directory first, > >> like /home/jenkins/nightly, and have the cron job handle cleanup of > >> old > >> rpms, adding of new rpms, and running createrepo? > > sure, i've got not problem with that.. > > > > there is one thing i don't understand, and sorry if not an expert in yum: > > > > we say we want to keep history for X builds, will all versions be kept > > under one repository? > > so 'createrepo' will run on all versions in that directory? > > > > so running yum install file.verX will work even if the repo has a x+1 > > version? > If you look at existing repo's many of them will include old versions of > the package yum / create repo will simple use the latest version in the > repo that meets all the requirements. Example when we first moved from > vdsm 4.9 to 4.10 the repo's got really screwy until all the packages > were rebuilt. In that case the older 4.9 builds would get used until > all the packages were in place then the newer versions would get used. If we still want to keep multiple night's versions, then we can have the cron job run and create a new directory called: cd /var/www/html/releases mkdir nightly-$(date +%Y%m%d) # move all content from /home/jenkins to new nightly- directory ln -snf nightly-$(date +%Y%m%d) nightly rm -rf nightly-$(date -d "3 days ago" +%Y%m%d) Mike > > > >> If not, how is the cron job going to cleanup old rpms? > >> > >> Uploading to a static location that isn't public (and is > >> under /home/jenkins) would make [3] and [4] unnecessary. I think I'd > >> rather avoid having a non-user with sudo and r/w on a publicly served > >> folder. > >> > > sounds right. > > > >> The publish ssh plugin can touch a file > >> /home/jenkins/nightly/FINISHED > >> when it's done, the cron job locally on ovirt.org can watch for that > >> file and then process the directory structure. > +1 This is the approach I was thinking about. > > good idea, we can have the cronjob monitor the dir for the FINISHED file, > > and delete it when it's done. > > > >> Mike > >> > >>> +1 for pushing this forward or comments? > >>> > >>> Eyal. > >>> > >>> > >>> [1] > >>> http://jenkins.ovirt.org/view/rpms/job/publish_ovirt_rpms_nightly/, > >>> this job currently works only for fedora17 rpms (that's what we > >>> have > >>> now). > >>> we'll need to improve it to be more generic (maybe as a matrix > >>> job) or duplicate it for each opertating system. > >>> [2] https://wiki.jenkins-ci.org/display/JENKINS/Publish+Over+SSH > >>> +Plugin, using pub/private key with user jenkins to connect > >>> [3] jenkins user will need r/q permissions to the nightly folder > >>> [4] will need sudo access for it. > >>> ___ > >>> Infra mailing list > >>> Infra@ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/infra > >> > >> > > ___ > > Infra mailing list > > Infra@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: how to get files from jenkins.ovirt.org to www.ovirt.org
On Tue, 2012-07-31 at 02:46 -0400, Eyal Edri wrote: > Hi, > > after looking into the process and testing it via jenkins.ovirt.info, > here is my proposal: > > 1. Nightly job [1] will collect rpms from all ovirt projects (other > jenkins jobs that build rpms per commit). >1.1 all files will be kept in a flat dir under $WORKSPCE/rpms >1.2 using 'publish over ssh' [2] plugin the job will then copy > files to their destination according to their names. [3] >for e.g'ovirt-engine-3.1.0-3.fc17.noarch.rpm' ==> > ovirt.org/var/www/html/releases/nightly/rpm/Fedora/17/noarch > 'ovirt-engine-3.1.0-3.fc17.src.rpm' ==> > ovirt.org/var/www/html/releases/nightly/rpm/Fedora/17/src > 'ovirt-engine-3.1.0-3.bz2' ==> > ovirt.org/var/www/html/releases/nightly/src' >1.3 publish ssh plugin can execute a command after its done copying > the file, so all is left is to run 'createrepo' on the relevant dirs. > [4] > > > 2. a separate cron cleaning script needs to run on ovirt.org to delete > old rpms and run createrepo. > Maybe upload to a non-published directory first, like /home/jenkins/nightly, and have the cron job handle cleanup of old rpms, adding of new rpms, and running createrepo? If not, how is the cron job going to cleanup old rpms? Uploading to a static location that isn't public (and is under /home/jenkins) would make [3] and [4] unnecessary. I think I'd rather avoid having a non-user with sudo and r/w on a publicly served folder. The publish ssh plugin can touch a file /home/jenkins/nightly/FINISHED when it's done, the cron job locally on ovirt.org can watch for that file and then process the directory structure. Mike > > +1 for pushing this forward or comments? > > Eyal. > > > [1] > http://jenkins.ovirt.org/view/rpms/job/publish_ovirt_rpms_nightly/, > this job currently works only for fedora17 rpms (that's what we have > now). > we'll need to improve it to be more generic (maybe as a matrix > job) or duplicate it for each opertating system. > [2] https://wiki.jenkins-ci.org/display/JENKINS/Publish+Over+SSH > +Plugin, using pub/private key with user jenkins to connect > [3] jenkins user will need r/q permissions to the nightly folder > [4] will need sudo access for it. > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Nightly Jenkins backup are running.
On Thu, 2012-07-26 at 09:25 -0400, Robert Middleswarth wrote: > On 07/26/2012 08:32 AM, Mike Burns wrote: > > On Thu, 2012-07-26 at 08:29 -0400, Robert Middleswarth wrote: > >> On 07/26/2012 03:22 AM, Eyal Edri wrote: > >>> Great! > >>> > >>> i think Jenkins puts his war file under /usr/lib/jenkins/jenkins.war > >>> also.. > >> Added > > Why? jenkins.war should be available from the jenkins website directly. > > Why would we be backing it up, unless we have some customizations that > > i'm not aware of. > > > > Mike > It is mainly to make it easy to restore in the event of failure. Lets > face it as a group we haven't been the best at updating stuff. Jenkins > is 1 version behind if we had to restore right now witch version would > you pull? Would you have pull in the same version as the backups. > Granted we should upgrade and pulling in a newer version shouldn't be an > issue but if you are attempting to do a restore keeping the number of > moving part to a min is important. > OK, point taken. Just didn't want to back up things that are easily available elsewhere, but these are good points. Mike > Thanks > Robert > > > >>> how long are keeping backups back? > >> intervaldaily 7 > >> intervalweekly 6 > >> intervalmonthly 3 > >> > >> I can change those numbers those are just the defaults. > >> > >> Thanks > >> Robert > >>> eyal. > >>> > >>> - Original Message - > >>>> From: "Robert Middleswarth" > >>>> To: "infra" > >>>> Sent: Wednesday, July 25, 2012 7:45:27 PM > >>>> Subject: Nightly Jenkins backup are running. > >>>> > >>>> I have nightly backups running that is pulling down the following > >>>> folders. > >>>> > >>>> /usr/local/bin/ > >>>> /usr/local/sbin/ > >>>> /etc/ > >>>> /home/ > >>>> /var/lib/jenkins/ > >>>> Excluding /var/lib/jenkins/workspace/* > >>>> /var/log/jenkins/ > >>>> > >>>> Did I miss anything? > >>>> > >>>> Thanks > >>>> Robert > >>>> ___ > >>>> Infra mailing list > >>>> Infra@ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/infra > >>>> > >> ___ > >> Infra mailing list > >> Infra@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/infra > > > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Nightly Jenkins backup are running.
On Thu, 2012-07-26 at 08:29 -0400, Robert Middleswarth wrote: > On 07/26/2012 03:22 AM, Eyal Edri wrote: > > Great! > > > > i think Jenkins puts his war file under /usr/lib/jenkins/jenkins.war also.. > Added Why? jenkins.war should be available from the jenkins website directly. Why would we be backing it up, unless we have some customizations that i'm not aware of. Mike > > how long are keeping backups back? > intervaldaily 7 > intervalweekly 6 > intervalmonthly 3 > > I can change those numbers those are just the defaults. > > Thanks > Robert > > eyal. > > > > - Original Message - > >> From: "Robert Middleswarth" > >> To: "infra" > >> Sent: Wednesday, July 25, 2012 7:45:27 PM > >> Subject: Nightly Jenkins backup are running. > >> > >> I have nightly backups running that is pulling down the following > >> folders. > >> > >> /usr/local/bin/ > >> /usr/local/sbin/ > >> /etc/ > >> /home/ > >> /var/lib/jenkins/ > >> Excluding /var/lib/jenkins/workspace/* > >> /var/log/jenkins/ > >> > >> Did I miss anything? > >> > >> Thanks > >> Robert > >> ___ > >> Infra mailing list > >> Infra@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/infra > >> > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Reduced the number of executors to 2 on master.
On Wed, 2012-07-25 at 09:04 -0400, Robert Middleswarth wrote: > On 07/25/2012 02:42 AM, Eyal Edri wrote: > > > > - Original Message - > >> From: "Robert Middleswarth" > >> To: "Karsten 'quaid' Wade" , "Eyal Edri" > >> , "Mike Burns" , > >> "infra" > >> Sent: Tuesday, July 24, 2012 10:01:13 PM > >> Subject: Reduced the number of executors to 2 on master. > >> > >> I was watching how overloaded Jenkins was well it was running 3 jobs > >> on > >> the master server. It was so overload that the Jenkins website > >> became > >> unresponsive for a several min. So I reduced the number of jobs that > >> will on the master. > >> > > if we have enough slaves, it's best practice to set it even to 0, > > and not run any jobs on it. > There is one Job that is set to run only on master but I don't have > problem dropping down the number of jobs running on master. I will > bring it down to 1 that should help lower the load on master even more. Before bringing it down any more, can we look at what requires master to run and if we can/should move those jobs off master? Thanks Mike > > Thanks > Robert > >> Thanks > >> Robert > >> > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Security issues when running gerrit patches on jenkins
On Wed, 2012-07-18 at 13:03 -0400, Eyal Edri wrote: > > - Original Message - > > From: "Robert Middleswarth" > > To: infra@ovirt.org > > Sent: Wednesday, July 18, 2012 8:00:44 PM > > Subject: Re: Security issues when running gerrit patches on jenkins > > > > On 07/18/2012 10:40 AM, Karsten 'quaid' Wade wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > On 07/18/2012 06:20 AM, Dan Kenigsberg wrote: > > >> On Wed, Jul 18, 2012 at 07:05:16AM -0400, Eyal Edri wrote: > > >>> Hi, > > >>> > > >>> Following last infra meeting, i want to open for discussion the > > >>> security issues that may arise if we allow Jenkins to run jobs > > >>> (i.e any code) with every gerrit patch. > > >>> > > >>> The problem: > > >>> > > >>> In theory, any user that is registered to gerrit might send a > > >>> patch to any ovirt project. That code might contain malicious > > >>> code, malware, harmfull or just not-related ovirt code that he > > >>> wants to use our resources for it. Even though we use limited > > >>> sudo on hosts, we can't be sure an exploit will be used against > > >>> one of the jenkins slaves. > > >>> > > >>> > > >>> The proposed solutions: > > >>> > > >>> - black-listing authors (published on ovirt.org?) - white-listing > > >>> authors (published on ovirt.org?) - auto approve patch via > > >>> comparing to lastest commits - check if author recent patches > > >>> were approved in the past? > > >>> > > >>> adding dan since he raised this issue when we wanted to add vdsm > > >>> gerrit tests. > > >> In my opinion, we can trust anyone who has already contributed > > >> code > > >> to the relevant project. We can even say: someone who contributed > > >> more than 3 commits over a month ago. > > > This seems like a reasonable approach. Trust people first, and it's > > > fine to have a method to untrust people if the need arises. That > > > shouldn't surprise or disappoint anyone - it's just simple sanity. > > > > > > The alternatives are to build untrust in to the process from the > > > start, which becomes a barrier to getting things done, and > > > perpetuates > > > a culture of untrust. > > > > > > I just remind myself, if someone is going to worm their way in to > > > our > > > trust to run malicious code on our Jenkins instances, there is so > > > much > > > more damage they can do with that trust. > > > > > > Trust is like fertilizer, water, and sunshine in the garden - it > > > makes > > > amazing things grow. :) > > I am on the opposite side of this issue. Maybe I have been attacked > > by > > 1 to many bot's or been a manager when someone I know and trusted > > stole > > from the company. I need trust to be earned so I +1 on whitelist. > > With > > that said I think getting on the whitelist should be pretty easy. We > > are not talking about blocking there commit's we are talking about > > should the automated system run test/code against there patch. I am > > still learning Jekins when using a whitelist is there a way to flag > > commits for users not in the list? I wonder if there is some way to > > create a list that someone can go though and whitelist the user or > > reject the user for commits not in the whitelist? > > > > i've never done this in the past. > i assume we'll need to read the author email/name from the gerrit patch > (before running the code) > wget the whitelist page from ovirt.org and match it.. > > or alternatively run git log and search it there... > > if there isn't a match, fail the job before running any code. No, I don't think we want to have failures in the main build job. What about a separate job that verifies the patch submitter, then triggers the build job. Would probably need to pass the GERRIT_REFSPEC variable between the 2 builds somehow. Mike > > > Thanks > > Robert > > > > > > - - 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/ > > > > > > iD8DBQFQBsrp2ZIOBq0ODEERAlfyAKDiJCl6RLXVQluAw9hsX9Uc4ftzMgCgjH6G > > > 0Ejk6rXviSMbc+oiKVTjMUs= > > > =3Hf2 > > > -END PGP SIGNATURE- > > > ___ > > > Infra mailing list > > > Infra@ovirt.org > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > ___ > > Infra mailing list > > Infra@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Security issues when running gerrit patches on jenkins
On Wed, 2012-07-18 at 13:34 -0400, Heiko W.Rupp wrote: > Am 18.07.2012 um 13:00 schrieb Robert Middleswarth: > > > I need trust to be earned so I +1 on whitelist. With that said I think > > getting on the whitelist should be pretty easy. > > Isn't that what you usually do on projects - have the first few commits not > directly go to master but being > reviewed by an existing committer and then giving full commit access to a new > user? > So I think that fits in and fits with what new committers are used to. Many > of them actually would be scared > if they got commit access from day 1. It's not commit access that is being discussed. We're not giving that away easily. Jenkins provides the ability to trigger builds/tests on patch submission (just submission, not commit). A savvy attacker could write a patch that could cause the tests to compromise the jenkins slave machine. The whitelist being proposed is a whitelist for running the build/test based on who submitted the patch. Mike > > Heiko > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: no [infra] prefix on infra mailing list emails
On Tue, 2012-07-17 at 08:12 -0700, Karsten 'quaid' Wade wrote:
> On 07/17/2012 05:40 AM, Doron Fediuck wrote:
>
> > Some mail clients will allow better presentation filtering based
> > on $SUBJECT.
>
> That's interesting, I thought people were perhaps using them for
> visual filter ("I see that is part of this list by the subject line"),
> but I didn't know you could get a different presentation filtering. So
> this would be different than moving it to a folder? Is it something
> automatic?
It's a mailman setting
>
> (I usually use reliable headers, such as x-been-there, for filtering
> mailing lists, since subject lines are inconsistent. Also, I tend to
> avoid [Listname] in the subject because it's always a prefix, which
> shortens how much of the actual subject is visible in the mail client.)
I usually use List-id header to filter. There is benefit both ways as
mentioned here. I don't have an overly strong opinion either way.
Mike
>
> - Karsten
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
Re: Maintainers list
On Mon, 2012-07-16 at 11:27 -0700, Karsten 'quaid' Wade wrote: > 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. :) I'll take on a limited role here. I'll attend the meetings and give feedback, as well as help if/when problems come up. I've also functioned (at times) as a backup for Ofer in the Release Manager role, and will continue with that. I'm unlikely to have time to be very involved in creating new infrastructure or deploying anything new though. Mike > > Thanks - Karsten > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Jenkins and RHEL 6.2
On Fri, 2012-07-13 at 00:40 -0400, Robert Middleswarth wrote: > On 07/12/2012 11:50 PM, Mike Burns wrote: > > On Thu, 2012-07-12 at 23:30 -0400, Robert Middleswarth wrote: > >> On 07/12/2012 11:48 AM, Mike Burns wrote: > >>> On Thu, 2012-07-12 at 10:59 -0400, Eyal Edri wrote: > >>>> - Original Message - > >>>>> From: "Robert Middleswarth" > >>>>> To: "infra" > >>>>> Sent: Thursday, July 12, 2012 5:44:44 PM > >>>>> Subject: Jenkins and RHEL 6.2 > >>>>> > >>>>> 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? > >>>>> > >>>> currently they are used for running mvn jobs like unit tests/find bugs. > >>>> > >>>> you mean use them to create RPMs for ovirt-engine? > >>>> supposing make rpm will work for that, all we'll need is to make sure > >>>> they have > >>>> the right rpm build packages installed (rpmbuild, make,autoconf,etc) > >>> If we want to do that, we should go down a slightly different path. > >>> Each project should have a job that makes the source rpm and tarball. > >>> Then separate jobs on each of the platforms (fedora, RHEL, ubuntu, > >>> etc...) that will take the srpm and/or tarball and generate packages for > >>> the distro. > >>> > >>> Mike > >> Well all the packages are built from a tar file but SPRM wont work for > >> Debian based systems. On my testing system creating the .tar.gz file > >> takes like 10 seconds. But having an updated tar.gz file on every > >> master commit could be useful. Not sure how much having a pre-done src > >> tar is going to save in actual build time. Although having diff build > >> packages for each distro makes a lot of since. I am all about steps to > >> make something happen. I can think of some steps we could go though to > >> convert the process but at best it would be based on my basic knowledge > >> you know the current build process and would be best for you to outline > >> the steps to get the changes in place. What steps do you think are the > >> best steps to getting the process changed up? > > So my thoughts in general on this (can be applied to any code based > > sub-project except node): > > > > Job 1: build source (done on latest fedora and/or rhel host) > > generates source tarball > > generates srpm > Can 1 srpm file support Fedora 17, Fedora 18, and EL6? Or will the > build process create 3 srpm files one for each rpm based distro? Still > learning about rpm spec files been in the .deb world for that last 8 years. In every case I've come across, yes. > > exports both as artifacts > > Job 2: Build Fedora 17 RPMs > > takes srpm artifact from Job 1 > > uses mock to build F17 RPMs > > Job 2.5: Build Fedora 18 RPMs once Fedora starts beta testing? > takes srpm artifact from Job 1 > uses mock to build F17 RPMs Sure, but F18 RPMs. BTW, with mock, we might even be able to build F17, F18, F*, EL* rpms all on one server. All depends on the mock config files, and fedora has one for EL6, fedora 14-17 and rawhide (18) > > > Job 3: Build EL6 RPMs > > takes srpm artifact from Job 1 > > uses mock to build EL6 RPMs > > Job 4-X: Build RPM for Distro XYZ > > takes either SRPM or tarball depending on distro > > build distro specific packages > > > > > > As for the code to do each job, I don't know all the ins and outs of > > building each individual component, but something like a make dist > > and/or a make srpm should provide the needed artifacts. > > > > I also don't know mock very well, but I'm pretty sure it's pretty > > straightforward for most packages. > > > > Potential problems that I see: > > > > 1. spec files will need massaging for el6 and f17 diffs > Can one spec file be used or will we need one for F17, F18, EL6? Yes, one spec is fine. Just need to have parts of it conditionalized for F17, F18, EL6... > > 2. will need distro specific spec file equivalents for each distro we > > support > Yep. From what I can see of the format of the engine repo there > shouldn't b
Re: Jenkins and RHEL 6.2
On Thu, 2012-07-12 at 23:30 -0400, Robert Middleswarth wrote: > On 07/12/2012 11:48 AM, Mike Burns wrote: > > On Thu, 2012-07-12 at 10:59 -0400, Eyal Edri wrote: > >> - Original Message - > >>> From: "Robert Middleswarth" > >>> To: "infra" > >>> Sent: Thursday, July 12, 2012 5:44:44 PM > >>> Subject: Jenkins and RHEL 6.2 > >>> > >>> 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? > >>> > >> currently they are used for running mvn jobs like unit tests/find bugs. > >> > >> you mean use them to create RPMs for ovirt-engine? > >> supposing make rpm will work for that, all we'll need is to make sure they > >> have > >> the right rpm build packages installed (rpmbuild, make,autoconf,etc) > > If we want to do that, we should go down a slightly different path. > > Each project should have a job that makes the source rpm and tarball. > > Then separate jobs on each of the platforms (fedora, RHEL, ubuntu, > > etc...) that will take the srpm and/or tarball and generate packages for > > the distro. > > > > Mike > Well all the packages are built from a tar file but SPRM wont work for > Debian based systems. On my testing system creating the .tar.gz file > takes like 10 seconds. But having an updated tar.gz file on every > master commit could be useful. Not sure how much having a pre-done src > tar is going to save in actual build time. Although having diff build > packages for each distro makes a lot of since. I am all about steps to > make something happen. I can think of some steps we could go though to > convert the process but at best it would be based on my basic knowledge > you know the current build process and would be best for you to outline > the steps to get the changes in place. What steps do you think are the > best steps to getting the process changed up? So my thoughts in general on this (can be applied to any code based sub-project except node): Job 1: build source (done on latest fedora and/or rhel host) generates source tarball generates srpm exports both as artifacts Job 2: Build Fedora 17 RPMs takes srpm artifact from Job 1 uses mock to build F17 RPMs Job 3: Build EL6 RPMs takes srpm artifact from Job 1 uses mock to build EL6 RPMs Job 4-X: Build RPM for Distro XYZ takes either SRPM or tarball depending on distro build distro specific packages As for the code to do each job, I don't know all the ins and outs of building each individual component, but something like a make dist and/or a make srpm should provide the needed artifacts. I also don't know mock very well, but I'm pretty sure it's pretty straightforward for most packages. Potential problems that I see: 1. spec files will need massaging for el6 and f17 diffs 2. will need distro specific spec file equivalents for each distro we support 3. possible missing options to create srpm and src tarball ovirt-node: only really supported on fedora right now. We could possibly build packages for el6 and other distros that contain the fedora based iso, but not sure if that is really useful or not. As for an EL6 based image, that will take some work to figure out as well (and not sure if that's really a major driver at this point or not). Mike > > Thanks > Robert > > >>> Thanks > >>> Robert > >>> ___ > >>> Infra mailing list > >>> Infra@ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/infra > >>> > >> ___ > >> Infra mailing list > >> Infra@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/infra > > > > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Infrastructure for Jenkins
On Thu, 2012-07-12 at 17:57 +0300, Itamar Heim wrote: > On 07/12/2012 05:55 PM, Eyal Edri wrote: > > > > > > - Original Message - > >> From: "Karsten 'quaid' Wade" > >> To: infra@ovirt.org > >> Sent: Thursday, July 12, 2012 5:31:41 PM > >> Subject: Re: Infrastructure for Jenkins > >> > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> On 07/12/2012 05:57 AM, Jabs, Joachim wrote: > >>> Hi Guys, > >>> > >>> > >>> > >>> as previously offered: > >>> > >>> > >>> > >>> Im willing to provide you guys infrastructure for Jenkins. Im > >>> currently trying out getting oVirt running on a cluster (we have > >>> 192 Cores and 3TB RAM aviable) for providing help with problems > >>> around ovirt that might arise. > >>> > >>> The Cluster is not commercially used (Not right now) and for me its > >>> also a good opportunity to learn about ovirt and also about hosting > >>> VM related infrastructure. This will also be a test for stability > >>> and maintainability around the hardware used. > >>> > >>> > >>> > >>> If you guys sum up what you need, I think I might be able to do > >>> something for you there. If you have any questions regarding the > >>> offer, just ask. > >> > >> Hey, thanks for following. This is a great offer, +1 from me. > >> > >> Ewoud, Eyal (& others?) - what does Joachim need to do? Is this a > >> good > >> place to start? -- > > > > This is an excellent offer and opportunity. > > Since we're talking about VMs, we can start with basic hardware spec > > and increase it after we'll see the bottle necks in real time. > > > > I would start with 3 VMs each running 16GB RAM, 200GB DISK, 32 GB SWAP, > > each with 4/8 cores each. > > > > Itamar, mburns -> any recommendation on how many VMs per hardware node > > should we use? > > > > considering the workload, i'd start with not overcomitting resources, > and later analyzing behavior Agree with Itamar. I'd also consider having a vm or 2 that are running various target distros where we can build packages for different distros. Also, 200GB disk seems a bit excessive to me. Since this is running on oVirt, maybe a thin provisioned disk would be a good choice. The slaves generally don't need as much disk. Mike > > > > >> > >> http://ovirt.org/wiki/Jenkins > >> > >> Cheers - 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/ > >> > >> iD8DBQFP/t/N2ZIOBq0ODEERAkM+AKCqsLii5DeVVDcueUR/0075fmSWhACfbmGP > >> PMWT116DTADxn/oNn/pXav4= > >> =EarP > >> -END PGP SIGNATURE- > >> ___ > >> Infra mailing list > >> Infra@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/infra > >> > > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Jenkins and RHEL 6.2
On Thu, 2012-07-12 at 10:59 -0400, Eyal Edri wrote: > > - Original Message - > > From: "Robert Middleswarth" > > To: "infra" > > Sent: Thursday, July 12, 2012 5:44:44 PM > > Subject: Jenkins and RHEL 6.2 > > > > 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? > > > > currently they are used for running mvn jobs like unit tests/find bugs. > > you mean use them to create RPMs for ovirt-engine? > supposing make rpm will work for that, all we'll need is to make sure they > have > the right rpm build packages installed (rpmbuild, make,autoconf,etc) If we want to do that, we should go down a slightly different path. Each project should have a job that makes the source rpm and tarball. Then separate jobs on each of the platforms (fedora, RHEL, ubuntu, etc...) that will take the srpm and/or tarball and generate packages for the distro. Mike > > > Thanks > > Robert > > ___ > > Infra mailing list > > Infra@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Vote on the mission statement.
+1 On Tue, 2012-07-10 at 21:31 -0400, Robert Middleswarth wrote: > After reviewing all the input and putting it all together this is what > we ended up with. Please vote if you think we should adopt this as out > mission statement. If you like please put +1 if you hate put a -1 if you > aren't sure put a 0. > > Proposed Mission Statement > > The oVirt Infra Team is a volunteer effort to provide community > infrastructure services by following the tenets of open source and accepted > professional standards of system administrators. > > Thanks > Robert > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Infra project mission statement RFC
On Tue, 2012-07-10 at 17:42 -0400, Robert Middleswarth wrote: > On 07/10/2012 04:47 PM, Robert Middleswarth wrote: > > On 07/10/2012 04:29 PM, Karsten 'quaid' Wade wrote: > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> On 07/10/2012 01:22 PM, Ewoud Kohl van Wijngaarden wrote: > >>> The oVirt Infra Team is a volunteer effort to provide community > >>> infrastructure services by following accepted professional > >>> standards of system administrators and the open source way. > >> OK, I like this now, it's maybe a bit long? but has all the elements. > >> > >> I do see the final clauses get confusing so that it can be read > >> "following accepted professional standards of the open source way." > >> Perhaps: > >> > >> "The oVirt Infra Team is a volunteer effort to provide community > >> infrastructure services by following the open source way and accepted > >> professional standards of system administrators." > > What about: > > > > The oVirt Infra Team is a volunteer effort to provide community > > infrastructure services by following "The Open Source Way" and accepted > > professional standards of system administrators. > > > Another option is: > > The oVirt Infra Team is a volunteer effort to provide community > infrastructure services by following the tenants of open source and accepted > professional standards of system administrators. Assuming you mean "tenets" instead of "tenants", I like this. > > > > That works for me. > > > > Thanks > > Robert > >> - - 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/ > >> > >> iD8DBQFP/JDD2ZIOBq0ODEERAgipAJ98Fvg20u7i9TzaVIlvWRY4TQAC5wCgl4GB > >> 5JNAJ8/ioawKk1cWCzeWpD4= > >> =u0no > >> -END PGP SIGNATURE- > >> ___ > >> Infra mailing list > >> Infra@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/infra > > > > > > ___ > > Infra mailing list > > Infra@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Infra project mission statement RFC
On Tue, 2012-07-10 at 16:09 -0400, Mike Burns wrote: > On Tue, 2012-07-10 at 21:58 +0200, Ewoud Kohl van Wijngaarden wrote: > > On Tue, Jul 10, 2012 at 03:49:54PM -0400, Robert Middleswarth wrote: > > > On 07/10/2012 03:48 PM, Mike Burns wrote: > > > >On Tue, 2012-07-10 at 15:27 -0400, Robert Middleswarth wrote: > > > >>This week in the infra meeting the topic of a mission statement was > > > >>talked about and I was asked to send out some suggestions and ask for > > > >>feedback and combine the comments into a good mission statement. I > > > >>tired to take what was talked about in the chat and looked at mission > > > >>statements of other projects and this is what I came up with. > > > >> > > > >>Proposed Mission Statement: > > > >> > > > >>The Infrastructure (infra) team is a community services infrastructure > > > >>team. It purpose is to manage in a professional manner the oVirt's > > > >>project infrastructure following accepted professional standards of > > > >>system administrators. These administrators volunteer their time to > > > >>contribute to the oVirt project. > > > >A few nits and reorganizations... > > > > > > > >The infra team is a community services infrastructure team made up of > > > >volunteers. It purpose is to manage, in a professional manner, the oVirt > > > >project's infrastructure following accepted professional standards of > > > >system administrators. > > > I like that one better :) > > Provided you change 'It purpose' to 'Its purpose' I mostly like it. Not > > sure about the double professional in there. What's the difference > > between a professional manner and following accepted professional > > standards? Maybe make it modern professional standards as well. > > I missed the double professional. Not sure how modern fits there. It > seems to make it a bit wordy... > > The infra team is a community services infrastructure team made up of > volunteers. It purpose is to manage the oVirt project's infrastructure > following accepted professional standards of system administrators. Fixing It -> Its The infra team is a community services infrastructure team made up of volunteers. Its purpose is to manage the oVirt project's infrastructure following accepted professional standards of system administrators. > > > ___ > > Infra mailing list > > Infra@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Infra project mission statement RFC
On Tue, 2012-07-10 at 21:58 +0200, Ewoud Kohl van Wijngaarden wrote: > On Tue, Jul 10, 2012 at 03:49:54PM -0400, Robert Middleswarth wrote: > > On 07/10/2012 03:48 PM, Mike Burns wrote: > > >On Tue, 2012-07-10 at 15:27 -0400, Robert Middleswarth wrote: > > >>This week in the infra meeting the topic of a mission statement was > > >>talked about and I was asked to send out some suggestions and ask for > > >>feedback and combine the comments into a good mission statement. I > > >>tired to take what was talked about in the chat and looked at mission > > >>statements of other projects and this is what I came up with. > > >> > > >>Proposed Mission Statement: > > >> > > >>The Infrastructure (infra) team is a community services infrastructure > > >>team. It purpose is to manage in a professional manner the oVirt's > > >>project infrastructure following accepted professional standards of > > >>system administrators. These administrators volunteer their time to > > >>contribute to the oVirt project. > > >A few nits and reorganizations... > > > > > >The infra team is a community services infrastructure team made up of > > >volunteers. It purpose is to manage, in a professional manner, the oVirt > > >project's infrastructure following accepted professional standards of > > >system administrators. > > I like that one better :) > Provided you change 'It purpose' to 'Its purpose' I mostly like it. Not > sure about the double professional in there. What's the difference > between a professional manner and following accepted professional > standards? Maybe make it modern professional standards as well. I missed the double professional. Not sure how modern fits there. It seems to make it a bit wordy... The infra team is a community services infrastructure team made up of volunteers. It purpose is to manage the oVirt project's infrastructure following accepted professional standards of system administrators. > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Infra project mission statement RFC
On Tue, 2012-07-10 at 15:27 -0400, Robert Middleswarth wrote: > This week in the infra meeting the topic of a mission statement was > talked about and I was asked to send out some suggestions and ask for > feedback and combine the comments into a good mission statement. I > tired to take what was talked about in the chat and looked at mission > statements of other projects and this is what I came up with. > > Proposed Mission Statement: > > The Infrastructure (infra) team is a community services infrastructure > team. It purpose is to manage in a professional manner the oVirt's > project infrastructure following accepted professional standards of > system administrators. These administrators volunteer their time to > contribute to the oVirt project. A few nits and reorganizations... The infra team is a community services infrastructure team made up of volunteers. It purpose is to manage, in a professional manner, the oVirt project's infrastructure following accepted professional standards of system administrators. > > Thanks > Robert > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Trust seed
On Tue, 2012-07-10 at 08:25 -0700, Karsten 'quaid' Wade wrote: > On 07/10/2012 03:03 AM, Ewoud Kohl van Wijngaarden wrote: > > On Tue, Jul 10, 2012 at 11:58:19AM +0200, Dave Neary wrote: > >> On 07/10/2012 08:00 AM, Robert Middleswarth wrote: > >>> On 07/10/2012 12:35 AM, Karsten 'quaid' Wade wrote: > >>>> As discussed in last week's meeting, I'm proposing myself as > >>>> a trust seed for this team. Here's what that means, why me, > >>>> and what it does for us. Full consensus requested, please: > >>>> +1, +0, or -1 (latter with reasoning included.) > >> > >>> +1 > >>> > >>> I personally believe the current team should be grandfathered > >>> in. I think moving forward is were we as a team need to be > >>> thinking about who gets added in. > >> > >> +1, and +1 also to seeding the team initially with the current > >> ppl doing sysadmin work, as Robert suggests. > > > > +1, I think those already doing work have proven themselves and as > > we gradually move towards configs in git we can introduce more fine > > grained access. > > +1 > > Basically, that's my scheme - start with the current team who has been > thinking and caring about Infra. My eye sees Ewoud Kohl van > Wijngaarden, Mike Burns, Robert Middleswarth, Eyal Edri, Itamar Heim, > and Moran Goldboim. Ofer should be on this list too... > > Am I missing anyone? Someone doing Infrastructure work in Tel Aviv who > needs to be included? > > Thanks - Karsten > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Trust seed
On Tue, 2012-07-10 at 08:27 -0700, Karsten 'quaid' Wade wrote: > On 07/10/2012 07:13 AM, Mike Burns wrote: > > On Tue, 2012-07-10 at 15:52 +0300, Livnat Peer wrote: > >> On 10/07/12 07:35, Karsten 'quaid' Wade wrote: > > As discussed in last week's meeting, I'm proposing myself as a > > trust seed for this team. Here's what that means, why me, and what > > it does for us. Full consensus requested, please: +1, +0, or -1 > > (latter with reasoning included.) > > > > We need to make the leap with this project and begin trusting each > > other enough to share root/sudo access on production servers[1]. By > > a "trust seed" I mean, a person who all others involved trust in > > deciding who else to trust. As a seed, it's a one time thing - > > once created, the initial trust circle will decide for itself how > > to perpetuate, i.e., how to add new people in to the trust circle. > > > > Regarding my qualifications for being trusted and extending trust, > > some supporting points: > > > > * Some of you have met me in person, at the initial oVirt workshop > > and other locations. * Demonstrated involvement in oVirt (presuming > > my wiki and GPG accounts are not compromised, I have commit and > > email history to show involvement.) * Trust in Red Hat can extend > > to me, based on my 10+ years employment, etc. * Presence and > > positions of trust in other open source projects, namely the Fedora > > Project. * Experience working in Fedora Infrastructure as part of a > > distance team of people who have never all met in person. * Handful > > of videos of me talking at conferences, identified by name, and so > > forth. > > > > I can provide references for the above, if requested. > > > > Thanks - Karsten > >>> > >>> > >>> +1, Karsten I think you are doing a great work in ovirt in > >>> general and I wish you luck making the infra sub-project a > >>> successful one. > > > >> +1 to Karsten being the initial seed and +1 to other infra > >> members being grandfathered. > > > >>> > >>> I would like to suggest that Moran Goldboim would also be > >>> included in the trust seed of the infra project. > >>> > >>> I think Moran is doing a lot of work in oVirt, he is well > >>> familiar in the oVirt community and has a lot of knowledge to > >>> contribute to the infra sub-project. > >> My only question here is whether Moran has already done work in > >> the infra team. There is certainly work done in other projects, > >> but not much in the infra team that I recall. Perhaps add Moran > >> as the first or second person through the process? > > I added Moran to my list just in case - I want to be sure we don't get > in the way of work anyone is doing already, even if we aren't aware of > it. By this I mean, some folks may be doing infrastructure work but > haven't been making noise about that work; if that's happening, let's > find a way to include such folks. Perhaps as you say, Moran and others > could go through an Infra Team joining process, as long as that > doesn't interfere with his ability to work? Sure, that's fine. Moran is pretty easy to accept anyway give the @redhat.com email address... Mike > > - Karsten > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Trust seed
On Tue, 2012-07-10 at 15:52 +0300, Livnat Peer wrote: > On 10/07/12 07:35, Karsten 'quaid' Wade wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > As discussed in last week's meeting, I'm proposing myself as a trust > > seed for this team. Here's what that means, why me, and what it does > > for us. Full consensus requested, please: +1, +0, or -1 (latter with > > reasoning included.) > > > > We need to make the leap with this project and begin trusting each > > other enough to share root/sudo access on production servers[1]. By a > > "trust seed" I mean, a person who all others involved trust in > > deciding who else to trust. As a seed, it's a one time thing - once > > created, the initial trust circle will decide for itself how to > > perpetuate, i.e., how to add new people in to the trust circle. > > > > Regarding my qualifications for being trusted and extending trust, > > some supporting points: > > > > * Some of you have met me in person, at the initial oVirt workshop and > > other locations. > > * Demonstrated involvement in oVirt (presuming my wiki and GPG > > accounts are not compromised, I have commit and email history to show > > involvement.) > > * Trust in Red Hat can extend to me, based on my 10+ years employment, > > etc. > > * Presence and positions of trust in other open source projects, > > namely the Fedora Project. > > * Experience working in Fedora Infrastructure as part of a distance > > team of people who have never all met in person. > > * Handful of videos of me talking at conferences, identified by name, > > and so forth. > > > > I can provide references for the above, if requested. > > > > Thanks - Karsten > > > +1, Karsten I think you are doing a great work in ovirt in general and I > wish you luck making the infra sub-project a successful one. +1 to Karsten being the initial seed and +1 to other infra members being grandfathered. > > I would like to suggest that Moran Goldboim would also be included in > the trust seed of the infra project. > > I think Moran is doing a lot of work in oVirt, he is well familiar in > the oVirt community and has a lot of knowledge to contribute to the > infra sub-project. My only question here is whether Moran has already done work in the infra team. There is certainly work done in other projects, but not much in the infra team that I recall. Perhaps add Moran as the first or second person through the process? Mike > > Livnat > > > > > > [1] If we move to OpenShift (or similar), then the admin access is who > > has keys to update the app on OpenShift; ultimately the same trust > > issues need to be resolved. > > - -- > > 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/ > > > > iD8DBQFP+7Eb2ZIOBq0ODEERAtCNAJ4zM91Pk9LsItsYXG6eU2x+HZHspACeJ8hy > > NGj6y7NSOuHVcPqYsxX9UCI= > > =16JZ > > -END PGP SIGNATURE- > > ___ > > Infra mailing list > > Infra@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Gerrit's gitweb page is missing public git url
On Mon, 2012-07-09 at 22:25 +0300, Itamar Heim wrote: > On 07/09/2012 10:13 PM, Mike Burns wrote: > > On Mon, 2012-07-09 at 22:07 +0300, Itamar Heim wrote: > >> On 07/09/2012 01:44 PM, Mike Burns wrote: > >>> On Mon, 2012-07-09 at 07:55 +0300, Itamar Heim wrote: > >>>> On 07/06/2012 09:00 PM, Mike Burns wrote: > >>>>> On Fri, 2012-07-06 at 18:10 +0300, Itamar Heim wrote: > >>>>>> On 07/05/2012 02:48 PM, Fabian Deutsch wrote: > >>>>>>> Hey, > >>>>>>> > >>>>>>> I just noted that the public gerrit gitweb page is missing the public > >>>>>>> git url to a repo. > >>>>>>> > >>>>>>> E.g.: ovirt-node-tests > >>>>>>> Gitweb page: http://gerrit.ovirt.org/gitweb?p=ovirt-node-tests.git > >>>>>>> > >>>>>>> Names http and private git url: > >>>>>>> http://gerrit.ovirt.org/p/ovirt-node-tests.git > >>>>>>> ssh://.../ovirt-node-tests.git > >>>>>>> > >>>>>>> Public git url (git://gerrit.ovirt.org/ovirt-node-tests) is missing. > >>>>>>> It would be nice if this url could also be displayed, as git transport > >>>>>>> is faster than http. > >>>>>>> > >>>>>> > >>>>>> its the same for all projects, not just ovirt-node-tests. > >>>>>> find me how to configure it and i will... > >>>>> > >>>>> In the gitweb.conf (or the equivalent), set: > >>>>> our @git_base_url_list = qw(git://gerrit.ovirt.org > >>>>>ssh://gerrit.ovirt.org); > >>>> > >>>> I wish it was that easy... > >>>> gerrit passes its own (for example, you will get the ssh link from > >>>> gitweb if you are logged in to gerrit, etc.). > >>>> and it manipulates git_base_url_list accordingly. > >>>> > >>>> http://code.google.com/p/gerrit/source/browse/gerrit-httpd/src/main/java/com/google/gerrit/httpd/gitweb/GitWebServlet.java > >>> > >>> Ahh, ok, I have my gitweb config independent of gerrit. Looks like you > >>> need GIT_ANONYMOUS_READ set and a git daemon url set. Looking at [1], i > >>> think you need download.scheme=anon_git and > >>> gerrit.canonicalGitUrl=git://gerrit.ovirt.org set in etc/gerrit.conf. > >> > >> wouldn't changing canonicalGitUrl will cause the default one to stop > >> being web based for links? > >> today we have this as the default: > >> canonicalWebUrl = http://gerrit.ovirt.org > > > > Should be 2 separate entries. > > > > canonicalWebUrl=http://... > > canonicalGitUrl=git://... > > indeed. > done - check it out... Looks good to me. ;-) > ___ > Infra mailing list > Infra@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
