You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by janI <ja...@apache.org> on 2013/09/04 18:36:12 UTC
requirements for vm-admins of forum/translate/wiki
Hi.
We have had some longer discussions on different ML/IRC about how a
vm-admin should behave and which level of service we expect for our servers.
We need new admins, so this is also a request for anyone interested to chip
in.
We have had some unfortunate incidents on all 3 vm, of different nature,
which made me question if we as a community:
a) want servers, that are cared for professionally or by happening.
b) want to (are capable to) maintain the servers ourself.
c) are prepared to support a change that make a), b) possible.
I have formulated some thoughts on how admins could work, but in general I
believe we should convince infra to take over the vm responsibility and
keep our well functioning forum/wiki admins.
We have a vm-team in place, that was created with the purpose of not having
a single person as admin. I my opinion the team have not lived up to that
purpose but I am still thankful for the help I have received.
Remarks the ideas below are my personal thought, which I have used during
the time where I maintained the servers:
===========
The server should at all times be maintained with the following priority:
1) security (the backside of being popular is to have the attention of
people who want to gain merit by breaking our servers)
2) stability (we have limited cpu/ram/disk so we must optimize)
3) add user wishes (we already have stable systems, 1,2 are far more
important that enhancing the systems).
Being an admin on a vm is a job that does not take soo much time, but
requires a lot of monitoring and communication (especially with infra).
A good setup would be, 3 types of admin:
Each server will have an appointed "owner" (anchor-admin)
A number of persons have full sudo on a server (admin)
A number of persons can reboot/restart/work on po files (help-admin)
=== Anchor-admin responsibilities ===
Anchor-admin is the "owner" of the vm and the prime contact to infra.
Anchor-admin has the overall responsibility of the vm.
1) help when receiving alerts
2) keep informed on available patches, especial security related patches
3) create/keep a maintenance plan
4) coordinate changes external to vm (like dns) with infra
5) participate in infra discussions relevant for the vm (e.g. certificates)
6) monitor the vm regularly for resource usage
7) secure that appl changes are implemented with relevant consensus
8) discuss work with admin, with the goal that they should be able to take
over one day.
These activities are expected to take 3-4 hours pr week, more in the
beginning and less later. The hour usage highly depend on the number and
level of admins.
=== Admin responsibilities ===
Admins help the anchor admin with ongoing maintenance and have full sudo.
All changes must be discussed and agreed with the anchor admin, no change
is so important that it cannot wait until discussed !
Admins are expected to:
1) help when receiving alerts
2) stay informed with the vm configuration
including but not limited to:
- where are which configuration done, and stored (svn/backup)
- how are the apps. configured
- read and update runbook, if something is unclear
3) participate in the regular maintenance
4) coordinate all non-scheduled work with anchor-admin
These activities are expected to take 1-2 hours pr week, more in the
beginning and less later.
Admin does not need to be specialists, we all learn, but it is important
that the admin have motivation and time to learn.
=== Help-admin responsibilities ===
Help-admins are located in different timezones, so we have 24/7 coverage
and have limited sudo (only restart/reboot/handle po files).
When a help-admin receives an alert mail, actions should be taken
1) is the vm reachable via ssh, then login else escalate to admin/infra
2) is the vm overloaded, or is apache/mysql not running
3) restart the needed processes
4) mail at least anchor-admin about with obervations and what was done.
===
remark the above are just my thoughts, there are a lot of other
possibilities.
Lets hear your opinion?
rgds
jan I.
Re: requirements for vm-admins of forum/translate/wiki
Posted by Kay Schenk <ka...@gmail.com>.
On Thu, Sep 5, 2013 at 2:56 PM, janI <ja...@apache.org> wrote:
> On 5 September 2013 22:14, Kay Schenk <ka...@gmail.com> wrote:
>
> > On Wed, Sep 4, 2013 at 9:36 AM, janI <ja...@apache.org> wrote:
> >
> > > Hi.
> > >
> > > We have had some longer discussions on different ML/IRC about how a
> > > vm-admin should behave and which level of service we expect for our
> > > servers.
> > >
> > > We need new admins, so this is also a request for anyone interested to
> > chip
> > > in.
> > >
> > > We have had some unfortunate incidents on all 3 vm, of different
> nature,
> > > which made me question if we as a community:
> > > a) want servers, that are cared for professionally or by happening.
> > > b) want to (are capable to) maintain the servers ourself.
> > > c) are prepared to support a change that make a), b) possible.
> > >
> > > I have formulated some thoughts on how admins could work, but in
> general
> > I
> > > believe we should convince infra to take over the vm responsibility and
> > > keep our well functioning forum/wiki admins.
> > >
> > > We have a vm-team in place, that was created with the purpose of not
> > having
> > > a single person as admin. I my opinion the team have not lived up to
> that
> > > purpose but I am still thankful for the help I have received.
> > >
> > > Remarks the ideas below are my personal thought, which I have used
> during
> > > the time where I maintained the servers:
> > >
> > > ===========
> > > The server should at all times be maintained with the following
> priority:
> > > 1) security (the backside of being popular is to have the attention of
> > > people who want to gain merit by breaking our servers)
> > > 2) stability (we have limited cpu/ram/disk so we must optimize)
> > > 3) add user wishes (we already have stable systems, 1,2 are far more
> > > important that enhancing the systems).
> > >
> > > Being an admin on a vm is a job that does not take soo much time, but
> > > requires a lot of monitoring and communication (especially with infra).
> > >
> > > A good setup would be, 3 types of admin:
> > > Each server will have an appointed "owner" (anchor-admin)
> > > A number of persons have full sudo on a server (admin)
> > > A number of persons can reboot/restart/work on po files (help-admin)
> > >
> > > === Anchor-admin responsibilities ===
> > > Anchor-admin is the "owner" of the vm and the prime contact to infra.
> > >
> > > Anchor-admin has the overall responsibility of the vm.
> > > 1) help when receiving alerts
> > > 2) keep informed on available patches, especial security related
> patches
> > > 3) create/keep a maintenance plan
> > > 4) coordinate changes external to vm (like dns) with infra
> > > 5) participate in infra discussions relevant for the vm (e.g.
> > certificates)
> > > 6) monitor the vm regularly for resource usage
> > > 7) secure that appl changes are implemented with relevant consensus
> > > 8) discuss work with admin, with the goal that they should be able to
> > take
> > > over one day.
> > >
> > > These activities are expected to take 3-4 hours pr week, more in the
> > > beginning and less later. The hour usage highly depend on the number
> and
> > > level of admins.
> > >
> > > === Admin responsibilities ===
> > > Admins help the anchor admin with ongoing maintenance and have full
> sudo.
> > >
> > > All changes must be discussed and agreed with the anchor admin, no
> change
> > > is so important that it cannot wait until discussed !
> > >
> > > Admins are expected to:
> > > 1) help when receiving alerts
> > > 2) stay informed with the vm configuration
> > > including but not limited to:
> > > - where are which configuration done, and stored (svn/backup)
> > > - how are the apps. configured
> > > - read and update runbook, if something is unclear
> > > 3) participate in the regular maintenance
> > > 4) coordinate all non-scheduled work with anchor-admin
> > >
> > > These activities are expected to take 1-2 hours pr week, more in the
> > > beginning and less later.
> > >
> > > Admin does not need to be specialists, we all learn, but it is
> important
> > > that the admin have motivation and time to learn.
> > >
> > >
> > > === Help-admin responsibilities ===
> > > Help-admins are located in different timezones, so we have 24/7
> coverage
> > > and have limited sudo (only restart/reboot/handle po files).
> > >
> > > When a help-admin receives an alert mail, actions should be taken
> > > 1) is the vm reachable via ssh, then login else escalate to admin/infra
> > > 2) is the vm overloaded, or is apache/mysql not running
> > > 3) restart the needed processes
> > > 4) mail at least anchor-admin about with obervations and what was done.
> > >
> > >
> > > ===
> > > remark the above are just my thoughts, there are a lot of other
> > > possibilities.
> > >
> > > Lets hear your opinion?
> > >
> > > rgds
> > > jan I.
> > >
> >
> > I would like to discuss this topic further, much further as a matter of
> > fact, but right now I don't really have enough information.
> >
> > Can you provide details on the following 9or point to document that
> > describes this):
> >
> > * to aid our memories, who are the current vm-team
> >
> jürgen, andrea, imacat, arist and myself.
>
>
> > * what are the three servers now under the vm-team
> >
> ooo-wiki-vm2.a.o (wiki.openoffice.org), ooo-forums-vm.a.o (
> forums.openoffice.org), translate-vm2.a.o
>
>
> Our servers also depend on erebus.a.o which are proxy server for HTTPS.
>
> * what vm-OS does each use
> >
> ubuntu 12.04 (I have standardized that part).
>
>
> > * for each server, what are the specific applications a vm-sysadmin would
> > need to know/become familiar with to be an effective sysadmin
> >
> for all 3 systems:
> - ubuntu, especially apt-get, apparmor
> - httpd, local installation as defined in ASF
> - php, generic installation
> - puppet, config as defined in ASF
> - sshd, config as defined in ASF
> - svn, usage depend on the single server, but in general all static changes
> are defined here
> - apbackup, as used by ASF
> - memcached
> - mysql
> - /root/bin, helper scripts
> - security applications, as defined in ASF (details are on purpose not
> given to a public list).
>
> For ooo-wiki:
> - wikimedia
> - ATS
>
> For ooo-forums
> - php2bb (remark multiforum setup with links)
>
> For translate
> - pootle
> - django
>
>
> * how are alerts on system failure currently handled
> >
> Nagios and circonus standard setup. Detected alerts goes to #asfinfra,
> infra-team and vm-team.
>
>
>
> > * what resources would a vm-admin need to respond to a system failure
> >
> ??? I am not sure I understand what you mean.
>
> help-admin, would restart/reboot system
> admin, would locate problem, try to fix it
>
OK, on this...basically ssh access to server vm for starters .
On this mention, ssh w/ password or keys?
>
> >
> >
> > Your role outline is good, but I think before we discuss future strategy,
> > we need a better idea about what's involved.
> >
> Or maybe we need someone that are interested before discussing
> theoretically. The Items I listed above, should all be obvious to people
> with SA experience.
>
> We can dream about strategies, but if we dont have volunteers, or the
> people that volunteered dont do the job, its seems to be wrong way.
Well this is certainly true. That is why I thought outlining skills like
this would be helpful.
> The
> vm-team was defined for that purpose, but I dont think the vm-team, apart
> from me, have responded to a single alert.
Well that is disappointing to say the least. A statement like you just made
really plays into the long term plans for these VMs in my mind.
> Arist helped me a lot with
> changing mysql on forum, but that about all the help I have received.
>
> Our current problem, is much more that the current admins do what they like
> to do, instead of following an organized plan. We do not need more people,
> we need people who care and do something as a team.
>
> rgds
> jan I.
>
OK, thanks for this response. Let's see how this analysis/discussion goes.
>
>
>
>
> >
> >
> >
> >
> >
> >
> >
> > --
> >
> >
> -------------------------------------------------------------------------------------------------
> > MzK
> >
> > "Truth is stranger than fiction, but it is because Fiction is obliged
> > to stick to possibilities. Truth isn't."
> > -- "Following the Equator", Mark Twain
> >
>
--
-------------------------------------------------------------------------------------------------
MzK
"Truth is stranger than fiction, but it is because Fiction is obliged
to stick to possibilities. Truth isn't."
-- "Following the Equator", Mark Twain
Re: requirements for vm-admins of forum/translate/wiki
Posted by janI <ja...@apache.org>.
On 5 September 2013 22:14, Kay Schenk <ka...@gmail.com> wrote:
> On Wed, Sep 4, 2013 at 9:36 AM, janI <ja...@apache.org> wrote:
>
> > Hi.
> >
> > We have had some longer discussions on different ML/IRC about how a
> > vm-admin should behave and which level of service we expect for our
> > servers.
> >
> > We need new admins, so this is also a request for anyone interested to
> chip
> > in.
> >
> > We have had some unfortunate incidents on all 3 vm, of different nature,
> > which made me question if we as a community:
> > a) want servers, that are cared for professionally or by happening.
> > b) want to (are capable to) maintain the servers ourself.
> > c) are prepared to support a change that make a), b) possible.
> >
> > I have formulated some thoughts on how admins could work, but in general
> I
> > believe we should convince infra to take over the vm responsibility and
> > keep our well functioning forum/wiki admins.
> >
> > We have a vm-team in place, that was created with the purpose of not
> having
> > a single person as admin. I my opinion the team have not lived up to that
> > purpose but I am still thankful for the help I have received.
> >
> > Remarks the ideas below are my personal thought, which I have used during
> > the time where I maintained the servers:
> >
> > ===========
> > The server should at all times be maintained with the following priority:
> > 1) security (the backside of being popular is to have the attention of
> > people who want to gain merit by breaking our servers)
> > 2) stability (we have limited cpu/ram/disk so we must optimize)
> > 3) add user wishes (we already have stable systems, 1,2 are far more
> > important that enhancing the systems).
> >
> > Being an admin on a vm is a job that does not take soo much time, but
> > requires a lot of monitoring and communication (especially with infra).
> >
> > A good setup would be, 3 types of admin:
> > Each server will have an appointed "owner" (anchor-admin)
> > A number of persons have full sudo on a server (admin)
> > A number of persons can reboot/restart/work on po files (help-admin)
> >
> > === Anchor-admin responsibilities ===
> > Anchor-admin is the "owner" of the vm and the prime contact to infra.
> >
> > Anchor-admin has the overall responsibility of the vm.
> > 1) help when receiving alerts
> > 2) keep informed on available patches, especial security related patches
> > 3) create/keep a maintenance plan
> > 4) coordinate changes external to vm (like dns) with infra
> > 5) participate in infra discussions relevant for the vm (e.g.
> certificates)
> > 6) monitor the vm regularly for resource usage
> > 7) secure that appl changes are implemented with relevant consensus
> > 8) discuss work with admin, with the goal that they should be able to
> take
> > over one day.
> >
> > These activities are expected to take 3-4 hours pr week, more in the
> > beginning and less later. The hour usage highly depend on the number and
> > level of admins.
> >
> > === Admin responsibilities ===
> > Admins help the anchor admin with ongoing maintenance and have full sudo.
> >
> > All changes must be discussed and agreed with the anchor admin, no change
> > is so important that it cannot wait until discussed !
> >
> > Admins are expected to:
> > 1) help when receiving alerts
> > 2) stay informed with the vm configuration
> > including but not limited to:
> > - where are which configuration done, and stored (svn/backup)
> > - how are the apps. configured
> > - read and update runbook, if something is unclear
> > 3) participate in the regular maintenance
> > 4) coordinate all non-scheduled work with anchor-admin
> >
> > These activities are expected to take 1-2 hours pr week, more in the
> > beginning and less later.
> >
> > Admin does not need to be specialists, we all learn, but it is important
> > that the admin have motivation and time to learn.
> >
> >
> > === Help-admin responsibilities ===
> > Help-admins are located in different timezones, so we have 24/7 coverage
> > and have limited sudo (only restart/reboot/handle po files).
> >
> > When a help-admin receives an alert mail, actions should be taken
> > 1) is the vm reachable via ssh, then login else escalate to admin/infra
> > 2) is the vm overloaded, or is apache/mysql not running
> > 3) restart the needed processes
> > 4) mail at least anchor-admin about with obervations and what was done.
> >
> >
> > ===
> > remark the above are just my thoughts, there are a lot of other
> > possibilities.
> >
> > Lets hear your opinion?
> >
> > rgds
> > jan I.
> >
>
> I would like to discuss this topic further, much further as a matter of
> fact, but right now I don't really have enough information.
>
> Can you provide details on the following 9or point to document that
> describes this):
>
> * to aid our memories, who are the current vm-team
>
jürgen, andrea, imacat, arist and myself.
> * what are the three servers now under the vm-team
>
ooo-wiki-vm2.a.o (wiki.openoffice.org), ooo-forums-vm.a.o (
forums.openoffice.org), translate-vm2.a.o
Our servers also depend on erebus.a.o which are proxy server for HTTPS.
* what vm-OS does each use
>
ubuntu 12.04 (I have standardized that part).
> * for each server, what are the specific applications a vm-sysadmin would
> need to know/become familiar with to be an effective sysadmin
>
for all 3 systems:
- ubuntu, especially apt-get, apparmor
- httpd, local installation as defined in ASF
- php, generic installation
- puppet, config as defined in ASF
- sshd, config as defined in ASF
- svn, usage depend on the single server, but in general all static changes
are defined here
- apbackup, as used by ASF
- memcached
- mysql
- /root/bin, helper scripts
- security applications, as defined in ASF (details are on purpose not
given to a public list).
For ooo-wiki:
- wikimedia
- ATS
For ooo-forums
- php2bb (remark multiforum setup with links)
For translate
- pootle
- django
* how are alerts on system failure currently handled
>
Nagios and circonus standard setup. Detected alerts goes to #asfinfra,
infra-team and vm-team.
> * what resources would a vm-admin need to respond to a system failure
>
??? I am not sure I understand what you mean.
help-admin, would restart/reboot system
admin, would locate problem, try to fix it
>
>
> Your role outline is good, but I think before we discuss future strategy,
> we need a better idea about what's involved.
>
Or maybe we need someone that are interested before discussing
theoretically. The Items I listed above, should all be obvious to people
with SA experience.
We can dream about strategies, but if we dont have volunteers, or the
people that volunteered dont do the job, its seems to be wrong way. The
vm-team was defined for that purpose, but I dont think the vm-team, apart
from me, have responded to a single alert. Arist helped me a lot with
changing mysql on forum, but that about all the help I have received.
Our current problem, is much more that the current admins do what they like
to do, instead of following an organized plan. We do not need more people,
we need people who care and do something as a team.
rgds
jan I.
>
>
>
>
>
>
>
> --
>
> -------------------------------------------------------------------------------------------------
> MzK
>
> "Truth is stranger than fiction, but it is because Fiction is obliged
> to stick to possibilities. Truth isn't."
> -- "Following the Equator", Mark Twain
>
Re: requirements for vm-admins of forum/translate/wiki
Posted by Kay Schenk <ka...@gmail.com>.
On Wed, Sep 4, 2013 at 9:36 AM, janI <ja...@apache.org> wrote:
> Hi.
>
> We have had some longer discussions on different ML/IRC about how a
> vm-admin should behave and which level of service we expect for our
> servers.
>
> We need new admins, so this is also a request for anyone interested to chip
> in.
>
> We have had some unfortunate incidents on all 3 vm, of different nature,
> which made me question if we as a community:
> a) want servers, that are cared for professionally or by happening.
> b) want to (are capable to) maintain the servers ourself.
> c) are prepared to support a change that make a), b) possible.
>
> I have formulated some thoughts on how admins could work, but in general I
> believe we should convince infra to take over the vm responsibility and
> keep our well functioning forum/wiki admins.
>
> We have a vm-team in place, that was created with the purpose of not having
> a single person as admin. I my opinion the team have not lived up to that
> purpose but I am still thankful for the help I have received.
>
> Remarks the ideas below are my personal thought, which I have used during
> the time where I maintained the servers:
>
> ===========
> The server should at all times be maintained with the following priority:
> 1) security (the backside of being popular is to have the attention of
> people who want to gain merit by breaking our servers)
> 2) stability (we have limited cpu/ram/disk so we must optimize)
> 3) add user wishes (we already have stable systems, 1,2 are far more
> important that enhancing the systems).
>
> Being an admin on a vm is a job that does not take soo much time, but
> requires a lot of monitoring and communication (especially with infra).
>
> A good setup would be, 3 types of admin:
> Each server will have an appointed "owner" (anchor-admin)
> A number of persons have full sudo on a server (admin)
> A number of persons can reboot/restart/work on po files (help-admin)
>
> === Anchor-admin responsibilities ===
> Anchor-admin is the "owner" of the vm and the prime contact to infra.
>
> Anchor-admin has the overall responsibility of the vm.
> 1) help when receiving alerts
> 2) keep informed on available patches, especial security related patches
> 3) create/keep a maintenance plan
> 4) coordinate changes external to vm (like dns) with infra
> 5) participate in infra discussions relevant for the vm (e.g. certificates)
> 6) monitor the vm regularly for resource usage
> 7) secure that appl changes are implemented with relevant consensus
> 8) discuss work with admin, with the goal that they should be able to take
> over one day.
>
> These activities are expected to take 3-4 hours pr week, more in the
> beginning and less later. The hour usage highly depend on the number and
> level of admins.
>
> === Admin responsibilities ===
> Admins help the anchor admin with ongoing maintenance and have full sudo.
>
> All changes must be discussed and agreed with the anchor admin, no change
> is so important that it cannot wait until discussed !
>
> Admins are expected to:
> 1) help when receiving alerts
> 2) stay informed with the vm configuration
> including but not limited to:
> - where are which configuration done, and stored (svn/backup)
> - how are the apps. configured
> - read and update runbook, if something is unclear
> 3) participate in the regular maintenance
> 4) coordinate all non-scheduled work with anchor-admin
>
> These activities are expected to take 1-2 hours pr week, more in the
> beginning and less later.
>
> Admin does not need to be specialists, we all learn, but it is important
> that the admin have motivation and time to learn.
>
>
> === Help-admin responsibilities ===
> Help-admins are located in different timezones, so we have 24/7 coverage
> and have limited sudo (only restart/reboot/handle po files).
>
> When a help-admin receives an alert mail, actions should be taken
> 1) is the vm reachable via ssh, then login else escalate to admin/infra
> 2) is the vm overloaded, or is apache/mysql not running
> 3) restart the needed processes
> 4) mail at least anchor-admin about with obervations and what was done.
>
>
> ===
> remark the above are just my thoughts, there are a lot of other
> possibilities.
>
> Lets hear your opinion?
>
> rgds
> jan I.
>
I would like to discuss this topic further, much further as a matter of
fact, but right now I don't really have enough information.
Can you provide details on the following 9or point to document that
describes this):
* to aid our memories, who are the current vm-team
* what are the three servers now under the vm-team
* what vm-OS does each use
* for each server, what are the specific applications a vm-sysadmin would
need to know/become familiar with to be an effective sysadmin
* how are alerts on system failure currently handled
* what resources would a vm-admin need to respond to a system failure
Your role outline is good, but I think before we discuss future strategy,
we need a better idea about what's involved.
--
-------------------------------------------------------------------------------------------------
MzK
"Truth is stranger than fiction, but it is because Fiction is obliged
to stick to possibilities. Truth isn't."
-- "Following the Equator", Mark Twain
Re: requirements for vm-admins of forum/translate/wiki
Posted by Andrea Pescetti <pe...@apache.org>.
Rob Weir wrote:
> (Note: I'm not talking about "configuration". I'm talking about
> website content, things like logos, contact information, terms and
> conditions, copyright statements, etc.) ...
> So this is not an either/or question. We should both have an active
> admin team as well as move toward allowing committers to maintain the
> content of our websites.
If they are different issues, let's focus on getting the first one
(admin team) solved.
I believe that if we have active "web admins" (meaning people who have
extended privileges, but through the web interface only, like it already
happens for the Forums) the use case for the second one ("committer as
maintainers") is very limited. And I don't expect that with the future
(or current) setup you will have to wait one month to get Google
Analytics integrated if it is something that can be done in a few
minutes. I prefer that we leave the maintenance to admins who adhere to
a "code of conduct" like the one Jan drafted; if this becomes a
bottleneck, we can see what to do, but this will depend on the specific
application anyway.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: requirements for vm-admins of forum/translate/wiki
Posted by Daniel Shahaf <da...@apache.org>.
Rob Weir wrote on Sun, Sep 08, 2013 at 18:11:19 -0400:
> On Sun, Sep 8, 2013 at 5:40 PM, Andrea Pescetti <pe...@apache.org> wrote:
> > On 04/09/2013 Rob Weir wrote:
> >>
> >> On Wed, Sep 4, 2013 at 12:36 PM, janI wrote:
> >>
> >> I assume we want well-maintained servers that help us get our
> >> project-related tasks done, and also help serve our users.
> >
> >
> > Yes we do. And Jan's proposal seems very reasonable and dictated from
> > experience (both personal experience and the experience of actually
> > maintaining these servers).
> >
> >
> >>> some thoughts on how admins could work, but in general I
> >>> believe we should convince infra to take over the vm responsibility and
> >>> keep our well functioning forum/wiki admins.
> >
> >
> > Last time we approached Infra on this, their answer was: find resources
> > (people) within the OpenOffice project to take care of the non-standard
> > tools (MediaWiki, phpBB) and Infra can be there as a backup. I believe they
> > helped a bit respecting these lines so far.
> >
> > Handing over to Infra would indeed be "peace of mind" for us, but I still
> > think that your proposal makes sense in light of the above: Infra prefers
> > that project-specific tools are maintained by the project itself as a
> > first/primary contact, and escalate to Infra if needed.
> >
> > By the way, if you believe that Infra could now be available to support us
> > more closely, feel free to investigate.
> >
> >
> >> maybe
> >> 3b) Try to evolve systems so users can implement their own wishes, in
> >> a way compatible with 1) and 2). For example, if routine logos and
> >> footers are synched to resources in the project's SVN tree, then any
> >> committer can update things.
> >
> >
> > This is not feasible in the current state. Even ignoring the fact that this
> > issue derailed the discussion, I see no benefit in implementing this: if we
> > have a real (reasonable active) team maintaining the servers, and the team
> > is not a bottleneck for the community, we will be fine with it. I won't feel
> > "excluded" if I have to ask someone to change some configuration: this
> > routinely happens for Infra-maintained services, or for our Bugzilla, and it
> > works.
> >
>
> That does not match my experience at all. From trying to get the
> terms and conditions statement on the Forum to integrating Google
> Analytic across the websites to rolling out the new logo, my
> experience has been that getting simple content changes make to the
> VMs has been very frustrating. Some of these changes took months.
>
> (Note: I'm not talking about "configuration". I'm talking about
> website content, things like logos, contact information, terms and
> conditions, copyright statements, etc.)
>
> You say that if we had active admin teams maintaining the servers,
> this would be easier. But we don't have such a team So these changes
> have been painful. Considering the admins are scarce and their time
> is precious, I'd like to find ways that we can allow some degree of
> "self- service" for committers, so we don't waste admin time on
> trivial content changes. Have the admins focus on things that only
> they can do.
>
I'd also like to point out that allowing any committer to make changes
--- when that is easy to implement, does not raise security or privacy
issues, and does not lead to abuse --- makes the project more
inclusionary, which is a good thing.
It's not unlike enabling non-committers to review patches.
Daniel
> So this is not an either/or question. We should both have an active
> admin team as well as move toward allowing committers to maintain the
> content of our websites.
>
> Regards,
>
> -Rob
>
> >
> >>> A good setup would be, 3 types of admin:
> >>> Each server will have an appointed "owner" (anchor-admin)
> >>> A number of persons have full sudo on a server (admin)
> >>> A number of persons can reboot/restart/work on po files (help-admin)
> >
> >
> > Something that we might discuss (but I guess this is implicit in your
> > proposal) is to avoid that the same person is the "anchor-admin" (or
> > "contact-admin", i.e., the first point of contact) for all the three
> > machines. This might help in sharing the knowledge and mitigate the
> > "loneliness" you have experienced so far in maintaining our infrastructure.
> >
> > It would actually make a lot of sense that you continue to be the
> > "main/anchor-admin" for at least one of the machines, so that the other
> > machines can be smoothly transitioned and that the whole knowledge, not only
> > what's written in the documentation, can be shared.
> >
> > Regards,
> > Andrea.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: requirements for vm-admins of forum/translate/wiki
Posted by Rob Weir <ro...@apache.org>.
On Sun, Sep 8, 2013 at 5:40 PM, Andrea Pescetti <pe...@apache.org> wrote:
> On 04/09/2013 Rob Weir wrote:
>>
>> On Wed, Sep 4, 2013 at 12:36 PM, janI wrote:
>>
>> I assume we want well-maintained servers that help us get our
>> project-related tasks done, and also help serve our users.
>
>
> Yes we do. And Jan's proposal seems very reasonable and dictated from
> experience (both personal experience and the experience of actually
> maintaining these servers).
>
>
>>> some thoughts on how admins could work, but in general I
>>> believe we should convince infra to take over the vm responsibility and
>>> keep our well functioning forum/wiki admins.
>
>
> Last time we approached Infra on this, their answer was: find resources
> (people) within the OpenOffice project to take care of the non-standard
> tools (MediaWiki, phpBB) and Infra can be there as a backup. I believe they
> helped a bit respecting these lines so far.
>
> Handing over to Infra would indeed be "peace of mind" for us, but I still
> think that your proposal makes sense in light of the above: Infra prefers
> that project-specific tools are maintained by the project itself as a
> first/primary contact, and escalate to Infra if needed.
>
> By the way, if you believe that Infra could now be available to support us
> more closely, feel free to investigate.
>
>
>> maybe
>> 3b) Try to evolve systems so users can implement their own wishes, in
>> a way compatible with 1) and 2). For example, if routine logos and
>> footers are synched to resources in the project's SVN tree, then any
>> committer can update things.
>
>
> This is not feasible in the current state. Even ignoring the fact that this
> issue derailed the discussion, I see no benefit in implementing this: if we
> have a real (reasonable active) team maintaining the servers, and the team
> is not a bottleneck for the community, we will be fine with it. I won't feel
> "excluded" if I have to ask someone to change some configuration: this
> routinely happens for Infra-maintained services, or for our Bugzilla, and it
> works.
>
That does not match my experience at all. From trying to get the
terms and conditions statement on the Forum to integrating Google
Analytic across the websites to rolling out the new logo, my
experience has been that getting simple content changes make to the
VMs has been very frustrating. Some of these changes took months.
(Note: I'm not talking about "configuration". I'm talking about
website content, things like logos, contact information, terms and
conditions, copyright statements, etc.)
You say that if we had active admin teams maintaining the servers,
this would be easier. But we don't have such a team So these changes
have been painful. Considering the admins are scarce and their time
is precious, I'd like to find ways that we can allow some degree of
"self- service" for committers, so we don't waste admin time on
trivial content changes. Have the admins focus on things that only
they can do.
So this is not an either/or question. We should both have an active
admin team as well as move toward allowing committers to maintain the
content of our websites.
Regards,
-Rob
>
>>> A good setup would be, 3 types of admin:
>>> Each server will have an appointed "owner" (anchor-admin)
>>> A number of persons have full sudo on a server (admin)
>>> A number of persons can reboot/restart/work on po files (help-admin)
>
>
> Something that we might discuss (but I guess this is implicit in your
> proposal) is to avoid that the same person is the "anchor-admin" (or
> "contact-admin", i.e., the first point of contact) for all the three
> machines. This might help in sharing the knowledge and mitigate the
> "loneliness" you have experienced so far in maintaining our infrastructure.
>
> It would actually make a lot of sense that you continue to be the
> "main/anchor-admin" for at least one of the machines, so that the other
> machines can be smoothly transitioned and that the whole knowledge, not only
> what's written in the documentation, can be shared.
>
> Regards,
> Andrea.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: requirements for vm-admins of forum/translate/wiki
Posted by janI <ja...@apache.org>.
On 8 September 2013 23:40, Andrea Pescetti <pe...@apache.org> wrote:
> On 04/09/2013 Rob Weir wrote:
>
>> On Wed, Sep 4, 2013 at 12:36 PM, janI wrote:
>>
>> I assume we want well-maintained servers that help us get our
>> project-related tasks done, and also help serve our users.
>>
>
> Yes we do. And Jan's proposal seems very reasonable and dictated from
> experience (both personal experience and the experience of actually
> maintaining these servers).
>
>
> some thoughts on how admins could work, but in general I
>>> believe we should convince infra to take over the vm responsibility and
>>> keep our well functioning forum/wiki admins.
>>>
>>
> Last time we approached Infra on this, their answer was: find resources
> (people) within the OpenOffice project to take care of the non-standard
> tools (MediaWiki, phpBB) and Infra can be there as a backup. I believe they
> helped a bit respecting these lines so far.
>
> Handing over to Infra would indeed be "peace of mind" for us, but I still
> think that your proposal makes sense in light of the above: Infra prefers
> that project-specific tools are maintained by the project itself as a
> first/primary contact, and escalate to Infra if needed.
>
> By the way, if you believe that Infra could now be available to support us
> more closely, feel free to investigate.
>
>
> maybe
>> 3b) Try to evolve systems so users can implement their own wishes, in
>> a way compatible with 1) and 2). For example, if routine logos and
>> footers are synched to resources in the project's SVN tree, then any
>> committer can update things.
>>
>
> This is not feasible in the current state. Even ignoring the fact that
> this issue derailed the discussion, I see no benefit in implementing this:
> if we have a real (reasonable active) team maintaining the servers, and the
> team is not a bottleneck for the community, we will be fine with it. I
> won't feel "excluded" if I have to ask someone to change some
> configuration: this routinely happens for Infra-maintained services, or for
> our Bugzilla, and it works.
>
>
> A good setup would be, 3 types of admin:
>>> Each server will have an appointed "owner" (anchor-admin)
>>> A number of persons have full sudo on a server (admin)
>>> A number of persons can reboot/restart/work on po files (help-admin)
>>>
>>
> Something that we might discuss (but I guess this is implicit in your
> proposal) is to avoid that the same person is the "anchor-admin" (or
> "contact-admin", i.e., the first point of contact) for all the three
> machines. This might help in sharing the knowledge and mitigate the
> "loneliness" you have experienced so far in maintaining our infrastructure.
>
just a short clarification, when I wrote this proposal, my intention was to
offer being "anchor-admin" for all 3 vms for a shorter period, and hope one
of the admins would like to more involved, so that person could in due time
take over some or all of the vms. My experience with the vm-team is that it
will be hard enough to find active admins.
It would actually make a lot of sense that you continue to be the
> "main/anchor-admin" for at least one of the machines, so that the other
> machines can be smoothly transitioned and that the whole knowledge, not
> only what's written in the documentation, can be shared.
>
Since I wrote this proposal a lot of things have happened and with the
current environment, this is a challenge I am not ready for.
I think this discussion is valuable and once consensus is reached, I will
(like hopefully the rest of the vm-team) take a closer look and see if it
fits with what I believe in.
rgds
jan I.
>
>
> Regards,
> Andrea.
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: requirements for vm-admins of forum/translate/wiki
Posted by Andrea Pescetti <pe...@apache.org>.
On 04/09/2013 Rob Weir wrote:
> On Wed, Sep 4, 2013 at 12:36 PM, janI wrote:
> I assume we want well-maintained servers that help us get our
> project-related tasks done, and also help serve our users.
Yes we do. And Jan's proposal seems very reasonable and dictated from
experience (both personal experience and the experience of actually
maintaining these servers).
>> some thoughts on how admins could work, but in general I
>> believe we should convince infra to take over the vm responsibility and
>> keep our well functioning forum/wiki admins.
Last time we approached Infra on this, their answer was: find resources
(people) within the OpenOffice project to take care of the non-standard
tools (MediaWiki, phpBB) and Infra can be there as a backup. I believe
they helped a bit respecting these lines so far.
Handing over to Infra would indeed be "peace of mind" for us, but I
still think that your proposal makes sense in light of the above: Infra
prefers that project-specific tools are maintained by the project itself
as a first/primary contact, and escalate to Infra if needed.
By the way, if you believe that Infra could now be available to support
us more closely, feel free to investigate.
> maybe
> 3b) Try to evolve systems so users can implement their own wishes, in
> a way compatible with 1) and 2). For example, if routine logos and
> footers are synched to resources in the project's SVN tree, then any
> committer can update things.
This is not feasible in the current state. Even ignoring the fact that
this issue derailed the discussion, I see no benefit in implementing
this: if we have a real (reasonable active) team maintaining the
servers, and the team is not a bottleneck for the community, we will be
fine with it. I won't feel "excluded" if I have to ask someone to change
some configuration: this routinely happens for Infra-maintained
services, or for our Bugzilla, and it works.
>> A good setup would be, 3 types of admin:
>> Each server will have an appointed "owner" (anchor-admin)
>> A number of persons have full sudo on a server (admin)
>> A number of persons can reboot/restart/work on po files (help-admin)
Something that we might discuss (but I guess this is implicit in your
proposal) is to avoid that the same person is the "anchor-admin" (or
"contact-admin", i.e., the first point of contact) for all the three
machines. This might help in sharing the knowledge and mitigate the
"loneliness" you have experienced so far in maintaining our infrastructure.
It would actually make a lot of sense that you continue to be the
"main/anchor-admin" for at least one of the machines, so that the other
machines can be smoothly transitioned and that the whole knowledge, not
only what's written in the documentation, can be shared.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: requirements for vm-admins of forum/translate/wiki
Posted by janI <ja...@apache.org>.
On 8 September 2013 14:29, Rob Weir <ro...@apache.org> wrote:
> On Sat, Sep 7, 2013 at 5:24 AM, janI <ja...@apache.org> wrote:
> > On 6 September 2013 19:49, Rob Weir <ro...@apache.org> wrote:
> >
> >> On Fri, Sep 6, 2013 at 12:14 PM, janI <ja...@apache.org> wrote:
> >> > On 6 September 2013 15:27, Dave Fisher <da...@comcast.net> wrote:
> >> >
> >> >>
> >> >> On Sep 4, 2013, at 11:37 PM, Jürgen Schmidt wrote:
> >> >>
> >> >> > On 9/4/13 10:17 PM, Rob Weir wrote:
> >> >> >> On Wed, Sep 4, 2013 at 12:36 PM, janI <ja...@apache.org> wrote:
> >> >> >>> Hi.
> >> >> >>>
> >> >> >>> We have had some longer discussions on different ML/IRC about
> how a
> >> >> >>> vm-admin should behave and which level of service we expect for
> our
> >> >> servers.
> >> >> >>>
> >> >> >>> We need new admins, so this is also a request for anyone
> interested
> >> to
> >> >> chip
> >> >> >>> in.
> >> >> >>>
> >> >> >>> We have had some unfortunate incidents on all 3 vm, of different
> >> >> nature,
> >> >> >>> which made me question if we as a community:
> >> >> >>
> >> >> >> I assume we have vms for Forums and for Wiki. But what is the 3rd
> >> one?
> >> >> >>
> >> >> >>> a) want servers, that are cared for professionally or by
> happening.
> >> >> >>> b) want to (are capable to) maintain the servers ourself.
> >> >> >>> c) are prepared to support a change that make a), b) possible.
> >> >> >>>
> >> >> >>
> >> >> >> I assume we want well-maintained servers that help us get our
> >> >> >> project-related tasks done, and also help serve our users.
> >> >> >
> >> >> > +1 that is the main goal, a working reliable infra structure that
> >> helps
> >> >> > to run our project.
> >> >> >
> >> >> > In the
> >> >> >> past, before you got involved, we were not very "proactive". It
> >> >> >> seemed like we just waited for something to break, and then tried
> to
> >> >> >> fix it.
> >> >> >
> >> >> > Exactly and doing it proactive is much better and in the end
> probably
> >> >> > less work.
> >> >> >
> >> >> >>
> >> >> >> I assume another goal is that we have several people helping with
> the
> >> >> >> admin, to share the work, avoid burnouts, cover for vacation, etc.
> >> >> >
> >> >> > And that is a very important goal, we need an environment where we
> can
> >> >> > at any time step in if somebody is not available. I now very well
> in
> >> the
> >> >> > same way as Jan how it is to be a bottleneck. Well it#s true for
> many
> >> >> > others of us in different areas. But if the servers are not
> running or
> >> >> > the services not available more people are affected faster
> >> >> >
> >> >> >
> >> >> >>
> >> >> >>> I have formulated some thoughts on how admins could work, but in
> >> >> general I
> >> >> >>> believe we should convince infra to take over the vm
> responsibility
> >> and
> >> >> >>> keep our well functioning forum/wiki admins.
> >> >> >>>
> >> >> >>> We have a vm-team in place, that was created with the purpose of
> not
> >> >> having
> >> >> >>> a single person as admin. I my opinion the team have not lived
> up to
> >> >> that
> >> >> >>> purpose but I am still thankful for the help I have received.
> >> >> >>>
> >> >> >>> Remarks the ideas below are my personal thought, which I have
> used
> >> >> during
> >> >> >>> the time where I maintained the servers:
> >> >> >>>
> >> >> >>> ===========
> >> >> >>> The server should at all times be maintained with the following
> >> >> priority:
> >> >> >>> 1) security (the backside of being popular is to have the
> attention
> >> of
> >> >> >>> people who want to gain merit by breaking our servers)
> >> >> >>> 2) stability (we have limited cpu/ram/disk so we must optimize)
> >> >> >>> 3) add user wishes (we already have stable systems, 1,2 are far
> >> more
> >> >> >>> important that enhancing the systems).
> >> >> >>>
> >> >> >>
> >> >> >> and maybe
> >> >> >>
> >> >> >> 3b) Try to evolve systems so users can implement their own
> wishes, in
> >> >> >> a way compatible with 1) and 2). For example, if routine logos
> and
> >> >> >> footers are synched to resources in the project's SVN tree, then
> any
> >> >> >> committer can update things.
> >> >>
> >> >> I really like this idea.
> >> >>
> >> >
> >> > I am impressed, is this real serious ?
> >> >
> >> > Think about all the fuzz we have had on several MLs because one
> committer
> >> > successfully convinced a vm-admin to change our logo, and the
> suggestion
> >> is
> >> > to make that automatic.
> >> >
> >> > Any committer who wants a change, just do a "svn commit", is that
> really
> >> > wanted ?
> >> >
> >>
> >> It also makes it possible for any committer to fix a problem if one
> occurs.
> >>
> >> > A couple of questions to that:
> >> >
> >> > Committer X want extension translate, and do a "svn commit" the
> config is
> >> > updated, but does not work because of other dependencies, who clears
> up
> >> the
> >> > work ? for sure THAT is not a vm-admin task.
> >> >
> >>
> >> Same as when a committer checks in code that breaks the build.
> >>
> >>
> >> > Committer X changes the logo, but doing a "svn commit", Committer Y
> dont
> >> > like it and does a "svn commit", where are our users in this process
> or
> >> our
> >> > decision process ?
> >> >
> >>
> >> Same as when a committer checks in code that someone doesn't like.
> >>
> >> We have a community-based process that handles these things already.
> >>
> >> Your proposal doesn't really avoid these issues. It handles it by
> >> having an admin judge the will of the community.
> >>
> > yes like all other vms I know.
> >
> >
> >>
> >> > 3b) is a sure way to scare any prof. SA away, thats pure anarchy.
> >> >
> >>
> >> In the good sense of the word "anarchy", yes.
> >>
> >> Note: I wouldn't do this for config files and core system files. But
> >> why should the logo or banner or footer of the forums or the wiki be
> >> any harder for a committer to edit than the same content of our
> >> website?
> >>
> >
> > Maybe because the CMS are laid out for that our apps are not. If you
> change
> > logo to e.g. a different size you will also need to edit
> > - css
> > - php (for mwiki)
> > - update symlinks (for php2bb)
> >
> > and you might also need to change in the httpd caching scheme, if the new
> > logo has a different extension.
> >
> > If you want to change to footer, you need to
> > - for wiki edit a php script, that also contains securtiy relevant
> > information.
> > - for php2bb, it can partly already be done by forum admin, but by doing
> > that you break the setup (all forums have identical setup, with symlinks
> to
> > a central place.
> >
>
> Read my original comment again. I wrote:
>
> "and maybe
>
> 3b) Try to evolve systems so users can implement their own wishes, in
> a way compatible with 1) and 2). For example, if routine logos and
> footers are synched to resources in the project's SVN tree, then any
> committer can update things."
>
>
> I didn't say, "Open it up for every one to make unrestrained changes
> on system files". I said "try to evolve...". This implies change,
> gradual change, deliberate change, goal-oriented change, to enable
> this. It was a statement of an ideal we should keep in mind and work
> towards.
>
> > But never mind. As requested by infra, I tried a last time, to get
> > consensus on having our vms maintained at the level and guidelines used
> for
> > infra vms and failed.
> >
>
> Maybe you have a different view of what consensus means. When I work
> on standards committees in ISO we have a useful definition of
> consensus:
>
> "General agreement, characterized by the absence of sustained
> opposition to substantial issues by any important part of the
> concerned interests and by a process that involves seeking to take
> into account the views of all parties concerned and to reconcile any
> conflicting arguments"
>
> Maybe we could adopt something like this? Note the emphasis on lack
> of opposition and on discussion to reconcile views. Consensus is
> something you gain by discussion, and through discussion we all remain
> open to other ideas and assume good will.
>
> > I acknowledge the fact that the community want vms that are open
> > playgrounds (letting admins change as they please, and even allow
> committer
> > access), I believe differently.
> >
>
> Again, the statement that I made, and which others agreed with, was
> "try to evolve...". It was not talking about "open playgrounds".
>
> > I have, effective 2 hours ago, asked root@a.o to remove my sudo
> > right/access to the vms and the alert notifications, so I can no longer
> be
> > expected to react and/or do cleanup of others playground work.
> >
>
> Maybe re-read the thread in light of what I've written here and see if
> it still looks that way? And remember, a 72-hour discussion is the
> minimum, not the maximum, especially over the weekend.
>
I have done as requested and re-read not only this thread but a couple of
other threads as well.
Thanks for your corrections, in regards of your statements, I took you
statements to the maximum extent, and you precise them to about the minimum
possible range.
I can however see it is as if we are in two different worlds.
I was fighting to get our vm-team to work (sending lots of mails to
activate them), and get the other admins to follow rules or leave. In order
to keep our vms at level, I believe in being restrictive, run everything by
the rules, and loudly remind those that break it.
You (and dave) on the other hand thought about how the future should be
(nothing wrong with that) and did not consider the eminent problems.
I decided to leave with good conscience, for these reasons:
- The vms are all at a very much higher level of maintenance as before.
- The community have the same support as before I took over (Imacat, jsc)
- My ways are much more strict than your (and the community) ideas, and I
will be in constant conflict with the PMC group.
I stand by my earlier mail today, talk this through with the vm-team, the
managed the vms before (at another level) and can simply continue doing
that.
Thanks again for your clarification, but I hope you this is not the kernel
problem that made me leave.
rgds
jan I.
> Regards,
>
> -Rob
>
> > The vms are not at risk, imacat, jsc, andrea and arist all have access
> and
> > sudo.
> >
> > Thanks for the trust the community have given me in the past.
> >
> > rgds
> > jan I.
> >
> >
> >> Regards,
> >>
> >> -Rob
> >>
> >>
> >> > Dont misunderstand, I have no problem with the community implementing
> >> > something like that, just dont expect to get stable well maintained
> >> servers
> >> > ! We have a serious problem with the current admins, expanding that to
> >> all
> >> > committers, that is something that will be in interesting to watch
> for a
> >> > large distance.
> >> >
> >> >
> >> >> >>
> >> >> >>> Being an admin on a vm is a job that does not take soo much time,
> >> but
> >> >> >>> requires a lot of monitoring and communication (especially with
> >> infra).
> >> >> >>>
> >> >> >>> A good setup would be, 3 types of admin:
> >> >> >>> Each server will have an appointed "owner" (anchor-admin)
> >> >> >>> A number of persons have full sudo on a server (admin)
> >> >> >>> A number of persons can reboot/restart/work on po files
> (help-admin)
> >> >> >>>
> >> >> >>> === Anchor-admin responsibilities ===
> >> >> >>> Anchor-admin is the "owner" of the vm and the prime contact to
> >> infra.
> >> >> >>>
> >> >> >>> Anchor-admin has the overall responsibility of the vm.
> >> >> >>> 1) help when receiving alerts
> >> >> >>> 2) keep informed on available patches, especial security related
> >> >> patches
> >> >> >>> 3) create/keep a maintenance plan
> >> >> >>> 4) coordinate changes external to vm (like dns) with infra
> >> >> >>> 5) participate in infra discussions relevant for the vm (e.g.
> >> >> certificates)
> >> >> >>> 6) monitor the vm regularly for resource usage
> >> >> >>> 7) secure that appl changes are implemented with relevant
> consensus
> >> >> >>> 8) discuss work with admin, with the goal that they should be
> able
> >> to
> >> >> take
> >> >> >>> over one day.
> >> >> >>>
> >> >> >>> These activities are expected to take 3-4 hours pr week, more in
> the
> >> >> >>> beginning and less later. The hour usage highly depend on the
> number
> >> >> and
> >> >> >>> level of admins.
> >> >> >>>
> >> >> >>> === Admin responsibilities ===
> >> >> >>> Admins help the anchor admin with ongoing maintenance and have
> full
> >> >> sudo.
> >> >> >>>
> >> >> >>> All changes must be discussed and agreed with the anchor admin,
> no
> >> >> change
> >> >> >>> is so important that it cannot wait until discussed !
> >> >> >>>
> >> >> >>
> >> >> >> We might also want an admin-dev@openoffice.apache.org list and
> >> perhaps
> >> >> >> a private one as well to coordinate.
> >> >>
> >> >> Perhaps an admin-dev, but a private one is a not a good idea - the
> team
> >> >> should be on the infrastructure list and infra should know what is
> up.
> >> >>
> >> > We can make any number of MLs, current fact is that surden admins do
> NOT
> >> > reply to private mails, asking them to act.
> >> >
> >> > I for one, do not need more MLs, I need rules admin follow or leave.
> >> >
> >> >>>
> >> >>>> Admins are expected to:
> >> >>>> 1) help when receiving alerts
> >> >>>> 2) stay informed with the vm configuration
> >> >>>> including but not limited to:
> >> >>>> - where are which configuration done, and stored (svn/backup)
> >> >>>> - how are the apps. configured
> >> >>>> - read and update runbook, if something is unclear
> >> >>>> 3) participate in the regular maintenance
> >> >>>> 4) coordinate all non-scheduled work with anchor-admin
> >> >>>>
> >> >>>> These activities are expected to take 1-2 hours pr week, more in
> the
> >> >>>> beginning and less later.
> >> >>>>
> >> >>>> Admin does not need to be specialists, we all learn, but it is
> >> important
> >> >>>> that the admin have motivation and time to learn.
> >> >>>>
> >> >>>>
> >> >>>> === Help-admin responsibilities ===
> >> >>>> Help-admins are located in different timezones, so we have 24/7
> >> coverage
> >> >>>> and have limited sudo (only restart/reboot/handle po files).
> >> >>>>
> >> >>>> When a help-admin receives an alert mail, actions should be taken
> >> >>>> 1) is the vm reachable via ssh, then login else escalate to
> >> admin/infra
> >> >>>> 2) is the vm overloaded, or is apache/mysql not running
> >> >>>> 3) restart the needed processes
> >> >>>> 4) mail at least anchor-admin about with obervations and what was
> >> done.
> >> >>>>
> >> >>>>
> >> >>>> ===
> >> >>>> remark the above are just my thoughts, there are a lot of other
> >> >>>> possibilities.
> >> >>
> >> >> It sounds very reasonable to me and worth to work in this direction.
> I
> >> >> see myself more in the role of a help-admin but I willing to learn
> more
> >> >> to be a better admin.
> >> >
> >> > I agree that the plan is reasonable and professional.
> >> >>
> >> >
> >> > thanks for you kinds words, but 3b) makes that plan obsolete. With 3b)
> >> > everyone is admin, a problem something like 1.000 times bigger than
> >> today,
> >> > where we cannot control 3 admins.
> >> >
> >> > rgds
> >> > jan I.
> >> >
> >> >
> >> >>
> >> >> Regards,
> >> >> Dave
> >> >>
> >> >> >
> >> >> > Juergen
> >> >> >
> >> >> >>>
> >> >> >>> Lets hear your opinion?
> >> >> >>>
> >> >> >>
> >> >> >> It sounds like a good way to think of this.
> >> >> >>
> >> >> >> Regards,
> >> >> >>
> >> >> >> -Rob
> >> >> >>
> >> >> >>> rgds
> >> >> >>> jan I.
> >> >> >>
> >> >> >>
> ---------------------------------------------------------------------
> >> >> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> >> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> ---------------------------------------------------------------------
> >> >> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> >> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >> >> >
> >> >>
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: requirements for vm-admins of forum/translate/wiki
Posted by Rob Weir <ro...@apache.org>.
On Sat, Sep 7, 2013 at 5:24 AM, janI <ja...@apache.org> wrote:
> On 6 September 2013 19:49, Rob Weir <ro...@apache.org> wrote:
>
>> On Fri, Sep 6, 2013 at 12:14 PM, janI <ja...@apache.org> wrote:
>> > On 6 September 2013 15:27, Dave Fisher <da...@comcast.net> wrote:
>> >
>> >>
>> >> On Sep 4, 2013, at 11:37 PM, Jürgen Schmidt wrote:
>> >>
>> >> > On 9/4/13 10:17 PM, Rob Weir wrote:
>> >> >> On Wed, Sep 4, 2013 at 12:36 PM, janI <ja...@apache.org> wrote:
>> >> >>> Hi.
>> >> >>>
>> >> >>> We have had some longer discussions on different ML/IRC about how a
>> >> >>> vm-admin should behave and which level of service we expect for our
>> >> servers.
>> >> >>>
>> >> >>> We need new admins, so this is also a request for anyone interested
>> to
>> >> chip
>> >> >>> in.
>> >> >>>
>> >> >>> We have had some unfortunate incidents on all 3 vm, of different
>> >> nature,
>> >> >>> which made me question if we as a community:
>> >> >>
>> >> >> I assume we have vms for Forums and for Wiki. But what is the 3rd
>> one?
>> >> >>
>> >> >>> a) want servers, that are cared for professionally or by happening.
>> >> >>> b) want to (are capable to) maintain the servers ourself.
>> >> >>> c) are prepared to support a change that make a), b) possible.
>> >> >>>
>> >> >>
>> >> >> I assume we want well-maintained servers that help us get our
>> >> >> project-related tasks done, and also help serve our users.
>> >> >
>> >> > +1 that is the main goal, a working reliable infra structure that
>> helps
>> >> > to run our project.
>> >> >
>> >> > In the
>> >> >> past, before you got involved, we were not very "proactive". It
>> >> >> seemed like we just waited for something to break, and then tried to
>> >> >> fix it.
>> >> >
>> >> > Exactly and doing it proactive is much better and in the end probably
>> >> > less work.
>> >> >
>> >> >>
>> >> >> I assume another goal is that we have several people helping with the
>> >> >> admin, to share the work, avoid burnouts, cover for vacation, etc.
>> >> >
>> >> > And that is a very important goal, we need an environment where we can
>> >> > at any time step in if somebody is not available. I now very well in
>> the
>> >> > same way as Jan how it is to be a bottleneck. Well it#s true for many
>> >> > others of us in different areas. But if the servers are not running or
>> >> > the services not available more people are affected faster
>> >> >
>> >> >
>> >> >>
>> >> >>> I have formulated some thoughts on how admins could work, but in
>> >> general I
>> >> >>> believe we should convince infra to take over the vm responsibility
>> and
>> >> >>> keep our well functioning forum/wiki admins.
>> >> >>>
>> >> >>> We have a vm-team in place, that was created with the purpose of not
>> >> having
>> >> >>> a single person as admin. I my opinion the team have not lived up to
>> >> that
>> >> >>> purpose but I am still thankful for the help I have received.
>> >> >>>
>> >> >>> Remarks the ideas below are my personal thought, which I have used
>> >> during
>> >> >>> the time where I maintained the servers:
>> >> >>>
>> >> >>> ===========
>> >> >>> The server should at all times be maintained with the following
>> >> priority:
>> >> >>> 1) security (the backside of being popular is to have the attention
>> of
>> >> >>> people who want to gain merit by breaking our servers)
>> >> >>> 2) stability (we have limited cpu/ram/disk so we must optimize)
>> >> >>> 3) add user wishes (we already have stable systems, 1,2 are far
>> more
>> >> >>> important that enhancing the systems).
>> >> >>>
>> >> >>
>> >> >> and maybe
>> >> >>
>> >> >> 3b) Try to evolve systems so users can implement their own wishes, in
>> >> >> a way compatible with 1) and 2). For example, if routine logos and
>> >> >> footers are synched to resources in the project's SVN tree, then any
>> >> >> committer can update things.
>> >>
>> >> I really like this idea.
>> >>
>> >
>> > I am impressed, is this real serious ?
>> >
>> > Think about all the fuzz we have had on several MLs because one committer
>> > successfully convinced a vm-admin to change our logo, and the suggestion
>> is
>> > to make that automatic.
>> >
>> > Any committer who wants a change, just do a "svn commit", is that really
>> > wanted ?
>> >
>>
>> It also makes it possible for any committer to fix a problem if one occurs.
>>
>> > A couple of questions to that:
>> >
>> > Committer X want extension translate, and do a "svn commit" the config is
>> > updated, but does not work because of other dependencies, who clears up
>> the
>> > work ? for sure THAT is not a vm-admin task.
>> >
>>
>> Same as when a committer checks in code that breaks the build.
>>
>>
>> > Committer X changes the logo, but doing a "svn commit", Committer Y dont
>> > like it and does a "svn commit", where are our users in this process or
>> our
>> > decision process ?
>> >
>>
>> Same as when a committer checks in code that someone doesn't like.
>>
>> We have a community-based process that handles these things already.
>>
>> Your proposal doesn't really avoid these issues. It handles it by
>> having an admin judge the will of the community.
>>
> yes like all other vms I know.
>
>
>>
>> > 3b) is a sure way to scare any prof. SA away, thats pure anarchy.
>> >
>>
>> In the good sense of the word "anarchy", yes.
>>
>> Note: I wouldn't do this for config files and core system files. But
>> why should the logo or banner or footer of the forums or the wiki be
>> any harder for a committer to edit than the same content of our
>> website?
>>
>
> Maybe because the CMS are laid out for that our apps are not. If you change
> logo to e.g. a different size you will also need to edit
> - css
> - php (for mwiki)
> - update symlinks (for php2bb)
>
> and you might also need to change in the httpd caching scheme, if the new
> logo has a different extension.
>
> If you want to change to footer, you need to
> - for wiki edit a php script, that also contains securtiy relevant
> information.
> - for php2bb, it can partly already be done by forum admin, but by doing
> that you break the setup (all forums have identical setup, with symlinks to
> a central place.
>
Read my original comment again. I wrote:
"and maybe
3b) Try to evolve systems so users can implement their own wishes, in
a way compatible with 1) and 2). For example, if routine logos and
footers are synched to resources in the project's SVN tree, then any
committer can update things."
I didn't say, "Open it up for every one to make unrestrained changes
on system files". I said "try to evolve...". This implies change,
gradual change, deliberate change, goal-oriented change, to enable
this. It was a statement of an ideal we should keep in mind and work
towards.
> But never mind. As requested by infra, I tried a last time, to get
> consensus on having our vms maintained at the level and guidelines used for
> infra vms and failed.
>
Maybe you have a different view of what consensus means. When I work
on standards committees in ISO we have a useful definition of
consensus:
"General agreement, characterized by the absence of sustained
opposition to substantial issues by any important part of the
concerned interests and by a process that involves seeking to take
into account the views of all parties concerned and to reconcile any
conflicting arguments"
Maybe we could adopt something like this? Note the emphasis on lack
of opposition and on discussion to reconcile views. Consensus is
something you gain by discussion, and through discussion we all remain
open to other ideas and assume good will.
> I acknowledge the fact that the community want vms that are open
> playgrounds (letting admins change as they please, and even allow committer
> access), I believe differently.
>
Again, the statement that I made, and which others agreed with, was
"try to evolve...". It was not talking about "open playgrounds".
> I have, effective 2 hours ago, asked root@a.o to remove my sudo
> right/access to the vms and the alert notifications, so I can no longer be
> expected to react and/or do cleanup of others playground work.
>
Maybe re-read the thread in light of what I've written here and see if
it still looks that way? And remember, a 72-hour discussion is the
minimum, not the maximum, especially over the weekend.
Regards,
-Rob
> The vms are not at risk, imacat, jsc, andrea and arist all have access and
> sudo.
>
> Thanks for the trust the community have given me in the past.
>
> rgds
> jan I.
>
>
>> Regards,
>>
>> -Rob
>>
>>
>> > Dont misunderstand, I have no problem with the community implementing
>> > something like that, just dont expect to get stable well maintained
>> servers
>> > ! We have a serious problem with the current admins, expanding that to
>> all
>> > committers, that is something that will be in interesting to watch for a
>> > large distance.
>> >
>> >
>> >> >>
>> >> >>> Being an admin on a vm is a job that does not take soo much time,
>> but
>> >> >>> requires a lot of monitoring and communication (especially with
>> infra).
>> >> >>>
>> >> >>> A good setup would be, 3 types of admin:
>> >> >>> Each server will have an appointed "owner" (anchor-admin)
>> >> >>> A number of persons have full sudo on a server (admin)
>> >> >>> A number of persons can reboot/restart/work on po files (help-admin)
>> >> >>>
>> >> >>> === Anchor-admin responsibilities ===
>> >> >>> Anchor-admin is the "owner" of the vm and the prime contact to
>> infra.
>> >> >>>
>> >> >>> Anchor-admin has the overall responsibility of the vm.
>> >> >>> 1) help when receiving alerts
>> >> >>> 2) keep informed on available patches, especial security related
>> >> patches
>> >> >>> 3) create/keep a maintenance plan
>> >> >>> 4) coordinate changes external to vm (like dns) with infra
>> >> >>> 5) participate in infra discussions relevant for the vm (e.g.
>> >> certificates)
>> >> >>> 6) monitor the vm regularly for resource usage
>> >> >>> 7) secure that appl changes are implemented with relevant consensus
>> >> >>> 8) discuss work with admin, with the goal that they should be able
>> to
>> >> take
>> >> >>> over one day.
>> >> >>>
>> >> >>> These activities are expected to take 3-4 hours pr week, more in the
>> >> >>> beginning and less later. The hour usage highly depend on the number
>> >> and
>> >> >>> level of admins.
>> >> >>>
>> >> >>> === Admin responsibilities ===
>> >> >>> Admins help the anchor admin with ongoing maintenance and have full
>> >> sudo.
>> >> >>>
>> >> >>> All changes must be discussed and agreed with the anchor admin, no
>> >> change
>> >> >>> is so important that it cannot wait until discussed !
>> >> >>>
>> >> >>
>> >> >> We might also want an admin-dev@openoffice.apache.org list and
>> perhaps
>> >> >> a private one as well to coordinate.
>> >>
>> >> Perhaps an admin-dev, but a private one is a not a good idea - the team
>> >> should be on the infrastructure list and infra should know what is up.
>> >>
>> > We can make any number of MLs, current fact is that surden admins do NOT
>> > reply to private mails, asking them to act.
>> >
>> > I for one, do not need more MLs, I need rules admin follow or leave.
>> >
>> >>>
>> >>>> Admins are expected to:
>> >>>> 1) help when receiving alerts
>> >>>> 2) stay informed with the vm configuration
>> >>>> including but not limited to:
>> >>>> - where are which configuration done, and stored (svn/backup)
>> >>>> - how are the apps. configured
>> >>>> - read and update runbook, if something is unclear
>> >>>> 3) participate in the regular maintenance
>> >>>> 4) coordinate all non-scheduled work with anchor-admin
>> >>>>
>> >>>> These activities are expected to take 1-2 hours pr week, more in the
>> >>>> beginning and less later.
>> >>>>
>> >>>> Admin does not need to be specialists, we all learn, but it is
>> important
>> >>>> that the admin have motivation and time to learn.
>> >>>>
>> >>>>
>> >>>> === Help-admin responsibilities ===
>> >>>> Help-admins are located in different timezones, so we have 24/7
>> coverage
>> >>>> and have limited sudo (only restart/reboot/handle po files).
>> >>>>
>> >>>> When a help-admin receives an alert mail, actions should be taken
>> >>>> 1) is the vm reachable via ssh, then login else escalate to
>> admin/infra
>> >>>> 2) is the vm overloaded, or is apache/mysql not running
>> >>>> 3) restart the needed processes
>> >>>> 4) mail at least anchor-admin about with obervations and what was
>> done.
>> >>>>
>> >>>>
>> >>>> ===
>> >>>> remark the above are just my thoughts, there are a lot of other
>> >>>> possibilities.
>> >>
>> >> It sounds very reasonable to me and worth to work in this direction. I
>> >> see myself more in the role of a help-admin but I willing to learn more
>> >> to be a better admin.
>> >
>> > I agree that the plan is reasonable and professional.
>> >>
>> >
>> > thanks for you kinds words, but 3b) makes that plan obsolete. With 3b)
>> > everyone is admin, a problem something like 1.000 times bigger than
>> today,
>> > where we cannot control 3 admins.
>> >
>> > rgds
>> > jan I.
>> >
>> >
>> >>
>> >> Regards,
>> >> Dave
>> >>
>> >> >
>> >> > Juergen
>> >> >
>> >> >>>
>> >> >>> Lets hear your opinion?
>> >> >>>
>> >> >>
>> >> >> It sounds like a good way to think of this.
>> >> >>
>> >> >> Regards,
>> >> >>
>> >> >> -Rob
>> >> >>
>> >> >>> rgds
>> >> >>> jan I.
>> >> >>
>> >> >> ---------------------------------------------------------------------
>> >> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> >> >> For additional commands, e-mail: dev-help@openoffice.apache.org
>> >> >>
>> >> >
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> >> > For additional commands, e-mail: dev-help@openoffice.apache.org
>> >> >
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> >> For additional commands, e-mail: dev-help@openoffice.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: requirements for vm-admins of forum/translate/wiki
Posted by janI <ja...@apache.org>.
On 8 September 2013 00:01, janI <ja...@apache.org> wrote:
>
> On Sep 7, 2013 10:28 PM, "Dave Fisher" <da...@comcast.net> wrote:
> >
> >
> > On Sep 7, 2013, at 2:24 AM, janI wrote:
> >
> > > On 6 September 2013 19:49, Rob Weir <ro...@apache.org> wrote:
> > >
> > >> On Fri, Sep 6, 2013 at 12:14 PM, janI <ja...@apache.org> wrote:
> > >>> On 6 September 2013 15:27, Dave Fisher <da...@comcast.net>
> wrote:
> > >>>
> > >>>>
> > >>>> On Sep 4, 2013, at 11:37 PM, Jürgen Schmidt wrote:
> > >>>>
> > >>>>> On 9/4/13 10:17 PM, Rob Weir wrote:
> > >>>>>> On Wed, Sep 4, 2013 at 12:36 PM, janI <ja...@apache.org> wrote:
> > >>>>>>> Hi.
> > >>>>>>>
> > >>>>>>> We have had some longer discussions on different ML/IRC about
> how a
> > >>>>>>> vm-admin should behave and which level of service we expect for
> our
> > >>>> servers.
> > >>>>>>>
> > >>>>>>> We need new admins, so this is also a request for anyone
> interested
> > >> to
> > >>>> chip
> > >>>>>>> in.
> > >>>>>>>
> > >>>>>>> We have had some unfortunate incidents on all 3 vm, of different
> > >>>> nature,
> > >>>>>>> which made me question if we as a community:
> > >>>>>>
> > >>>>>> I assume we have vms for Forums and for Wiki. But what is the 3rd
> > >> one?
> > >>>>>>
> > >>>>>>> a) want servers, that are cared for professionally or by
> happening.
> > >>>>>>> b) want to (are capable to) maintain the servers ourself.
> > >>>>>>> c) are prepared to support a change that make a), b) possible.
> > >>>>>>>
> > >>>>>>
> > >>>>>> I assume we want well-maintained servers that help us get our
> > >>>>>> project-related tasks done, and also help serve our users.
> > >>>>>
> > >>>>> +1 that is the main goal, a working reliable infra structure that
> > >> helps
> > >>>>> to run our project.
> > >>>>>
> > >>>>> In the
> > >>>>>> past, before you got involved, we were not very "proactive". It
> > >>>>>> seemed like we just waited for something to break, and then tried
> to
> > >>>>>> fix it.
> > >>>>>
> > >>>>> Exactly and doing it proactive is much better and in the end
> probably
> > >>>>> less work.
> > >>>>>
> > >>>>>>
> > >>>>>> I assume another goal is that we have several people helping with
> the
> > >>>>>> admin, to share the work, avoid burnouts, cover for vacation, etc.
> > >>>>>
> > >>>>> And that is a very important goal, we need an environment where we
> can
> > >>>>> at any time step in if somebody is not available. I now very well
> in
> > >> the
> > >>>>> same way as Jan how it is to be a bottleneck. Well it#s true for
> many
> > >>>>> others of us in different areas. But if the servers are not
> running or
> > >>>>> the services not available more people are affected faster
> > >>>>>
> > >>>>>
> > >>>>>>
> > >>>>>>> I have formulated some thoughts on how admins could work, but in
> > >>>> general I
> > >>>>>>> believe we should convince infra to take over the vm
> responsibility
> > >> and
> > >>>>>>> keep our well functioning forum/wiki admins.
> > >>>>>>>
> > >>>>>>> We have a vm-team in place, that was created with the purpose of
> not
> > >>>> having
> > >>>>>>> a single person as admin. I my opinion the team have not lived
> up to
> > >>>> that
> > >>>>>>> purpose but I am still thankful for the help I have received.
> > >>>>>>>
> > >>>>>>> Remarks the ideas below are my personal thought, which I have
> used
> > >>>> during
> > >>>>>>> the time where I maintained the servers:
> > >>>>>>>
> > >>>>>>> ===========
> > >>>>>>> The server should at all times be maintained with the following
> > >>>> priority:
> > >>>>>>> 1) security (the backside of being popular is to have the
> attention
> > >> of
> > >>>>>>> people who want to gain merit by breaking our servers)
> > >>>>>>> 2) stability (we have limited cpu/ram/disk so we must optimize)
> > >>>>>>> 3) add user wishes (we already have stable systems, 1,2 are far
> > >> more
> > >>>>>>> important that enhancing the systems).
> > >>>>>>>
> > >>>>>>
> > >>>>>> and maybe
> > >>>>>>
> > >>>>>> 3b) Try to evolve systems so users can implement their own
> wishes, in
> > >>>>>> a way compatible with 1) and 2). For example, if routine logos
> and
> > >>>>>> footers are synched to resources in the project's SVN tree, then
> any
> > >>>>>> committer can update things.
> > >>>>
> > >>>> I really like this idea.
> > >>>>
> > >>>
> > >>> I am impressed, is this real serious ?
> > >>>
> > >>> Think about all the fuzz we have had on several MLs because one
> committer
> > >>> successfully convinced a vm-admin to change our logo, and the
> suggestion
> > >> is
> > >>> to make that automatic.
> > >>>
> > >>> Any committer who wants a change, just do a "svn commit", is that
> really
> > >>> wanted ?
> > >>>
> > >>
> > >> It also makes it possible for any committer to fix a problem if one
> occurs.
> > >>
> > >>> A couple of questions to that:
> > >>>
> > >>> Committer X want extension translate, and do a "svn commit" the
> config is
> > >>> updated, but does not work because of other dependencies, who clears
> up
> > >> the
> > >>> work ? for sure THAT is not a vm-admin task.
> > >>>
> > >>
> > >> Same as when a committer checks in code that breaks the build.
> > >>
> > >>
> > >>> Committer X changes the logo, but doing a "svn commit", Committer Y
> dont
> > >>> like it and does a "svn commit", where are our users in this process
> or
> > >> our
> > >>> decision process ?
> > >>>
> > >>
> > >> Same as when a committer checks in code that someone doesn't like.
> > >>
> > >> We have a community-based process that handles these things already.
> > >>
> > >> Your proposal doesn't really avoid these issues. It handles it by
> > >> having an admin judge the will of the community.
> > >>
> > > yes like all other vms I know.
> > >
> > >
> > >>
> > >>> 3b) is a sure way to scare any prof. SA away, thats pure anarchy.
> > >>>
> > >>
> > >> In the good sense of the word "anarchy", yes.
> > >>
> > >> Note: I wouldn't do this for config files and core system files. But
> > >> why should the logo or banner or footer of the forums or the wiki be
> > >> any harder for a committer to edit than the same content of our
> > >> website?
> > >>
> > >
> > > Maybe because the CMS are laid out for that our apps are not. If you
> change
> > > logo to e.g. a different size you will also need to edit
> > > - css
> > > - php (for mwiki)
> > > - update symlinks (for php2bb)
> > >
> > > and you might also need to change in the httpd caching scheme, if the
> new
> > > logo has a different extension.
> > >
> > > If you want to change to footer, you need to
> > > - for wiki edit a php script, that also contains securtiy relevant
> > > information.
> > > - for php2bb, it can partly already be done by forum admin, but by
> doing
> > > that you break the setup (all forums have identical setup, with
> symlinks to
> > > a central place.
> >
> > What both Rob and I were looking for is an understanding of what it
> might take to have a unified approach. Your reasoning is fine we were
> discussing in a robust way what it would take to make this work. You are
> precisely correct to tell us what a high bar this is.
> >
> > We have 8 different systems to maintain brand on we need to fully
> understand all of the implications.
> >
> > >
> > > But never mind. As requested by infra, I tried a last time, to get
> > > consensus on having our vms maintained at the level and guidelines
> used for
> > > infra vms and failed.
> > >
> > > I acknowledge the fact that the community want vms that are open
> > > playgrounds (letting admins change as they please, and even allow
> committer
> > > access), I believe differently.
> >
> > You are the one who says that we want an open playground to do anything.
> We are only asking for a way to control the brand. Let's talk about what it
> would take. You give concrete information above and then at the same time
> you quit
> >
> > You are impossible to have a discussion with. You should be open to
> finding a way.
>
> I am sorry you feel that way, I have tried to get attention for about 3
> months without success and only because I give up we start to discuss,
> does that make me impossible, or is it those that did not want to discuss
> earlier ?
>
> I was forced to accept a vm-team (a very good idea), that have not reacted
> to a single alert or (apart from arist helping with forum) helped with a
> single change/update. But I was told, that it was all good, because we had
> an efficient team, does it make me impossible that I tell the truth, that
> the team does not work ?
>
> I have been fighting to get our servers updated, including creating
> several new vms, I have 1 time asked for support, when we had the incident
> with logo changes, which another admin did, in a way that put our servers
> at risk. Does it make me impossible that I cannot accept the way that admin
> worked (remember this is not the first incident) ?
>
> I feel I have really tried to find ways, but none wanted to listen,
> probably because I was there and took care of it. Does that make me
> impossible ?
>
> So yes, I did quit, because I could not see any other options.
>
>
> >>
>
> > > I have, effective 2 hours ago, asked root@a.o to remove my sudo
> > > right/access to the vms and the alert notifications, so I can no
> longer be
> > > expected to react and/or do cleanup of others playground work.
> > >
> > > The vms are not at risk, imacat, jsc, andrea and arist all have access
> and
> > > sudo.
> > >
> > > Thanks for the trust the community have given me in the past.
> >
> > Thanks for not noticing the difference between an action and a
> discussion of how we can go into a "devops" mode and alleviate some of the
> burden that you feel as a sysadmin.
>
> I do know the difference, just look at the mail archives, and you will see
> how often I have raised these problems the last couple of months. Dont
> forget the vm-team was such a "alleviation", which turned out just to make
> the burden worse. It seems to me, that the difference is something else:
>
> I fight and discuss about a workable solution with the resources we have
> today, while "devops" mode and other suggestions seems to focus on a future
> and resources that we dont know if we will ever get.
>
> We need a solution for today, who and how, we already have pending
> updates. If we solve today, we can start dreaming about the future.
>
> >
> > You act like Rob and I have no experience. That is not so. I work 12
> hours days and manage both java and php developers and solaris/ubuntu
> syadmins. I am a firm believer in DevOps. As much as possible sysadmins
> provide a stable environment for QUALIFIED developers to configure
> applications. I may be the person most qualified in this project to help
> make this full rebranding happen in a way that makes it easy and not hard
> to present a unified header.
>
>
> Actually you are one of the people in here I admire, and I believe you
> have experience. But please so do I, I sold my companies a year ago, we
> operated worldwide and dealt with fortune 500 companies. I decided to
> change lane, stop managing and do what I really like, to help opensource
> projects. Enough about you and me, I think we have established that we both
> know what we do.
>
> I acknowledge that both you and rob have experience, but both of you talk
> about an unknown future with resources we dont have right now, and we do
> have a problem today to solve first.
>
>
> >
> > I've worked with Roller and Confluence, etc.
> >
> > I am sorry you cannot tell the difference between those who want to work
> with you and those who go around you and seemingly don't respect the effort
> that you provide.
>
> I am sorry you cannot acknowledge how long I have been fighting while
> having my worries ignored.
>
> I am aware I should have done like some of the other vm-team members,
> "nothing". I get criticized because I tell that I quit after having tried
> hard to get something done, is that real fair ? Would it not be equally
> fair to question the vm-team, why they cannot take over, as was expected.
>
> I feel that I have become more of a burden, than an asset, if my feeling
> is right just tell me straight.
>
After a good nights sleep, I have a positive suggestion.
Take a discussion either with or among the current vm-team, on how the work
can be handled. Some members of the team did the work before I took over,
so they should be able to continue doing it at the same level.
It seems my suggestions/presence makes the discussions more
emotional/personal, something that is very uncool for the project, so I
will keep a distance.
If we want a higher level maintenance, as I have delivered, persuade infra
to take responsibility for the vms, that will ensure professional care (I
have told in here and to infra, that in such a setup, I would be happy to
continue).
Hope this takes the heat out of the discussion.
rgds
jan I.
> rgds
>
> jan I.
>
>
> >
> > Best Regards,
> > Dave
> >
> > >
> > > rgds
> > > jan I.
> > >
> > >
> > >> Regards,
> > >>
> > >> -Rob
> > >>
> > >>
> > >>> Dont misunderstand, I have no problem with the community implementing
> > >>> something like that, just dont expect to get stable well maintained
> > >> servers
> > >>> ! We have a serious problem with the current admins, expanding that
> to
> > >> all
> > >>> committers, that is something that will be in interesting to watch
> for a
> > >>> large distance.
> > >>>
> > >>>
> > >>>>>>
> > >>>>>>> Being an admin on a vm is a job that does not take soo much time,
> > >> but
> > >>>>>>> requires a lot of monitoring and communication (especially with
> > >> infra).
> > >>>>>>>
> > >>>>>>> A good setup would be, 3 types of admin:
> > >>>>>>> Each server will have an appointed "owner" (anchor-admin)
> > >>>>>>> A number of persons have full sudo on a server (admin)
> > >>>>>>> A number of persons can reboot/restart/work on po files
> (help-admin)
> > >>>>>>>
> > >>>>>>> === Anchor-admin responsibilities ===
> > >>>>>>> Anchor-admin is the "owner" of the vm and the prime contact to
> > >> infra.
> > >>>>>>>
> > >>>>>>> Anchor-admin has the overall responsibility of the vm.
> > >>>>>>> 1) help when receiving alerts
> > >>>>>>> 2) keep informed on available patches, especial security related
> > >>>> patches
> > >>>>>>> 3) create/keep a maintenance plan
> > >>>>>>> 4) coordinate changes external to vm (like dns) with infra
> > >>>>>>> 5) participate in infra discussions relevant for the vm (e.g.
> > >>>> certificates)
> > >>>>>>> 6) monitor the vm regularly for resource usage
> > >>>>>>> 7) secure that appl changes are implemented with relevant
> consensus
> > >>>>>>> 8) discuss work with admin, with the goal that they should be
> able
> > >> to
> > >>>> take
> > >>>>>>> over one day.
> > >>>>>>>
> > >>>>>>> These activities are expected to take 3-4 hours pr week, more in
> the
> > >>>>>>> beginning and less later. The hour usage highly depend on the
> number
> > >>>> and
> > >>>>>>> level of admins.
> > >>>>>>>
> > >>>>>>> === Admin responsibilities ===
> > >>>>>>> Admins help the anchor admin with ongoing maintenance and have
> full
> > >>>> sudo.
> > >>>>>>>
> > >>>>>>> All changes must be discussed and agreed with the anchor admin,
> no
> > >>>> change
> > >>>>>>> is so important that it cannot wait until discussed !
> > >>>>>>>
> > >>>>>>
> > >>>>>> We might also want an admin-dev@openoffice.apache.org list and
> > >> perhaps
> > >>>>>> a private one as well to coordinate.
> > >>>>
> > >>>> Perhaps an admin-dev, but a private one is a not a good idea - the
> team
> > >>>> should be on the infrastructure list and infra should know what is
> up.
> > >>>>
> > >>> We can make any number of MLs, current fact is that surden admins do
> NOT
> > >>> reply to private mails, asking them to act.
> > >>>
> > >>> I for one, do not need more MLs, I need rules admin follow or leave.
> > >>>
> > >>>>>
> > >>>>>> Admins are expected to:
> > >>>>>> 1) help when receiving alerts
> > >>>>>> 2) stay informed with the vm configuration
> > >>>>>> including but not limited to:
> > >>>>>> - where are which configuration done, and stored (svn/backup)
> > >>>>>> - how are the apps. configured
> > >>>>>> - read and update runbook, if something is unclear
> > >>>>>> 3) participate in the regular maintenance
> > >>>>>> 4) coordinate all non-scheduled work with anchor-admin
> > >>>>>>
> > >>>>>> These activities are expected to take 1-2 hours pr week, more in
> the
> > >>>>>> beginning and less later.
> > >>>>>>
> > >>>>>> Admin does not need to be specialists, we all learn, but it is
> > >> important
> > >>>>>> that the admin have motivation and time to learn.
> > >>>>>>
> > >>>>>>
> > >>>>>> === Help-admin responsibilities ===
> > >>>>>> Help-admins are located in different timezones, so we have 24/7
> > >> coverage
> > >>>>>> and have limited sudo (only restart/reboot/handle po files).
> > >>>>>>
> > >>>>>> When a help-admin receives an alert mail, actions should be taken
> > >>>>>> 1) is the vm reachable via ssh, then login else escalate to
> > >> admin/infra
> > >>>>>> 2) is the vm overloaded, or is apache/mysql not running
> > >>>>>> 3) restart the needed processes
> > >>>>>> 4) mail at least anchor-admin about with obervations and what was
> > >> done.
> > >>>>>>
> > >>>>>>
> > >>>>>> ===
> > >>>>>> remark the above are just my thoughts, there are a lot of other
> > >>>>>> possibilities.
> > >>>>
> > >>>> It sounds very reasonable to me and worth to work in this
> direction. I
> > >>>> see myself more in the role of a help-admin but I willing to learn
> more
> > >>>> to be a better admin.
> > >>>
> > >>> I agree that the plan is reasonable and professional.
> > >>>>
> > >>>
> > >>> thanks for you kinds words, but 3b) makes that plan obsolete. With
> 3b)
> > >>> everyone is admin, a problem something like 1.000 times bigger than
> > >> today,
> > >>> where we cannot control 3 admins.
> > >>>
> > >>> rgds
> > >>> jan I.
> > >>>
> > >>>
> > >>>>
> > >>>> Regards,
> > >>>> Dave
> > >>>>
> > >>>>>
> > >>>>> Juergen
> > >>>>>
> > >>>>>>>
> > >>>>>>> Lets hear your opinion?
> > >>>>>>>
> > >>>>>>
> > >>>>>> It sounds like a good way to think of this.
> > >>>>>>
> > >>>>>> Regards,
> > >>>>>>
> > >>>>>> -Rob
> > >>>>>>
> > >>>>>>> rgds
> > >>>>>>> jan I.
> > >>>>>>
> > >>>>>>
> ---------------------------------------------------------------------
> > >>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > >>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > >>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > >>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> > >>>>
> > >>>>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > >> For additional commands, e-mail: dev-help@openoffice.apache.org
> > >>
> > >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
Re: requirements for vm-admins of forum/translate/wiki
Posted by janI <ja...@apache.org>.
On Sep 7, 2013 10:28 PM, "Dave Fisher" <da...@comcast.net> wrote:
>
>
> On Sep 7, 2013, at 2:24 AM, janI wrote:
>
> > On 6 September 2013 19:49, Rob Weir <ro...@apache.org> wrote:
> >
> >> On Fri, Sep 6, 2013 at 12:14 PM, janI <ja...@apache.org> wrote:
> >>> On 6 September 2013 15:27, Dave Fisher <da...@comcast.net> wrote:
> >>>
> >>>>
> >>>> On Sep 4, 2013, at 11:37 PM, Jürgen Schmidt wrote:
> >>>>
> >>>>> On 9/4/13 10:17 PM, Rob Weir wrote:
> >>>>>> On Wed, Sep 4, 2013 at 12:36 PM, janI <ja...@apache.org> wrote:
> >>>>>>> Hi.
> >>>>>>>
> >>>>>>> We have had some longer discussions on different ML/IRC about how
a
> >>>>>>> vm-admin should behave and which level of service we expect for
our
> >>>> servers.
> >>>>>>>
> >>>>>>> We need new admins, so this is also a request for anyone
interested
> >> to
> >>>> chip
> >>>>>>> in.
> >>>>>>>
> >>>>>>> We have had some unfortunate incidents on all 3 vm, of different
> >>>> nature,
> >>>>>>> which made me question if we as a community:
> >>>>>>
> >>>>>> I assume we have vms for Forums and for Wiki. But what is the 3rd
> >> one?
> >>>>>>
> >>>>>>> a) want servers, that are cared for professionally or by
happening.
> >>>>>>> b) want to (are capable to) maintain the servers ourself.
> >>>>>>> c) are prepared to support a change that make a), b) possible.
> >>>>>>>
> >>>>>>
> >>>>>> I assume we want well-maintained servers that help us get our
> >>>>>> project-related tasks done, and also help serve our users.
> >>>>>
> >>>>> +1 that is the main goal, a working reliable infra structure that
> >> helps
> >>>>> to run our project.
> >>>>>
> >>>>> In the
> >>>>>> past, before you got involved, we were not very "proactive". It
> >>>>>> seemed like we just waited for something to break, and then tried
to
> >>>>>> fix it.
> >>>>>
> >>>>> Exactly and doing it proactive is much better and in the end
probably
> >>>>> less work.
> >>>>>
> >>>>>>
> >>>>>> I assume another goal is that we have several people helping with
the
> >>>>>> admin, to share the work, avoid burnouts, cover for vacation, etc.
> >>>>>
> >>>>> And that is a very important goal, we need an environment where we
can
> >>>>> at any time step in if somebody is not available. I now very well in
> >> the
> >>>>> same way as Jan how it is to be a bottleneck. Well it#s true for
many
> >>>>> others of us in different areas. But if the servers are not running
or
> >>>>> the services not available more people are affected faster
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>> I have formulated some thoughts on how admins could work, but in
> >>>> general I
> >>>>>>> believe we should convince infra to take over the vm
responsibility
> >> and
> >>>>>>> keep our well functioning forum/wiki admins.
> >>>>>>>
> >>>>>>> We have a vm-team in place, that was created with the purpose of
not
> >>>> having
> >>>>>>> a single person as admin. I my opinion the team have not lived up
to
> >>>> that
> >>>>>>> purpose but I am still thankful for the help I have received.
> >>>>>>>
> >>>>>>> Remarks the ideas below are my personal thought, which I have used
> >>>> during
> >>>>>>> the time where I maintained the servers:
> >>>>>>>
> >>>>>>> ===========
> >>>>>>> The server should at all times be maintained with the following
> >>>> priority:
> >>>>>>> 1) security (the backside of being popular is to have the
attention
> >> of
> >>>>>>> people who want to gain merit by breaking our servers)
> >>>>>>> 2) stability (we have limited cpu/ram/disk so we must optimize)
> >>>>>>> 3) add user wishes (we already have stable systems, 1,2 are far
> >> more
> >>>>>>> important that enhancing the systems).
> >>>>>>>
> >>>>>>
> >>>>>> and maybe
> >>>>>>
> >>>>>> 3b) Try to evolve systems so users can implement their own wishes,
in
> >>>>>> a way compatible with 1) and 2). For example, if routine logos and
> >>>>>> footers are synched to resources in the project's SVN tree, then
any
> >>>>>> committer can update things.
> >>>>
> >>>> I really like this idea.
> >>>>
> >>>
> >>> I am impressed, is this real serious ?
> >>>
> >>> Think about all the fuzz we have had on several MLs because one
committer
> >>> successfully convinced a vm-admin to change our logo, and the
suggestion
> >> is
> >>> to make that automatic.
> >>>
> >>> Any committer who wants a change, just do a "svn commit", is that
really
> >>> wanted ?
> >>>
> >>
> >> It also makes it possible for any committer to fix a problem if one
occurs.
> >>
> >>> A couple of questions to that:
> >>>
> >>> Committer X want extension translate, and do a "svn commit" the
config is
> >>> updated, but does not work because of other dependencies, who clears
up
> >> the
> >>> work ? for sure THAT is not a vm-admin task.
> >>>
> >>
> >> Same as when a committer checks in code that breaks the build.
> >>
> >>
> >>> Committer X changes the logo, but doing a "svn commit", Committer Y
dont
> >>> like it and does a "svn commit", where are our users in this process
or
> >> our
> >>> decision process ?
> >>>
> >>
> >> Same as when a committer checks in code that someone doesn't like.
> >>
> >> We have a community-based process that handles these things already.
> >>
> >> Your proposal doesn't really avoid these issues. It handles it by
> >> having an admin judge the will of the community.
> >>
> > yes like all other vms I know.
> >
> >
> >>
> >>> 3b) is a sure way to scare any prof. SA away, thats pure anarchy.
> >>>
> >>
> >> In the good sense of the word "anarchy", yes.
> >>
> >> Note: I wouldn't do this for config files and core system files. But
> >> why should the logo or banner or footer of the forums or the wiki be
> >> any harder for a committer to edit than the same content of our
> >> website?
> >>
> >
> > Maybe because the CMS are laid out for that our apps are not. If you
change
> > logo to e.g. a different size you will also need to edit
> > - css
> > - php (for mwiki)
> > - update symlinks (for php2bb)
> >
> > and you might also need to change in the httpd caching scheme, if the
new
> > logo has a different extension.
> >
> > If you want to change to footer, you need to
> > - for wiki edit a php script, that also contains securtiy relevant
> > information.
> > - for php2bb, it can partly already be done by forum admin, but by doing
> > that you break the setup (all forums have identical setup, with
symlinks to
> > a central place.
>
> What both Rob and I were looking for is an understanding of what it might
take to have a unified approach. Your reasoning is fine we were discussing
in a robust way what it would take to make this work. You are precisely
correct to tell us what a high bar this is.
>
> We have 8 different systems to maintain brand on we need to fully
understand all of the implications.
>
> >
> > But never mind. As requested by infra, I tried a last time, to get
> > consensus on having our vms maintained at the level and guidelines used
for
> > infra vms and failed.
> >
> > I acknowledge the fact that the community want vms that are open
> > playgrounds (letting admins change as they please, and even allow
committer
> > access), I believe differently.
>
> You are the one who says that we want an open playground to do anything.
We are only asking for a way to control the brand. Let's talk about what it
would take. You give concrete information above and then at the same time
you quit
>
> You are impossible to have a discussion with. You should be open to
finding a way.
I am sorry you feel that way, I have tried to get attention for about 3
months without success and only because I give up we start to discuss,
does that make me impossible, or is it those that did not want to discuss
earlier ?
I was forced to accept a vm-team (a very good idea), that have not reacted
to a single alert or (apart from arist helping with forum) helped with a
single change/update. But I was told, that it was all good, because we had
an efficient team, does it make me impossible that I tell the truth, that
the team does not work ?
I have been fighting to get our servers updated, including creating several
new vms, I have 1 time asked for support, when we had the incident with
logo changes, which another admin did, in a way that put our servers at
risk. Does it make me impossible that I cannot accept the way that admin
worked (remember this is not the first incident) ?
I feel I have really tried to find ways, but none wanted to listen,
probably because I was there and took care of it. Does that make me
impossible ?
So yes, I did quit, because I could not see any other options.
>>
> > I have, effective 2 hours ago, asked root@a.o to remove my sudo
> > right/access to the vms and the alert notifications, so I can no longer
be
> > expected to react and/or do cleanup of others playground work.
> >
> > The vms are not at risk, imacat, jsc, andrea and arist all have access
and
> > sudo.
> >
> > Thanks for the trust the community have given me in the past.
>
> Thanks for not noticing the difference between an action and a discussion
of how we can go into a "devops" mode and alleviate some of the burden that
you feel as a sysadmin.
I do know the difference, just look at the mail archives, and you will see
how often I have raised these problems the last couple of months. Dont
forget the vm-team was such a "alleviation", which turned out just to make
the burden worse. It seems to me, that the difference is something else:
I fight and discuss about a workable solution with the resources we have
today, while "devops" mode and other suggestions seems to focus on a future
and resources that we dont know if we will ever get.
We need a solution for today, who and how, we already have pending
updates. If we solve today, we can start dreaming about the future.
>
> You act like Rob and I have no experience. That is not so. I work 12
hours days and manage both java and php developers and solaris/ubuntu
syadmins. I am a firm believer in DevOps. As much as possible sysadmins
provide a stable environment for QUALIFIED developers to configure
applications. I may be the person most qualified in this project to help
make this full rebranding happen in a way that makes it easy and not hard
to present a unified header.
Actually you are one of the people in here I admire, and I believe you have
experience. But please so do I, I sold my companies a year ago, we operated
worldwide and dealt with fortune 500 companies. I decided to change lane,
stop managing and do what I really like, to help opensource projects.
Enough about you and me, I think we have established that we both know what
we do.
I acknowledge that both you and rob have experience, but both of you talk
about an unknown future with resources we dont have right now, and we do
have a problem today to solve first.
>
> I've worked with Roller and Confluence, etc.
>
> I am sorry you cannot tell the difference between those who want to work
with you and those who go around you and seemingly don't respect the effort
that you provide.
I am sorry you cannot acknowledge how long I have been fighting while
having my worries ignored.
I am aware I should have done like some of the other vm-team members,
"nothing". I get criticized because I tell that I quit after having tried
hard to get something done, is that real fair ? Would it not be equally
fair to question the vm-team, why they cannot take over, as was expected.
I feel that I have become more of a burden, than an asset, if my feeling is
right just tell me straight.
rgds
jan I.
>
> Best Regards,
> Dave
>
> >
> > rgds
> > jan I.
> >
> >
> >> Regards,
> >>
> >> -Rob
> >>
> >>
> >>> Dont misunderstand, I have no problem with the community implementing
> >>> something like that, just dont expect to get stable well maintained
> >> servers
> >>> ! We have a serious problem with the current admins, expanding that to
> >> all
> >>> committers, that is something that will be in interesting to watch
for a
> >>> large distance.
> >>>
> >>>
> >>>>>>
> >>>>>>> Being an admin on a vm is a job that does not take soo much time,
> >> but
> >>>>>>> requires a lot of monitoring and communication (especially with
> >> infra).
> >>>>>>>
> >>>>>>> A good setup would be, 3 types of admin:
> >>>>>>> Each server will have an appointed "owner" (anchor-admin)
> >>>>>>> A number of persons have full sudo on a server (admin)
> >>>>>>> A number of persons can reboot/restart/work on po files
(help-admin)
> >>>>>>>
> >>>>>>> === Anchor-admin responsibilities ===
> >>>>>>> Anchor-admin is the "owner" of the vm and the prime contact to
> >> infra.
> >>>>>>>
> >>>>>>> Anchor-admin has the overall responsibility of the vm.
> >>>>>>> 1) help when receiving alerts
> >>>>>>> 2) keep informed on available patches, especial security related
> >>>> patches
> >>>>>>> 3) create/keep a maintenance plan
> >>>>>>> 4) coordinate changes external to vm (like dns) with infra
> >>>>>>> 5) participate in infra discussions relevant for the vm (e.g.
> >>>> certificates)
> >>>>>>> 6) monitor the vm regularly for resource usage
> >>>>>>> 7) secure that appl changes are implemented with relevant
consensus
> >>>>>>> 8) discuss work with admin, with the goal that they should be able
> >> to
> >>>> take
> >>>>>>> over one day.
> >>>>>>>
> >>>>>>> These activities are expected to take 3-4 hours pr week, more in
the
> >>>>>>> beginning and less later. The hour usage highly depend on the
number
> >>>> and
> >>>>>>> level of admins.
> >>>>>>>
> >>>>>>> === Admin responsibilities ===
> >>>>>>> Admins help the anchor admin with ongoing maintenance and have
full
> >>>> sudo.
> >>>>>>>
> >>>>>>> All changes must be discussed and agreed with the anchor admin, no
> >>>> change
> >>>>>>> is so important that it cannot wait until discussed !
> >>>>>>>
> >>>>>>
> >>>>>> We might also want an admin-dev@openoffice.apache.org list and
> >> perhaps
> >>>>>> a private one as well to coordinate.
> >>>>
> >>>> Perhaps an admin-dev, but a private one is a not a good idea - the
team
> >>>> should be on the infrastructure list and infra should know what is
up.
> >>>>
> >>> We can make any number of MLs, current fact is that surden admins do
NOT
> >>> reply to private mails, asking them to act.
> >>>
> >>> I for one, do not need more MLs, I need rules admin follow or leave.
> >>>
> >>>>>
> >>>>>> Admins are expected to:
> >>>>>> 1) help when receiving alerts
> >>>>>> 2) stay informed with the vm configuration
> >>>>>> including but not limited to:
> >>>>>> - where are which configuration done, and stored (svn/backup)
> >>>>>> - how are the apps. configured
> >>>>>> - read and update runbook, if something is unclear
> >>>>>> 3) participate in the regular maintenance
> >>>>>> 4) coordinate all non-scheduled work with anchor-admin
> >>>>>>
> >>>>>> These activities are expected to take 1-2 hours pr week, more in
the
> >>>>>> beginning and less later.
> >>>>>>
> >>>>>> Admin does not need to be specialists, we all learn, but it is
> >> important
> >>>>>> that the admin have motivation and time to learn.
> >>>>>>
> >>>>>>
> >>>>>> === Help-admin responsibilities ===
> >>>>>> Help-admins are located in different timezones, so we have 24/7
> >> coverage
> >>>>>> and have limited sudo (only restart/reboot/handle po files).
> >>>>>>
> >>>>>> When a help-admin receives an alert mail, actions should be taken
> >>>>>> 1) is the vm reachable via ssh, then login else escalate to
> >> admin/infra
> >>>>>> 2) is the vm overloaded, or is apache/mysql not running
> >>>>>> 3) restart the needed processes
> >>>>>> 4) mail at least anchor-admin about with obervations and what was
> >> done.
> >>>>>>
> >>>>>>
> >>>>>> ===
> >>>>>> remark the above are just my thoughts, there are a lot of other
> >>>>>> possibilities.
> >>>>
> >>>> It sounds very reasonable to me and worth to work in this direction.
I
> >>>> see myself more in the role of a help-admin but I willing to learn
more
> >>>> to be a better admin.
> >>>
> >>> I agree that the plan is reasonable and professional.
> >>>>
> >>>
> >>> thanks for you kinds words, but 3b) makes that plan obsolete. With 3b)
> >>> everyone is admin, a problem something like 1.000 times bigger than
> >> today,
> >>> where we cannot control 3 admins.
> >>>
> >>> rgds
> >>> jan I.
> >>>
> >>>
> >>>>
> >>>> Regards,
> >>>> Dave
> >>>>
> >>>>>
> >>>>> Juergen
> >>>>>
> >>>>>>>
> >>>>>>> Lets hear your opinion?
> >>>>>>>
> >>>>>>
> >>>>>> It sounds like a good way to think of this.
> >>>>>>
> >>>>>> Regards,
> >>>>>>
> >>>>>> -Rob
> >>>>>>
> >>>>>>> rgds
> >>>>>>> jan I.
> >>>>>>
> >>>>>>
---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>>>>
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
Re: requirements for vm-admins of forum/translate/wiki
Posted by Dave Fisher <da...@comcast.net>.
On Sep 7, 2013, at 2:24 AM, janI wrote:
> On 6 September 2013 19:49, Rob Weir <ro...@apache.org> wrote:
>
>> On Fri, Sep 6, 2013 at 12:14 PM, janI <ja...@apache.org> wrote:
>>> On 6 September 2013 15:27, Dave Fisher <da...@comcast.net> wrote:
>>>
>>>>
>>>> On Sep 4, 2013, at 11:37 PM, Jürgen Schmidt wrote:
>>>>
>>>>> On 9/4/13 10:17 PM, Rob Weir wrote:
>>>>>> On Wed, Sep 4, 2013 at 12:36 PM, janI <ja...@apache.org> wrote:
>>>>>>> Hi.
>>>>>>>
>>>>>>> We have had some longer discussions on different ML/IRC about how a
>>>>>>> vm-admin should behave and which level of service we expect for our
>>>> servers.
>>>>>>>
>>>>>>> We need new admins, so this is also a request for anyone interested
>> to
>>>> chip
>>>>>>> in.
>>>>>>>
>>>>>>> We have had some unfortunate incidents on all 3 vm, of different
>>>> nature,
>>>>>>> which made me question if we as a community:
>>>>>>
>>>>>> I assume we have vms for Forums and for Wiki. But what is the 3rd
>> one?
>>>>>>
>>>>>>> a) want servers, that are cared for professionally or by happening.
>>>>>>> b) want to (are capable to) maintain the servers ourself.
>>>>>>> c) are prepared to support a change that make a), b) possible.
>>>>>>>
>>>>>>
>>>>>> I assume we want well-maintained servers that help us get our
>>>>>> project-related tasks done, and also help serve our users.
>>>>>
>>>>> +1 that is the main goal, a working reliable infra structure that
>> helps
>>>>> to run our project.
>>>>>
>>>>> In the
>>>>>> past, before you got involved, we were not very "proactive". It
>>>>>> seemed like we just waited for something to break, and then tried to
>>>>>> fix it.
>>>>>
>>>>> Exactly and doing it proactive is much better and in the end probably
>>>>> less work.
>>>>>
>>>>>>
>>>>>> I assume another goal is that we have several people helping with the
>>>>>> admin, to share the work, avoid burnouts, cover for vacation, etc.
>>>>>
>>>>> And that is a very important goal, we need an environment where we can
>>>>> at any time step in if somebody is not available. I now very well in
>> the
>>>>> same way as Jan how it is to be a bottleneck. Well it#s true for many
>>>>> others of us in different areas. But if the servers are not running or
>>>>> the services not available more people are affected faster
>>>>>
>>>>>
>>>>>>
>>>>>>> I have formulated some thoughts on how admins could work, but in
>>>> general I
>>>>>>> believe we should convince infra to take over the vm responsibility
>> and
>>>>>>> keep our well functioning forum/wiki admins.
>>>>>>>
>>>>>>> We have a vm-team in place, that was created with the purpose of not
>>>> having
>>>>>>> a single person as admin. I my opinion the team have not lived up to
>>>> that
>>>>>>> purpose but I am still thankful for the help I have received.
>>>>>>>
>>>>>>> Remarks the ideas below are my personal thought, which I have used
>>>> during
>>>>>>> the time where I maintained the servers:
>>>>>>>
>>>>>>> ===========
>>>>>>> The server should at all times be maintained with the following
>>>> priority:
>>>>>>> 1) security (the backside of being popular is to have the attention
>> of
>>>>>>> people who want to gain merit by breaking our servers)
>>>>>>> 2) stability (we have limited cpu/ram/disk so we must optimize)
>>>>>>> 3) add user wishes (we already have stable systems, 1,2 are far
>> more
>>>>>>> important that enhancing the systems).
>>>>>>>
>>>>>>
>>>>>> and maybe
>>>>>>
>>>>>> 3b) Try to evolve systems so users can implement their own wishes, in
>>>>>> a way compatible with 1) and 2). For example, if routine logos and
>>>>>> footers are synched to resources in the project's SVN tree, then any
>>>>>> committer can update things.
>>>>
>>>> I really like this idea.
>>>>
>>>
>>> I am impressed, is this real serious ?
>>>
>>> Think about all the fuzz we have had on several MLs because one committer
>>> successfully convinced a vm-admin to change our logo, and the suggestion
>> is
>>> to make that automatic.
>>>
>>> Any committer who wants a change, just do a "svn commit", is that really
>>> wanted ?
>>>
>>
>> It also makes it possible for any committer to fix a problem if one occurs.
>>
>>> A couple of questions to that:
>>>
>>> Committer X want extension translate, and do a "svn commit" the config is
>>> updated, but does not work because of other dependencies, who clears up
>> the
>>> work ? for sure THAT is not a vm-admin task.
>>>
>>
>> Same as when a committer checks in code that breaks the build.
>>
>>
>>> Committer X changes the logo, but doing a "svn commit", Committer Y dont
>>> like it and does a "svn commit", where are our users in this process or
>> our
>>> decision process ?
>>>
>>
>> Same as when a committer checks in code that someone doesn't like.
>>
>> We have a community-based process that handles these things already.
>>
>> Your proposal doesn't really avoid these issues. It handles it by
>> having an admin judge the will of the community.
>>
> yes like all other vms I know.
>
>
>>
>>> 3b) is a sure way to scare any prof. SA away, thats pure anarchy.
>>>
>>
>> In the good sense of the word "anarchy", yes.
>>
>> Note: I wouldn't do this for config files and core system files. But
>> why should the logo or banner or footer of the forums or the wiki be
>> any harder for a committer to edit than the same content of our
>> website?
>>
>
> Maybe because the CMS are laid out for that our apps are not. If you change
> logo to e.g. a different size you will also need to edit
> - css
> - php (for mwiki)
> - update symlinks (for php2bb)
>
> and you might also need to change in the httpd caching scheme, if the new
> logo has a different extension.
>
> If you want to change to footer, you need to
> - for wiki edit a php script, that also contains securtiy relevant
> information.
> - for php2bb, it can partly already be done by forum admin, but by doing
> that you break the setup (all forums have identical setup, with symlinks to
> a central place.
What both Rob and I were looking for is an understanding of what it might take to have a unified approach. Your reasoning is fine we were discussing in a robust way what it would take to make this work. You are precisely correct to tell us what a high bar this is.
We have 8 different systems to maintain brand on we need to fully understand all of the implications.
>
> But never mind. As requested by infra, I tried a last time, to get
> consensus on having our vms maintained at the level and guidelines used for
> infra vms and failed.
>
> I acknowledge the fact that the community want vms that are open
> playgrounds (letting admins change as they please, and even allow committer
> access), I believe differently.
You are the one who says that we want an open playground to do anything. We are only asking for a way to control the brand. Let's talk about what it would take. You give concrete information above and then at the same time you quit.
You are impossible to have a discussion with. You should be open to finding a way.
>
> I have, effective 2 hours ago, asked root@a.o to remove my sudo
> right/access to the vms and the alert notifications, so I can no longer be
> expected to react and/or do cleanup of others playground work.
>
> The vms are not at risk, imacat, jsc, andrea and arist all have access and
> sudo.
>
> Thanks for the trust the community have given me in the past.
Thanks for not noticing the difference between an action and a discussion of how we can go into a "devops" mode and alleviate some of the burden that you feel as a sysadmin.
You act like Rob and I have no experience. That is not so. I work 12 hours days and manage both java and php developers and solaris/ubuntu syadmins. I am a firm believer in DevOps. As much as possible sysadmins provide a stable environment for QUALIFIED developers to configure applications. I may be the person most qualified in this project to help make this full rebranding happen in a way that makes it easy and not hard to present a unified header.
I've worked with Roller and Confluence, etc.
I am sorry you cannot tell the difference between those who want to work with you and those who go around you and seemingly don't respect the effort that you provide.
Best Regards,
Dave
>
> rgds
> jan I.
>
>
>> Regards,
>>
>> -Rob
>>
>>
>>> Dont misunderstand, I have no problem with the community implementing
>>> something like that, just dont expect to get stable well maintained
>> servers
>>> ! We have a serious problem with the current admins, expanding that to
>> all
>>> committers, that is something that will be in interesting to watch for a
>>> large distance.
>>>
>>>
>>>>>>
>>>>>>> Being an admin on a vm is a job that does not take soo much time,
>> but
>>>>>>> requires a lot of monitoring and communication (especially with
>> infra).
>>>>>>>
>>>>>>> A good setup would be, 3 types of admin:
>>>>>>> Each server will have an appointed "owner" (anchor-admin)
>>>>>>> A number of persons have full sudo on a server (admin)
>>>>>>> A number of persons can reboot/restart/work on po files (help-admin)
>>>>>>>
>>>>>>> === Anchor-admin responsibilities ===
>>>>>>> Anchor-admin is the "owner" of the vm and the prime contact to
>> infra.
>>>>>>>
>>>>>>> Anchor-admin has the overall responsibility of the vm.
>>>>>>> 1) help when receiving alerts
>>>>>>> 2) keep informed on available patches, especial security related
>>>> patches
>>>>>>> 3) create/keep a maintenance plan
>>>>>>> 4) coordinate changes external to vm (like dns) with infra
>>>>>>> 5) participate in infra discussions relevant for the vm (e.g.
>>>> certificates)
>>>>>>> 6) monitor the vm regularly for resource usage
>>>>>>> 7) secure that appl changes are implemented with relevant consensus
>>>>>>> 8) discuss work with admin, with the goal that they should be able
>> to
>>>> take
>>>>>>> over one day.
>>>>>>>
>>>>>>> These activities are expected to take 3-4 hours pr week, more in the
>>>>>>> beginning and less later. The hour usage highly depend on the number
>>>> and
>>>>>>> level of admins.
>>>>>>>
>>>>>>> === Admin responsibilities ===
>>>>>>> Admins help the anchor admin with ongoing maintenance and have full
>>>> sudo.
>>>>>>>
>>>>>>> All changes must be discussed and agreed with the anchor admin, no
>>>> change
>>>>>>> is so important that it cannot wait until discussed !
>>>>>>>
>>>>>>
>>>>>> We might also want an admin-dev@openoffice.apache.org list and
>> perhaps
>>>>>> a private one as well to coordinate.
>>>>
>>>> Perhaps an admin-dev, but a private one is a not a good idea - the team
>>>> should be on the infrastructure list and infra should know what is up.
>>>>
>>> We can make any number of MLs, current fact is that surden admins do NOT
>>> reply to private mails, asking them to act.
>>>
>>> I for one, do not need more MLs, I need rules admin follow or leave.
>>>
>>>>>
>>>>>> Admins are expected to:
>>>>>> 1) help when receiving alerts
>>>>>> 2) stay informed with the vm configuration
>>>>>> including but not limited to:
>>>>>> - where are which configuration done, and stored (svn/backup)
>>>>>> - how are the apps. configured
>>>>>> - read and update runbook, if something is unclear
>>>>>> 3) participate in the regular maintenance
>>>>>> 4) coordinate all non-scheduled work with anchor-admin
>>>>>>
>>>>>> These activities are expected to take 1-2 hours pr week, more in the
>>>>>> beginning and less later.
>>>>>>
>>>>>> Admin does not need to be specialists, we all learn, but it is
>> important
>>>>>> that the admin have motivation and time to learn.
>>>>>>
>>>>>>
>>>>>> === Help-admin responsibilities ===
>>>>>> Help-admins are located in different timezones, so we have 24/7
>> coverage
>>>>>> and have limited sudo (only restart/reboot/handle po files).
>>>>>>
>>>>>> When a help-admin receives an alert mail, actions should be taken
>>>>>> 1) is the vm reachable via ssh, then login else escalate to
>> admin/infra
>>>>>> 2) is the vm overloaded, or is apache/mysql not running
>>>>>> 3) restart the needed processes
>>>>>> 4) mail at least anchor-admin about with obervations and what was
>> done.
>>>>>>
>>>>>>
>>>>>> ===
>>>>>> remark the above are just my thoughts, there are a lot of other
>>>>>> possibilities.
>>>>
>>>> It sounds very reasonable to me and worth to work in this direction. I
>>>> see myself more in the role of a help-admin but I willing to learn more
>>>> to be a better admin.
>>>
>>> I agree that the plan is reasonable and professional.
>>>>
>>>
>>> thanks for you kinds words, but 3b) makes that plan obsolete. With 3b)
>>> everyone is admin, a problem something like 1.000 times bigger than
>> today,
>>> where we cannot control 3 admins.
>>>
>>> rgds
>>> jan I.
>>>
>>>
>>>>
>>>> Regards,
>>>> Dave
>>>>
>>>>>
>>>>> Juergen
>>>>>
>>>>>>>
>>>>>>> Lets hear your opinion?
>>>>>>>
>>>>>>
>>>>>> It sounds like a good way to think of this.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> -Rob
>>>>>>
>>>>>>> rgds
>>>>>>> jan I.
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: requirements for vm-admins of forum/translate/wiki
Posted by janI <ja...@apache.org>.
On 6 September 2013 19:49, Rob Weir <ro...@apache.org> wrote:
> On Fri, Sep 6, 2013 at 12:14 PM, janI <ja...@apache.org> wrote:
> > On 6 September 2013 15:27, Dave Fisher <da...@comcast.net> wrote:
> >
> >>
> >> On Sep 4, 2013, at 11:37 PM, Jürgen Schmidt wrote:
> >>
> >> > On 9/4/13 10:17 PM, Rob Weir wrote:
> >> >> On Wed, Sep 4, 2013 at 12:36 PM, janI <ja...@apache.org> wrote:
> >> >>> Hi.
> >> >>>
> >> >>> We have had some longer discussions on different ML/IRC about how a
> >> >>> vm-admin should behave and which level of service we expect for our
> >> servers.
> >> >>>
> >> >>> We need new admins, so this is also a request for anyone interested
> to
> >> chip
> >> >>> in.
> >> >>>
> >> >>> We have had some unfortunate incidents on all 3 vm, of different
> >> nature,
> >> >>> which made me question if we as a community:
> >> >>
> >> >> I assume we have vms for Forums and for Wiki. But what is the 3rd
> one?
> >> >>
> >> >>> a) want servers, that are cared for professionally or by happening.
> >> >>> b) want to (are capable to) maintain the servers ourself.
> >> >>> c) are prepared to support a change that make a), b) possible.
> >> >>>
> >> >>
> >> >> I assume we want well-maintained servers that help us get our
> >> >> project-related tasks done, and also help serve our users.
> >> >
> >> > +1 that is the main goal, a working reliable infra structure that
> helps
> >> > to run our project.
> >> >
> >> > In the
> >> >> past, before you got involved, we were not very "proactive". It
> >> >> seemed like we just waited for something to break, and then tried to
> >> >> fix it.
> >> >
> >> > Exactly and doing it proactive is much better and in the end probably
> >> > less work.
> >> >
> >> >>
> >> >> I assume another goal is that we have several people helping with the
> >> >> admin, to share the work, avoid burnouts, cover for vacation, etc.
> >> >
> >> > And that is a very important goal, we need an environment where we can
> >> > at any time step in if somebody is not available. I now very well in
> the
> >> > same way as Jan how it is to be a bottleneck. Well it#s true for many
> >> > others of us in different areas. But if the servers are not running or
> >> > the services not available more people are affected faster
> >> >
> >> >
> >> >>
> >> >>> I have formulated some thoughts on how admins could work, but in
> >> general I
> >> >>> believe we should convince infra to take over the vm responsibility
> and
> >> >>> keep our well functioning forum/wiki admins.
> >> >>>
> >> >>> We have a vm-team in place, that was created with the purpose of not
> >> having
> >> >>> a single person as admin. I my opinion the team have not lived up to
> >> that
> >> >>> purpose but I am still thankful for the help I have received.
> >> >>>
> >> >>> Remarks the ideas below are my personal thought, which I have used
> >> during
> >> >>> the time where I maintained the servers:
> >> >>>
> >> >>> ===========
> >> >>> The server should at all times be maintained with the following
> >> priority:
> >> >>> 1) security (the backside of being popular is to have the attention
> of
> >> >>> people who want to gain merit by breaking our servers)
> >> >>> 2) stability (we have limited cpu/ram/disk so we must optimize)
> >> >>> 3) add user wishes (we already have stable systems, 1,2 are far
> more
> >> >>> important that enhancing the systems).
> >> >>>
> >> >>
> >> >> and maybe
> >> >>
> >> >> 3b) Try to evolve systems so users can implement their own wishes, in
> >> >> a way compatible with 1) and 2). For example, if routine logos and
> >> >> footers are synched to resources in the project's SVN tree, then any
> >> >> committer can update things.
> >>
> >> I really like this idea.
> >>
> >
> > I am impressed, is this real serious ?
> >
> > Think about all the fuzz we have had on several MLs because one committer
> > successfully convinced a vm-admin to change our logo, and the suggestion
> is
> > to make that automatic.
> >
> > Any committer who wants a change, just do a "svn commit", is that really
> > wanted ?
> >
>
> It also makes it possible for any committer to fix a problem if one occurs.
>
> > A couple of questions to that:
> >
> > Committer X want extension translate, and do a "svn commit" the config is
> > updated, but does not work because of other dependencies, who clears up
> the
> > work ? for sure THAT is not a vm-admin task.
> >
>
> Same as when a committer checks in code that breaks the build.
>
>
> > Committer X changes the logo, but doing a "svn commit", Committer Y dont
> > like it and does a "svn commit", where are our users in this process or
> our
> > decision process ?
> >
>
> Same as when a committer checks in code that someone doesn't like.
>
> We have a community-based process that handles these things already.
>
> Your proposal doesn't really avoid these issues. It handles it by
> having an admin judge the will of the community.
>
yes like all other vms I know.
>
> > 3b) is a sure way to scare any prof. SA away, thats pure anarchy.
> >
>
> In the good sense of the word "anarchy", yes.
>
> Note: I wouldn't do this for config files and core system files. But
> why should the logo or banner or footer of the forums or the wiki be
> any harder for a committer to edit than the same content of our
> website?
>
Maybe because the CMS are laid out for that our apps are not. If you change
logo to e.g. a different size you will also need to edit
- css
- php (for mwiki)
- update symlinks (for php2bb)
and you might also need to change in the httpd caching scheme, if the new
logo has a different extension.
If you want to change to footer, you need to
- for wiki edit a php script, that also contains securtiy relevant
information.
- for php2bb, it can partly already be done by forum admin, but by doing
that you break the setup (all forums have identical setup, with symlinks to
a central place.
But never mind. As requested by infra, I tried a last time, to get
consensus on having our vms maintained at the level and guidelines used for
infra vms and failed.
I acknowledge the fact that the community want vms that are open
playgrounds (letting admins change as they please, and even allow committer
access), I believe differently.
I have, effective 2 hours ago, asked root@a.o to remove my sudo
right/access to the vms and the alert notifications, so I can no longer be
expected to react and/or do cleanup of others playground work.
The vms are not at risk, imacat, jsc, andrea and arist all have access and
sudo.
Thanks for the trust the community have given me in the past.
rgds
jan I.
> Regards,
>
> -Rob
>
>
> > Dont misunderstand, I have no problem with the community implementing
> > something like that, just dont expect to get stable well maintained
> servers
> > ! We have a serious problem with the current admins, expanding that to
> all
> > committers, that is something that will be in interesting to watch for a
> > large distance.
> >
> >
> >> >>
> >> >>> Being an admin on a vm is a job that does not take soo much time,
> but
> >> >>> requires a lot of monitoring and communication (especially with
> infra).
> >> >>>
> >> >>> A good setup would be, 3 types of admin:
> >> >>> Each server will have an appointed "owner" (anchor-admin)
> >> >>> A number of persons have full sudo on a server (admin)
> >> >>> A number of persons can reboot/restart/work on po files (help-admin)
> >> >>>
> >> >>> === Anchor-admin responsibilities ===
> >> >>> Anchor-admin is the "owner" of the vm and the prime contact to
> infra.
> >> >>>
> >> >>> Anchor-admin has the overall responsibility of the vm.
> >> >>> 1) help when receiving alerts
> >> >>> 2) keep informed on available patches, especial security related
> >> patches
> >> >>> 3) create/keep a maintenance plan
> >> >>> 4) coordinate changes external to vm (like dns) with infra
> >> >>> 5) participate in infra discussions relevant for the vm (e.g.
> >> certificates)
> >> >>> 6) monitor the vm regularly for resource usage
> >> >>> 7) secure that appl changes are implemented with relevant consensus
> >> >>> 8) discuss work with admin, with the goal that they should be able
> to
> >> take
> >> >>> over one day.
> >> >>>
> >> >>> These activities are expected to take 3-4 hours pr week, more in the
> >> >>> beginning and less later. The hour usage highly depend on the number
> >> and
> >> >>> level of admins.
> >> >>>
> >> >>> === Admin responsibilities ===
> >> >>> Admins help the anchor admin with ongoing maintenance and have full
> >> sudo.
> >> >>>
> >> >>> All changes must be discussed and agreed with the anchor admin, no
> >> change
> >> >>> is so important that it cannot wait until discussed !
> >> >>>
> >> >>
> >> >> We might also want an admin-dev@openoffice.apache.org list and
> perhaps
> >> >> a private one as well to coordinate.
> >>
> >> Perhaps an admin-dev, but a private one is a not a good idea - the team
> >> should be on the infrastructure list and infra should know what is up.
> >>
> > We can make any number of MLs, current fact is that surden admins do NOT
> > reply to private mails, asking them to act.
> >
> > I for one, do not need more MLs, I need rules admin follow or leave.
> >
> >>>
> >>>> Admins are expected to:
> >>>> 1) help when receiving alerts
> >>>> 2) stay informed with the vm configuration
> >>>> including but not limited to:
> >>>> - where are which configuration done, and stored (svn/backup)
> >>>> - how are the apps. configured
> >>>> - read and update runbook, if something is unclear
> >>>> 3) participate in the regular maintenance
> >>>> 4) coordinate all non-scheduled work with anchor-admin
> >>>>
> >>>> These activities are expected to take 1-2 hours pr week, more in the
> >>>> beginning and less later.
> >>>>
> >>>> Admin does not need to be specialists, we all learn, but it is
> important
> >>>> that the admin have motivation and time to learn.
> >>>>
> >>>>
> >>>> === Help-admin responsibilities ===
> >>>> Help-admins are located in different timezones, so we have 24/7
> coverage
> >>>> and have limited sudo (only restart/reboot/handle po files).
> >>>>
> >>>> When a help-admin receives an alert mail, actions should be taken
> >>>> 1) is the vm reachable via ssh, then login else escalate to
> admin/infra
> >>>> 2) is the vm overloaded, or is apache/mysql not running
> >>>> 3) restart the needed processes
> >>>> 4) mail at least anchor-admin about with obervations and what was
> done.
> >>>>
> >>>>
> >>>> ===
> >>>> remark the above are just my thoughts, there are a lot of other
> >>>> possibilities.
> >>
> >> It sounds very reasonable to me and worth to work in this direction. I
> >> see myself more in the role of a help-admin but I willing to learn more
> >> to be a better admin.
> >
> > I agree that the plan is reasonable and professional.
> >>
> >
> > thanks for you kinds words, but 3b) makes that plan obsolete. With 3b)
> > everyone is admin, a problem something like 1.000 times bigger than
> today,
> > where we cannot control 3 admins.
> >
> > rgds
> > jan I.
> >
> >
> >>
> >> Regards,
> >> Dave
> >>
> >> >
> >> > Juergen
> >> >
> >> >>>
> >> >>> Lets hear your opinion?
> >> >>>
> >> >>
> >> >> It sounds like a good way to think of this.
> >> >>
> >> >> Regards,
> >> >>
> >> >> -Rob
> >> >>
> >> >>> rgds
> >> >>> jan I.
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >> >>
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: requirements for vm-admins of forum/translate/wiki
Posted by Rob Weir <ro...@apache.org>.
On Fri, Sep 6, 2013 at 12:14 PM, janI <ja...@apache.org> wrote:
> On 6 September 2013 15:27, Dave Fisher <da...@comcast.net> wrote:
>
>>
>> On Sep 4, 2013, at 11:37 PM, Jürgen Schmidt wrote:
>>
>> > On 9/4/13 10:17 PM, Rob Weir wrote:
>> >> On Wed, Sep 4, 2013 at 12:36 PM, janI <ja...@apache.org> wrote:
>> >>> Hi.
>> >>>
>> >>> We have had some longer discussions on different ML/IRC about how a
>> >>> vm-admin should behave and which level of service we expect for our
>> servers.
>> >>>
>> >>> We need new admins, so this is also a request for anyone interested to
>> chip
>> >>> in.
>> >>>
>> >>> We have had some unfortunate incidents on all 3 vm, of different
>> nature,
>> >>> which made me question if we as a community:
>> >>
>> >> I assume we have vms for Forums and for Wiki. But what is the 3rd one?
>> >>
>> >>> a) want servers, that are cared for professionally or by happening.
>> >>> b) want to (are capable to) maintain the servers ourself.
>> >>> c) are prepared to support a change that make a), b) possible.
>> >>>
>> >>
>> >> I assume we want well-maintained servers that help us get our
>> >> project-related tasks done, and also help serve our users.
>> >
>> > +1 that is the main goal, a working reliable infra structure that helps
>> > to run our project.
>> >
>> > In the
>> >> past, before you got involved, we were not very "proactive". It
>> >> seemed like we just waited for something to break, and then tried to
>> >> fix it.
>> >
>> > Exactly and doing it proactive is much better and in the end probably
>> > less work.
>> >
>> >>
>> >> I assume another goal is that we have several people helping with the
>> >> admin, to share the work, avoid burnouts, cover for vacation, etc.
>> >
>> > And that is a very important goal, we need an environment where we can
>> > at any time step in if somebody is not available. I now very well in the
>> > same way as Jan how it is to be a bottleneck. Well it#s true for many
>> > others of us in different areas. But if the servers are not running or
>> > the services not available more people are affected faster
>> >
>> >
>> >>
>> >>> I have formulated some thoughts on how admins could work, but in
>> general I
>> >>> believe we should convince infra to take over the vm responsibility and
>> >>> keep our well functioning forum/wiki admins.
>> >>>
>> >>> We have a vm-team in place, that was created with the purpose of not
>> having
>> >>> a single person as admin. I my opinion the team have not lived up to
>> that
>> >>> purpose but I am still thankful for the help I have received.
>> >>>
>> >>> Remarks the ideas below are my personal thought, which I have used
>> during
>> >>> the time where I maintained the servers:
>> >>>
>> >>> ===========
>> >>> The server should at all times be maintained with the following
>> priority:
>> >>> 1) security (the backside of being popular is to have the attention of
>> >>> people who want to gain merit by breaking our servers)
>> >>> 2) stability (we have limited cpu/ram/disk so we must optimize)
>> >>> 3) add user wishes (we already have stable systems, 1,2 are far more
>> >>> important that enhancing the systems).
>> >>>
>> >>
>> >> and maybe
>> >>
>> >> 3b) Try to evolve systems so users can implement their own wishes, in
>> >> a way compatible with 1) and 2). For example, if routine logos and
>> >> footers are synched to resources in the project's SVN tree, then any
>> >> committer can update things.
>>
>> I really like this idea.
>>
>
> I am impressed, is this real serious ?
>
> Think about all the fuzz we have had on several MLs because one committer
> successfully convinced a vm-admin to change our logo, and the suggestion is
> to make that automatic.
>
> Any committer who wants a change, just do a "svn commit", is that really
> wanted ?
>
It also makes it possible for any committer to fix a problem if one occurs.
> A couple of questions to that:
>
> Committer X want extension translate, and do a "svn commit" the config is
> updated, but does not work because of other dependencies, who clears up the
> work ? for sure THAT is not a vm-admin task.
>
Same as when a committer checks in code that breaks the build.
> Committer X changes the logo, but doing a "svn commit", Committer Y dont
> like it and does a "svn commit", where are our users in this process or our
> decision process ?
>
Same as when a committer checks in code that someone doesn't like.
We have a community-based process that handles these things already.
Your proposal doesn't really avoid these issues. It handles it by
having an admin judge the will of the community.
> 3b) is a sure way to scare any prof. SA away, thats pure anarchy.
>
In the good sense of the word "anarchy", yes.
Note: I wouldn't do this for config files and core system files. But
why should the logo or banner or footer of the forums or the wiki be
any harder for a committer to edit than the same content of our
website?
Regards,
-Rob
> Dont misunderstand, I have no problem with the community implementing
> something like that, just dont expect to get stable well maintained servers
> ! We have a serious problem with the current admins, expanding that to all
> committers, that is something that will be in interesting to watch for a
> large distance.
>
>
>> >>
>> >>> Being an admin on a vm is a job that does not take soo much time, but
>> >>> requires a lot of monitoring and communication (especially with infra).
>> >>>
>> >>> A good setup would be, 3 types of admin:
>> >>> Each server will have an appointed "owner" (anchor-admin)
>> >>> A number of persons have full sudo on a server (admin)
>> >>> A number of persons can reboot/restart/work on po files (help-admin)
>> >>>
>> >>> === Anchor-admin responsibilities ===
>> >>> Anchor-admin is the "owner" of the vm and the prime contact to infra.
>> >>>
>> >>> Anchor-admin has the overall responsibility of the vm.
>> >>> 1) help when receiving alerts
>> >>> 2) keep informed on available patches, especial security related
>> patches
>> >>> 3) create/keep a maintenance plan
>> >>> 4) coordinate changes external to vm (like dns) with infra
>> >>> 5) participate in infra discussions relevant for the vm (e.g.
>> certificates)
>> >>> 6) monitor the vm regularly for resource usage
>> >>> 7) secure that appl changes are implemented with relevant consensus
>> >>> 8) discuss work with admin, with the goal that they should be able to
>> take
>> >>> over one day.
>> >>>
>> >>> These activities are expected to take 3-4 hours pr week, more in the
>> >>> beginning and less later. The hour usage highly depend on the number
>> and
>> >>> level of admins.
>> >>>
>> >>> === Admin responsibilities ===
>> >>> Admins help the anchor admin with ongoing maintenance and have full
>> sudo.
>> >>>
>> >>> All changes must be discussed and agreed with the anchor admin, no
>> change
>> >>> is so important that it cannot wait until discussed !
>> >>>
>> >>
>> >> We might also want an admin-dev@openoffice.apache.org list and perhaps
>> >> a private one as well to coordinate.
>>
>> Perhaps an admin-dev, but a private one is a not a good idea - the team
>> should be on the infrastructure list and infra should know what is up.
>>
> We can make any number of MLs, current fact is that surden admins do NOT
> reply to private mails, asking them to act.
>
> I for one, do not need more MLs, I need rules admin follow or leave.
>
>>>
>>>> Admins are expected to:
>>>> 1) help when receiving alerts
>>>> 2) stay informed with the vm configuration
>>>> including but not limited to:
>>>> - where are which configuration done, and stored (svn/backup)
>>>> - how are the apps. configured
>>>> - read and update runbook, if something is unclear
>>>> 3) participate in the regular maintenance
>>>> 4) coordinate all non-scheduled work with anchor-admin
>>>>
>>>> These activities are expected to take 1-2 hours pr week, more in the
>>>> beginning and less later.
>>>>
>>>> Admin does not need to be specialists, we all learn, but it is important
>>>> that the admin have motivation and time to learn.
>>>>
>>>>
>>>> === Help-admin responsibilities ===
>>>> Help-admins are located in different timezones, so we have 24/7 coverage
>>>> and have limited sudo (only restart/reboot/handle po files).
>>>>
>>>> When a help-admin receives an alert mail, actions should be taken
>>>> 1) is the vm reachable via ssh, then login else escalate to admin/infra
>>>> 2) is the vm overloaded, or is apache/mysql not running
>>>> 3) restart the needed processes
>>>> 4) mail at least anchor-admin about with obervations and what was done.
>>>>
>>>>
>>>> ===
>>>> remark the above are just my thoughts, there are a lot of other
>>>> possibilities.
>>
>> It sounds very reasonable to me and worth to work in this direction. I
>> see myself more in the role of a help-admin but I willing to learn more
>> to be a better admin.
>
> I agree that the plan is reasonable and professional.
>>
>
> thanks for you kinds words, but 3b) makes that plan obsolete. With 3b)
> everyone is admin, a problem something like 1.000 times bigger than today,
> where we cannot control 3 admins.
>
> rgds
> jan I.
>
>
>>
>> Regards,
>> Dave
>>
>> >
>> > Juergen
>> >
>> >>>
>> >>> Lets hear your opinion?
>> >>>
>> >>
>> >> It sounds like a good way to think of this.
>> >>
>> >> Regards,
>> >>
>> >> -Rob
>> >>
>> >>> rgds
>> >>> jan I.
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> >> For additional commands, e-mail: dev-help@openoffice.apache.org
>> >>
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> > For additional commands, e-mail: dev-help@openoffice.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: requirements for vm-admins of forum/translate/wiki
Posted by janI <ja...@apache.org>.
On 6 September 2013 15:27, Dave Fisher <da...@comcast.net> wrote:
>
> On Sep 4, 2013, at 11:37 PM, Jürgen Schmidt wrote:
>
> > On 9/4/13 10:17 PM, Rob Weir wrote:
> >> On Wed, Sep 4, 2013 at 12:36 PM, janI <ja...@apache.org> wrote:
> >>> Hi.
> >>>
> >>> We have had some longer discussions on different ML/IRC about how a
> >>> vm-admin should behave and which level of service we expect for our
> servers.
> >>>
> >>> We need new admins, so this is also a request for anyone interested to
> chip
> >>> in.
> >>>
> >>> We have had some unfortunate incidents on all 3 vm, of different
> nature,
> >>> which made me question if we as a community:
> >>
> >> I assume we have vms for Forums and for Wiki. But what is the 3rd one?
> >>
> >>> a) want servers, that are cared for professionally or by happening.
> >>> b) want to (are capable to) maintain the servers ourself.
> >>> c) are prepared to support a change that make a), b) possible.
> >>>
> >>
> >> I assume we want well-maintained servers that help us get our
> >> project-related tasks done, and also help serve our users.
> >
> > +1 that is the main goal, a working reliable infra structure that helps
> > to run our project.
> >
> > In the
> >> past, before you got involved, we were not very "proactive". It
> >> seemed like we just waited for something to break, and then tried to
> >> fix it.
> >
> > Exactly and doing it proactive is much better and in the end probably
> > less work.
> >
> >>
> >> I assume another goal is that we have several people helping with the
> >> admin, to share the work, avoid burnouts, cover for vacation, etc.
> >
> > And that is a very important goal, we need an environment where we can
> > at any time step in if somebody is not available. I now very well in the
> > same way as Jan how it is to be a bottleneck. Well it#s true for many
> > others of us in different areas. But if the servers are not running or
> > the services not available more people are affected faster
> >
> >
> >>
> >>> I have formulated some thoughts on how admins could work, but in
> general I
> >>> believe we should convince infra to take over the vm responsibility and
> >>> keep our well functioning forum/wiki admins.
> >>>
> >>> We have a vm-team in place, that was created with the purpose of not
> having
> >>> a single person as admin. I my opinion the team have not lived up to
> that
> >>> purpose but I am still thankful for the help I have received.
> >>>
> >>> Remarks the ideas below are my personal thought, which I have used
> during
> >>> the time where I maintained the servers:
> >>>
> >>> ===========
> >>> The server should at all times be maintained with the following
> priority:
> >>> 1) security (the backside of being popular is to have the attention of
> >>> people who want to gain merit by breaking our servers)
> >>> 2) stability (we have limited cpu/ram/disk so we must optimize)
> >>> 3) add user wishes (we already have stable systems, 1,2 are far more
> >>> important that enhancing the systems).
> >>>
> >>
> >> and maybe
> >>
> >> 3b) Try to evolve systems so users can implement their own wishes, in
> >> a way compatible with 1) and 2). For example, if routine logos and
> >> footers are synched to resources in the project's SVN tree, then any
> >> committer can update things.
>
> I really like this idea.
>
I am impressed, is this real serious ?
Think about all the fuzz we have had on several MLs because one committer
successfully convinced a vm-admin to change our logo, and the suggestion is
to make that automatic.
Any committer who wants a change, just do a "svn commit", is that really
wanted ?
A couple of questions to that:
Committer X want extension translate, and do a "svn commit" the config is
updated, but does not work because of other dependencies, who clears up the
work ? for sure THAT is not a vm-admin task.
Committer X changes the logo, but doing a "svn commit", Committer Y dont
like it and does a "svn commit", where are our users in this process or our
decision process ?
3b) is a sure way to scare any prof. SA away, thats pure anarchy.
Dont misunderstand, I have no problem with the community implementing
something like that, just dont expect to get stable well maintained servers
! We have a serious problem with the current admins, expanding that to all
committers, that is something that will be in interesting to watch for a
large distance.
> >>
> >>> Being an admin on a vm is a job that does not take soo much time, but
> >>> requires a lot of monitoring and communication (especially with infra).
> >>>
> >>> A good setup would be, 3 types of admin:
> >>> Each server will have an appointed "owner" (anchor-admin)
> >>> A number of persons have full sudo on a server (admin)
> >>> A number of persons can reboot/restart/work on po files (help-admin)
> >>>
> >>> === Anchor-admin responsibilities ===
> >>> Anchor-admin is the "owner" of the vm and the prime contact to infra.
> >>>
> >>> Anchor-admin has the overall responsibility of the vm.
> >>> 1) help when receiving alerts
> >>> 2) keep informed on available patches, especial security related
> patches
> >>> 3) create/keep a maintenance plan
> >>> 4) coordinate changes external to vm (like dns) with infra
> >>> 5) participate in infra discussions relevant for the vm (e.g.
> certificates)
> >>> 6) monitor the vm regularly for resource usage
> >>> 7) secure that appl changes are implemented with relevant consensus
> >>> 8) discuss work with admin, with the goal that they should be able to
> take
> >>> over one day.
> >>>
> >>> These activities are expected to take 3-4 hours pr week, more in the
> >>> beginning and less later. The hour usage highly depend on the number
> and
> >>> level of admins.
> >>>
> >>> === Admin responsibilities ===
> >>> Admins help the anchor admin with ongoing maintenance and have full
> sudo.
> >>>
> >>> All changes must be discussed and agreed with the anchor admin, no
> change
> >>> is so important that it cannot wait until discussed !
> >>>
> >>
> >> We might also want an admin-dev@openoffice.apache.org list and perhaps
> >> a private one as well to coordinate.
>
> Perhaps an admin-dev, but a private one is a not a good idea - the team
> should be on the infrastructure list and infra should know what is up.
>
We can make any number of MLs, current fact is that surden admins do NOT
reply to private mails, asking them to act.
I for one, do not need more MLs, I need rules admin follow or leave.
>>
>>> Admins are expected to:
>>> 1) help when receiving alerts
>>> 2) stay informed with the vm configuration
>>> including but not limited to:
>>> - where are which configuration done, and stored (svn/backup)
>>> - how are the apps. configured
>>> - read and update runbook, if something is unclear
>>> 3) participate in the regular maintenance
>>> 4) coordinate all non-scheduled work with anchor-admin
>>>
>>> These activities are expected to take 1-2 hours pr week, more in the
>>> beginning and less later.
>>>
>>> Admin does not need to be specialists, we all learn, but it is important
>>> that the admin have motivation and time to learn.
>>>
>>>
>>> === Help-admin responsibilities ===
>>> Help-admins are located in different timezones, so we have 24/7 coverage
>>> and have limited sudo (only restart/reboot/handle po files).
>>>
>>> When a help-admin receives an alert mail, actions should be taken
>>> 1) is the vm reachable via ssh, then login else escalate to admin/infra
>>> 2) is the vm overloaded, or is apache/mysql not running
>>> 3) restart the needed processes
>>> 4) mail at least anchor-admin about with obervations and what was done.
>>>
>>>
>>> ===
>>> remark the above are just my thoughts, there are a lot of other
>>> possibilities.
>
> It sounds very reasonable to me and worth to work in this direction. I
> see myself more in the role of a help-admin but I willing to learn more
> to be a better admin.
I agree that the plan is reasonable and professional.
>
thanks for you kinds words, but 3b) makes that plan obsolete. With 3b)
everyone is admin, a problem something like 1.000 times bigger than today,
where we cannot control 3 admins.
rgds
jan I.
>
> Regards,
> Dave
>
> >
> > Juergen
> >
> >>>
> >>> Lets hear your opinion?
> >>>
> >>
> >> It sounds like a good way to think of this.
> >>
> >> Regards,
> >>
> >> -Rob
> >>
> >>> rgds
> >>> jan I.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: requirements for vm-admins of forum/translate/wiki
Posted by Dave Fisher <da...@comcast.net>.
On Sep 4, 2013, at 11:37 PM, Jürgen Schmidt wrote:
> On 9/4/13 10:17 PM, Rob Weir wrote:
>> On Wed, Sep 4, 2013 at 12:36 PM, janI <ja...@apache.org> wrote:
>>> Hi.
>>>
>>> We have had some longer discussions on different ML/IRC about how a
>>> vm-admin should behave and which level of service we expect for our servers.
>>>
>>> We need new admins, so this is also a request for anyone interested to chip
>>> in.
>>>
>>> We have had some unfortunate incidents on all 3 vm, of different nature,
>>> which made me question if we as a community:
>>
>> I assume we have vms for Forums and for Wiki. But what is the 3rd one?
>>
>>> a) want servers, that are cared for professionally or by happening.
>>> b) want to (are capable to) maintain the servers ourself.
>>> c) are prepared to support a change that make a), b) possible.
>>>
>>
>> I assume we want well-maintained servers that help us get our
>> project-related tasks done, and also help serve our users.
>
> +1 that is the main goal, a working reliable infra structure that helps
> to run our project.
>
> In the
>> past, before you got involved, we were not very "proactive". It
>> seemed like we just waited for something to break, and then tried to
>> fix it.
>
> Exactly and doing it proactive is much better and in the end probably
> less work.
>
>>
>> I assume another goal is that we have several people helping with the
>> admin, to share the work, avoid burnouts, cover for vacation, etc.
>
> And that is a very important goal, we need an environment where we can
> at any time step in if somebody is not available. I now very well in the
> same way as Jan how it is to be a bottleneck. Well it#s true for many
> others of us in different areas. But if the servers are not running or
> the services not available more people are affected faster
>
>
>>
>>> I have formulated some thoughts on how admins could work, but in general I
>>> believe we should convince infra to take over the vm responsibility and
>>> keep our well functioning forum/wiki admins.
>>>
>>> We have a vm-team in place, that was created with the purpose of not having
>>> a single person as admin. I my opinion the team have not lived up to that
>>> purpose but I am still thankful for the help I have received.
>>>
>>> Remarks the ideas below are my personal thought, which I have used during
>>> the time where I maintained the servers:
>>>
>>> ===========
>>> The server should at all times be maintained with the following priority:
>>> 1) security (the backside of being popular is to have the attention of
>>> people who want to gain merit by breaking our servers)
>>> 2) stability (we have limited cpu/ram/disk so we must optimize)
>>> 3) add user wishes (we already have stable systems, 1,2 are far more
>>> important that enhancing the systems).
>>>
>>
>> and maybe
>>
>> 3b) Try to evolve systems so users can implement their own wishes, in
>> a way compatible with 1) and 2). For example, if routine logos and
>> footers are synched to resources in the project's SVN tree, then any
>> committer can update things.
I really like this idea.
>>
>>> Being an admin on a vm is a job that does not take soo much time, but
>>> requires a lot of monitoring and communication (especially with infra).
>>>
>>> A good setup would be, 3 types of admin:
>>> Each server will have an appointed "owner" (anchor-admin)
>>> A number of persons have full sudo on a server (admin)
>>> A number of persons can reboot/restart/work on po files (help-admin)
>>>
>>> === Anchor-admin responsibilities ===
>>> Anchor-admin is the "owner" of the vm and the prime contact to infra.
>>>
>>> Anchor-admin has the overall responsibility of the vm.
>>> 1) help when receiving alerts
>>> 2) keep informed on available patches, especial security related patches
>>> 3) create/keep a maintenance plan
>>> 4) coordinate changes external to vm (like dns) with infra
>>> 5) participate in infra discussions relevant for the vm (e.g. certificates)
>>> 6) monitor the vm regularly for resource usage
>>> 7) secure that appl changes are implemented with relevant consensus
>>> 8) discuss work with admin, with the goal that they should be able to take
>>> over one day.
>>>
>>> These activities are expected to take 3-4 hours pr week, more in the
>>> beginning and less later. The hour usage highly depend on the number and
>>> level of admins.
>>>
>>> === Admin responsibilities ===
>>> Admins help the anchor admin with ongoing maintenance and have full sudo.
>>>
>>> All changes must be discussed and agreed with the anchor admin, no change
>>> is so important that it cannot wait until discussed !
>>>
>>
>> We might also want an admin-dev@openoffice.apache.org list and perhaps
>> a private one as well to coordinate.
Perhaps an admin-dev, but a private one is a not a good idea - the team should be on the infrastructure list and infra should know what is up.
>>
>>> Admins are expected to:
>>> 1) help when receiving alerts
>>> 2) stay informed with the vm configuration
>>> including but not limited to:
>>> - where are which configuration done, and stored (svn/backup)
>>> - how are the apps. configured
>>> - read and update runbook, if something is unclear
>>> 3) participate in the regular maintenance
>>> 4) coordinate all non-scheduled work with anchor-admin
>>>
>>> These activities are expected to take 1-2 hours pr week, more in the
>>> beginning and less later.
>>>
>>> Admin does not need to be specialists, we all learn, but it is important
>>> that the admin have motivation and time to learn.
>>>
>>>
>>> === Help-admin responsibilities ===
>>> Help-admins are located in different timezones, so we have 24/7 coverage
>>> and have limited sudo (only restart/reboot/handle po files).
>>>
>>> When a help-admin receives an alert mail, actions should be taken
>>> 1) is the vm reachable via ssh, then login else escalate to admin/infra
>>> 2) is the vm overloaded, or is apache/mysql not running
>>> 3) restart the needed processes
>>> 4) mail at least anchor-admin about with obervations and what was done.
>>>
>>>
>>> ===
>>> remark the above are just my thoughts, there are a lot of other
>>> possibilities.
>
> It sounds very reasonable to me and worth to work in this direction. I
> see myself more in the role of a help-admin but I willing to learn more
> to be a better admin.
I agree that the plan is reasonable and professional.
Regards,
Dave
>
> Juergen
>
>>>
>>> Lets hear your opinion?
>>>
>>
>> It sounds like a good way to think of this.
>>
>> Regards,
>>
>> -Rob
>>
>>> rgds
>>> jan I.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: requirements for vm-admins of forum/translate/wiki
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 9/4/13 10:17 PM, Rob Weir wrote:
> On Wed, Sep 4, 2013 at 12:36 PM, janI <ja...@apache.org> wrote:
>> Hi.
>>
>> We have had some longer discussions on different ML/IRC about how a
>> vm-admin should behave and which level of service we expect for our servers.
>>
>> We need new admins, so this is also a request for anyone interested to chip
>> in.
>>
>> We have had some unfortunate incidents on all 3 vm, of different nature,
>> which made me question if we as a community:
>
> I assume we have vms for Forums and for Wiki. But what is the 3rd one?
>
>> a) want servers, that are cared for professionally or by happening.
>> b) want to (are capable to) maintain the servers ourself.
>> c) are prepared to support a change that make a), b) possible.
>>
>
> I assume we want well-maintained servers that help us get our
> project-related tasks done, and also help serve our users.
+1 that is the main goal, a working reliable infra structure that helps
to run our project.
In the
> past, before you got involved, we were not very "proactive". It
> seemed like we just waited for something to break, and then tried to
> fix it.
Exactly and doing it proactive is much better and in the end probably
less work.
>
> I assume another goal is that we have several people helping with the
> admin, to share the work, avoid burnouts, cover for vacation, etc.
And that is a very important goal, we need an environment where we can
at any time step in if somebody is not available. I now very well in the
same way as Jan how it is to be a bottleneck. Well it#s true for many
others of us in different areas. But if the servers are not running or
the services not available more people are affected faster
>
>> I have formulated some thoughts on how admins could work, but in general I
>> believe we should convince infra to take over the vm responsibility and
>> keep our well functioning forum/wiki admins.
>>
>> We have a vm-team in place, that was created with the purpose of not having
>> a single person as admin. I my opinion the team have not lived up to that
>> purpose but I am still thankful for the help I have received.
>>
>> Remarks the ideas below are my personal thought, which I have used during
>> the time where I maintained the servers:
>>
>> ===========
>> The server should at all times be maintained with the following priority:
>> 1) security (the backside of being popular is to have the attention of
>> people who want to gain merit by breaking our servers)
>> 2) stability (we have limited cpu/ram/disk so we must optimize)
>> 3) add user wishes (we already have stable systems, 1,2 are far more
>> important that enhancing the systems).
>>
>
> and maybe
>
> 3b) Try to evolve systems so users can implement their own wishes, in
> a way compatible with 1) and 2). For example, if routine logos and
> footers are synched to resources in the project's SVN tree, then any
> committer can update things.
>
>> Being an admin on a vm is a job that does not take soo much time, but
>> requires a lot of monitoring and communication (especially with infra).
>>
>> A good setup would be, 3 types of admin:
>> Each server will have an appointed "owner" (anchor-admin)
>> A number of persons have full sudo on a server (admin)
>> A number of persons can reboot/restart/work on po files (help-admin)
>>
>> === Anchor-admin responsibilities ===
>> Anchor-admin is the "owner" of the vm and the prime contact to infra.
>>
>> Anchor-admin has the overall responsibility of the vm.
>> 1) help when receiving alerts
>> 2) keep informed on available patches, especial security related patches
>> 3) create/keep a maintenance plan
>> 4) coordinate changes external to vm (like dns) with infra
>> 5) participate in infra discussions relevant for the vm (e.g. certificates)
>> 6) monitor the vm regularly for resource usage
>> 7) secure that appl changes are implemented with relevant consensus
>> 8) discuss work with admin, with the goal that they should be able to take
>> over one day.
>>
>> These activities are expected to take 3-4 hours pr week, more in the
>> beginning and less later. The hour usage highly depend on the number and
>> level of admins.
>>
>> === Admin responsibilities ===
>> Admins help the anchor admin with ongoing maintenance and have full sudo.
>>
>> All changes must be discussed and agreed with the anchor admin, no change
>> is so important that it cannot wait until discussed !
>>
>
> We might also want an admin-dev@openoffice.apache.org list and perhaps
> a private one as well to coordinate.
>
>> Admins are expected to:
>> 1) help when receiving alerts
>> 2) stay informed with the vm configuration
>> including but not limited to:
>> - where are which configuration done, and stored (svn/backup)
>> - how are the apps. configured
>> - read and update runbook, if something is unclear
>> 3) participate in the regular maintenance
>> 4) coordinate all non-scheduled work with anchor-admin
>>
>> These activities are expected to take 1-2 hours pr week, more in the
>> beginning and less later.
>>
>> Admin does not need to be specialists, we all learn, but it is important
>> that the admin have motivation and time to learn.
>>
>>
>> === Help-admin responsibilities ===
>> Help-admins are located in different timezones, so we have 24/7 coverage
>> and have limited sudo (only restart/reboot/handle po files).
>>
>> When a help-admin receives an alert mail, actions should be taken
>> 1) is the vm reachable via ssh, then login else escalate to admin/infra
>> 2) is the vm overloaded, or is apache/mysql not running
>> 3) restart the needed processes
>> 4) mail at least anchor-admin about with obervations and what was done.
>>
>>
>> ===
>> remark the above are just my thoughts, there are a lot of other
>> possibilities.
It sounds very reasonable to me and worth to work in this direction. I
see myself more in the role of a help-admin but I willing to learn more
to be a better admin.
Juergen
>>
>> Lets hear your opinion?
>>
>
> It sounds like a good way to think of this.
>
> Regards,
>
> -Rob
>
>> rgds
>> jan I.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: requirements for vm-admins of forum/translate/wiki
Posted by Rob Weir <ro...@apache.org>.
On Wed, Sep 4, 2013 at 12:36 PM, janI <ja...@apache.org> wrote:
> Hi.
>
> We have had some longer discussions on different ML/IRC about how a
> vm-admin should behave and which level of service we expect for our servers.
>
> We need new admins, so this is also a request for anyone interested to chip
> in.
>
> We have had some unfortunate incidents on all 3 vm, of different nature,
> which made me question if we as a community:
I assume we have vms for Forums and for Wiki. But what is the 3rd one?
> a) want servers, that are cared for professionally or by happening.
> b) want to (are capable to) maintain the servers ourself.
> c) are prepared to support a change that make a), b) possible.
>
I assume we want well-maintained servers that help us get our
project-related tasks done, and also help serve our users. In the
past, before you got involved, we were not very "proactive". It
seemed like we just waited for something to break, and then tried to
fix it.
I assume another goal is that we have several people helping with the
admin, to share the work, avoid burnouts, cover for vacation, etc.
> I have formulated some thoughts on how admins could work, but in general I
> believe we should convince infra to take over the vm responsibility and
> keep our well functioning forum/wiki admins.
>
> We have a vm-team in place, that was created with the purpose of not having
> a single person as admin. I my opinion the team have not lived up to that
> purpose but I am still thankful for the help I have received.
>
> Remarks the ideas below are my personal thought, which I have used during
> the time where I maintained the servers:
>
> ===========
> The server should at all times be maintained with the following priority:
> 1) security (the backside of being popular is to have the attention of
> people who want to gain merit by breaking our servers)
> 2) stability (we have limited cpu/ram/disk so we must optimize)
> 3) add user wishes (we already have stable systems, 1,2 are far more
> important that enhancing the systems).
>
and maybe
3b) Try to evolve systems so users can implement their own wishes, in
a way compatible with 1) and 2). For example, if routine logos and
footers are synched to resources in the project's SVN tree, then any
committer can update things.
> Being an admin on a vm is a job that does not take soo much time, but
> requires a lot of monitoring and communication (especially with infra).
>
> A good setup would be, 3 types of admin:
> Each server will have an appointed "owner" (anchor-admin)
> A number of persons have full sudo on a server (admin)
> A number of persons can reboot/restart/work on po files (help-admin)
>
> === Anchor-admin responsibilities ===
> Anchor-admin is the "owner" of the vm and the prime contact to infra.
>
> Anchor-admin has the overall responsibility of the vm.
> 1) help when receiving alerts
> 2) keep informed on available patches, especial security related patches
> 3) create/keep a maintenance plan
> 4) coordinate changes external to vm (like dns) with infra
> 5) participate in infra discussions relevant for the vm (e.g. certificates)
> 6) monitor the vm regularly for resource usage
> 7) secure that appl changes are implemented with relevant consensus
> 8) discuss work with admin, with the goal that they should be able to take
> over one day.
>
> These activities are expected to take 3-4 hours pr week, more in the
> beginning and less later. The hour usage highly depend on the number and
> level of admins.
>
> === Admin responsibilities ===
> Admins help the anchor admin with ongoing maintenance and have full sudo.
>
> All changes must be discussed and agreed with the anchor admin, no change
> is so important that it cannot wait until discussed !
>
We might also want an admin-dev@openoffice.apache.org list and perhaps
a private one as well to coordinate.
> Admins are expected to:
> 1) help when receiving alerts
> 2) stay informed with the vm configuration
> including but not limited to:
> - where are which configuration done, and stored (svn/backup)
> - how are the apps. configured
> - read and update runbook, if something is unclear
> 3) participate in the regular maintenance
> 4) coordinate all non-scheduled work with anchor-admin
>
> These activities are expected to take 1-2 hours pr week, more in the
> beginning and less later.
>
> Admin does not need to be specialists, we all learn, but it is important
> that the admin have motivation and time to learn.
>
>
> === Help-admin responsibilities ===
> Help-admins are located in different timezones, so we have 24/7 coverage
> and have limited sudo (only restart/reboot/handle po files).
>
> When a help-admin receives an alert mail, actions should be taken
> 1) is the vm reachable via ssh, then login else escalate to admin/infra
> 2) is the vm overloaded, or is apache/mysql not running
> 3) restart the needed processes
> 4) mail at least anchor-admin about with obervations and what was done.
>
>
> ===
> remark the above are just my thoughts, there are a lot of other
> possibilities.
>
> Lets hear your opinion?
>
It sounds like a good way to think of this.
Regards,
-Rob
> rgds
> jan I.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org