Re: requirements for vm-admins of forum/translate/wiki
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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: requirements for vm-admins of forum/translate/wiki
On 8 September 2013 00:01, janI j...@apache.org wrote: On Sep 7, 2013 10:28 PM, Dave Fisher dave2w...@comcast.net wrote: On Sep 7, 2013, at 2:24 AM, janI wrote: On 6 September 2013 19:49, Rob Weir robw...@apache.org wrote: On Fri, Sep 6, 2013 at 12:14 PM, janI j...@apache.org wrote: On 6 September 2013 15:27, Dave Fisher dave2w...@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 j...@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
Re: requirements for vm-admins of forum/translate/wiki
On Sat, Sep 7, 2013 at 5:24 AM, janI j...@apache.org wrote: On 6 September 2013 19:49, Rob Weir robw...@apache.org wrote: On Fri, Sep 6, 2013 at 12:14 PM, janI j...@apache.org wrote: On 6 September 2013 15:27, Dave Fisher dave2w...@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 j...@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
Re: requirements for vm-admins of forum/translate/wiki
On 8 September 2013 14:29, Rob Weir robw...@apache.org wrote: On Sat, Sep 7, 2013 at 5:24 AM, janI j...@apache.org wrote: On 6 September 2013 19:49, Rob Weir robw...@apache.org wrote: On Fri, Sep 6, 2013 at 12:14 PM, janI j...@apache.org wrote: On 6 September 2013 15:27, Dave Fisher dave2w...@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 j...@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
Re: requirements for vm-admins of forum/translate/wiki
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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: requirements for vm-admins of forum/translate/wiki
On Sun, Sep 8, 2013 at 5:40 PM, Andrea Pescetti pesce...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: requirements for vm-admins of forum/translate/wiki
On 8 September 2013 23:40, Andrea Pescetti pesce...@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.orgdev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: requirements for vm-admins of forum/translate/wiki
Rob Weir wrote on Sun, Sep 08, 2013 at 18:11:19 -0400: On Sun, Sep 8, 2013 at 5:40 PM, Andrea Pescetti pesce...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For
Re: requirements for vm-admins of forum/translate/wiki
On 6 September 2013 19:49, Rob Weir robw...@apache.org wrote: On Fri, Sep 6, 2013 at 12:14 PM, janI j...@apache.org wrote: On 6 September 2013 15:27, Dave Fisher dave2w...@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 j...@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
Re: requirements for vm-admins of forum/translate/wiki
On Sep 7, 2013, at 2:24 AM, janI wrote: On 6 September 2013 19:49, Rob Weir robw...@apache.org wrote: On Fri, Sep 6, 2013 at 12:14 PM, janI j...@apache.org wrote: On 6 September 2013 15:27, Dave Fisher dave2w...@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 j...@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
Re: requirements for vm-admins of forum/translate/wiki
On Sep 7, 2013 10:28 PM, Dave Fisher dave2w...@comcast.net wrote: On Sep 7, 2013, at 2:24 AM, janI wrote: On 6 September 2013 19:49, Rob Weir robw...@apache.org wrote: On Fri, Sep 6, 2013 at 12:14 PM, janI j...@apache.org wrote: On 6 September 2013 15:27, Dave Fisher dave2w...@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 j...@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
Re: requirements for vm-admins of forum/translate/wiki
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 j...@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-...@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
Re: requirements for vm-admins of forum/translate/wiki
On 6 September 2013 15:27, Dave Fisher dave2w...@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 j...@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
Re: requirements for vm-admins of forum/translate/wiki
On Fri, Sep 6, 2013 at 12:14 PM, janI j...@apache.org wrote: On 6 September 2013 15:27, Dave Fisher dave2w...@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 j...@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
Re: requirements for vm-admins of forum/translate/wiki
On 9/4/13 10:17 PM, Rob Weir wrote: On Wed, Sep 4, 2013 at 12:36 PM, janI j...@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-...@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. ===
Re: requirements for vm-admins of forum/translate/wiki
On Wed, Sep 4, 2013 at 9:36 AM, janI j...@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. --
Re: requirements for vm-admins of forum/translate/wiki
On 5 September 2013 22:14, Kay Schenk kay.sch...@gmail.com wrote: On Wed, Sep 4, 2013 at 9:36 AM, janI j...@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
Re: requirements for vm-admins of forum/translate/wiki
On Thu, Sep 5, 2013 at 2:56 PM, janI j...@apache.org wrote: On 5 September 2013 22:14, Kay Schenk kay.sch...@gmail.com wrote: On Wed, Sep 4, 2013 at 9:36 AM, janI j...@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 (
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
On Wed, Sep 4, 2013 at 12:36 PM, janI j...@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-...@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
