Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editing an existing job definition deletes expose paths #12174

Closed
jhitt25 opened this issue Mar 2, 2022 · 6 comments · Fixed by #15541
Closed

Editing an existing job definition deletes expose paths #12174

jhitt25 opened this issue Mar 2, 2022 · 6 comments · Fixed by #15541

Comments

@jhitt25
Copy link

jhitt25 commented Mar 2, 2022

Nomad version

Nomad v1.2.6 (a6c6b47)

Operating system and Environment details

8 node nomad/consul cluster, 3 control, 5 worker nodes. All nodes running Nomad 1.2.6, Consul 1.11.3 and Oracle Linux 7.9 with kernel 5.4.17

Issue

When editing an existing job definition in the UI manually defined expose paths are lost, even if no actual edit is performed. Simply clicking 'Edit', then 'Plan' and 'Run' will remove existing expose paths.

Reproduction steps

Run a simple job:

job "test-job" {
  datacenters = ["centralus"]
  type        = "service"

  group "test-group" {
    count = 1

    network {
        mode = "bridge"
        port "http-echo" {}
        port "health"  {}
    }

    service {
      name = "test-service"
      port = "8080"

      connect {
        sidecar_service {
          proxy {
            expose {
              path {
                path = "/"
                protocol = "http"
                local_path_port = 8080
                listener_port = "health"
              }
            }
          }
        }
      }
    }

    task "test-task" {
      driver = "docker"
      config {
        image = "hashicorp/http-echo:latest"
        args = [ "-listen=:8080", "-text='expose test'" ]
      }
    }
  }
}

If you view the definition, under TaskGroups[0].Services[0].Connect.SidecarService.Proxy you will have:

                "Expose": {
                  "Paths": [
                    {
                      "Path": "/",
                      "Protocol": "http",
                      "LocalPathPort": 8080,
                      "ListenerPort": "health"
                    }
                  ]
                },

Next, edit the job (there's no need to make any changes), plan, and run.

If you view the definition now, TaskGroups[0].Services[0].Connect.SidecarService.Proxy.Expose will be null.

Expected Result

The expose paths will be retained

Actual Result

The expose paths are removed

@jrasell
Copy link
Member

jrasell commented Mar 3, 2022

Hi @jhitt25 and thanks for raising this issue.

I have not been able to reproduce this locally using v1.2.6 or current main yet. Could you share the details reported when you perform the plan phase of the reproduction along with any logs from the server?

@jhitt25
Copy link
Author

jhitt25 commented Mar 3, 2022

There is nothing showing up in the Nomad logs. I have attached a zip file containing the request/response payloads for the following operations and resulting file numbers. I have also tested this on both our dev cluster and our production cluster with identical results.

  • HCL pasted into GUI and 'Plan' is clicked.
    1 - parse request/response
    2 - plan request/response
  • 'Run' is clicked.
    3 - run request/response, and the job definition in the GUI after
  • 'Edit' is clicked, then 'Plan' again.
    4 - plan request/response
  • 'Run' is clicked again.
    5 - run request/response, and the job definition in the GUI after

detailed_requests.zip

@jrasell jrasell moved this from Triaging to Needs Triage in Nomad - Community Issues Triage Mar 4, 2022
@jrasell jrasell added theme/consul/connect Consul Connect integration theme/jobspec and removed stage/waiting-reply labels Mar 4, 2022
@tgross tgross moved this from Needs Triage to Triaging in Nomad - Community Issues Triage Mar 7, 2022
@jrasell
Copy link
Member

jrasell commented Mar 7, 2022

Hi @jhitt25 and thanks for the updated response. I notice in the file 5_run_request that the expose section is detailed as expected which suggests the UI is sending the correct request to Nomad.

nothing showing up in the Nomad logs

So is the UI request making it to the Nomad leader? If so, grabbing all the logs from around the time where you perform action relating to stage 5 would be useful.

@jhitt25
Copy link
Author

jhitt25 commented Mar 7, 2022

I just re-ran all my steps again while monitoring the nomad logs on all 3 servers. There is not a single log line during the job manipulation on any of the 3 servers. I'm only at log_level = "INFO", should i increase it to DEBUG (or some other value?) during this test to get more information?

My UI request initially was not on the leader. I did re-run all the steps directly against the currently elected leader and the result is identical. The Expose paths are missing in the final job and there is nothing in the nomad logs during this timeframe.

@jorgemarey
Copy link
Contributor

Maybe a duplicated of #11304 ?

@jhitt25
Copy link
Author

jhitt25 commented Apr 28, 2022

It appears so. Going back to run these requests directly against the API was on my list, but it appears i was beaten to the punch by about 5 months!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

Successfully merging a pull request may close this issue.

3 participants