6:03 a.m.
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
Thanks,
Dan Yasny
7:19 a.m.
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).
The big questions:
* Who is doing the original design and content seeding?
* Who will own keeping things up to date going forward?
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.
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. 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.
Mike
Thanks,
Dan Yasny
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
7:23 a.m.
----- Original Message -----
From: "Mike Burns" <mburns(a)redhat.com>
To: "Dan Yasny" <dyasny(a)redhat.com>
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
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 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
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?
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
Mike
>
> Thanks,
> Dan Yasny
> _______________________________________________
> Infra mailing list
> Infra(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
--
Regards,
Dan Yasny
Red Hat Israel
+972 9769 2280
7:32 a.m.
On Mon, 2012-08-20 at 08:23 -0400, Dan Yasny wrote:
----- Original Message -----
> From: "Mike Burns" <mburns(a)redhat.com>
> To: "Dan Yasny" <dyasny(a)redhat.com>
> 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.
>
> 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.
>
> 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.
>
> 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.
> 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/
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.
Mike
>
> Mike
>
> >
> > Thanks,
> > Dan Yasny
> > _______________________________________________
> > Infra mailing list
> > Infra(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
>
>
>
7:59 a.m.
----- Original Message -----
From: "Mike Burns" <mburns(a)redhat.com>
To: "Dan Yasny" <dyasny(a)redhat.com>
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>
> > To: "Dan Yasny" <dyasny(a)redhat.com>
> > 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
> >
> >
> >
>
--
Regards,
Dan Yasny
Red Hat Israel
+972 9769 2280
8:32 a.m.
On Mon, 2012-08-20 at 08:59 -0400, Dan Yasny wrote:
----- Original Message -----
> From: "Mike Burns" <mburns(a)redhat.com>
> To: "Dan Yasny" <dyasny(a)redhat.com>
> 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>
> > > To: "Dan Yasny" <dyasny(a)redhat.com>
> > > 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?
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.
> >
> > > 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.
>
> 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
> > >
> > >
> > >
> >
>
>
>
8:38 a.m.
----- Original Message -----
From: "Mike Burns" <mburns(a)redhat.com>
To: "Dan Yasny" <dyasny(a)redhat.com>
Cc: infra(a)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(a)redhat.com>
> > To: "Dan Yasny" <dyasny(a)redhat.com>
> > 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>
> > > > To: "Dan Yasny" <dyasny(a)redhat.com>
> > > > 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?
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(a)ovirt.org
> > > > > http://lists.ovirt.org/mailman/listinfo/infra
> > > >
> > > >
> > > >
> > >
> >
> >
> >
>
--
Regards,
Dan Yasny
Red Hat Israel
+972 9769 2280
8:43 a.m.
On Mon, 2012-08-20 at 09:38 -0400, Dan Yasny wrote:
----- Original Message -----
> From: "Mike Burns" <mburns(a)redhat.com>
> To: "Dan Yasny" <dyasny(a)redhat.com>
> Cc: infra(a)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(a)redhat.com>
> > > To: "Dan Yasny" <dyasny(a)redhat.com>
> > > 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>
> > > > > To: "Dan Yasny" <dyasny(a)redhat.com>
> > > > > 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?
>
> 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(a)ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/infra
> > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> >
>
>
>
10:16 a.m.
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5AF949B9BDCBB5268939B46C
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 08/20/2012 05:23 AM, Dan Yasny wrote:
=20
=20
----- Original Message -----
> From: "Mike Burns" <mburns(a)redhat.com> 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.
=20
I'd rather take it directly to a separate page - there's nothing more
permanent than the temporary
Because a wiki page is easier to maintain, can we use e.g.
wiki.ovirt.org/wiki/VDSM_hooks as the page?
No objection from me about using /hooks, but I will point out that there
is a higher barrier to entry for the WordPress side that makes it harder
to share maintenance.
The redirect of hooks.ovirt.org can go anywhere. (BTW, I've never tried
it, but it's possible that anyone with @redhat.com can make a Service
Desk request to get a CNAME record put in for ovirt.org. I certainly
don't need to be the bottleneck.)
- Karsten
--=20
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
--------------enig5AF949B9BDCBB5268939B46C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFQNPfi2ZIOBq0ODEERAg+GAKCLU+FJNYJ/XGPYvNhwMa1w92V/agCgpG6n
63CgzfjdH5B74wbUizzstrE=
=qXUF
-----END PGP SIGNATURE-----
--------------enig5AF949B9BDCBB5268939B46C--
10:47 a.m.
----- Original Message -----
From: "Karsten 'quaid' Wade"
<kwade(a)redhat.com>
To: "Dan Yasny" <dyasny(a)redhat.com>
Cc: "Mike Burns" <mburns(a)redhat.com>, infra(a)ovirt.org
Sent: Wednesday, 22 August, 2012 6:16:50 PM
Subject: Re: vdsm hooks pages at ovirt.org
On 08/20/2012 05:23 AM, Dan Yasny wrote:
>
>
> ----- Original Message -----
>> From: "Mike Burns" <mburns(a)redhat.com> 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
Because a wiki page is easier to maintain, can we use e.g.
wiki.ovirt.org/wiki/VDSM_hooks as the page?
Wiki pages are used by engineering, mainly to describe features and projects. I really
want the hooks to have a consumable look to them, just like https://extensions.gnome.org/
or http://gallery.zimbra.com/ or marketplace.redhat.com
This will have to be built, and will take a lot of effort, so I don't expect too many
changes there, once it's up and running, and the entry barrier is negligible, compared
to the amount of work I'll be putting in there anyway.
So if Wiki is the only choice, we'll have to use wiki, but if it's possible to do
this in a nicer, more mature-looking way, I'd rather go there
No objection from me about using /hooks, but I will point out that
there
is a higher barrier to entry for the WordPress side that makes it
harder
to share maintenance.
The redirect of hooks.ovirt.org can go anywhere. (BTW, I've never
tried
it, but it's possible that anyone with @redhat.com can make a Service
Desk request to get a CNAME record put in for ovirt.org. I certainly
don't need to be the bottleneck.)
- Karsten
--
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
--
Regards,
Dan Yasny
Red Hat Israel
+972 9769 2280
12:55 p.m.
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCD22BC247D3AD6203A456859
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 08/22/2012 08:47 AM, Dan Yasny wrote:
=20
Wiki pages are used by engineering, mainly to describe features and
projects. I really want the hooks to have a consumable look to them,
just like https://extensions.gnome.org/ or http://gallery.zimbra.com/
or marketplace.redhat.com
=20
This will have to be built, and will take a lot of effort, so I don't
expect too many changes there, once it's up and running, and the
entry barrier is negligible, compared to the amount of work I'll be
putting in there anyway.
=20
So if Wiki is the only choice, we'll have to use wiki, but if it's
possible to do this in a nicer, more mature-looking way, I'd rather
go there
It's not that the wiki is the only choice, I just didn't see an
explanation in the discussion as to why it won't suffice. I reckon I see
your point now. My only concern is if you can get the design resources
to make the look&feel. However, using WordPress at least gets you the
same look&feel as the rest of the site (including when it is updated.)
BTW, WordPress isn't a requirement either - you could build this another
way, but WordPress has some conveniences, including making it much
simpler for other people to help with maintenance.
Are these 'hooks' only going to be for VDSM? Or could there be others
for other components? I'm asking because hooks.ovirt.org is a generic
namespace, vs. vdsm-hooks.ovirt.org etc. Just want to make sure we don't
lock ourselves in to a name usage that we may not always want.
I'll add Dan as an Editor for the WordPress instance - you can always
start a page and rename it if the naming changes. I'll hold-off on
requesting the DNS addition to see what the answers to my questions are.
- Karsten
--=20
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
--------------enigCD22BC247D3AD6203A456859
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFQNRz02ZIOBq0ODEERAvfvAKCHFW/YqDH++6X4PKavXrYHXpo0/QCfV88e
Mfz9wXRIUBQfn1wfzf6vZ1g=
=zoYV
-----END PGP SIGNATURE-----
--------------enigCD22BC247D3AD6203A456859--
2:06 p.m.
----- Original Message -----
From: "Karsten 'quaid' Wade"
<kwade(a)redhat.com>
To: "Dan Yasny" <dyasny(a)redhat.com>
Cc: infra(a)ovirt.org
Sent: Wednesday, 22 August, 2012 8:55:00 PM
Subject: Re: vdsm hooks pages at ovirt.org
On 08/22/2012 08:47 AM, Dan Yasny wrote:
>
> Wiki pages are used by engineering, mainly to describe features and
> projects. I really want the hooks to have a consumable look to
> them,
> just like https://extensions.gnome.org/ or
> http://gallery.zimbra.com/
> or marketplace.redhat.com
>
> This will have to be built, and will take a lot of effort, so I
> don't
> expect too many changes there, once it's up and running, and the
> entry barrier is negligible, compared to the amount of work I'll be
> putting in there anyway.
>
> So if Wiki is the only choice, we'll have to use wiki, but if it's
> possible to do this in a nicer, more mature-looking way, I'd rather
> go there
It's not that the wiki is the only choice, I just didn't see an
explanation in the discussion as to why it won't suffice. I reckon I
see
your point now. My only concern is if you can get the design
resources
to make the look&feel. However, using WordPress at least gets you the
same look&feel as the rest of the site (including when it is
updated.)
BTW, WordPress isn't a requirement either - you could build this
another
way, but WordPress has some conveniences, including making it much
simpler for other people to help with maintenance.
What other way would that be? I'm open for suggestions, since this is quite new to me
too
Are these 'hooks' only going to be for VDSM? Or could there be others
for other components? I'm asking because hooks.ovirt.org is a generic
namespace, vs. vdsm-hooks.ovirt.org etc. Just want to make sure we
don't
lock ourselves in to a name usage that we may not always want.
Makes sense. We might also have a simpler repository for API and SDK scripts, instead of
people keeping their own githubs all over the place, but hooks are important because they
allow you to expand the functionality of oVirt in a very broad range of features
I'll add Dan as an Editor for the WordPress instance - you can always
start a page and rename it if the naming changes. I'll hold-off on
requesting the DNS addition to see what the answers to my questions
are.
OK, is there a place I can read up on getting started with wordpress? Used to play with
Joomla a few years ago, but nothing too serious
- Karsten
--
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
--
Regards,
Dan Yasny
Red Hat Israel
+972 9769 2280
3:41 p.m.
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA1045AC21057BAB95BC096E5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
BTW, I transposed letters in your name, so I just remade the account.
On 08/22/2012 12:06 PM, Dan Yasny wrote:
=20
=20
----- Original Message -----
> From: "Karsten 'quaid' Wade" <kwade(a)redhat.com> To: "Dan
Yasny"
> <dyasny(a)redhat.com> Cc: infra(a)ovirt.org Sent: Wednesday, 22 August,
> 2012 8:55:00 PM Subject: Re: vdsm hooks pages at ovirt.org
>=20
> On 08/22/2012 08:47 AM, Dan Yasny wrote:
>>=20
>> Wiki pages are used by engineering, mainly to describe features
>> and projects. I really want the hooks to have a consumable look
>> to them, just like https://extensions.gnome.org/ or=20
>> http://gallery.zimbra.com/ or marketplace.redhat.com
>>=20
>> This will have to be built, and will take a lot of effort, so I=20
>> don't expect too many changes there, once it's up and running,
>> and the entry barrier is negligible, compared to the amount of
>> work I'll be putting in there anyway.
>>=20
>> So if Wiki is the only choice, we'll have to use wiki, but if
>> it's possible to do this in a nicer, more mature-looking way, I'd
>> rather go there
>=20
> It's not that the wiki is the only choice, I just didn't see an=20
> explanation in the discussion as to why it won't suffice. I reckon
> I see your point now. My only concern is if you can get the design=20
> resources to make the look&feel. However, using WordPress at least
> gets you the same look&feel as the rest of the site (including when
> it is updated.)
>=20
> BTW, WordPress isn't a requirement either - you could build this=20
> another way, but WordPress has some conveniences, including making
> it much simpler for other people to help with maintenance.
=20
What other way would that be? I'm open for suggestions, since this is
quite new to me too
For example, we could setup /hooks as an actual sub-directory that
Apache serves up. The directory could be populated with a different
publishing framework, hand-built pages, etc. It could be automatically
generated from a git checkout, etc. It all comes down to what the VDSM
folks want to have and maintain. Using WordPress is easy, though: Infra
maintains it for the projects, it has built-in authentication, it has
the same design as the rest of the site, etc.
> Are these 'hooks' only going to be for VDSM? Or could
there be
> others for other components? I'm asking because hooks.ovirt.org is
> a generic namespace, vs. vdsm-hooks.ovirt.org etc. Just want to
> make sure we don't lock ourselves in to a name usage that we may
> not always want.
=20
Makes sense. We might also have a simpler repository for API and SDK
scripts, instead of people keeping their own githubs all over the
place, but hooks are important because they allow you to expand the
functionality of oVirt in a very broad range of features
Does this mean hooks.ovirt.org is fine to use, and could be used by
non-VDSM projects? I'm fine with api.ovirt.org, sdk.ovirt.org, etc. Just
want to make sure we are thinking about them in a nice
information-architecture as well as program-support ways.
> I'll add Dan as an Editor for the WordPress instance - you
can
> always start a page and rename it if the naming changes. I'll
> hold-off on requesting the DNS addition to see what the answers to
> my questions are.
=20
OK, is there a place I can read up on getting started with wordpress?
Used to play with Joomla a few years ago, but nothing too serious
WordPress is essentially a blog engine, but it has other features that
allow it to be a CMS - stand-alone (static) pages, categories, etc.
This is a good place to start:
http://codex.wordpress.org/Getting_Started_with_WordPress
It's a very popular website framework so there is a lot out there about
how to use it. For myself, it's usually my favorite piece of software as
a user, which says a lot because I loathe webapps. :) (It's pretty great
as a sysadmin, too.)
- Karsten
--=20
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
--------------enigA1045AC21057BAB95BC096E5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFQNUQF2ZIOBq0ODEERAuNbAJ4nT6g0qJU9clxkNTc9N2S6N/EaTQCgn9P2
sLHcCpWJArFH6cJLZbasWig=
=rPiS
-----END PGP SIGNATURE-----
--------------enigA1045AC21057BAB95BC096E5--
5:05 a.m.
Hi Karsten,
On 08/22/2012 07:55 PM, Karsten 'quaid' Wade wrote:
On 08/22/2012 08:47 AM, Dan Yasny wrote:
> Wiki pages are used by engineering, mainly to describe features and
> projects. I really want the hooks to have a consumable look to them,
> just like https://extensions.gnome.org/ or http://gallery.zimbra.com/
> or marketplace.redhat.com
>
> This will have to be built, and will take a lot of effort, so I don't
> expect too many changes there, once it's up and running, and the
> entry barrier is negligible, compared to the amount of work I'll be
> putting in there anyway.
>
> So if Wiki is the only choice, we'll have to use wiki, but if it's
> possible to do this in a nicer, more mature-looking way, I'd rather
> go there
It's not that the wiki is the only choice, I just didn't see an
explanation in the discussion as to why it won't suffice. I reckon I see
your point now. My only concern is if you can get the design resources
to make the look&feel. However, using WordPress at least gets you the
same look&feel as the rest of the site (including when it is updated.)
Just to make it clear: the idea of VDSM hooks is that they're
downloadable pieces of software (if I understand correctly, they're
usually shell or Python scripts), so in my mind a wiki isn't really
appropriate - you want users to be able to upload new hooks, order
search results based on ratings and/or download statistics for hooks,
and features like tagging, ratings, comments on a hook and versioning
are appropriate and useful.
Cheers,
Dave.
--
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
8:52 a.m.
----- Original Message -----
From: "Dave Neary" <dneary(a)redhat.com>
To: "Karsten 'quaid' Wade" <kwade(a)redhat.com>
Cc: infra(a)ovirt.org
Sent: Thursday, August 23, 2012 6:05:12 AM
Subject: Re: vdsm hooks pages at ovirt.org
Hi Karsten,
On 08/22/2012 07:55 PM, Karsten 'quaid' Wade wrote:
> On 08/22/2012 08:47 AM, Dan Yasny wrote:
>> Wiki pages are used by engineering, mainly to describe features
>> and
>> projects. I really want the hooks to have a consumable look to
>> them,
>> just like https://extensions.gnome.org/ or
>> http://gallery.zimbra.com/
>> or marketplace.redhat.com
>>
>> This will have to be built, and will take a lot of effort, so I
>> don't
>> expect too many changes there, once it's up and running, and the
>> entry barrier is negligible, compared to the amount of work I'll
>> be
>> putting in there anyway.
>>
>> So if Wiki is the only choice, we'll have to use wiki, but if it's
>> possible to do this in a nicer, more mature-looking way, I'd
>> rather
>> go there
>
> It's not that the wiki is the only choice, I just didn't see an
> explanation in the discussion as to why it won't suffice. I reckon
> I see
> your point now. My only concern is if you can get the design
> resources
> to make the look&feel. However, using WordPress at least gets you
> the
> same look&feel as the rest of the site (including when it is
> updated.)
Just to make it clear: the idea of VDSM hooks is that they're
downloadable pieces of software (if I understand correctly, they're
usually shell or Python scripts), so in my mind a wiki isn't really
appropriate - you want users to be able to upload new hooks, order
search results based on ratings and/or download statistics for hooks,
and features like tagging, ratings, comments on a hook and versioning
are appropriate and useful.
The hooks are delivered as RPMs -they need to be in a yum repo (for fedora/EL) with
web/wiki pages with help/docs/etc
Cheers,
Dave.
--
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
3:43 p.m.
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD82084699563B6450602D80E
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 08/23/2012 06:52 AM, Andrew Cathrow wrote:
=20
=20
----- Original Message -----
> From: "Dave Neary" <dneary(a)redhat.com>
>=20
> Just to make it clear: the idea of VDSM hooks is that they're=20
> downloadable pieces of software (if I understand correctly,
> they're usually shell or Python scripts), so in my mind a wiki
> isn't really appropriate - you want users to be able to upload new
> hooks, order search results based on ratings and/or download
> statistics for hooks, and features like tagging, ratings, comments
> on a hook and versioning are appropriate and useful.
=2E.. which sounds like a new web service. I can see that vision, just
figured the urgency meant we were going to take it in phases, e.g.:
1. Get up a webpage that explains each hook & links to it directly +
directions for setting up yum repo.
1.1 Do this quickly with WordPress, maybe get some design thoughts from
Garrett.
2. Based on what we learn in doing phase 1, we can figure out the
appropriate web service to grab, install, and run.
2.1 We definitely want to get UX and design help here.
What wasn't clear to me is if the hooks are specific to VDSM or generic
for oVirt. In other words, are we ordering up:
vdsm-hooks.ovirt.org =3D> ovirt.org/VDSM-hooks
or
hooks.ovirt.org =3D> ovirt.org/hooks
(We'll do the Apache config to make it whatever, but fundamentally we're
building a new tree at either /VDSM-hooks or /hooks as root, with a repo
tree underneath to start, and sporting an eventual web service.)
The hooks are delivered as RPMs -they need to be in a yum repo (for
fedora/EL) with web/wiki pages with help/docs/etc
OK, I can do the Apache work, create the directory tree, and order up
DNS as soon as $someone_who_knows confirms that the generic word 'hooks'
works, i.e. that we aren't tying up the incorrect namespace.
- Karsten
--=20
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
--------------enigD82084699563B6450602D80E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFQNpXq2ZIOBq0ODEERAmTxAKCLKnPDULTYgfSn66tRjW1MV28eRACgywiL
U9/cfDnTfpH3UxG8xiM99xI=
=+EWK
-----END PGP SIGNATURE-----
--------------enigD82084699563B6450602D80E--
4:04 p.m.
----- Original Message -----
From: "Karsten 'quaid' Wade"
<kwade(a)redhat.com>
To: "Andrew Cathrow" <acathrow(a)redhat.com>
Cc: infra(a)ovirt.org
Sent: Thursday, 23 August, 2012 11:43:22 PM
Subject: Re: vdsm hooks pages at ovirt.org
On 08/23/2012 06:52 AM, Andrew Cathrow wrote:
>
>
> ----- Original Message -----
>> From: "Dave Neary" <dneary(a)redhat.com>
>>
>> Just to make it clear: the idea of VDSM hooks is that they're
>> downloadable pieces of software (if I understand correctly,
>> they're usually shell or Python scripts), so in my mind a wiki
>> isn't really appropriate - you want users to be able to upload new
>> hooks, order search results based on ratings and/or download
>> statistics for hooks, and features like tagging, ratings, comments
>> on a hook and versioning are appropriate and useful.
... which sounds like a new web service. I can see that vision, just
figured the urgency meant we were going to take it in phases, e.g.:
1. Get up a webpage that explains each hook & links to it directly +
directions for setting up yum repo.
1.1 Do this quickly with WordPress, maybe get some design thoughts
from
Garrett.
2. Based on what we learn in doing phase 1, we can figure out the
appropriate web service to grab, install, and run.
2.1 We definitely want to get UX and design help here.
What wasn't clear to me is if the hooks are specific to VDSM or
generic
for oVirt. In other words, are we ordering up:
vdsm-hooks.ovirt.org => ovirt.org/VDSM-hooks
or
hooks.ovirt.org => ovirt.org/hooks
IMO vdsm-hooks is better, because we already have libvirt hooks out there, and who knows
what else will come up next.
(We'll do the Apache config to make it whatever, but fundamentally
we're
building a new tree at either /VDSM-hooks or /hooks as root, with a
repo
tree underneath to start, and sporting an eventual web service.)
> The hooks are delivered as RPMs -they need to be in a yum repo (for
> fedora/EL) with web/wiki pages with help/docs/etc
OK, I can do the Apache work, create the directory tree, and order up
DNS as soon as $someone_who_knows confirms that the generic word
'hooks'
works, i.e. that we aren't tying up the incorrect namespace.
- Karsten
--
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
--
Regards,
Dan Yasny
Red Hat Israel
+972 9769 2280
4:25 p.m.
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5B668CE4588CD0D007007E5A
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 08/23/2012 02:04 PM, Dan Yasny wrote:
=20
IMO vdsm-hooks is better, because we already have libvirt hooks out
there, and who knows what else will come up next.
OK, I'll request the DNS entry and setup Apache to receive.
Dan and I are planning on meeting on IRC just to go over the whole
requirement and figure out a plan. Anyone welcome to join in.
Dan - what is actually good for you? (Are you out for Fri to Sat?) We
can maybe make enough progress so we can put off the meeting until
Monday? (I could possibly do something that was late Sunday
California/early Monday Tel Aviv, or we do early Cali Monday e.g. 10 am
EDT/1400 UTC.)
- Karsten
--=20
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
--------------enig5B668CE4588CD0D007007E5A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFQNp+z2ZIOBq0ODEERAitLAKDEdDreShM2PRRa8kXaYZh4BrlTMwCeMHMv
R3fMa6twUZLisCyRnwjqWe8=
=4j/b
-----END PGP SIGNATURE-----
--------------enig5B668CE4588CD0D007007E5A--
5:01 p.m.
----- Original Message -----
From: "Karsten 'quaid' Wade"
<kwade(a)redhat.com>
To: "Dan Yasny" <dyasny(a)redhat.com>
Cc: infra(a)ovirt.org, "Andrew Cathrow" <acathrow(a)redhat.com>
Sent: Friday, 24 August, 2012 12:25:07 AM
Subject: Re: vdsm hooks pages at ovirt.org
On 08/23/2012 02:04 PM, Dan Yasny wrote:
>
> IMO vdsm-hooks is better, because we already have libvirt hooks out
> there, and who knows what else will come up next.
OK, I'll request the DNS entry and setup Apache to receive.
Dan and I are planning on meeting on IRC just to go over the whole
requirement and figure out a plan. Anyone welcome to join in.
Dan - what is actually good for you? (Are you out for Fri to Sat?) We
can maybe make enough progress so we can put off the meeting until
Monday? (I could possibly do something that was late Sunday
California/early Monday Tel Aviv, or we do early Cali Monday e.g. 10
am
EDT/1400 UTC.)
I'm out for Sat-Sun usually, but can come online if need be. Maybe set something up
via zimbra, and it will show you when I'm busy and when not
- Karsten
--
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
--
Regards,
Dan Yasny
Red Hat Israel
+972 9769 2280
5:12 p.m.
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigCCDB37146044B0F29D0092E1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 08/23/2012 03:01 PM, Dan Yasny wrote:
=20
I'm out for Sat-Sun usually, but can come online if need be. Maybe
set something up via zimbra, and it will show you when I'm busy and
when not
OK, I just picked 8 am PDT/11 am EDT/1500 UTC. We'll meet on #ovirt on
OFTC and use the meetbot to capture the actions, info, log, etc.
cheers - Karsten
--=20
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
--------------enigCCDB37146044B0F29D0092E1
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFQNqrC2ZIOBq0ODEERAspMAKDD//+ukzGLHEBz/Rv+yHYO0KvpggCfckP3
CWlDGNVdIXHaTB8zMrlqbHA=
=XAEh
-----END PGP SIGNATURE-----
--------------enigCCDB37146044B0F29D0092E1--
3:34 a.m.
Hi,
On 08/23/2012 10:43 PM, Karsten 'quaid' Wade wrote:
On 08/23/2012 06:52 AM, Andrew Cathrow wrote:
> The hooks are delivered as RPMs -they need to be in a yum repo (for
> fedora/EL) with web/wiki pages with help/docs/etc
OK, I can do the Apache work, create the directory tree, and order up
DNS as soon as $someone_who_knows confirms that the generic word 'hooks'
works, i.e. that we aren't tying up the incorrect namespace.
Has anyone figured out how to do a nice web interface to a Yum
repository yet? Something with ratings, download stats, version history,
user comments, all that nice stuff... seems like it would be a nice
side-project for someone (but then again, I have no idea what would be
involved).
Cheers,
Dave.
--
Dave Neary
Community Action and Impact
Open Source and Standards Team, Red Hat
Phone: +33 9 50 71 55 62
10:44 a.m.
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig75C648362D3A6D0BB1E62F3B
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On 08/24/2012 01:34 AM, Dave Neary wrote:
Hi,
=20
On 08/23/2012 10:43 PM, Karsten 'quaid' Wade wrote:
> On 08/23/2012 06:52 AM, Andrew Cathrow wrote:
>> The hooks are delivered as RPMs -they need to be in a yum repo (for
>> fedora/EL) with web/wiki pages with help/docs/etc
>
> OK, I can do the Apache work, create the directory tree, and order up
> DNS as soon as $someone_who_knows confirms that the generic word 'hook=
s'
> works, i.e. that we aren't tying up the incorrect namespace.
=20
Has anyone figured out how to do a nice web interface to a Yum
repository yet? Something with ratings, download stats, version history=
,
user comments, all that nice stuff... seems like it would be a nice
side-project for someone (but then again, I have no idea what would be
involved).
Something like this?
https://admin.fedoraproject.org/updates/
That is a more focused app than I think you imagine, but I bet Bodhi
could be stripped to something that was more about ratings etc. for a
single repo, with the packager workflow bits hidden.
- Karsten
--=20
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
--------------enig75C648362D3A6D0BB1E62F3B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iD8DBQFQN6Ff2ZIOBq0ODEERAuuKAKCFEHk3hi1nGNOxC/AUhfvT4pAJmACeJ3pV
4G8kdoJwNgtTR34ffkIjJEs=
=p6uH
-----END PGP SIGNATURE-----
--------------enig75C648362D3A6D0BB1E62F3B--
10:55 a.m.
----- Original Message -----
From: "Karsten 'quaid' Wade"
<kwade(a)redhat.com>
To: "Dave Neary" <dneary(a)redhat.com>
Cc: infra(a)ovirt.org
Sent: Friday, 24 August, 2012 6:44:31 PM
Subject: Re: vdsm hooks pages at ovirt.org
On 08/24/2012 01:34 AM, Dave Neary wrote:
> Hi,
>
> On 08/23/2012 10:43 PM, Karsten 'quaid' Wade wrote:
>> On 08/23/2012 06:52 AM, Andrew Cathrow wrote:
>>> The hooks are delivered as RPMs -they need to be in a yum repo
>>> (for
>>> fedora/EL) with web/wiki pages with help/docs/etc
>>
>> OK, I can do the Apache work, create the directory tree, and order
>> up
>> DNS as soon as $someone_who_knows confirms that the generic word
>> 'hooks'
>> works, i.e. that we aren't tying up the incorrect namespace.
>
> Has anyone figured out how to do a nice web interface to a Yum
> repository yet? Something with ratings, download stats, version
> history,
> user comments, all that nice stuff... seems like it would be a nice
> side-project for someone (but then again, I have no idea what would
> be
> involved).
Something like this?
https://admin.fedoraproject.org/updates/
I was thinking more about pkgs.org
That is a more focused app than I think you imagine, but I bet Bodhi
could be stripped to something that was more about ratings etc. for a
single repo, with the packager workflow bits hidden.
- Karsten
--
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org .^\ http://community.redhat.com
@quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
_______________________________________________
Infra mailing list
Infra(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra
--
Regards,
Dan Yasny
Red Hat Israel
+972 9769 2280
10:57 a.m.
Hi,
On 08/24/2012 05:44 PM, Karsten 'quaid' Wade wrote:
On 08/24/2012 01:34 AM, Dave Neary wrote:
> Has anyone figured out how to do a nice web interface to a Yum
> repository yet? Something with ratings, download stats, version history,
> user comments, all that nice stuff... seems like it would be a nice
> side-project for someone (but then again, I have no idea what would be
> involved).
Something like this?
https://admin.fedoraproject.org/updates/
I meant something lore like this: http://maemo.org/downloads/Maemo5/
Every package has its own auto-generated page, quality indicator,
average rating, download count, update history, link to bug tracker
(required by Maemo packaging guidelines) and user comments. For example:
http://maemo.org/downloads/product/Maemo5/marble-maps/
The package maintainer can also add screenshots, if he wants.
That is a more focused app than I think you imagine, but I bet Bodhi
could be stripped to something that was more about ratings etc. for a
single repo, with the packager workflow bits hidden.
That sounds wonderful - if we could make it more visually attractive,
and integrate some kind of QA on package descriptions (à la Maemo) it
would be automatically useful as you maintained and updated your software.
The key point of the Maemo way of doing things is that you had an
initial upload step where you had to fill in various product information
fields, and afterwards, as the developer you had almost nothing else to
take care of. It was great!
Cheers,
Dave.
--
Dave Neary
Community Action and Impact
Open Source and Standards, Red Hat
Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13
4262
days inactive
4266
days old
23 comments
5 participants
participants (5)
-
Andrew Cathrow -
Dan Yasny -
Dave Neary -
Karsten 'quaid' Wade -
Mike Burns