puppet-ceilometer/5abe96e9cbc1a3a9e517e9f8acf4d7533ab576a7

{
  "comments": [
    {
      "unresolved": false,
      "key": {
        "uuid": "dc8818ee_f3d77a84",
        "filename": "/PATCHSET_LEVEL",
        "patchSetId": 1
      },
      "lineNbr": 0,
      "author": {
        "id": 9816
      },
      "writtenOn": "2022-05-05T17:01:56Z",
      "side": 1,
      "message": "The ceilometer user should be created by ceilometer-common package. The current resource definition is used to add the ceilometer user to nova/libvirt group but we do not intend to override the default package user. I\u0027m not sure how much beneficial to let users to override uid/gid.",
      "revId": "5abe96e9cbc1a3a9e517e9f8acf4d7533ab576a7",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
    },
    {
      "unresolved": false,
      "key": {
        "uuid": "acbe1e09_6b5e4639",
        "filename": "/PATCHSET_LEVEL",
        "patchSetId": 1
      },
      "lineNbr": 0,
      "author": {
        "id": 26721
      },
      "writtenOn": "2022-05-05T23:18:28Z",
      "side": 1,
      "message": "yeah the benefit is more about the ceilometer container deployment. Like for kolla container, the ceilometer uid/gid will by default use different value: 42405. Have the ability to override them will make container deployment easier. So how do you think of it?",
      "parentUuid": "dc8818ee_f3d77a84",
      "revId": "5abe96e9cbc1a3a9e517e9f8acf4d7533ab576a7",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
    },
    {
      "unresolved": false,
      "key": {
        "uuid": "d6a4a84f_e9053dcb",
        "filename": "/PATCHSET_LEVEL",
        "patchSetId": 1
      },
      "lineNbr": 0,
      "author": {
        "id": 26721
      },
      "writtenOn": "2022-05-05T23:35:26Z",
      "side": 1,
      "message": "Looks you got another change to drop the user/group creation. https://review.opendev.org/c/openstack/puppet-ceilometer/+/830022 that is totally fine with me to go with this way.",
      "revId": "5abe96e9cbc1a3a9e517e9f8acf4d7533ab576a7",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
    },
    {
      "unresolved": false,
      "key": {
        "uuid": "7306a96c_f9a33bfc",
        "filename": "/PATCHSET_LEVEL",
        "patchSetId": 1
      },
      "lineNbr": 0,
      "author": {
        "id": 26721
      },
      "writtenOn": "2022-05-11T01:03:00Z",
      "side": 1,
      "message": "@Takashi do you have any further comments about this change?",
      "revId": "5abe96e9cbc1a3a9e517e9f8acf4d7533ab576a7",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
    },
    {
      "unresolved": true,
      "key": {
        "uuid": "e6181112_194f38fd",
        "filename": "/PATCHSET_LEVEL",
        "patchSetId": 1
      },
      "lineNbr": 0,
      "author": {
        "id": 9816
      },
      "writtenOn": "2022-05-14T13:19:30Z",
      "side": 1,
      "message": "Sorry I was off during first week of May and missed this after coming back holidays.\n\nThough I understand part of your thought, do you mind explaining a few more details, expecialy about the way you use the puppet module with such container deployment ? AFAIK in Kolla the users are created during building the packages, so as long as you execute puppet inside containers then you don\u0027t need this change as the puppet execution looks up the user inside container images. This is how we actually use puppet modules in TripleO and we have never seen any issue with that.\n\nYou might be able to use puppet modules to generate config files, but the current modules do not support that use case perfectly (eg. There are some packages still forcefully installed. A few configuration tasks like apache files requires the packages are installed) and I believe we still need some amount of work, which I\u0027m not sure could be worth doing.",
      "parentUuid": "acbe1e09_6b5e4639",
      "revId": "5abe96e9cbc1a3a9e517e9f8acf4d7533ab576a7",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
    },
    {
      "unresolved": true,
      "key": {
        "uuid": "3e4f3062_2c383b6c",
        "filename": "/PATCHSET_LEVEL",
        "patchSetId": 1
      },
      "lineNbr": 0,
      "author": {
        "id": 9816
      },
      "writtenOn": "2022-05-14T13:20:22Z",
      "side": 1,
      "message": "\u003e You might be able to use puppet modules to generate config files,\n\nI meant;\n\nYou might be able to use puppet modules in host level to generate config files, ...",
      "parentUuid": "e6181112_194f38fd",
      "revId": "5abe96e9cbc1a3a9e517e9f8acf4d7533ab576a7",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
    },
    {
      "unresolved": true,
      "key": {
        "uuid": "1e2ab5cd_9d83ade7",
        "filename": "/PATCHSET_LEVEL",
        "patchSetId": 1
      },
      "lineNbr": 0,
      "author": {
        "id": 26721
      },
      "writtenOn": "2022-05-14T13:43:42Z",
      "side": 1,
      "message": "Thanks Takashi for your comments. \n\nYes, we use puppet module in the host(VM) level to generate config files. And kolla container will mount the config files/folder during its runtime. In that case, if we keep the default kolla image uid/gid, we should use the same one to start the container from the host(VM). This is a natural transistion for us, because we are migarting our services from VM to container. And we deployed the service on VM using puppet module before and it worked well, so now we just want to start the service as a container without changing other things. \n\nAnd as you replied in another change I made (https://review.opendev.org/c/openstack/puppet-ceilometer/+/841528), maybe adding uid/gid as configurable parameter will be easier solution?",
      "parentUuid": "3e4f3062_2c383b6c",
      "revId": "5abe96e9cbc1a3a9e517e9f8acf4d7533ab576a7",
      "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543"
    }
  ]
}