Beiträge von DjoeC

    No. It is an OMV-wide setting.

    Have you used the filter in the top right of the datatable? I have 6 pages in my dev system and rarely change pages.

    I assume when you say "system wide setting" you mean "hard coded"? Because, if it were a setting somewhere it could be changed (system wide, fine with me) :) :)


    Yes, I do use the filter but it's not my favorite way of doing things (personal preference). It all depends on what I'm trying to do or want to see.

    Is there a way to (permanently) increase the number of items per page in the Compose section? 25 appears reasonable but I find myself going back and forth quite a bit. Maybe a setting somewhere for "all"? Or is there a keyboard shortcut I haven't found yet?


    I'm mainly a keyboard user, don't like to use my mouse for paging as it is invariably in the wrong place on my (large) screen and as my number of compose files, containers and images is still increasing this will happen more and more.



    OT but I have to say though (as a compliment to the makers of OMV 7 & extras): Now that I'm starting to get used to it, I'm starting to like it :) :)

    First setup a macvlan:

    Code
    Name: macvlan
    Driver: macvlan
    Parent network: end0
    Subnet: 10.x.x.23/32
    gateway: 10.x.x.1
    range: blank

    The subnet allows exactly 1 IP number: 10.x.x.23 to be used on the macvlan. Lowering the "32" allows for more IP addresses. Use for example https://jodies.de/ipcalc to determine your values.


    This is my pihole compose file. Before bringing this up create macvlan in the networking tab. pihole_ip is defined as 10.x.x.23 in the

    OMV -> Services -> Compose -> Files _> Global environment variables

    file.

    You can use the same File and Dockerfile name now in 7.2.1 in the repo now.

    :thumbup: :thumbup:


    I was going to reply to your post above but this is better, thanks!


    I certainly understand your reluctance to indiscriminately code extra features, code needs to remain maintainable. Changes require thought before making them... But, this is another fix which should make the plugin better.


    <edit>: And just used it, it's working!

    Thanks, I read this and as I understand they are talking about 2 different containers with the same name whereas I'm talking about:

    Dockerfile which is used to create an image

    Compose (yml) which is used to create a container based on an image where in some cases Dockerfile can be included (as part of the Compose Build Specification).


    2 different things which should not cause a Docker conflict. In this case as ryecoaaron points out it is not a Docker conflict but an OMV blockade build in by design. That's at least my interpretation and his perogative.

    It was by design because I did not want the plugin to put compose file stuff in the same folder as dockerfile stuff. So, there is a check to see if the same name exists in both places. It also makes plugin code easier. If the compose file and the dockerfile need the same file(s), I'm confused why.

    I understand easy of coding somewhat. So "design decision" sounds like the reason.


    However the file Dockerfile with the build instructions in folder X (based on the OMV name) does NOT have the same name as X.yml or X.env in folder X (also based on OMV name). Your check is on the resulting foldername, not on Dockerfile or Compose name. Many GitHub projects have the Dockerfile & yml in the same folder so I would expect same to be possible in OMV.


    The Docker Compose Build Specification also appears to suggest the Dockerfile to be in the same folder as the Compose file - even though an alternative path is possible.


    But, as mentioned before: I am certainly not an experienced Docker person. Just someone who is using the advantages of OMV & Docker to get my projects operational without too much maintenance effort. And 2 base folders per project instead of 1 (with at least 20 container projects to go) seems unnecessary. Of course, as a workaround I could call all Dockerfile files <project-build> instead of <project> and keep the Compose names <project>


    So, in the end I can make it workable ;) Thanks for your explanation.

    I am trying to create a Python container to run a Python program so I have created a Dockerfile (Services -> Compose -> Dockerfiles) with name <dockname> resulting in /<shared folder name>/<dockname>/Dockerfile. Next I'm trying to create a Compose file (Services -> Compose -> Files) which I am trying to save with filename <dockname>, same name as the Dockerfile. This should result in /<shared folder name>/<dockname>/<dockname.yml> and /<shared folder name>/<dockname>/dockname.env>.


    As far as filenames goes I see no (naming) conflict, however OMV Compose does not allow this and returns a 502 on saving. Is there a particular reason not to allow this? Since this is one Python program to me it would be logical (who am I...) to have everything in the same "project" folder and not have to mess with multiple names in the /<shared folder name> folder.


    Error:

    Code
    Name is in use by a Dockerfile.
    
    OMV\Exception: Name is in use by a Dockerfile. in /usr/share/openmediavault/engined/rpc/compose.inc:502
    Stack trace:
    #0 [internal function]: OMVRpcServiceCompose->setFile()
    #1 /usr/share/php/openmediavault/rpc/serviceabstract.inc(122): call_user_func_array()
    #2 /usr/share/php/openmediavault/rpc/rpc.inc(86): OMV\Rpc\ServiceAbstract->callMethod()
    #3 /usr/sbin/omv-engined(544): OMV\Rpc\Rpc::call()
    #4 {main}

    That is what the plugin does for the CHANGE_TO_COMPOSE_DATA_PATH string. I don't have a problem adding more but I just want to know more about how it would be used.

    As mentioned: I would like to use "available items" such as the COMPOSE_FILENAME to use as a "derived" variable (not Global, not Local) to use in compose files. In my case - and I assume many other users work the same way - the COMPOSE_FILENAME shows up again in the compose file. I hate strings which could/should be variables ;)


    For me: I'm relatively new to docker so for now this is the only item I've identified which would make my (and possibly others) life easier / compose files more flexible to use. And maybe there are other ways of accomplishing multiple unique containers based on the same compose file, haven't found that yet but cenrtainly my knowledge is lacking there....


    If you add a variable I would be very happy about it, if not - no hard feelings, for now I was checking the options.


    Thanks!

    Interesting, tested with

    COMPOSE_FILENAME=joomla01

    in global environment variables.


    version: "3.8"

    services:

    "${COMPOSE_FILENAME}":

    hostname: "${COMPOSE_FILENAME}"

    image: "joomla:5"

    container_name: "${COMPOSE_FILENAME}"

    environment:

    - PUID=${PUID}

    - PGID=${PGID}

    - TZ=${TZ}

    - "JOOMLA_DB_HOST=${DB_HOST}"

    - "JOOMLA_DB_NAME=${COMPOSE_FILENAME}"

    At first glance by checking: all substitutions work properly except services Additional property ${COMPOSE_FILENAME} is not allowed on the services tag.


    But I guess the answer is clear: What I would like is not currently possible. It would require pre-processing the compose file before handing it to over to docker.


    Thanks for your help and giving me insights.

    Then you can use the other solution that I already gave you. Create an environment variable in the global environment variables file and use that variable in compose files. As explained here. https://wiki.omv-extras.org/do…l_environmental_variables

    Thanks, I am using globals i.e. for DB_HOSTNAME but don't see how <compose filename> could be a global variable since then it would only be 1 value. I can see it as a variable at the file level but that defeats the purpose as then it's not based on <filename> but a manual entry.


    The only way <compose filename> as a variable would work is if the compose -> file -> check / compose -> file -> up commands would set the (as I understand: non existing) variable value before kicking off.


    But, apologies, I'm not an expert in OMV or Docker so probably I misunderstand something. Will need to rethink my issue and options .

    If you want the persistent data to end up in the CHANGE_TO_COMPOSE_DATA_PATH folder, don't use relative paths, use that variable instead

    - CHANGE_TO_COMPOSE_DATA_PATH/Joomla01/config:/config

    Or the full route:

    - /srv/dev-disk-by-uuid-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/Joomla01/config:/config

    This solution does not allow me to reuse the compose file as every data path which includes the filename will need to be hardcoded. I'm trying to avoid that. Compose filename as a variable would be used for: part of data path, container name, (part of) database name, other places which "need" to be "generic" but unique. So having 1 variable in the compose file which will be substituted by <filename variable> would be a major benefit.

    Apologies if I've overlooked something in the docs or wanting to do something silly....


    Are there any default environment variables besides CHANGE_TO_COMPOSE_DATA_PATH for the default Docker folders on the Compose Settings screen? Also does a variable exist for the "current compose filename" to be used when building?


    "./" points to "/<location of compose files>/<filename>"

    "CHANGE_TO_COMPOSE_DATA_PATH" points to "/location of persistent container data"


    I like the ./ default including filename as a path however I cannot find the filename as a variable even though Compose must somehow have it available. I would like my persistent data to end up in "CHANGE_TO_COMPOSE_DATA_PATH/<filename>" to separate the data for example multiple Joomla instances (Joomla01, Joomla02, ...)

    I like the Network tab, like you, I wouldn't mind a Network create, but again it's not a biggie as that's quite a bit extra to program in.

    I'd like a network create. I use it once per docker instance to create a user bridge for communication between named containers which the normal bridge does not provide.


    Per the docker documentation:  Containers on the default bridge network can only access each other by IP addresses, unless you use the --link option, which is considered legacy. On a user-defined bridge network, containers can resolve each other by name or alias.


    Maybe instead of extra buttons (create/delete) store all non compose files in some type of docker (shell?) command file? That could be a solution for everything which does not fit the compose format and yaml checks..