FAQ

On 10/16/2013 12:07 PM, Ryan Coleman wrote:

- operating_system : OSes your module supports stated like the
$operatingsystem Facter values Ubuntu or RedHat
- This new metadata will be used on forge.puppetlabs.com
<http://forge.puppetlabs.com> on module pages, search results and will
be available over its (soon to be released) REST API.
Ok, I'll bite :)

How does this plan to deal with all of the RedHat flavors? If the
module author doesn't list out RedHat, CentOS, OEL, Scientific, etc,
will it work?

Might osfamily be better here? (With the caveat that Fedora should
probably be it's own osfamily and not redhat).

Jason

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Dolf Schimmel - Freeaqingme at Oct 16, 2013 at 4:44 pm
    Hi Ryan,

    Thanks for the update. The improvements that are coming sound awesome! (I
    was in fact about to begin a thread to discuss this issue - glad to see
    you're way ahead of me).

    Some insight into how I currently experience the Puppet forge (you may be
    aware of it all, yet anyway):
    - From an end-users perspective, the web form has been my biggest struggle
    for me. I have one script to publish new versions of my modules (run tests,
    create tag, push to github). Anything related to getting a new version on
    the forge should be doable in Bash. A popular tool in the PHP community
    named Composer has done this pretty neatly. You may want to take a look at
    this tool, before reinventing the wheel (it utilizes the Github api and
    simply scans for new tags iirc).
    - In its current state, the module tool complains if modules don't match,
    even though an alternative may provide the same interface. The concat
    module comes to mind, there are several versions of the concat module
    around that all share the same interface. It would be nice if there's some
    'provides' or 'replaces' syntax that allows to define if a module can also
    provide functionality for that of another module.
    - It's hard to find the 'best' module on the Forge. Rather than only seeing
    the number of downloads, I'd also like to see some qualitative score, like
    a 1-5 star rating.
    - There exists a possibility to specify an alternative repo. I would
    however like to have the option to also configure multiple repos. In
    commercial organizations it's not rare to have a private set of modules,
    and a public one as well.
    - Judging from the number of modules that use Github as project page, it
    seems Git is a rather popular tool. I personally prefer to use submodules
    instead of embedding all the extra code in my own repository. Would be nice
    if the module tool could simply manage my submodules instead.
    - There's currently no support for optional dependencies. Many of the
    Example42 modules ( https://github.com/example42?tab=repositories ) can
    integrate with example42/firewall and example42/monitoring, but you're in
    no way obliged to use this integration. It would be nice if these could be
    listed as optional dependencies.

    Because of the reasons above I don't use the module tool myself. I'm sorry
    if I have misunderstood any functionality or suggested that some isn't
    available while it actually is - I'm just not aware of it (nor can I find
    it).

    Lastly, I can't stress enough to take a look at Composer (tool:
    http://getcomposer.org/ & forge: https://packagist.org/ ). Although it's
    based around PHP, I'm fairly certain they face(d) the exact same challenges
    as there are with the Puppet Module tool. It would be a shame if you'd
    reinvent the wheel here.

    Regards,

    Dolf
    -- Freeaqingme
    On Wednesday, October 16, 2013 6:07:57 PM UTC+2, Ryan Coleman wrote:

    We've been working hard to reduce the complexity involved in publishing
    modules to the Forge and make it simpler to find great modules. I'm writing
    today to give you some background on the problems we're working to solve
    and the approach we'd like to take to help solve them.

    To publish a Forge module today, you must provide some metadata in a form
    on forge.puppetlabs.com and create a file named Modulefile in your module
    root which contains additional (and in some cases duplicate) metadata. Then
    you must run `puppet module build` or follow a workflow in Geppetto which
    both transform the Modulefile into the metadata.json artifact that Puppet
    and the Forge consume.

    On top of that, the types of metadata you can enter into the Modulefile is
    static and requires an update to Puppet to improve. You've been waiting for
    a way to find modules that work with your version of Puppet and on the
    operating systems you run in your datacenter. The Forge is ready to display
    this information, allow you to filter search results on it and more. The
    last step is to allow for additional metadata to be supplied by module
    authors in a single, simple, source of metadata.


    So, what are we planning to simplify module publishing and enable better
    module discovery on Forge?

    - The web form on Forge currently required to publish a new module is
    going away.
    - The Modulefile metadata file will be deprecated in the next major
    release of Puppet
    - metadata.json (part of the `puppet module build` output) will become the
    single-source of metadata
    -
    http://docs.puppetlabs.com/puppet/latest/reference/modules_publishing.htmlwill be updated to reflect these changes and to document brand new metadata
    keys including:
    - puppet_version : The major.minor versions of Puppet your module
    supports like 2.7 or 3.3
    - operating_system : OSes your module supports stated like the
    $operatingsystem Facter values Ubuntu or RedHat
    - This new metadata will be used on forge.puppetlabs.com on module pages,
    search results and will be available over its (soon to be released) REST
    API.

    There are a couple of notable caveats to the above which will be included
    in the documentation along with much greater detail on each metadata key.
    For example, we'd like to allow for more flexible expressions in
    puppet_version (not just major.minor) and we'd like to allow for version
    comparison in operating_system. We plan to introduce these keys as
    described above until Forge is ready to accept more complicated
    expressions. Once able, we'll update the documentation to document the new
    capabilities and accept both forms of metadata.



    Will this break all my modules and when can I start using this stuff?

    We know that these changes aren't trivial and even though Puppet and the
    Forge use metadata.json already, some tools interact with Modulefile
    directly. We're doing several things to make this transition seamless and
    pleasant.

    First, rest easy knowing that the modules you build with the module tool
    available in 2.7.14 and later will continue to work. Though you won't be
    able to express the new metadata or publish to the Forge without visiting
    the website, older versions of Puppet and Geppetto will continue to create
    and interact with modules just the same.

    Users of Puppet 3.3.0 and later will enjoy extra flexibility during this
    transition. It includes a change to respect the new metadata fields
    expressed in metadata.json when building your release tarball based on the
    metadata entered in Modulefile. Though you won't be living the single
    source of metadata dream, you can still express new metadata with few
    manual steps.

    The next major version of Puppet will include a greatly revamped Puppet
    Module Tool that (amongst other improvements) will make it easy to express
    and validate the new metadata directly in metadata.json. A future release
    of Geppetto will be the easiest choice when it provides a simple form
    editor to express, edit and validate the new metadata.

    The updated documentation which should be available within the next month.
    It will also describe these changes in greater detail and provide all the
    information you need to get started.

    Best of all, once module authors begin publishing new releases which
    contain the new metadata keys, you'll be able to filter your Forge search
    results on the Puppet versions and operating systems that you care about.
    Three sources of module metadata will be reduced to one authoritative
    source that doesn't require an upgrade of your entire Puppet infrastructure
    to improve. Publishing modules to the Forge will no longer require web-site
    interaction enabling vastly improved workflows like GitHub-based publishing
    that we hope to work on in the coming months.

    On behalf of all of us at Puppet Labs, I want to thank you for being such
    an awesome community and I'm looking forward to the next year of module
    development. You're always welcome to email me directly or find me as
    ryanycoleman in #puppet on Freenode. There are many more things coming from
    us in the next few months and I look forward to sharing those with you soon.


    --Ryan
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dolf Schimmel - Freeaqingme at Oct 16, 2013 at 4:55 pm
    Reposting my last post as I got an error that it could not be delivered
    because of my SPF records. Now with a different email address
    ----------

    Hi Ryan,

    Thanks for the update. The improvements that are coming sound awesome! (I
    was in fact about to begin a thread to discuss this issue - glad to see
    you're way ahead of me).

    Some insight into how I currently experience the Puppet forge (you may be
    aware of it all, yet anyway):
    - From an end-users perspective, the web form has been my biggest struggle
    for me. I have one script to publish new versions of my modules (run tests,
    create tag, push to github). Anything related to getting a new version on
    the forge should be doable in Bash. A popular tool in the PHP community
    named Composer has done this pretty neatly. You may want to take a look at
    this tool, before reinventing the wheel (it utilizes the Github api and
    simply scans for new tags iirc).
    - In its current state, the module tool complains if modules don't match,
    even though an alternative may provide the same interface. The concat
    module comes to mind, there are several versions of the concat module
    around that all share the same interface. It would be nice if there's some
    'provides' or 'replaces' syntax that allows to define if a module can also
    provide functionality for that of another module.
    - It's hard to find the 'best' module on the Forge. Rather than only seeing
    the number of downloads, I'd also like to see some qualitative score, like
    a 1-5 star rating.
    - There exists a possibility to specify an alternative repo. I would
    however like to have the option to also configure multiple repos. In
    commercial organizations it's not rare to have a private set of modules,
    and a public one as well.
    - Judging from the number of modules that use Github as project page, it
    seems Git is a rather popular tool. I personally prefer to use submodules
    instead of embedding all the extra code in my own repository. Would be nice
    if the module tool could simply manage my submodules instead.
    - There's currently no support for optional dependencies. Many of the
    Example42 modules ( https://github.com/example42?tab=repositories ) can
    integrate with example42/firewall and example42/monitoring, but you're in
    no way obliged to use this integration. It would be nice if these could be
    listed as optional dependencies.

    Because of the reasons above I don't use the module tool myself. I'm sorry
    if I have misunderstood any functionality or suggested that some isn't
    available while it actually is - I'm just not aware of it (nor can I find
    it).

    Lastly, I can't stress enough to take a look at Composer (tool:
    http://getcomposer.org/ & forge: https://packagist.org/ ). Although it's
    based around PHP, I'm fairly certain they face(d) the exact same challenges
    as there are with the Puppet Module tool. It would be a shame if you'd
    reinvent the wheel here.

    Regards,

    Dolf
    -- Freeaqingme
    On Wednesday, October 16, 2013 6:07:57 PM UTC+2, Ryan Coleman wrote:

    We've been working hard to reduce the complexity involved in publishing
    modules to the Forge and make it simpler to find great modules. I'm writing
    today to give you some background on the problems we're working to solve
    and the approach we'd like to take to help solve them.

    To publish a Forge module today, you must provide some metadata in a form
    on forge.puppetlabs.com and create a file named Modulefile in your module
    root which contains additional (and in some cases duplicate) metadata. Then
    you must run `puppet module build` or follow a workflow in Geppetto which
    both transform the Modulefile into the metadata.json artifact that Puppet
    and the Forge consume.

    On top of that, the types of metadata you can enter into the Modulefile is
    static and requires an update to Puppet to improve. You've been waiting for
    a way to find modules that work with your version of Puppet and on the
    operating systems you run in your datacenter. The Forge is ready to display
    this information, allow you to filter search results on it and more. The
    last step is to allow for additional metadata to be supplied by module
    authors in a single, simple, source of metadata.


    So, what are we planning to simplify module publishing and enable better
    module discovery on Forge?

    - The web form on Forge currently required to publish a new module is
    going away.
    - The Modulefile metadata file will be deprecated in the next major
    release of Puppet
    - metadata.json (part of the `puppet module build` output) will become the
    single-source of metadata
    -
    http://docs.puppetlabs.com/puppet/latest/reference/modules_publishing.htmlwill be updated to reflect these changes and to document brand new metadata
    keys including:
    - puppet_version : The major.minor versions of Puppet your module
    supports like 2.7 or 3.3
    - operating_system : OSes your module supports stated like the
    $operatingsystem Facter values Ubuntu or RedHat
    - This new metadata will be used on forge.puppetlabs.com on module pages,
    search results and will be available over its (soon to be released) REST
    API.

    There are a couple of notable caveats to the above which will be included
    in the documentation along with much greater detail on each metadata key.
    For example, we'd like to allow for more flexible expressions in
    puppet_version (not just major.minor) and we'd like to allow for version
    comparison in operating_system. We plan to introduce these keys as
    described above until Forge is ready to accept more complicated
    expressions. Once able, we'll update the documentation to document the new
    capabilities and accept both forms of metadata.



    Will this break all my modules and when can I start using this stuff?

    We know that these changes aren't trivial and even though Puppet and the
    Forge use metadata.json already, some tools interact with Modulefile
    directly. We're doing several things to make this transition seamless and
    pleasant.

    First, rest easy knowing that the modules you build with the module tool
    available in 2.7.14 and later will continue to work. Though you won't be
    able to express the new metadata or publish to the Forge without visiting
    the website, older versions of Puppet and Geppetto will continue to create
    and interact with modules just the same.

    Users of Puppet 3.3.0 and later will enjoy extra flexibility during this
    transition. It includes a change to respect the new metadata fields
    expressed in metadata.json when building your release tarball based on the
    metadata entered in Modulefile. Though you won't be living the single
    source of metadata dream, you can still express new metadata with few
    manual steps.

    The next major version of Puppet will include a greatly revamped Puppet
    Module Tool that (amongst other improvements) will make it easy to express
    and validate the new metadata directly in metadata.json. A future release
    of Geppetto will be the easiest choice when it provides a simple form
    editor to express, edit and validate the new metadata.

    The updated documentation which should be available within the next month.
    It will also describe these changes in greater detail and provide all the
    information you need to get started.

    Best of all, once module authors begin publishing new releases which
    contain the new metadata keys, you'll be able to filter your Forge search
    results on the Puppet versions and operating systems that you care about.
    Three sources of module metadata will be reduced to one authoritative
    source that doesn't require an upgrade of your entire Puppet infrastructure
    to improve. Publishing modules to the Forge will no longer require web-site
    interaction enabling vastly improved workflows like GitHub-based publishing
    that we hope to work on in the coming months.

    On behalf of all of us at Puppet Labs, I want to thank you for being such
    an awesome community and I'm looking forward to the next year of module
    development. You're always welcome to email me directly or find me as
    ryanycoleman in #puppet on Freenode. There are many more things coming from
    us in the next few months and I look forward to sharing those with you soon.


    --Ryan
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedOct 16, '13 at 4:37p
activeOct 16, '13 at 4:55p
posts3
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase