vdsm hooks pages at ovirt.org

Mike Burns mburns at redhat.com
Mon Aug 20 13:43:04 UTC 2012 

On Mon, 2012-08-20 at 09:38 -0400, Dan Yasny wrote:
> 
> ----- Original Message -----
> > From: "Mike Burns" <mburns at redhat.com>
> > To: "Dan Yasny" <dyasny at redhat.com>
> > Cc: infra at 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" <mburns at redhat.com>
> > > > To: "Dan Yasny" <dyasny at redhat.com>
> > > > Cc: infra at 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" <mburns at redhat.com>
> > > > > > To: "Dan Yasny" <dyasny at redhat.com>
> > > > > > Cc: infra at 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, and
> > > things might end up getting stuck or turning into a splitbrain
> > > between two locations. I'd rather start off properly and avoid it
> > > all
> > > 
> > OK
> > > 
> > > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > 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.
> > > 
> > > OK, so we basically rsync a set of RPMs directly from EPEL and
> > > fedora every few days? If this can be automated, I'm happy with
> > > that
> > 
> > Not sure exactly what process we'll follow.  I was thinking more
> > on-demand requests to pull in new versions, but if we can automate
> > it,
> > that would be better.  Only question is links between the frontend
> > page
> > and the rpm names.
> 
> There's a loose name convention around hook names already out there, and we can keep it enforced, which will make naming easier across the board

Was more referring to the filename on the local system changing from
vdsm-hook-abcd-4.10.0-7.fc17.noarch.rpm to 
vdsm-hook-abcd-4.10.0-8.fc17.noarch.rpm and the corresponding link on
frontend page updating correctly.

Mike
> 
> > > 
> > > > > 
> > > > > >  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/
> > > 
> > > you mean https://admin.fedoraproject.org/updates/vdsm-4.10.0-7.fc17
> > > ?
> > 
> > No, those are fedora repos.  Our nightly jenkins builds pull the spec
> > from git and build based off of that.  We need the changes that
> > Federico
> > posted to get into git as well for them to be built.
> 
> So, we have two VDSM builds - one going into fedora, and one built on our build servers? Are the resulting RPMs identical?
> 
> > 
> > > 
> > > 
> > > > 
> > > > 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.
> > > 
> > > Cool, the rest will start coming in now, that Federico is building
> > > them
> > > 
> > > > 
> > > > Mike
> > > > 
> > > > > 
> > > > > > 
> > > > > > Mike
> > > > > > 
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Dan Yasny
> > > > > > > _______________________________________________
> > > > > > > Infra mailing list
> > > > > > > Infra at ovirt.org
> > > > > > > http://lists.ovirt.org/mailman/listinfo/infra
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > 
> > 
> > 
>

More information about the Infra mailing list