Here's the workflow that I would like, in descending order. - memstat.json.rb handles updates to members.txt via multiUpdate which moves the emeritus request from emeritus-requests-received to emeritus all in one big svn transaction. If there is a failure, return the transcript with details what went wrong so secretary can manually fix whatever needs to be done.
- memstat.json.rb handles updates to members.txt via multiUpdate which separately moves the emeritus request from emeritus-requests-received to emeritus. If there is a failure, return the transcript with details what went wrong so secretary can manually fix whatever needs to be done. - memstat.json.rb handles updates to members.txt and then in a separate svn_ operation moves the emeritus request from emeritus-requests-received to emeritus. If there is a failure, return the transcript with details what went wrong so secretary can manually fix whatever needs to be done. IIUC the first (most preferable) option requires infra to approve the PR that Sam/Sebb proposed. Their evaluation has no publicly reported time frame. The other options require additional analysis and implementation by the whimsy team. Meanwhile, the roster emeritus project is stalled. I'd like to at least push the changes to memstat.json.rb but without some fix that may be premature. Craig > On Jul 7, 2020, at 5:04 PM, Sam Ruby <ru...@intertwingly.net> wrote: > > lets give this a shot: > > https://github.com/apache/infrastructure-p6/pull/394 > <https://github.com/apache/infrastructure-p6/pull/394> > > - Sam Ruby > > On Tue, Jul 7, 2020 at 7:25 PM Craig Russell <apache....@gmail.com > <mailto:apache....@gmail.com>> wrote: >> >> I would say that the easiest solution is for the svn repositories to be >> "fixed" to allow the code that we have to work. >> >> Sebb, can you find out from infra if there is a technical solution to this? >> If it is just "change some permissions" that allows svnmucc to work then >> let's do that. >> >> Or is there some other side effect (like the code has to first checkout a >> non-existent repository and fiddle with some svnurl magic that bypasses our >> repository.yml architecture)? >> >> Please let's see if this is viable. >> >> Thanks, >> Craig >> >>> On Jul 7, 2020, at 3:31 PM, sebb <seb...@gmail.com> wrote: >>> >>> On Tue, 7 Jul 2020 at 23:14, Sam Ruby <ru...@intertwingly.net >>> <mailto:ru...@intertwingly.net> <mailto:ru...@intertwingly.net >>> <mailto:ru...@intertwingly.net>>> wrote: >>>> >>>> On Tue, Jul 7, 2020 at 12:59 PM Craig Russell <apache....@gmail.com> wrote: >>>>> >>>>> Hi Sebb, >>>>> >>>>> Good job figuring out what the problem was (is). >>>>> >>>>> From my perspective, having emeritus under documents is somewhat >>>>> arbitrary. There is no reason for the emeritus documents to have to live >>>>> there, considering that they are all foundation. You could also make a >>>>> case for moving member_apps under foundation since the member apps are >>>>> probably the most personal-sensitive documents we hold. >>>>> >>>>> My recommended solution: >>>>> >>>>> mv documents/emeritus* foundation >>>> >>>> I've lost track of what error this fixes. >>> >>> svnmucc cannot update both ^foundation and ^documents in the same batch. >>> >>> This appears to be because the top-level private directory is locked down. >>> >>>> Question: would it be possible to go the other way? >>>> >>>> It sounds like there is a directory for temporary documents, and that >>>> is currently in foundation, and that causes a problem. >>> >>> Not a temporary directory, it is members.txt that is under ^foundation >>> >>>> Can that directory instead be in documents? >>> >>> Not the whole directory, but potentially members.txt could move. >>> That might however be more disruptive. >>> >>> The alternatives are: >>> - solve the svnmucc permission issue with the help of Infra >>> - use a non-atomic sequence of SVN commands to update members.txt and >>> the emeritus files. >>> The commands to do the updates are not difficult, however successful >>> recovery from errors is tricky, which is why I suggested svnmucc. >>> But if using svnmucc does not make it easier, then we don't have to use it. >>> >>>> It just seems weird to me for the rule to be that all documents are in >>>> documents except for those that aren't. >>> >>> What is a document? >>> There are lots of files under ^foundation that could be classified as >>> documents... >>> >>>>> A bit of code tweaking to change repository.yml and we're done. >>>>> >>>>> If no objections within 72, we can proceed with this plan. >>>>> >>>>> Craig >>>> >>>> - Sam Ruby >>>> >>>>>> On Jul 7, 2020, at 8:31 AM, sebb <seb...@gmail.com> wrote: >>>>>> >>>>>> On Tue, 7 Jul 2020 at 14:39, Craig Russell <apache....@gmail.com> wrote: >>>>>>> >>>>>>> Any new news on the failure in (emeritus) function? >>>>>> >>>>>> Whilst the changes are both to the same repository, they have different >>>>>> roots: >>>>>> >>>>>> ^foundation >>>>>> and >>>>>> ^documents >>>>>> >>>>>> Thus the common root is ^ >>>>>> >>>>>> It looks like it may be necessary to have write access to the >>>>>> top-level directory to allow the commit to succeed as a batch. >>>>>> I doubt that would be granted, so it may be necessary to find a >>>>>> different approach -- or move the documents? >>>>>> >>>>>> At present not even read-access is allowed at top-level. >>>>>> If read access were sufficient, that might be allowed by Infra. >>>>>> >>>>>>> I don't want to step on any toes if anyone is still working on the >>>>>>> error. >>>>>>> >>>>>>> Craig >>>>>>> >>>>>>>> On Jul 6, 2020, at 2:17 PM, Craig Russell <apache....@gmail.com> wrote: >>>>>>>> >>>>>>>> Hi Sebb, >>>>>>>> >>>>>>>> Thanks for that. Now there is a different problem with (Emeritus). See >>>>>>>> else thread. >>>>>>>> >>>>>>>> Craig >>>>>>>> >>>>>>>>> On Jul 6, 2020, at 1:17 PM, sebb <seb...@gmail.com> wrote: >>>>>>>>> >>>>>>>>> On Mon, 6 Jul 2020 at 18:44, Craig Russell <apache....@gmail.com> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> I merged the roster-emeritus branch and tried out some of the new >>>>>>>>>> features. >>>>>>>>>> >>>>>>>>>> 1. Request emeritus fails on line 70 of memstat.json.rb [1] >>>>>>>>>> template, err = >>>>>>>>>> ASF::SVN.svn('cat', EMERITUS_TEMPLATE_URL, {env:env}) >>>>>>>>> >>>>>>>>> AFAICT it must be env that is untainted, but not sure if so or where >>>>>>>>> to fix this yet. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2. Move to emeritus status for a member with an outstanding request >>>>>>>>>> fails on line 21 of memstat.json.rb [2] >>>>>>>>>> ASF::SVN.multiUpdate_ members_txt, message, env, _ do |text| >>>>>>>>> >>>>>>>>> Should be fixed; whimsy4 is on an old Ruby which does not have >>>>>>>>> URI::File >>>>>>>>> >>>>>>>>>> Any ideas? >>>>>>>>>> >>>>>>>>>> Craig >>>>>>>>>> >>>>>>>>>> [1] { >>>>>>>>>> "exception": "#<SecurityError: Insecure operation - spawn>", >>>>>>>>>> "backtrace": [ >>>>>>>>>> "/usr/local/rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/open3.rb:199:in >>>>>>>>>> `spawn'", >>>>>>>>>> "/usr/local/rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/open3.rb:199:in >>>>>>>>>> `popen_run'", >>>>>>>>>> "/usr/local/rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/open3.rb:95:in >>>>>>>>>> `popen3'", >>>>>>>>>> "/usr/local/rvm/rubies/ruby-2.4.1/lib/ruby/2.4.0/open3.rb:258:in >>>>>>>>>> `capture3'", >>>>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/svn.rb:387:in `svn'", >>>>>>>>>> "/x1/srv/whimsy/www/roster/views/actions/memstat.json.rb:70:in >>>>>>>>>> `_evaluate'", >>>>>>>>>> "/x1/srv/whimsy/www/roster/main.rb:204:in `block in <top >>>>>>>>>> (required)>'", >>>>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/rack.rb:223:in `call'", >>>>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/rack.rb:48:in `call'", >>>>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/rack.rb:200:in `call'", >>>>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/rack.rb:254:in `call'", >>>>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/rack/thread_handler_extension.rb:97:in >>>>>>>>>> `process_request'", >>>>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:157:in >>>>>>>>>> `accept_and_process_next_request'", >>>>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:110:in >>>>>>>>>> `main_loop'", >>>>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/request_handler.rb:415:in >>>>>>>>>> `block (3 levels) in start_threads'", >>>>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/utils.rb:113:in >>>>>>>>>> `block in create_thread_and_abort_on_exception'" >>>>>>>>>> ] >>>>>>>>>> >>>>>>>>>> [2] { >>>>>>>>>> "exception": "#<NameError: uninitialized constant URI::File\nDid you >>>>>>>>>> mean? File>", >>>>>>>>>> "backtrace": [ >>>>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/svn.rb:752:in `multiUpdate_'", >>>>>>>>>> "/x1/srv/whimsy/www/roster/views/actions/memstat.json.rb:21:in >>>>>>>>>> `_evaluate'", >>>>>>>>>> "/x1/srv/whimsy/www/roster/main.rb:204:in `block in <top >>>>>>>>>> (required)>'", >>>>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/rack.rb:223:in `call'", >>>>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/rack.rb:48:in `call'", >>>>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/rack.rb:200:in `call'", >>>>>>>>>> "/x1/srv/whimsy/lib/whimsy/asf/rack.rb:254:in `call'", >>>>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/rack/thread_handler_extension.rb:97:in >>>>>>>>>> `process_request'", >>>>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:157:in >>>>>>>>>> `accept_and_process_next_request'", >>>>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/request_handler/thread_handler.rb:110:in >>>>>>>>>> `main_loop'", >>>>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/request_handler.rb:415:in >>>>>>>>>> `block (3 levels) in start_threads'", >>>>>>>>>> "/usr/local/rvm/gems/ruby-2.4.1/gems/passenger-6.0.2/src/ruby_supportlib/phusion_passenger/utils.rb:113:in >>>>>>>>>> `block in create_thread_and_abort_on_exception'" >>>>>>>>>> ] >>>>>>>>>> } >>>>>>>>>> } >>>>>>>>>> Craig L Russell >>>>>>>>>> c...@apache.org >>>>>>>>>> >>>>>>>> >>>>>>>> Craig L Russell >>>>>>>> c...@apache.org >>>>>>>> >>>>>>> >>>>>>> Craig L Russell >>>>>>> c...@apache.org >>>>>>> >>>>> >>>>> Craig L Russell >>>>> c...@apache.org >> >> Craig L Russell >> c...@apache.org Craig L Russell c...@apache.org
