Investigate removing karlserve

[Tres Seaver]

Absent the never-realized "plankton KARL" business model, the complexity / obfuscation of karlserve is outweighing its utility. We need to figure out how much work is involved to rip it out.

As a deliverable, create a branch of the 'dev-buildout' and remove all traces of 'karlserve' from it. Document what features will need to be re-worked (e.g., plugin scripts, etc.)

[Chris McDonough (chrism-plope)]

I've created a branch of KARL dev-buildout (<email address hidden>:karlproject/dev-buildout.git) named 'karlserveless'. It removes the dependency on karlserve from the build, and uses a 'karlserveless' branch of the karl package, into which I cut n pasted a bunch of code from karlserve (a root factory, mainly).

Changes on this branch as compared to master:

- karlserve, the package, is not depended upon nor put on the PYTHONPATH.

- karlserve, the command, is no longer available. You start karl via "bin/paster serve etc/karl.ini" rather than "bin/karlserve serve"

- etc/karl.ini is new, etc/karlserve.ini was removed.

- etc/instances.ini was removed. It was an artifact of karlserve.

- a new pg.conf zconfig file is in etc representing the configuration for RelStorage-based deployments. This used to be the domain of karlserve, which would dynamically write such a file.

- Per-instance configuration stored in the database is no longer honored.

A bunch of functionality will need to be reworked for this branch to be merged back to master. In particular, all the non-"serve" parts of karlserve, which are thus:

```
    backdate Backdate created and modified timestamps of content.
    chown Backdate created and modified timestamps of content.
    clean_tags Reassign tags owned by users who no longer exist.
    create_mailin_trace
                        Add a fake blog tool to community for receiving mailin
                        trace emails.
    debug Open a debug session with a Karl instance.
    digest Send digest emails.
    evolve Bring database up to date with code.
    export_community Export a community's data.
    export_usage_metadata
                        Export usage metadata for OSI.
    feeds Rss/Atom feed operations.
    generate_stats Generate statistics about communities and users.
    gsa_sync Sync staff profiles and login to OSI GSA.
    init_repozitory Initialize repozitory for objects not yet in
                        repozitory.
    mailin Process incoming mail.
    mailout Send outgoing mail.
    metrics Save metrics to the zodb.
    mode Show or change mode of instances.
    peopleconf Dump or load a people directory configuration.
    reindex_text Switches the text index of an instance to use either
                        zope.index or pgtextindex.
    remove_extracted_data
                        Removed cached _extracted_data from files.
    samplegen Generate sample content in the database.
    settings Manage instance configuration.
    sso Operations for mapping SSO credentials to Karl users
    usersync Sync users to external data source.
```

[Chris McDonough (chrism-plope)]

Other features of note:

- "only_one" feature for scripts, which prevents a subsequent run of a script from stomping on an already-running instance.

- "last_sync_tid" feature (see karlserve)

- maintenance mode

[Chris McDonough (chrism-plope)]

Figure out difference between "mode" (NORMAL/MAINTENANCE/READONLY) and settings read_only flag.

[Chris McDonough (chrism-plope)]

squash all mentions of var_instance

[Chris McDonough (chrism-plope)]

These settings were "migratable" in migrate_ini, investigate what they mean:

migratable_settings = [
    'package',
    'system_name',
    'system_email_domain',
    'admin_email',
    'offline_app_url',
    'postoffice.bounce_from_email',
    'staff_change_password_url',
    'forgot_password_url',
    'kaltura_enabled',
    'kaltura_partner_id',
    'kaltura_sub_partner_id',
    'kaltura_user_secret',
    'kaltura_admin_secret',
    'kaltura_client_session',
    'kaltura_kcw_uiconf_id',
    'kaltura_player_cache_st',
    'kaltura_player_uiconf_id',
    'kaltura_player_cache_st',
    '+error_monitor_subsystems',
]

[Chris McDonough (chrism-plope)]

Feed settings probably have to migrate back to ini file ("[feed:foo]")

[Chris McDonough (chrism-plope)]

"read_only" flag in config is now non-meaningful. Instead, a "mode" value in config can be NORMAL, MAINTENANCE, or READONLY. Readonly is implied by the value being one of (MAINTENANCE, READONLY).

[Chris McDonough (chrism-plope)]

All tests now pass in karl and osi on karlserveless branches.

[Tres Seaver (tseaver)]

We want to land this one ASAP in m138.

[Paul Everitt (paul-agendaless)]

Back to Chris.

[Chris McDonough (chrism-plope)]

I've created a karlserveless branch of "osideploy" that builds karlstaging/karlprod instances using checkouts of the karlserveless branches of various other packages.

Nits:

- It uses git@ urls instead of https urls for development checkouts, because one of them (osi) is not accessible via https (at least I couldn't figure out how to do it). This means that "bin/stage localstaging build" will require that your 'karltest' user has a passphraseless ssh pubkey that correlates with a github user that has access to the repositories being checked out.

- It builds libmemcached 1.0.18 instead of 0.53, because 0.53 refused to build on my Ubuntu 12.04 system (see https://bugzilla.redhat.com/show_bug.cgi?id=1037707).

- Unfortunately, using libmemcached 1.0.18 breaks pylibmc, which is used by RelStorage, so I've had to disable the memcached related items in the relstorage configuration.

- The mailin process isn't working because it wants a ``postoffice.queue`` to be present in the configuration and I'm not sure what to set it to.

Independent/mindful of these nits, running "bin/stage localstaging run" successfully starts karl, and I can visit it on localhost:6544.

[Chris McDonough (chrism-plope)]

Note that we'll need to backport commits that go into master into karlserveless. I've tried to cherry-pick some already, and I believe the ones that are outstanding start at https://github.com/karlproject/karl/commit/25e66a85834019740cfa4590b6adec1b7351157b

[Paul Everitt (paul-agendaless)]

1) I don't think we can get this into production without memcache for RelStorage. Do you suggest that I make a ticket for ChrisR next week to research what versions of libmemcached/pylibmc we can get running? Or do we need to go into RelStorage and straighten it out?

2) Want me to make a ticket for ChrisR to address the postoffice.queue setting?

3) I think we'll enter a stage where we don't do a flurry of small fixes on master. I can ask ChrisR to get the current backlog of commits onto the branch.

--Paul

On Jul 4, 2014, at 7:05 PM, Chris McDonough <email address hidden> wrote:

> Note that we'll need to backport commits that go into master into
> karlserveless. I've tried to cherry-pick some already, and I believe
> the ones that are outstanding start at
> https://github.com/karlproject/karl/commit/25e66a85834019740cfa4590b6adec1b7351157b
>
> --
> You received this bug notification because you are subscribed to KARL3.
> https://bugs.launchpad.net/bugs/1319545
>
> Title:
> Investigate removing karlserve
>
> Status in KARL3:
> In Progress
>
> Bug description:
> Absent the never-realized "plankton KARL" business model, the
> complexity / obfuscation of karlserve is outweighing its utility. We
> need to figure out how much work is involved to rip it out.
>
> As a deliverable, create a branch of the 'dev-buildout' and remove all
> traces of 'karlserve' from it. Document what features will need to be
> re-worked (e.g., plugin scripts, etc.)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/karl3/+bug/1319545/+subscriptions

[Chris McDonough (chrism-plope)]

It may be an issue that is only local to my machine. Is anyone else having problems building libmemcache? This is the output I get:

[localhost] out: CXXLD clients/memparse
[localhost] out: libmemcached/.libs/libmemcached.so: undefined reference to `pthread_once'
[localhost] out: collect2: ld returned 1 exit status
[localhost] out: make[1]: *** [clients/memparse] Error 1
[localhost] out: make[1]: Leaving directory `/tmp/tmpB_JuTYbuildout-libmemcached/libmemcached-0.53'
[localhost] out: make: *** [all] Error 2
[localhost] out: libmemcached: cmmi failed: /tmp/tmpB_JuTYbuildout-libmemcached
[localhost] out: While:
[localhost] out: Installing libmemcached.
[localhost] out:
[localhost] out: An internal error occured due to a bug in either zc.buildout or in a
[localhost] out: recipe being used:
[localhost] out: Traceback (most recent call last):
[localhost] out: File "/srv/karltest/staging/2/lib/python2.6/site-packages/zc.buildout-1.4.3-py2.6.egg/zc/buildout/buildout.py", line 1660, in main
[localhost] out: getattr(buildout, command)(args)
[localhost] out: File "/srv/karltest/staging/2/lib/python2.6/site-packages/zc.buildout-1.4.3-py2.6.egg/zc/buildout/buildout.py", line 532, in install
[localhost] out: installed_files = self[part]._call(recipe.install)
[localhost] out: File "/srv/karltest/staging/2/lib/python2.6/site-packages/zc.buildout-1.4.3-py2.6.egg/zc/buildout/buildout.py", line 1204, in _call
[localhost] out: return f()
[localhost] out: File "/srv/karltest/staging/2/eggs/zc.recipe.cmmi-1.3.4-py2.6.egg/zc/recipe/cmmi/__init__.py", line 99, in install
[localhost] out: self.build()
[localhost] out: File "/srv/karltest/staging/2/eggs/zc.recipe.cmmi-1.3.4-py2.6.egg/zc/recipe/cmmi/__init__.py", line 182, in build
[localhost] out: self.cmmi(dest)
[localhost] out: File "/srv/karltest/staging/2/eggs/zc.recipe.cmmi-1.3.4-py2.6.egg/zc/recipe/cmmi/__init__.py", line 208, in cmmi
[localhost] out: system("make")
[localhost] out: File "/srv/karltest/staging/2/eggs/zc.recipe.cmmi-1.3.4-py2.6.egg/zc/recipe/cmmi/__init__.py", line 31, in system
[localhost] out: raise SystemError("Failed", c)
[localhost] out: SystemError: ('Failed', 'make')
[localhost] out:

Fatal error: sudo() received nonzero return code 1 while executing!

Requested: bin/buildout -N
Executed: sudo -S -p 'sudo password:' -u "karltest" /bin/bash -l -c "cd /srv/karltest/staging/2 && bin/buildout -N"

Aborting.

[Chris McDonough (chrism-plope)]

I figured out the postoffice.queue thing fwiw.

[Paul Everitt (paul-agendaless)]

Over to ChrisR for two tasks in comment #15 on this ticket:

- See if you can build pylibmc on karlserveless branch on Ubuntu without problems
- Get unmerged commits from master back onto karlservless branch

Should be an hour and a half for these two combined.

[Paul Everitt (paul-agendaless)]

Let's move karlserveless to September.

[Paul Everitt (paul-agendaless)]

We aren't going to have enough budget in September to do this. Punt.

[Paul Everitt (paul-agendaless)]

ChrisR, comment #1 on this ticket has the analysis from ChrisM.

[Chris Rossi (chris-archimedeanco)]

I've gone ahead and rebased on top of current master the karlserveless branches for both the development buildout and the karl package. Existing checkouts of these packages should be deleted/recloned.

From reading the comments, the things I'm concerned about and will investigate:

1) Figure out what's going on with feeds now. Do they need to be reconfigured for OSI?

2) Dump any persistent settings for OSF and make sure the wind up in karl.ini.

3) I think mcdonc's memcached woes are just on his box, but I'll make sure we can use memcache din the gocept environment. There is also another ticket related to seeing if we can just use a system libmemcached in osideploy.

[Paul Everitt (paul-agendaless)]

1) I'm not sure what would be needed to get feeds over to the new world. I presume it just means, we need a console script?

2) Ok.

3) Let's make life easier for this ticket and say that upgrading libmemcached is *not* part of karlserveless. It is ok for now if you are able to build it but he isn't.

--Paul

On Sep 25, 2014, at 11:12 AM, Chris Rossi <email address hidden> wrote:

> I've gone ahead and rebased on top of current master the karlserveless
> branches for both the development buildout and the karl package.
> Existing checkouts of these packages should be deleted/recloned.
>
>> From reading the comments, the things I'm concerned about and will
> investigate:
>
> 1) Figure out what's going on with feeds now. Do they need to be
> reconfigured for OSI?
>
> 2) Dump any persistent settings for OSF and make sure the wind up in
> karl.ini.
>
> 3) I think mcdonc's memcached woes are just on his box, but I'll make
> sure we can use memcache din the gocept environment. There is also
> another ticket related to seeing if we can just use a system
> libmemcached in osideploy.
>
> --
> You received this bug notification because you are subscribed to KARL3.
> https://bugs.launchpad.net/bugs/1319545
>
> Title:
> Investigate removing karlserve
>
> Status in KARL3:
> In Progress
>
> Bug description:
> Absent the never-realized "plankton KARL" business model, the
> complexity / obfuscation of karlserve is outweighing its utility. We
> need to figure out how much work is involved to rip it out.
>
> As a deliverable, create a branch of the 'dev-buildout' and remove all
> traces of 'karlserve' from it. Document what features will need to be
> re-worked (e.g., plugin scripts, etc.)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/karl3/+bug/1319545/+subscriptions

[Chris Rossi (chris-archimedeanco)]

4) Make sure variables set in instances.ini aren't lost, especially intranet paths.

[Chris Rossi (chris-archimedeanco)]

I've rebased osideploy karlserveless branch as well.

[Chris Rossi (chris-archimedeanco)]

5) Set up urchin

[Chris Rossi (chris-archimedeanco)]

I still need to look at feeds. Staging is running karlserveless right now, though.

[Chris Rossi (chris-archimedeanco)]

On the feeds stuff, it looks mcdonc took care of it. It should be noted that we'll need to rewrite the cron jobs when going into production, a process which is not currently automated.

[Chris Rossi (chris-archimedeanco)]

But something on staging is not releasing db connection, so that needs investigation.

[Chris Rossi (chris-archimedeanco)]

Fixed mailin. I'm going to go ahead and mark this ticket as complete. Let's use new tickets for bugs as we find them.