vdsm hooks pages at ovirt.org

Dan Yasny dyasny at redhat.com
Mon Aug 20 13:38:41 UTC 2012 


----- 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

> > 
> > > > 
> > > > >  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
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > 
> > > 
> > > 
> > 
> 
> 
> 

-- 



Regards, 

Dan Yasny 
Red Hat Israel 
+972 9769 2280

More information about the Infra mailing list