On Mon, 2012-08-20 at 09:38 -0400, Dan Yasny wrote: > > ----- Original Message ----- > > From: "Mike Burns" <[email protected]> > > To: "Dan Yasny" <[email protected]> > > Cc: [email protected] > > 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" <[email protected]> > > > > To: "Dan Yasny" <[email protected]> > > > > Cc: [email protected] > > > > 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" <[email protected]> > > > > > > To: "Dan Yasny" <[email protected]> > > > > > > Cc: [email protected] > > > > > > 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 > > > > > > > [email protected] > > > > > > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Infra mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/infra
