I have just posted this on Nick Yeates "New ZenPack Landscape" blog post, but given he's no longer at Zenoss, I want to ensure there's some discussion around this.
There are many a number of reasons for my grievances around this decision, I listed the major ones here, with a general rationale for each. I can of course go into much more detail.
1. While folk who released ZenPacks.community.* ZenPacks tacitly agreed to Zenoss doing whatever it wished with their product, one should have generally assumed that those who didn't did not.
My company's ZenPacks are labelled ZenPacks.lbn.* (and there is a ZenPacks.oie.* pack released under the auspices of a large telco). The reason that they were not labelled as community packs is because we have our own subversion repos and manage changes there. Not that it ever does, but the community is welcome to provide patches, and these repos are publicly read-accessible.
We now discover that there is another repo altogether for our software, and from which it is quite likely that we're out of the loop of generous community patches to *our own software*!
2. SCM systems are a means to manage patches and software releases, they're not a mechanism for which to deploy software. Simply because Python software is mostly interpreted and it thus *can* be released via a SCM doesn't mean that it *should* be released this way (and I've no quarrel with electing to use Github for SCM).
Whatsmore, we *all* know that ZenPacks are only slightly tarted up eggs, and we *all* know that Python eggs are released on PyPi. I've been releasing all of our ZenPacks on PyPi for some time now, and this is where any forward-thinking organisation would place them.
3. Since at this point, I'm unsure about contributing new stuff on Github, these products cannot even appear in the ZenPack area on zenoss.org. I have an excellent LDAPMonitor zenpack for organisations doing big LDAP (monitors connections, querys, caches etc etc), and it's not even possible to advertise it within the structures you've provided.
On the other hand, it's on PyPi (ZenPacks.lbn.LDAPMonitor) and has had 70 downloads ...
How is this "New Landsacpe" supposed to work for my company as an entity which contributes to, and extends the range of your product offering?
I'm not trying to add or take away from any of your points, but I'm confused about point #3.
and it's not even possible to advertise it within the structures you've provided
Why not? One of the initiatives was to "unlock" the listings page to the community. You should be able to freely update: http://community.zenoss.org/docs/DOC-12922
and it should in turn show up on the listings page.
Gotcha, Here is my take on that... The page I linked above is editable, regardless of whether you complete the google form or not. I get that the document implies they want everything there, but like I said the document is editable. As a user, I'd rather have your ZenPacks linked form that page regardless of where they are.
I believe the only thing that "won't happen" without the google form submission is that your GitHub Repo (Which you are not using), wont get linked via their zenpacks submodules. Since there has been 0 updates on how that will benefit the community, I'd consider it to be a "who cares".
Quite honestly, there has been so little activity on any of those documents or processes, my vote would be to link to your packs regardless of their resting place. If Zenoss Inc sees that as a problem, the community can certainly find a place to host a simple table of links
I have a document in the hopper, which will supplement this post with more detail and illustrate some of the new things coming with Core 4. As Jane as explain we're currently in a bit of a transitional stage. None the less, I'd like to address each of your concerns briefly:
As dpetzel has indicated above, there is absolutely no exclusionary policy in place. You can host and share your ZenPack in whichever way you prefer. It's pointless to play enforcer when there are so many alternatives, instead we hope to build a enticing argument for everyone to move. For now our hope behind our Github push is, to streamline the process of collaboration amongst ZenPack contributors, which we find Github is by far the best.
I completely agree that an SCM repository is not a means to distribute software and that a PyPi based repository is ideal. As a little secret from me to you, try running zenpack --fetch=ZenPacks.AndreaConsadori.Asterisk on one of the more recent Zenoss Alpha builds. If you'd like to make your stuff available via the same method a Github repository would be the first step (more details to follow).
As somewhat addressed in 1 and indicated by dpetzel, I invite you to edit the ZenPack page and please share your pack with us though whichever means you'd like.
Let me know if you have further questions or concerns.
I'm digging the zenpack --fetch. Having all the packs available in a 2.7 egg format is also Handy.
Simon the fact that a 2.7 egg is available for every pack is pretty huge. Is there any reason this has been more promoted throughout the ALPHA testing?
Thanks for the reply. For the moment then, can I get you to remove the ZenPacks.lbn.* and ZenPack.oie.Kannel from your github.
I have edited the ZenPack page. Somehow I wasn't smart enough to figure out how to find that jive-whatever number to anchor back to my login for the package maintainer.
There is/was code the Products.ZenModel.ZenPack stuff to wrap easy_install to auto-retrieve dependencies. I suspect this was going to be an 'enterprise' feature that didn't quite kick off. Naturally, if all the eggs were on PyPi, easy_install would - well just easy_install them ...
If you've finally got all your eggs together, you should revisit my post a very long time ago with regard to using buildout to deploy Zenoss.
At the same time, you could/should use the 'console_scripts' entry point to rewrite your crapulous startup/migration shell scripts in Python
And BTW, have you seen our Zenoss 3.2.x egg repo at:
These aren't created purely through setuptools, but via our RPM packages, and thus have all the identical patches applied as per our RPM spec files.
We make these available such that non-RPM-based *nix's can still participate in our rigorous release cycles.
you seem to have found out somehow, wait... did Alan give away our little secret? We'll I suppose it's out now. Again, this shouldn't really be a surprise, since we've anounced this as a "futures" item during the original Github post. Anyway, it would be great if you guys could start to simply checking your ZenPacks into Github, then simply use the Google form to tell us about the checkin location. Thereafter we will add it to the community-submodule directory. Anything that is currently part of the community-submodule directory will be build as soon as any check-in occurs.
Simon is any way this could be altered so that the submodule repo is owned by the community, thus doing away with the need for the google form? I also have some concerns about linking out to individual folks repos and the confusion that will cause in the long term as folks come and and out of interest with the project. I posted a note about this here a little while back: http://community.zenoss.org/message/64920#64920
Or maybe instead of the community owning the sole submodule a submodule could exists that is owned by the community that zenoss links too?
I hope this is enough for now to rename the post to at least: "ZenPacks on Github might be a pretty cool?" (I am just kidding about the renaming part). We'll be attacking other areas of improvement soon as well.
Possibly tangential to the original issues, but if you had not learned elsewhere, Chet has put together an impressive automated test infrastructure for all zenpacks to be authored by or blessed by Zenoss, which relies on their being acessible as Git submodules, presumably on GitHub itself.
Here's his G+ post under the Zenoss G+ account:on Improving ZenPack Quality.
Just to comment on this -- I'm the new community guy around here --
It is actually quite beneficial to have the source repo available, but I don't really see why it needs to always be on GitHub.
This will be something that will likely be more flexible in the future.
I don't think PyPi is going to be a great option for delivering future ZenPacks, but I am definitely a fan of non-centralized models.
It makes sense to encourage the use of source repos (with tags for releases) as many of our ZenPacks can be extended and improved to support new or future devices, and having access to the source repo facilitates this.