11:16 a.m.
Interesting test I saw this morning:
http://everythingsysadmin.com/the-test.html
I think we do pretty well overall, but there's some areas we could
improve in.
kevin
11:24 a.m.
On Mon, 2011-07-25 at 10:16 -0600, Kevin Fenzi wrote:
Interesting test I saw this morning:
http://everythingsysadmin.com/the-test.html
I think we do pretty well overall, but there's some areas we could
improve in.
You're right, we don't do terribly on that list at all.
We've gotten much better at remote processes and global changes.
Some of our SoP's need to be updated but in general they are documented.
I've thought a bit about the SoPs and I've been wondering - do we want
to move them OUT of the wiki and onto infra.fp.o?
I ask specifically b/c if our stuff goes sideways - recovering
infra.fp.o is a priority but we may not know HOW to without being able
to get to the wiki webserver, let alone the db.
Just a thought...
-sv
11:31 a.m.
On Mon, Jul 25, 2011 at 12:24:09PM -0400, seth vidal wrote:
I've thought a bit about the SoPs and I've been wondering -
do we want
to move them OUT of the wiki and onto infra.fp.o?
Or have a cron job that exports them from the wiki and into static pages
on infra.fp.o, instead of moving them?
--
Ian Weller <ian(a)ianweller.org>
_
\/"/_ All Hail the Beefy Miracle!
/_/ beefymiracle.org
\ \
11:43 a.m.
On Mon, 2011-07-25 at 12:31 -0400, Ian Weller wrote:
On Mon, Jul 25, 2011 at 12:24:09PM -0400, seth vidal wrote:
> I've thought a bit about the SoPs and I've been wondering - do we want
> to move them OUT of the wiki and onto infra.fp.o?
Or have a cron job that exports them from the wiki and into static pages
on infra.fp.o, instead of moving them?
It still means editing them on the wiki which, imo, is onerous and
overkill for what they are. That might just be me, though, but I suspect
it isn't. Wiki editing is slow and cumbersome, I've found and a brief
interview with a few others in sysadmin-* bears out my suspicion..
Here's what I was thinking, actually:
infra-docs git repo on /git on infra.fp.o
docs exported on commit/push to infra.fp.o/infradocs/ or some such dir
maybe in markdown or rst - but probably just plain text to start with.
The folks who are most likely to write an SoP are going to be comfy with
a text editor, I suspect.
It means if someone goes through and mauls the wiki we don't end up with
broken docs in our DR location on infra.fp.o.
It also gives us an opportunity to sift through all of our docs in the
transition and dump out the ones that don't matter anymore or just
aren't accurate.
It would be simple to redirect all SoPs over to that site so no one gets
lost.
In general I like the idea of infra.fp.o being the one place we need to
recover to bring everything else back up and to know how to bring
everything back up.
-sv
3 p.m.
On Mon, Jul 25, 2011 at 12:43:28PM -0400, seth vidal wrote:
On Mon, 2011-07-25 at 12:31 -0400, Ian Weller wrote:
> On Mon, Jul 25, 2011 at 12:24:09PM -0400, seth vidal wrote:
> > I've thought a bit about the SoPs and I've been wondering - do we want
> > to move them OUT of the wiki and onto infra.fp.o?
>
> Or have a cron job that exports them from the wiki and into static pages
> on infra.fp.o, instead of moving them?
It still means editing them on the wiki which, imo, is onerous and
overkill for what they are. That might just be me, though, but I suspect
it isn't. Wiki editing is slow and cumbersome, I've found and a brief
interview with a few others in sysadmin-* bears out my suspicion..
Here's what I was thinking, actually:
infra-docs git repo on /git on infra.fp.o
docs exported on commit/push to infra.fp.o/infradocs/ or some such dir
maybe in markdown or rst - but probably just plain text to start with.
The folks who are most likely to write an SoP are going to be comfy with
a text editor, I suspect.
It means if someone goes through and mauls the wiki we don't end up with
broken docs in our DR location on infra.fp.o.
It also gives us an opportunity to sift through all of our docs in the
transition and dump out the ones that don't matter anymore or just
aren't accurate.
It would be simple to redirect all SoPs over to that site so no one gets
lost.
In general I like the idea of infra.fp.o being the one place we need to
recover to bring everything else back up and to know how to bring
everything back up.
I think the biggest benefits of the wiki are a table of contents (Where on
the ISOP:PKGDB page do I find something about removing a package?) and
hyperlinks. (I'm making a new release; what do I have to do in pkgdb,
mirrormanger, and bodhi?). We could do something simple like learn just
enough rst to be able to have headings and anchors then generate static html
from that using sphinx. That would give us static html with table of
contents and hyperlinks for normal use and the rst text both for editing and
when we need to read them using less during recovery.
-Toshio
3:17 p.m.
On Mon, 2011-07-25 at 13:00 -0700, Toshio Kuratomi wrote:
On Mon, Jul 25, 2011 at 12:43:28PM -0400, seth vidal wrote:
> On Mon, 2011-07-25 at 12:31 -0400, Ian Weller wrote:
> > On Mon, Jul 25, 2011 at 12:24:09PM -0400, seth vidal wrote:
> > > I've thought a bit about the SoPs and I've been wondering - do we
want
> > > to move them OUT of the wiki and onto infra.fp.o?
> >
> > Or have a cron job that exports them from the wiki and into static pages
> > on infra.fp.o, instead of moving them?
>
> It still means editing them on the wiki which, imo, is onerous and
> overkill for what they are. That might just be me, though, but I suspect
> it isn't. Wiki editing is slow and cumbersome, I've found and a brief
> interview with a few others in sysadmin-* bears out my suspicion..
>
> Here's what I was thinking, actually:
>
> infra-docs git repo on /git on infra.fp.o
>
> docs exported on commit/push to infra.fp.o/infradocs/ or some such dir
>
> maybe in markdown or rst - but probably just plain text to start with.
>
> The folks who are most likely to write an SoP are going to be comfy with
> a text editor, I suspect.
>
> It means if someone goes through and mauls the wiki we don't end up with
> broken docs in our DR location on infra.fp.o.
>
> It also gives us an opportunity to sift through all of our docs in the
> transition and dump out the ones that don't matter anymore or just
> aren't accurate.
>
> It would be simple to redirect all SoPs over to that site so no one gets
> lost.
>
> In general I like the idea of infra.fp.o being the one place we need to
> recover to bring everything else back up and to know how to bring
> everything back up.
>
I think the biggest benefits of the wiki are a table of contents (Where on
the ISOP:PKGDB page do I find something about removing a package?) and
hyperlinks. (I'm making a new release; what do I have to do in pkgdb,
mirrormanger, and bodhi?). We could do something simple like learn just
enough rst to be able to have headings and anchors then generate static html
from that using sphinx. That would give us static html with table of
contents and hyperlinks for normal use and the rst text both for editing and
when we need to read them using less during recovery.
Or, alternatively, just generate an index based on a simple 'first line
of file' mechanism. Most/all is trivial.
I guess I really think I'm more likely to read the files/docs using less
from a prompt.
it means I can use grep to look for things, too.
-sv
6:50 p.m.
On Mon, Jul 25, 2011 at 10:24, seth vidal <skvidal(a)fedoraproject.org> wrote:
On Mon, 2011-07-25 at 10:16 -0600, Kevin Fenzi wrote:
> Interesting test I saw this morning:
>
> http://everythingsysadmin.com/the-test.html
>
> I think we do pretty well overall, but there's some areas we could
> improve in.
You're right, we don't do terribly on that list at all.
We've gotten much better at remote processes and global changes.
Some of our SoP's need to be updated but in general they are documented.
I've thought a bit about the SoPs and I've been wondering - do we want
to move them OUT of the wiki and onto infra.fp.o?
Well we could put them in with the CSI documentation and keep both up
to date hand in hand.
I ask specifically b/c if our stuff goes sideways - recovering
infra.fp.o is a priority but we may not know HOW to without being able
to get to the wiki webserver, let alone the db.
Just a thought...
-sv
_______________________________________________
infrastructure mailing list
infrastructure(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
4651
days inactive
4651
days old
infrastructure@lists.fedoraproject.org
6 comments
5 participants
participants (5)
-
Ian Weller -
Kevin Fenzi -
Seth Vidal -
Stephen John Smoogen -
Toshio Kuratomi