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 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-...@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-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 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 additional commands, e-mail: dev-h...@openoffice.apache.org >
