vdsm hooks pages at ovirt.org
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=6f33db4079b2... 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
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=6f33db4079b2... 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
----- Original Message -----
From: "Mike Burns" <mburns@redhat.com> To: "Dan Yasny" <dyasny@redhat.com> Cc: infra@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=6f33db4079b2... 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@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Regards, Dan Yasny Red Hat Israel +972 9769 2280
On Mon, 2012-08-20 at 08:23 -0400, Dan Yasny wrote:
----- Original Message -----
From: "Mike Burns" <mburns@redhat.com> To: "Dan Yasny" <dyasny@redhat.com> Cc: infra@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=6f33db4079b2...
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
----- Original Message -----
From: "Mike Burns" <mburns@redhat.com> To: "Dan Yasny" <dyasny@redhat.com> Cc: infra@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@redhat.com> To: "Dan Yasny" <dyasny@redhat.com> Cc: infra@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=6f33db4079b2...
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:
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Regards, Dan Yasny Red Hat Israel +972 9769 2280
On Mon, 2012-08-20 at 08:59 -0400, Dan Yasny wrote:
----- Original Message -----
From: "Mike Burns" <mburns@redhat.com> To: "Dan Yasny" <dyasny@redhat.com> Cc: infra@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@redhat.com> To: "Dan Yasny" <dyasny@redhat.com> Cc: infra@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=6f33db4079b2...
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:
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
----- Original Message -----
From: "Mike Burns" <mburns@redhat.com> To: "Dan Yasny" <dyasny@redhat.com> Cc: infra@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@redhat.com> To: "Dan Yasny" <dyasny@redhat.com> Cc: infra@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@redhat.com> To: "Dan Yasny" <dyasny@redhat.com> Cc: infra@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=6f33db4079b2...
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:
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Regards, Dan Yasny Red Hat Israel +972 9769 2280
On Mon, 2012-08-20 at 09:38 -0400, Dan Yasny wrote:
----- Original Message -----
From: "Mike Burns" <mburns@redhat.com> To: "Dan Yasny" <dyasny@redhat.com> Cc: infra@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@redhat.com> To: "Dan Yasny" <dyasny@redhat.com> Cc: infra@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@redhat.com> To: "Dan Yasny" <dyasny@redhat.com> Cc: infra@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=6f33db4079b2... > 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:
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@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra
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:
From: "Mike Burns" <mburns@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
=20 =20 ----- Original Message ----- 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--
----- Original Message -----
From: "Karsten 'quaid' Wade" <kwade@redhat.com> To: "Dan Yasny" <dyasny@redhat.com> Cc: "Mike Burns" <mburns@redhat.com>, infra@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@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
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--
----- Original Message -----
From: "Karsten 'quaid' Wade" <kwade@redhat.com> To: "Dan Yasny" <dyasny@redhat.com> Cc: infra@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
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@redhat.com> To: "Dan Yasny" <dyasny@redhat.com> Cc: infra@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--
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
----- Original Message -----
From: "Dave Neary" <dneary@redhat.com> To: "Karsten 'quaid' Wade" <kwade@redhat.com> Cc: infra@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
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@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--
----- Original Message -----
From: "Karsten 'quaid' Wade" <kwade@redhat.com> To: "Andrew Cathrow" <acathrow@redhat.com> Cc: infra@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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Regards, Dan Yasny Red Hat Israel +972 9769 2280
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--
----- Original Message -----
From: "Karsten 'quaid' Wade" <kwade@redhat.com> To: "Dan Yasny" <dyasny@redhat.com> Cc: infra@ovirt.org, "Andrew Cathrow" <acathrow@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
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--
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
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--
----- Original Message -----
From: "Karsten 'quaid' Wade" <kwade@redhat.com> To: "Dave Neary" <dneary@redhat.com> Cc: infra@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?
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Regards, Dan Yasny Red Hat Israel +972 9769 2280
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?
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
participants (5)
-
Andrew Cathrow -
Dan Yasny -
Dave Neary -
Karsten 'quaid' Wade -
Mike Burns