I personally don't care where the CI runs, as long as it runs :) Adding to that, it should run *for every merge proposal*, not just on trunk (when it's too late). Travis is a time and cost effective way to achieve this, but I'd be more than happy with whatever alternative solution.
- Chris On Wed, Aug 12, 2015 at 1:12 PM, Marco Ceppi <marco.ce...@canonical.com> wrote: > I don't have a problem moving to github for the project. However, we have a > lot of people contributing to the library already in launchpad and I would > hate to disrupt that flow. I'm not sure if there's an advantage to moving to > github at this moment in time if only to use travis. I'd be interested in > more contributors feedback about moving before doing anything. Working with > the Juju QA team to add a Jenkins job for test landing is a great idea, one > we should certainly do now while we figure the rest of this out. > > On Wed, Aug 12, 2015 at 6:59 AM Christopher Glass <trib...@gmail.com> wrote: >> >> Small comment while mentioning charm-helpers: >> >> What I would really like to see is the project's tests running in CI, >> before things start moving around. The last few times we ran them we >> discovered many were broken (I suspect people need to put out fires >> and don't bother running the tests before committing). >> >> Could we consider moving to i.e. github.com with travis? It's there, >> it works, and somebody else is maintaining it (for free, no less). >> >> - Chris >> >> On Tue, Aug 11, 2015 at 3:42 PM, Marco Ceppi <marco.ce...@canonical.com> >> wrote: >> > Hello everyone, >> > >> > There have been a lot of conversations had over the past few months >> > about >> > charm-helpers and how to proceed forward with the project. As a result >> > of >> > these conversations I'd like to surface the following items for >> > discussion: >> > >> > # Trimming down charm-helpers >> > >> > The first item, and arguably the largest is a complete reorganization of >> > the >> > current charm-helpers code base. Originally, charm helpers was setup to >> > allow a path for developers to place unstable code (contrib directory) >> > where >> > they could iterate without a guarantee of API stability. However, this >> > quickly grew to include code that simply didn't make sense as a "core" >> > feature of charm-helpers. This includes a large set of code for domain >> > specific charm ecosystems (bigdata, openstack, storage) as well as >> > quickly >> > fixes to missing features in Juju (leader election). >> > >> > The amount of collaborative code in contrib is fantastic! However, it's >> > making the release and distribution of charm-helpers more complicated. >> > With >> > an inability to keep up with documentation for methods contrib and the >> > "volatile" nature of "unstable API", I'd like to propose we completely >> > remove the contrib directory and instead urge code maintainers in >> > contrib to >> > create their own libraries for the feature and code they wish to >> > maintain >> > going forward which simply depends on charm-helpers for the code in >> > core. >> > >> > This will allow groups like bigdata, openstack charmers, storage, and >> > others >> > to maintain their own release and review process for helpers specific to >> > their solutions, as well as their own means of delivery (be it >> > charm-helpers-sync, pypi, debian, or another means). This will also >> > GREATLY >> > slim down the charm-helpers library to instead include one of two >> > things: >> > >> > - API in Python for communicating with Juju >> > - Simple collection of tools in Python to solve shared universal >> > problems >> > >> > Which roughly translates to hookenv.py, host.py, and fetch tools. Once >> > contrib is removed and relocated I'd like to also propose flattening the >> > library namespaces from >> > >> > charmhelpers.core.hookenv -> charmhelpers.hookenv >> > charmhelpers.core.host -> charmhelpers.host >> > charmhelpers.core.files -> charmhelpers.host >> > charmhelpers.core.fstab -> charmhelpers.host >> > charmhelpers.core.sysctl -> charmhelpers.host >> > charmhelpers.core.kv -> separate project? >> > >> > Everything else, outside of contrib would remain the same. While I think >> > it's important to slim down charm-helpers I'm not convinced the above >> > outlined rename/code merges are the right or best way forward. I welcome >> > feedback and a discussion around this. >> > >> > # Packaging charm-helpers >> > >> > Currently, charm-helpers are available via either bazaar source or PyPI. >> > With a more stable, slim, and maintainable code base we would like to >> > package charm-helpers still on PyPI with semantic versioning, make a >> > dist/wheel[0] available for embedding (instead of charm-helpers-sycn), >> > and >> > in Debian and have them available via a PPA but also potentially in the >> > archive proper. >> > >> > The hardest challenge will be keeping the archive as up to date as >> > possible >> > with releases of charm-helpers. Since charms and Juju versions are >> > decoupled >> > from packages "frozen" in the archive, just having a version of >> > charm-helpers in the archive for the version of Juju in that archive >> > won't >> > necessarily last the test of time. Someone deploying a charm now from a >> > new >> > version of Juju against trusty would get the 1.21 equivalent of >> > charm-helpers which may not include the new leadership or extended >> > status >> > methods causing the charm to fail erroneously. >> > >> > Having a PPA can alleviate this, but PyPI and PPAs may interfere with >> > firewalls and policies where Juju is being deployed. Opinions on how to >> > help >> > with this are appreciated. Otherwise, we may simply recommend authors to >> > use >> > a bit of bootstrap code which attempts to install from PyPI, with a >> > fallback >> > to install an embedded version of charmhelpers that was included in the >> > charm as a dist/wheel. >> > >> > # Charm-helpers for other languages >> > >> > We already have charm-helpers written for three languages! Python[0], >> > PowerShell[1], and Rust-lang[2]. By sliming down the charm-helpers we >> > can >> > define a minimum requirement that each new charm-helper language should >> > expose. This will enable us to document charm-helpers more thoroughly >> > and >> > include code examples for each language supported in our docs. Also, by >> > having a narrowly defined scope of methods, it enables other communities >> > to >> > create helpers for their languages. >> > >> > The PowerShell library was written by the folks at CloubBase, I had the >> > chance to sit down with them a few months back and review how their >> > structure looks. It's already very far along, includes unit testing, and >> > matches the relative structure we have had in the Python charm helpers >> > for >> > some time. Going forward I'd like to continue this trend and sent some >> > guidelines around future charm-helper libraries for other languages. >> > >> > # More exposure via the CLI >> > >> > Finally, we have a CLI interface for the charm-helpers python library. >> > Recently there have been several merges which add exposure to additional >> > methods and features of python charm-helpers. I'd like to continue this >> > tend >> > and add a CLI hook for everything in charm-helpers, within reason. A >> > recent >> > addition, by Cory Johns, enabled the internal key-value store in >> > charm-helpers to be accesible via CLI. While making things like the >> > "config_get" method available by CLI is silly, other key and core >> > methods >> > that exist as code in Python only and aren't a 1:1 bridge to Juju >> > commands >> > should also be made available. This will allow authors creating first >> > drafts >> > of charms in bash to access these higher methods. >> > >> > # Conclusion >> > >> > I welcome discussion, dissent, and suggestions around these topics. They >> > are >> > by no means set in stone but are the assumed plan at the moment. >> > >> > TL;DR: I want to make charm-helpers very slim, versioned, packaged, >> > documented, and easily portable to other languages. >> > >> > Thanks, >> > Marco Ceppi >> > Juju Developer Experience group >> > >> > [0] http://pythonwheels.com/ >> > [1] https://github.com/cloudbase/juju-powershell-modules >> > [2] https://crates.io/crates/juju >> > >> > -- >> > Juju mailing list >> > Juju@lists.ubuntu.com >> > Modify settings or unsubscribe at: >> > https://lists.ubuntu.com/mailman/listinfo/juju >> > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
