nexedi / slapos.core

Marked this merge request as a Work In Progress

mentioned in merge request slapos.recipe.cmmi!6

@rafael @xiaowu.zhang this MR is a placeholder for slapos node software part of slapos.recipe.cmmi!6 , as suggested in slapos.recipe.cmmi!6 (comment 60883)

I'm wondering if we should define one path or multiple paths to support the use case of webrunner (or testnode) using the cache of "parent" slapos.

In that case, slapos from webrunner or testnode would not be able to write to this cache (because no permission to write in that folder), but can still use softwares from this shared path.

One problem is that it would be harder to track which softwares are using the shared when we want to remove obsolete entries from the shared folder.

Also slapos.recipe.cmmi would be a bit more complex.

you can also include download-cache option too

In fact, I think here:

https://lab.nexedi.com/nexedi/slapos.core/blob/master/slapos/grid/SlapObject.py#L275

should generate something like:

[buildout]
extends = %(software_release)s

%(additional_options)s

I don't know why we append options on the command line, instead just write a buildout.cfg that actually works out of the box.

@rafael thanks for comments. I just realize you suggested in slapos.recipe.cmmi!6 (comment 60867) to name this option shared-part and here I used slapos-recipe-cmmi-shared-path name. I have no strong preference for either name. I started using slapos-recipe-cmmi-shared-path before noticing your suggestion.

That's a good point that we could generate a "ready to use" buildout in the first place. I just copied existing behaviour of passing options on command line, but it seems better to add this in generated buildout.

Added 1 commit:

• b9f401ba - [shared]: Rename slapos_recipe_cmmi_shared_path into shared_software_root

Added 1 commit:

• 9d9b3680 - wip: Create shared_software_root folders

@rafael I don't think we should use ',' as path separator. We could use os.pathsep but for consistency with other options in slapos.cfg ( for example download-from-binary-cache-url-blacklist ), why not be\n separated, one path per line ?

shared_software_root =
  /opt/slapgrid/shared/
  /srv/slapgrid/slappart0/srv/runner/software/shared/

sure, pathsep is better

how can i test this patch ? it seems i can't test in my webrunner. i changed slapos.core, but the one i changed is not used

Like everthing else related to egg "python setup.py test"

this patch is unfinished probably, as tests may fail (I may not finish myself, it is up to you to finish)

Added 1 commit:

• 65b4bfba - use \n for consistency with other options

@rafael and I discussed this one year ago in Lille. We said that it's important to support the "recursivity" of slapos, so that when we have a "slapos in slapos", the inner slapos can reuse shared parts from the outer slapos, but cannot write to shared parts of outer slapos.

If I remember well what we said with

• in slapos.cfg we should define a list of shared paths, the idea is that the last (or first I forgot) one is read-write, others are read-only.
• slapos.recipe.cmmi supports this and try to find existing shared parts in all shared path and if not found, it will use the read-write one.
• code creating a recursive slapos ( testnode, webrunner, standalone ...) needs to pass their own list of shared path as read-only when creating a slapos.

mentioned in merge request slapos!624

mentioned in merge request slapos.recipe.cmmi!9

added 713 commits

• 65b4bfba...1b68f7d4 - 712 commits from branch master
• aaa023e5 - grid: new shared_part_list config file option

Compare with previous version

@luke @rafael I updated this part as well. I'm still testing, but I already appreciate feedback. I changed to add in the generated buildout.cfg as you suggested.

@jerome looks fine the latest changes

added 1 commit

• dbab6068 - grid: new shared_part_list config file option

Compare with previous version

added 41 commits

• dbab6068...1bc9a264 - 40 commits from branch master
• 5348eedc - grid: new shared_part_list config file option

Compare with previous version

unmarked as a Work In Progress

changed title from WIP: Support for slapos.recipe.cmmi in slapos node software to grid: new shared_part_list config file option

I update to use another buildout option, because we cannot make the same option become a list without breaking old software releases that assume that it's a single value.

tests: on py2 on py3

mentioned in merge request !64

If this and slapos.recipe.cmmi!9 looks OK, it would be nice to see how we can merge and release eggs (if we can make a release of slapos.core with this and !64 that would be perfect :))

mentioned in merge request slapos!629

mentioned in commit 5cbd70bc

merged

I am afraid that shared_part_list usage is incompatible with binary cache upload, as SlapObject.uploadSoftwareRelease tarballs only the SR, and does nothing regarding shared parts. Am I right? I see no test coverage for this case.

I propose to make shared_part_list mutually exclusive with any option which would result with uploading binary cache. IMO the best way is to fail hard with error if upload could happen with shared_part_list enabled, thus we will protect shacache against bad SRs to be uploaded.

Yes it is incompatible, we won't use on production shared_part_list for now.

I am afraid that shared_part_list usage is incompatible with binary cache upload, as SlapObject.uploadSoftwareRelease tarballs only the SR, and does nothing regarding shared parts.

Something was done in the first batch of changes to support shared software. I think that 19e3f1b6 is already doing what you suggest to do. But I don't know what is supposed to create this .shared. I have some software installed using shared parts and there's no .shared.

If we want to support this, maybe it's easier/more reliable to introspect the content of .installed.cfg to see if the some shared parts are referenced.

I see no test coverage for this case.

Yes, it seems there is no test for that .shared thing, but there is no test for uploading either (I only see tests checking that blacklisted software don't upload) . Maybe we should uploading software to shacache ?

Maybe we should uploading software to shacache ?

typo ... Maybe we should abandon uploading software to shacache ?

If we want to support this, maybe it's easier/more reliable to introspect the content of .installed.cfg to see if the some shared parts are referenced.

I'll give it a try.

typo ... Maybe we should abandon uploading software to shacache ?

For Vifib team uploading to binary cache (which happens during slapos node software run on some servers automatically) is a critical feature to have good deployments.

I'll give it a try.

Proposed in !152