Duplicate get_hostname implementations #14819

Activity

1. lukesteensen

   added

   type: tech debtA code change that does not add user value.A code change that does not add user value.

   domain: vrlAnything related to the Vector Remap LanguageAnything related to the Vector Remap Language

   vrl: stdlibchanges to VRL's standard library.changes to VRL's standard library.

   on Oct 12, 2022
2. lukesteensen

   added a commit that references this issue on Oct 12, 2022

   feat(config): allow hostname to be overridden via env var

   ...

   This issue will close once commit 49605fa is merged into the 'master' branch.

   49605fa
3. tobz commented on Oct 12, 2022

   

   tobz

   on Oct 12, 2022

   Contributor

   More actions

   We should de-duplicate those, yes. One way to avoid circular dependencies would be to force VRL to take stubs to anything that performs "external" I/O, such as getting the hostname. We would simply configure it when Vector initializes the VRL runtime, or something to that effect.

   This would allow deduplicating without circular dependencies, and could be a potential model to expand upon for exposing "external" I/O through controlled interfaces.
4. bruceg commented on Oct 12, 2022

   

   bruceg

   on Oct 12, 2022

   Member

   More actions

   We should de-duplicate those, yes. One way to avoid circular dependencies would be to force VRL to take stubs

   Or just move it to vector_common
5. tobz commented on Oct 12, 2022

   

   tobz

   on Oct 12, 2022

   Contributor

   More actions

   Perhaps. That's definitely easier in the short term.
6. lukesteensen commented on Oct 12, 2022

   

   lukesteensen

   on Oct 12, 2022

   MemberAuthor

   More actions

   Good point, vector_common is a reasonable short-term fix here. I still don't love that arrangement in general, but that's a different issue.
7. JeanMertz commented on Oct 13, 2022

   

   JeanMertz

   on Oct 13, 2022

   Contributor

   More actions

   Yeah, I'd be happy with moving it to vector_common for now, and we can provide an actual public API/trait in VRL in the future, when we need VRL to be completely separate from Vector.
8. jszwedko

   added a commit that references this issue on Mar 24, 2023

   feat(config): allow hostname to be overridden via env var

   ...

   This issue will close once commit 70cd01d is merged into the 'master' branch.

   70cd01d
9. Captain1653 commented on Oct 12, 2026

   

   Captain1653

   on Oct 12, 2026

   Contributor

   More actions

   I looked into this issue to see if the duplication still exists. It seems this has already been resolved in the current codebase.

   The centralized implementation resides in src/lib.rs and properly handles the VECTOR_HOSTNAME override:

   // src/lib.rs
   pub fn get_hostname() -> std::io::Result<String> {
       Ok(if let Ok(hostname) = std::env::var("VECTOR_HOSTNAME") {
           hostname
       } else {
           hostname::get()?.to_string_lossy().into_owned()
       })
   }

   The implementation in src/sources/exec/mod.rs no longer duplicates any logic — it simply delegates directly to crate::get_hostname() while converting the Result to an Option:

   // src/sources/exec/mod.rs
   fn get_hostname() -> Option<String> {
       crate::get_hostname().ok()
   }

   Since the logic is centralized and there is no remaining duplication within Vector, I believe this issue can be safely closed.

   👍React with 👍1Reacted by Pavlos Rontidis
10. pront commented on Oct 13, 2026

    

    pront

    on Oct 13, 2026

    Member

    More actions

    #14819 (comment)
11. pront

    closed this as completedon Oct 13, 2026