Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Everton Ribeiro
    @nuxlli
    @slobo, the docker not support any way to change the permissions of a drive mapping to create a container
    in your case you have two options:
    forcing the user with:
    docker_extra: {
      // extra docker options
      create: {
        User: "root",
      },
    },
    Slobodan Mišković
    @slobo
    heh, i tried start: {User and run:{User.
    are these documented anywhere?
    Everton Ribeiro
    @nuxlli
    the docker_extra is divided into: create (when the container is being created) and start (when it will be started)
    unfortunately not yet, mainly because widely support the use of these options, since azk is premised to be agnostic to the container system
    Slobodan Mišković
    @slobo
    makes sense to keep 'em hidden then
    Everton Ribeiro
    @nuxlli
    :D
    this user question is known to us, but we have not found a definitive approach to it
    Slobodan Mišković
    @slobo
    out of curiosity, what other containers are considered in the future? BSD jails?
    Everton Ribeiro
    @nuxlli
    the main reason is that the very Docker does not have a good solution to issues such as:
    • Change permissions for mapped folders in containers
    • Mapping between users and the host container (something like a table ids)
    rsrs, jails, among others, like "container app" (Rocket)
    Slobodan Mišković
    @slobo
    one suggestion, since we already have to specify image: { docker:, i would put docker_extra inside the image key to keep them together
    Is there a way to get more debugging out of azk? -vv doesn't seem to provide much to the effect of what commands it's trying to execute etc. Is there a debug log somewhere?
    Everton Ribeiro
    @nuxlli
    add the docker_extra to images seems to me an interesting option that suits our idea of ​​separating the images declaration on an extra point off the systems statement, something like: image ('my_image', { docker: //... });
    Slobodan Mišković
    @slobo
    or even image: docker('php:53', {create: { User: 'root'{})
    to keep it similar to path() and persistent()
    Everton Ribeiro
    @nuxlli
    you are right, -vv does not yet offer all the power you want, the azk --log=debug start ... should offer something closer to what you are searching for (at least hourly)
    yes, that would be "DSL"
    Slobodan Mišković
    @slobo
    --log=debug gives more events that are happening, but getting closer :smile:
    Everton Ribeiro
    @nuxlli
    rsrs
    we are currently working on an internal improvement in the way azk code behaves as the events that can be logged or displayed in a verbose mode: azukiapp/azk#385
    after this change will be able to improve the verbose
    finally the idea is to change the system logs to use "syslog"
    Slobodan Mišković
    @slobo
    sounds promissing :D
    Slobodan Mišković
    @slobo
    Is there a canonical way to keep Azkfile.js small, like say having
    ` include('azk/*')
    and then i could have azk/system1.js with just the definition of system1 in it. How much javascript is supported/encouraged inside Azkfile.js?
    Everton Ribeiro
    @nuxlli
    it's good point, @slobo! we have this already mapped but it's in the backlog yet.
    if you could open an issue to that would be great! In this way you can follow the evolution of azk regard this feature
    Slobodan Mišković
    @slobo
    #395
    Also, is there ability to use CoffeScript? Would be nice since there is less syntactic noise.
    Everton Ribeiro
    @nuxlli
    thanks
    Everton Ribeiro
    @nuxlli
    As for the CoffeScript: we have plans to add "plugins" support in the azk, it would give the possibility to endure CoffeScript and ES6 directly in Azkfile.js
    Slobodan Mišković
    @slobo
    for { mounts: { '/path': persistent('foo')}} documentation says "persistent allows to share data across applications". Does that mean that if I have /folder1/Azkfile.js and /folder2/Azkfile.js both will get the same data for persistent('foo')?
    Gullit Miranda
    @gullitmiranda
    no
    Slobodan Mišković
    @slobo
    ok, good, i was dreading having to ensure different persistent names :)
    Gullit Miranda
    @gullitmiranda
    it allows sharing between of the same project applications (Azkfile.js).
    it is not necessary =D
    Slobodan Mišković
    @slobo
    consider changing the docs wording to clarify: "Using the same parameter with the persistent option allows you to share data across systems in the same Azkfile.js".
    Gullit Miranda
    @gullitmiranda
    You could open an issue for this? =D
    Slobodan Mišković
    @slobo

    Q2: I want to have a custom suffix for http: { domains:, say

        http: {
          domains: [ "#{system.name}.#{my_domain}" ]
        },

    I tried putting on top of Azkfile.js something like

    var my_domain = manifest.dir + '.' + azk.default_domain;

    but that results in error: "Manifest not defined". Now, I solved my problem by doing

        http: {
          domains: [ "#{system.name}.#{manifest.dir}.#{azk.default_domain}" ]
        },

    But am wondering in general how much JS is allowed / encouraged in Azkfile.js? What variables / functions are allowed in there?

    Come to think of it, these values are not interpolated right away, but only later in execution, right?
    Gullit Miranda
    @gullitmiranda
    The Azkfile.js is based on JS, but is its own DSL. We discourage the use of javascript, precisely because it is not documented which can be used JS.
    And yes, the value is interpolated later, so you must use the last form.
    Slobodan Mišković
    @slobo
    do you see any downside to doing this:
    var http_template = {
      domains: [ "#{system.name}.#{manifest.dir}.#{azk.default_domain}" ]
    };
    systems({
      sys1: {
        http: http_template,
        // ...
      },
      sys2: {
        http: http_template,
        // ...
      },
      // ...
     });
    There is lots of benefits to having full power of javascript in Azkfile.js, I found it usefull in say grunt. I like the DSL that you provide since it will let you change internals easier, but if you decide that JavaScript is a total no-no, i'd then rename the file to Azkfile, without .js to stop the temptation :)
    Slobodan Mišković
    @slobo
    btw, whats the reason to disallow the use of underscore in system names? something with internals?
    Gullit Miranda
    @gullitmiranda

    No, actually, in the Azkfile.js AZK we used that way. But there is a more elegant way to do this extension:

    systems({
      sys1: {
        http: {
          domains: [ "#{system.name}.#{manifest.dir}.#{azk.default_domain}" ]
        },
        // ...
      },
      sys2: {
        extends: 'sys1'
        // ...
      },
      // ...
    });

    http://docs.azk.io/en/reference/azkfilejs/extends.html