1. 17 Sep, 2018 1 commit
  2. 16 Oct, 2017 1 commit
  3. 31 Jul, 2017 1 commit
  4. 22 Jul, 2017 2 commits
  5. 04 Jan, 2017 3 commits
  6. 22 Dec, 2016 1 commit
    • Jon Grimm's avatar
      LICENSE: Allow dual licensing GPL-3 or Apache 2.0 · b2a9f336
      Jon Grimm authored
      This has been a recurring ask and we had initially just made the change to
      the cloud-init 2.0 codebase.  As the current thinking is we'll just
      continue to enhance the current codebase, its desirable to relicense to
      match what we'd intended as part of the 2.0 plan here.
      
      - put a brief description of license in LICENSE file
      - put full license versions in LICENSE-GPLv3 and LICENSE-Apache2.0
      - simplify the per-file header to reference LICENSE
      - tox: ignore H102 (Apache License Header check)
      
      Add license header to files that ship.
      Reformat headers, make sure everything has vi: at end of file.
      
      Non-shipping files do not need the copyright header,
      but at the moment tests/ have it.
      b2a9f336
  7. 04 Dec, 2016 2 commits
  8. 03 Dec, 2016 1 commit
    • Scott Moser's avatar
      fix decoding of utf-8 chars in yaml test · 166df605
      Scott Moser authored
      Python 3 would fail to load yaml from doc/examples/cloud-config-apt.txt
      when the LANG (specifically LC_CTYPE) was 'C'.
      
      The changes here do 2 things:
       a.) remove the non-ascii characters from the yaml file.
       b.) fix the validate-yaml.py program to decode using utf-8 specifically
           rather than using the inherited settings.
      
      This fixes it now for ascii and in the future also should non-ascii slip in.
      166df605
  9. 21 Nov, 2016 1 commit
  10. 11 Nov, 2016 1 commit
  11. 22 Aug, 2016 1 commit
    • Scott Moser's avatar
      azure dhclient-hook cleanups · 64522efe
      Scott Moser authored
      This adds some function to the generator to maintain the presense of a
      flag file '/run/cloud-init/enabled' indicating that cloud-init is enabled.
      
      Then, only run the dhclient hooks if on Azure and cloud-init is enabled.
      The test for is_azure currently only checks to see that the board vendor
      is Microsoft, not actually that we are on azure.  Running should not be
      harmful anywhere, other than slowing down dhclient.
      
      The value of this additional code is that then dhclient having run
      does not task the system with the load of cloud-init.
      
      Additionally, some changes to config are done here.
       * rename 'dhclient_leases' to 'dhclient_lease_file'
       * move that to the datasource config (datasource/Azure/dhclient_lease_file)
      
      Also, it removes the config in config/cloud.cfg that set agent_command
      to __builtin__.  This means that by default cloud-init still needs
      the agent installed.  The suggested follow-on improvement is to
      use __builtin__ if there is no walinux-agent installed.
      64522efe
  12. 15 Aug, 2016 1 commit
    • Brent Baude's avatar
      Get Azure endpoint server from DHCP client · 648dbbf6
      Brent Baude authored
      It is more efficient and cross-distribution safe to use the hooks function
      from dhclient to obtain the Azure endpoint server (DHCP option 245).
      
      This is done by providing shell scritps that are called by the hooks
      infrastructure of both dhclient and NetworkManager.  The hooks then
      invoke 'cloud-init dhclient-hook' that maintains json data
      with the dhclient options in
      /run/cloud-init/dhclient.hooks/<interface>.json .
      
      The azure helper then pulls the value from
      /run/cloud-init/dhclient.hooks/<interface>.json file(s). If that file does
      not exist or the value is not present, it will then fall back to the
      original method of scraping the dhcp client lease file.
      648dbbf6
  13. 10 Aug, 2016 2 commits
  14. 09 Aug, 2016 1 commit
  15. 08 Aug, 2016 1 commit
    • Scott Moser's avatar
      For upstream snapshot versions do not modify git-describe output. · 48ec60ae
      Scott Moser authored
      For upstream version directly use the output of git-describe
      (X.Y.Z-number.gHASH) rather than rather than changing it to
      (X.Y.Z+number.gHASH).
      
      The rpm version does not allow '-' in Version, so we create and use
      rpm_upstream_version in the rpm spec file.  That is of format:
      X.Y.Z+number.gHASH
      48ec60ae
  16. 05 Aug, 2016 2 commits
    • Scott Moser's avatar
      drop modification of version during make-tarball, tools changes. · 42bed116
      Scott Moser authored
      Modification of the tarball became problematic, as it meant that
      any tool extracting source would find the orig source tarball different.
      I found this unusable when trying to use 'gbp buildpackage'.
      
      Other changes here are to better support using python3 or python2
      for the build.  Makefile will try to call the right python version
      and can be told which python to use.
      
      read-version: by adding 'tiny_p' and avoiding the import of
      cloudinit.util, we need less dependencies to run this.
      42bed116
    • Scott Moser's avatar
      adjust tools and version information. · 10f82bd4
      Scott Moser authored
      upstream snapshots are versioned in the format 'X.Y.Z+<distance>.g<commit>'
      where X.Y.Z are major, minor, and micro.  Distance is number of commits
      since last annotated tag, and commit is the git commit.
      
      bddeb and brpm will now create and use the "upstream version" like above.
      
      Things changed here:
       - tools/make-tarball
         update cloudinit/version.py to contain the full version
         support --output
         support '--long' to always create the long format version string.
      
       - bddeb:
         - use quilt debian source format
         - use read-version and long version in changelog.
      
       - brpm:
         - change to use read-version and upstream long version in the spec.
         - flake8 changes
      
       - tools/read-version
         - read version from git or from cloudinit/version.
         - provide --json output with more nicely formed data.
      10f82bd4
  17. 03 Aug, 2016 1 commit
    • Lars Kellogg-Stedman's avatar
      Update build tools to work with git · 72d6adcb
      Lars Kellogg-Stedman authored
      - Update HACKING.rst to include git instructions
      - update MANIFEST.in and .gitignore to ignore git-related things
      - replaced tarball generation scripts with git-based script
      - have the spec files correctly identify themselves as cheetah templates
      - make brpm work with git
      72d6adcb
  18. 15 Jun, 2016 2 commits
  19. 04 Apr, 2016 1 commit
  20. 04 Mar, 2016 1 commit
  21. 03 Mar, 2016 2 commits
  22. 01 May, 2015 1 commit
  23. 11 Feb, 2015 1 commit
  24. 10 Feb, 2015 1 commit
    • Scott Moser's avatar
      make bddeb work with python3 or python2 · a4a67027
      Scott Moser authored
      painful, and not perfect, but at this point the output builds
      on a vivid system python2 (bddeb --python2) or python3.
      
       * remove use of cheetah by bddeb in favor of builtin renderer
       * add '--python2' flag to bddeb and knowledge of python 2 and python3
         package names.
       * read-dependencies can now read test-requirements also.
       * differenciate from build-requirements and runtime requirements.
      a4a67027
  25. 23 Jan, 2015 1 commit
  26. 06 Jan, 2015 1 commit
  27. 09 Dec, 2014 1 commit
  28. 29 Sep, 2014 3 commits
  29. 03 Sep, 2014 1 commit
  30. 26 Aug, 2014 1 commit