vdsm hooks pages at ovirt.org

[Dan Yasny]

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

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


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

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


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