Re: vdsm hooks pages at ovirt.org

----- Original Message ----- > From: "Mike Burns" <mburns(a)redhat.com&gt; > To: "Dan Yasny" <dyasny(a)redhat.com&gt; > Cc: infra(a)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(a)redhat.com&gt; > > > To: "Dan Yasny" <dyasny(a)redhat.com&gt; > > > Cc: infra(a)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=6f33db407... > > > > 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(a)ovirt.org > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > > > > > > > >