GitLab

For now, map it to dump_results() which has butt-ugly output but is way
better than a "Can't locate object method" exception. Ultimately the few
uses of this method will get replaced by script specific printfs. I see
no reason for a general emulation of this method.

they can just convert directly over.

will teach me to believe what I read on the web), there is absolutely
no support at all inside. So, a little more wrapping of things and
some code changes, and presto, dataseek() works. Good that we do not
do this very often.

current and maintained DBI::mysql module. A couple of things make this
a little more work then you might think.

Mysql exports a slightly different API then DBI, both at the DB *and*
the statement level. The former required some restructuring of
emdbi.pm, partly cause we want external sites to continue using Mysql
for a while longer. So, emdbi suppports both interfaces, via the
configure variable TBUSEDBI.

I also took the opportunity to also scrap the existing fork()
detection code and redo it in an easier to understand manner.
Actually, I had no idea what the previous code was trying to do, so it
was easier to just get rid of it, rather then try to make it work for
the DBI API.

There are also API differences in the "statement" class, but
fortunately this can be hidden by wrapping the statement class with a
wrapper that adds the routines we need to avoid making silly changes
to 1000s of queries. They are all trivial little things since mostly
its a matter of naming (numrows --> rows).

I also changed the library we use on ops (db/libtbdb.pm.in) to use
DBI, but in this case I just switched it over. Seemed like overkill to
worry about supporting both APIs on ops. If it works it works, and so
far it does. 

Lastly, the following modules still use Mysql directly. They all need
to be changed, but none of these are on the critical path to swapin
and swapout, so they can change later.

db/dumperrorlog.proxy.in
db/showgraph.in
db/sitevarscheck.in
bgmon/find-asymmetric
db/pelab_opspush.proxy.in
slothd/sdisrunning.in
utils/export_tables.in
utils/setbuildinfo.in
pelab/bgmon/libpelabdb.pm
pelab/dbmonitor/libtbdb.pm

error in protogeni/updates/14

when called in list context.

updates are done.

  When a project is initially created a new mailing list is created,
  PROJ-admin@emulab.net.

  testbed-approval is subscribed to the list

  Several emails that originally went to testbed-approval now go to the
  mailing list instead.  The From, To, fields are basically the same
  with testbed-approval becoming PROJ-admin.  This means some mail
  is sent with a From PROJ-admin and Bcc the mailing list.  Note that
  some mail still goes to testbed-approval directly, in particular
  ones where there is no clear project involved, and when a project is
  denied.

  In addition notifications of approval status of new members is also
  sent to the list.  These emails use to only go to testbed-audit@.

  Currently All mail sent to PROJ-admin is also sent to testbed-audit
  (via a Bcc).  This means that some mail that didn't use to go to
  testbed-audit now does.

  The mailing list is deleted when a project is deleted with out first
  being approved.  Becuase of this notified that a project is denied
  is sent to testbed-approval instead of PROJ-admin.

  Admins can access the mailing list from the Project Profile page.

  The mailing list is open in order to allow users to reply to the
  mailing list, in addition the check that PROJ-admin is in the To or
  CC field is disabled.  There is currently no spam control on the
  mailing lists.  However, since the mailing list address is not posted
  anywhere it should't pick up to much spam.  If it does we can deal
  with it then.

  Finally, a new script is created to create the per-project admin
  mailing list.  See doc/UPDATING.

Also add DBQuerySingleFatal to libdb, which is like DBQueryFatal but
also fails if the query didn't return any results.  Basically
identical to he version in libtblog.  Eventually libtblog should be
modified to use this version.

into a new module called emdbi.pm, and reexport the symbol names back
out. This allows me to import just the db interface code to the Geni
modules I am writing, without having to drag in 4000 lines of other
crap that is Emulab specific. This change is invisible to the Emulab
code, although I did it without any perl exporter/importer magic
incantations; did it the old fashioned way.