Re: Question for cosmetic and understandability of breadcrumbs in github
If it helps, the charm set command supports arbitrary key values to be stored in extra-info in the charm store. e.g. $ charm set cs:~evarlast/trusty/parse-server-0 layer-x=rev1 layer-y=rev2 Then this will be displayed in extrainfo: $ charm show cs:~containers/trusty/swarm extra-info extra-info: layer-x: rev1 layer-y: rev2 After pushing, you could use set to save the revisions of what was used to build the charm. -- Jay On Thu, Jun 16, 2016 at 8:51 PM, Charles Butler < charles.but...@canonical.com> wrote: > Greetings, > > I deposit many of my layers in GitHub, and one of the things I've been > striving to do is keep tag releases at the revisions i cut a charm release > for a given channel. As we know, the default channel is seen by no-one, and > runs in increments of n+1. > > My prior projects i've been following semver for releases, but that has > *nothing* in terms of a breadcrumb trail back to the store. > > Would it be seen as good practice to tag releases - on the top most layer > of a charm - with what charm release its coordinated with? > > Given the scenario that i'm ready to release swarm, and lets assume that > to date i haven't tagged any releases in the layer repository: > > charm show cs:~containers/trusty/swarm revision-info > revision-info: > Revisions: > - cs:~containers/trusty/swarm-2 > - cs:~containers/trusty/swarm-1 > - cs:~containers/trusty/swarm-0 > > I see that i'm ready to push swarm-3 to the store: > > git tag 3 > git push origin --tags > > I can now correlate the source revision to what i've put in my account on > the store, but this does not account for promulgation (which has an > orthogonal revision history), and mis-match of those id's. > > I think this can simply be documented that tags track > <>/<> pushes, and to correlate source with release, to use > the method shown above to fetch release info. > > Does this sound useful/helpful or am I being pedantic? (I say this because > Kubernetes touches ~ 7 layers, and it gets confusing keeping everything up > to date locally while testing, and then again re-testing with > --no-local-layers to ensure our repositories are caught up with current > development work. (Cant count the number of open pull requests hanging > waiting for review because we've moved to the next hot-ticket item) > > All the best, > > Charles > -- > Juju Charmer > Canonical Group Ltd. > Ubuntu - Linux for human beings | www.ubuntu.com > Juju - The fastest way to model your service | www.jujucharms.com > > -- > 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
Re: Question for cosmetic and understandability of breadcrumbs in github
On 17 June 2016 at 04:42, David Britton wrote: > We are planning a tag for every push for the landscape-server and client > charms, and bundles. +1 on it being mentioned as a best practice (the same > type of thing as when you release a version of any other software!). > Though, I would recommend using the full charm store identifier eg: > 'cs:~user/charm-3'. Basically, the full standard out of the charm push > operation. This is what I'm doing with the PostgreSQL charm. I wrote up https://github.com/stub42/ReactiveCharmingWorkflow to help polish my processes as much as I could. I start with a layer, build to a separate branch for testing, push that to the charmstore, tag it wth the pushed revno and publish it to the dev channel. If tests pass, I merge --no-ff the tested build into a release branch, publish it to the release channel and tag it with both charmstore rev and semantic version number. By doing the merges the right way, the change history of the primary layer is visible on all three branches (the 'built' commit has the source 'layer' commit as a parent, and 'git log' does what you want). I have an issue open on the charmstore-client to make parsing the pushed charmstore revno easier. After doing the write up it became obvious that it is all still too fiddly, so rather than polish it for publication I instead planed to do some git plugins to smooth over the process (sketched out in the 'Future' section). I'm mulling over how to handle dependant layers, and if we can get them into the repo to solve the pinning problem and include their change history. I haven't got this sketched out very far beyond some vague thoughts that subtrees might be useful, and don't know if it is at all practical. The build and publish process seems solid though, and the 'manual' equivalent in my Makefile rules has been working well for me. I want to get the basic build, push and publish plugins done in the very near future. > I also like the repo-info for traceability the other way around. They solve > a similar problem but depending on where you are looking are both useful. Yes. This seems a good thing to have my proposed 'git charm-build' generate too. -- Stuart Bishop -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Question for cosmetic and understandability of breadcrumbs in github
On Fri, Jun 17, 2016 at 2:10 AM, Jay Wren wrote: > If it helps, the charm set command supports arbitrary key values to be > stored in extra-info in the charm store. > > e.g. > > $ charm set cs:~evarlast/trusty/parse-server-0 layer-x=rev1 layer-y=rev2 > > Then this will be displayed in extrainfo: > > $ charm show cs:~containers/trusty/swarm extra-info > extra-info: > layer-x: rev1 > layer-y: rev2 > > After pushing, you could use set to save the revisions of what was used to > build the charm. > Thanks, Jay. There is some potential in that. I think it'd be worth discussing some k:v norms around this that we can all gather around. Then, perhaps more importantly, how that info will persist in the places where it needs to be observed, such as: charm store ui, a pulled charm, and the resulting deployments. > > -- > Jay > > On Thu, Jun 16, 2016 at 8:51 PM, Charles Butler < > charles.but...@canonical.com> wrote: > >> Greetings, >> >> I deposit many of my layers in GitHub, and one of the things I've been >> striving to do is keep tag releases at the revisions i cut a charm release >> for a given channel. As we know, the default channel is seen by no-one, and >> runs in increments of n+1. >> >> My prior projects i've been following semver for releases, but that has >> *nothing* in terms of a breadcrumb trail back to the store. >> >> Would it be seen as good practice to tag releases - on the top most layer >> of a charm - with what charm release its coordinated with? >> >> Given the scenario that i'm ready to release swarm, and lets assume that >> to date i haven't tagged any releases in the layer repository: >> >> charm show cs:~containers/trusty/swarm revision-info >> revision-info: >> Revisions: >> - cs:~containers/trusty/swarm-2 >> - cs:~containers/trusty/swarm-1 >> - cs:~containers/trusty/swarm-0 >> >> I see that i'm ready to push swarm-3 to the store: >> >> git tag 3 >> git push origin --tags >> >> I can now correlate the source revision to what i've put in my account on >> the store, but this does not account for promulgation (which has an >> orthogonal revision history), and mis-match of those id's. >> >> I think this can simply be documented that tags track >> <>/<> pushes, and to correlate source with release, to use >> the method shown above to fetch release info. >> >> Does this sound useful/helpful or am I being pedantic? (I say this >> because Kubernetes touches ~ 7 layers, and it gets confusing keeping >> everything up to date locally while testing, and then again re-testing with >> --no-local-layers to ensure our repositories are caught up with current >> development work. (Cant count the number of open pull requests hanging >> waiting for review because we've moved to the next hot-ticket item) >> >> All the best, >> >> Charles >> -- >> Juju Charmer >> Canonical Group Ltd. >> Ubuntu - Linux for human beings | www.ubuntu.com >> Juju - The fastest way to model your service | www.jujucharms.com >> >> -- >> 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 > > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: Question for cosmetic and understandability of breadcrumbs in github
There are the annotations in Juju that aren't used for much but X/Y coordinates for the GUI to lay out services. There might be something really interesting in pulling charm metadata into annotations automatically at deployment time. On Fri, Jun 17, 2016 at 9:17 AM Ryan Beisner wrote: > On Fri, Jun 17, 2016 at 2:10 AM, Jay Wren wrote: > >> If it helps, the charm set command supports arbitrary key values to be >> stored in extra-info in the charm store. >> >> e.g. >> >> $ charm set cs:~evarlast/trusty/parse-server-0 layer-x=rev1 layer-y=rev2 >> >> Then this will be displayed in extrainfo: >> >> $ charm show cs:~containers/trusty/swarm extra-info >> extra-info: >> layer-x: rev1 >> layer-y: rev2 >> >> After pushing, you could use set to save the revisions of what was used >> to build the charm. >> > > Thanks, Jay. There is some potential in that. I think it'd be worth > discussing some k:v norms around this that we can all gather around. Then, > perhaps more importantly, how that info will persist in the places where it > needs to be observed, such as: charm store ui, a pulled charm, and the > resulting deployments. > > > >> >> -- >> Jay >> >> On Thu, Jun 16, 2016 at 8:51 PM, Charles Butler < >> charles.but...@canonical.com> wrote: >> >>> Greetings, >>> >>> I deposit many of my layers in GitHub, and one of the things I've been >>> striving to do is keep tag releases at the revisions i cut a charm release >>> for a given channel. As we know, the default channel is seen by no-one, and >>> runs in increments of n+1. >>> >>> My prior projects i've been following semver for releases, but that has >>> *nothing* in terms of a breadcrumb trail back to the store. >>> >>> Would it be seen as good practice to tag releases - on the top most >>> layer of a charm - with what charm release its coordinated with? >>> >>> Given the scenario that i'm ready to release swarm, and lets assume that >>> to date i haven't tagged any releases in the layer repository: >>> >>> charm show cs:~containers/trusty/swarm revision-info >>> revision-info: >>> Revisions: >>> - cs:~containers/trusty/swarm-2 >>> - cs:~containers/trusty/swarm-1 >>> - cs:~containers/trusty/swarm-0 >>> >>> I see that i'm ready to push swarm-3 to the store: >>> >>> git tag 3 >>> git push origin --tags >>> >>> I can now correlate the source revision to what i've put in my account >>> on the store, but this does not account for promulgation (which has an >>> orthogonal revision history), and mis-match of those id's. >>> >>> I think this can simply be documented that tags track >>> <>/<> pushes, and to correlate source with release, to use >>> the method shown above to fetch release info. >>> >>> Does this sound useful/helpful or am I being pedantic? (I say this >>> because Kubernetes touches ~ 7 layers, and it gets confusing keeping >>> everything up to date locally while testing, and then again re-testing with >>> --no-local-layers to ensure our repositories are caught up with current >>> development work. (Cant count the number of open pull requests hanging >>> waiting for review because we've moved to the next hot-ticket item) >>> >>> All the best, >>> >>> Charles >>> -- >>> Juju Charmer >>> Canonical Group Ltd. >>> Ubuntu - Linux for human beings | www.ubuntu.com >>> Juju - The fastest way to model your service | www.jujucharms.com >>> >>> -- >>> 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 >> >> -- > 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
Re: Charm push crashes when uploading big charms
Merlijn, thanks. I'm going to bet there's an issue with http request sizes for the charmstore that the charm command talks do as we've got some layers (Apache, Squid) in front of the actual application. The team is looking into it. Thanks for giving us the heads up. On Wed, Jun 15, 2016 at 10:28 AM Merlijn Sebrechts < merlijn.sebrec...@gmail.com> wrote: > Hi all > > > I've hit a roadblock in setting up my CI pipeline. I have a charm with a > Java sdk blob of ~200MB. Pushing this charm to the store causes the tool to > crash. I put a bug report here: > https://bugs.launchpad.net/juju/+bug/1592822 > > Juju resources would fix my problem, but then I'd need to move to Juju 2.0 > and I'm not ready to do that yet. > > > > Kind regards > Merlijn Sebrechts > -- > 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
[Review Queue] Abot, Rabbitmq-server, IBM, and npm-app
Hi everyone, The big data team (Kevin, Pete, Andrew and me) got together to do some reviews: June 16, 2016: Kevin/Kostas/Pete/Andrew - Abot - https://bugs.launchpad.net/charms/+bug/1582176 - The initial version of the Test Automation Framework charm - We found some issues that call the attention of the author: - No tests present - Readme improvements - No charm pushed for us to promulgate - We cannot proceed with the charm at this point. - Rabbitmq-server - https://code.launchpad.net/~ben-kaehne/charms/trusty/rabbitmq-server/statsfix/+merge/290949 - `make lint` and `make test` fail - Lots of tests failing, left a comment - IBM Base Layer - https://bugs.launchpad.net/charms/+bug/1584507 - Didn’t see any code to review; moving to Incomplete - IBM Installation Manager - https://bugs.launchpad.net/charms/+bug/1575746 - Waiting for decision on our MP; moving to In Progress - Interface for ibm-db2 - https://bugs.launchpad.net/charms/+bug/1578167 - We made a few lint, format, and doc updates. - Overall, +1, the db2 interface is published and available on http://interfaces.juju.solutions/ - IBM DB2 - https://code.launchpad.net/~ibmcharmers/charms/trusty/ibm-db2/trunk/+merge/294153 - Because of interface state name changes above, this MP needed to be updated. We made the needed changes and asked that those be verified before proceeding with promulgation. - New IBM NFSStorage interface - https://bugs.launchpad.net/charms/+bug/1578166 - Gave an initial +1, based on a read-through of the code. - New Charm: npm-app - https://bugs.launchpad.net/charms/+bug/1572326 - Pinged the submitter, asking how he would like to proceed (we left a question for him two weeks ago). Cheers, Konstantinos -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
[Review Queue] Auditd
Tim Kuhlman needed a hot review for auditd. This was a good looking submission, primarily a sync of lower layers and some minor top layer edits. Approved has been pushed to: cs:trusty/auditd-1 All the best, Charles -- Juju Charmer Canonical Group Ltd. Ubuntu - Linux for human beings | www.ubuntu.com Juju - The fastest way to model your service | www.jujucharms.com -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Problem setting provisioner-harvest-mode on 2.0 beta 7
Hello, I am running juju 2.0 beta 7 on a fresh install of xenial. My end goal is to deploy MAAS with juju. While I should never remove all juju services from these machines, I would like to ensure that juju will not remove the machines when all services are removed. Reading the docs, I set the provisioner-harvest-mode to none with this command: juju set-model-config provisioner-harvest-mode=none A juju get-model-config verifies that the parameter is set. However, when I deploy services and then destroy them, juju removes the machine they were deployed to. Did I miss something in the docs? Thanks! Chance Ellis -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
"juju attach"
Hi folks, A couple of days ago I started looking at charming TitanDB. I was looking at using resources to store the TitanDB distribution, and while looking at the docs [0] I found a rather surprisingly named command: "juju attach". The verb "attach" by itself tells me that, presumably, it will attach something to something else. It doesn't tell me what. And because it's non-specific, it either rules out the possibility of multiple unrelated attach-type commands. We always intended to give the user a means of attaching floating storage to a unit/machine. i.e. I should be able to detach and reattach storage to units in a model, so long as the storage provider supports it. I think the commands would naturally be called "attach-storage" and "detach-storage". Can we rename attach to attach-resource? Note that there's also "charm attach". That may benefit from a similar rename too, at least to be consistent. Cheers, Andrew [0] https://jujucharms.com/docs/devel/developer-resources -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: "juju attach"
We can change a CLI until RC, and its good for us to debate them. Here are the guiding principles. * shorter is better, much much better * we strongly prefer one word to always mean the same thing * we strongly prefer a unique verb to a common-verb-plus-noun For the latter reason I prefer not to go to attach-storage, attach-nic and attach-cpu... What you're looking for is a 1-3 syllable single verb which is distinct, nice to say, quick to tab-complete, and preferably implies storage. The one exception I can think of is list-* where we like the tab-complete "tell me about all the things" experience. Suggestions welcome for the word, but these are the principles we'll decide by. I may add more principles later :) Mark -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
