Love that.
But the dynamics of this would then be still that the upstream project would accept this contribution and ideally also at least provide some infrastructure to maintain it as part of releases etc. For example to be able to release both snap:s and deb:s as part of a release schedule for juju. I’m not experienced in how all that works, but for sure Canonical as the project lead would have to be partially involved.
I’m sure you (Canonical) have done these things before…
Is there a point in trying to engage with some independent Debian developers to produce deb? @heitor
I know @hallback is good at rpm.
@erik-lonroth it would be great if you could post a query to the snapscraft forum about your setup regarding NFS mounted home dir etc; I’d be interested to see what they respond with, and we can get a feel for what the gaps are etc.
Thanx for coming back to this.
I have posted a number of texts, bugs, discourse posts and expressed my concerns on this in both juju and snap discourses over the years on this.
Its painful and time consuming. It is also difficult for me to do the deepdive into the complexity related to the combination of many technologies. Not only snap, but also centos, nfs, selinux, etc.
I think that the easier path is to invest in getting a RPM built and possibly a DEB.
I don’t think snapd will be included in centos in a very long time, so getting a stable solution meanwhile is critical.
I appreciate the snap for juju in some contexts, but it has also caused alot of very serious problems that keeps coming back.
Oh wow, that’s a lot of posts. I’ll ask some people, but it does seem like it’s not a solved issue 
. It would be good to understand why.
My understanding is that snaps are supported on centos, so if the NFS home issue were solved, they could be a viable solution for the juju client.
@wallyworld I apprechiate the effort. But I don’t want to have the snap when working on systems which has NFS or/and centos.
I’m trying as we speak to build juju on centos7 and running into problem since the Makefile depends on snap aswell.
## install-mongo-dependencies: Install Mongo and its dependencies
@echo Installing ${JUJU_DB_CHANNEL} juju-db snap for mongodb
@sudo snap refresh juju-db --channel=${JUJU_DB_CHANNEL} 2> /dev/null; sudo snap install juju-db --channel=${JUJU_DB_CHANNEL} 2> /dev/null
@$(WAIT_FOR_DPKG)
@sudo apt-get --yes install $(strip $(DEPENDENCIES))
I’m looking for help to build juju so that I can produce a .RPM as a PoC.
How can I get mongodb rependencies in from sources?
I can’t find what is needed from here: https://github.com/juju/juju-db-snap
I’m currently at this point…
[root@c7 juju]# cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"
[root@c7 juju]# make install-dependencies
Using installed go-1.17
Installing 4.4/stable juju-db snap for mongodb
make: *** [install-mongo-dependencies] Error 1
[root@c7 juju]#
I’d like to know if anyone would be able to assist me in building the code on centos and then I might figure out how to get help building the RPM from experts like @hallback =)
You shouldn’t need to install any runtime dependencies just to build juju.
make go-install should do the trick
I’ll try right away
The command terminated OK.
make go-install
...
github.com/canonical/pebble/internal/overlord/checkstate
github.com/canonical/pebble/internal/overlord/servstate
github.com/canonical/pebble/internal/overlord
github.com/canonical/pebble/internal/daemon
github.com/canonical/pebble/cmd/pebble
I’m trying now
make
Generating facade schema...
go: downloading golang.org/x/tools v0.1.5
go: downloading github.com/juju/jsonschema-gen v0.0.0-20220207021829-b1697c753155
go: downloading golang.org/x/xerrors v0.0.0-20200804184101-5ec99f83aff1
go: downloading golang.org/x/mod v0.5.1
Building github.com/juju/juju/cmd/jujuc for linux/amd64
Building github.com/juju/juju/cmd/jujud for linux/amd64
Building github.com/juju/juju/cmd/containeragent for linux/amd64
Building github.com/canonical/pebble/cmd/pebble for linux/amd64
Building github.com/juju/juju/cmd/juju for linux/amd64
Building github.com/juju/juju/cmd/plugins/juju-metadata for linux/amd64
Building github.com/juju/juju/cmd/plugins/juju-wait-for for linux/amd64
[root@c7 juju]#
Seems to work…
[root@c7 juju]# cd _build/linux_amd64/bin/
[root@c7 bin]# ls
containeragent juju jujuc jujud juju-metadata juju-wait-for pebble
[root@c7 bin]#
Lets try it!
[root@c7 bin]# ./juju version
2.9.28-centos-amd64
[root@c7 bin]#
Lets take it for a ride:
[root@c7 bin]# ./juju login jaas
Opening an authorization web page in your browser.
If it does not open, please open this URL:
https://api.jujucharms.com/identity/login?did=fc6b01275f1fb0c809a452b411d384ef3e25d6115441c12c12c0fdca94912f12
Welcome, erik-lonroth@external. You are now logged into "jaas".
There are 2 models available. Use "juju switch" to select
one of them:
- juju switch foobar
- juju switch monitoring
[root@c7 bin]#Awesome, looks like it worked 
This is a good start @wallyworld
This was my path here.
lxc launch images:centos/7/cloud c7
lxc shell c7
yum install make
yum install git
curl -k -O https://dl.google.com/go/go1.17.linux-amd64.tar.gz
sudo tar -C /usr/local -xzf go1.17.linux-amd64.tar.gz
echo 'export PATH=$PATH:/usr/local/go/bin' >> ~/.bash_profile
source ~/.bash_profile
mkdir -p ~/go/src/
cd ~/go/src/
git clone https://github.com/juju/juju.git
make go-install
make
ls _build/linux_amd64/bin/
containeragent juju jujuc jujud juju-metadata juju-wait-for pebble
cd _build/linux_amd64/bin/
./juju version
2.9.28-centos-amd64
Success.
Thanx to you! I think this would be a starting point for something that might look like a RPM in a week or so.
I woke up today thinking about how this discussion could be turned in to a better (not least) documentation on how to build and contribute to juju. @tmihoc
Further
There is more to this I think and I really think these matters are critical to the future of Juju - attracting, caring and expanding the community.
Thank you for taking the time to provide very thoughtful feedback. We can look to improve things for sure; in the meantime, here are some answers/responses…
I can see the point about the contributing guidelines - they are buried in a link at the bottom of a wall of (sales) text. And they could probably target different types of user as you suggest.
The contributing instructions are technically correct. You ended up bypassing the install-dependencies step because snaps don’t work on your setup, so just did make install to build juju. However, the dependencies are needed for running unit tests, which of course is necessary when contributing. What could be better for sure is instructions for doing such things when snap isn’t available.
With Launchpad for bugs, you don’t need bzr at all. 1. Launchpad supports git, and 2. code hosting is on github anyway. Launchpad’s bug tracker offers features we don’t get from github issues, like tying an issue to multiple related projects, integration with LP release milestones etc. All you need is a Launchpad login and you can report and participate in bug discussions etc. I am not sure that is a “massive problem”?
With the building of explicit components, the make install step will build all the binaries (juju client, jujud agent, juju-wait-for plugin etc). It seems though we could document this better.
With building for different OS, or even arch, this can be done by setting GOOS and GOARCH, which is standard Go practice, but this could be explicitly called out in the guidelines.
Building the snap is easy and should be documented:
eg from the juju top level directory, run:
snapcraft remote-build --launchpad-accept-public-upload --build-on amd64
The dashboard and jimm are separate projects. The dashboard is in a bit of flux at the moment as it is transitioning to become a charm rather than a blob which is unpacked and served by the controller. Jimm is a private project which is not currently opensource.
Thanx again @wallyworld I do totally recognize that some of my notes and comments above are a consequence of me not knowing enough of the juju from a development view.
However, I think I look at this from a perspective of growing the juju community. Especially out side of Canonical. This has nothing to do with that we don’t want Canonical - its just that the project would be stronger with contributions from a broader community.
In my opinion, this should be a Juju project priority.
Make contributing to Juju easy for non-canonical contributors
The below is typical - but does it help or cause issues to a potential new developer?
No, this is not a massive problem. Its just another problem, adding to the general complexity. Removing them - one by one - is what will make progress if the priority of growing the community matters.
I’m also not saying that being able to track bugs in github would be the top priority, but I think my point comes through.
If we were to compile a long list of items which is currently pain-points for contribution and adoption of juju outside of Canonical/Ubuntu - what would such a list look like?
Perhaps this is a topic for a joint community workshop this year?
Totally, but I think the close relation to Juju would make them quite important to mention with Juju. In my opinion, they are tightly integrated. I would say it makes little sense to separate them from the project.
Again, massive thanx for the great work on Juju. My criticism is intended to get better and make juju more enjoyable by users and developers.
Yes, this is super easy! I wish that was on top of the README and not in this post 
[Update] Even if I like the simplicity of this build method - the build time is massive. It took 20 minutes to build a snap I’m working on which is fairly small.
If interrupted, resume with: 'snapcraft remote-build --recover --build-id snapcraft-nagios-substrate-884a3c99478224221a4569c65e24009f'
Building snap package for amd64. This may take some time to finish.
Build status as of 2022-03-21 07:43:03.618786:
...
20 minutes goes by...
...
Build status as of 2022-03-21 08:03:46.161574:
arch=amd64 state=Successfully built
Snapped nagios-substrate_0.1_amd64.snap
Build log available at 'nagios-substrate_amd64.txt'
Build complete.
So, unfortunately - this build time is not working if you intend to enter a development cycle.
Hey, just to be super clear - I agree totally with your great feedback and the pain points you mention are valid and things we need to fix. I was just trying to offer some quick answers to the questions raised in the short term to help unblock things, until we can get updates to the relevant docs etc.
With the building of the juju snap, you don’t have to do it remotely, but doing it locally does use a LXD container by default and so I didn’t mention that given the issues you are having with snaps. Sometimes the builders can get congested, but for me at least, I find it only takes usually 10 minutes or so. One thing I think which takes time is that if there’s a .git directory, all of that gets slurped up and it really doesn’t need to. And for juju, that is huge. It’s something we can look into assuming I am correct in this regard.
Also note you can iterate on juju without the snap; all you need is the compiled binaries and you can bootstrap and even upgrade a controller itsitu if you make changes and need to test, via juju upgrade-controller --build-agent. No juju developer I know uses the snap at all for any development work; it’s just a means to distribute the finished product.
Thanks again for the input on all of this.
Just wanted to drop in and say that I have been using the confined snap, with my existing lxd cloud, and it works great thus far!
I’ll drop back in if I run into any issues. But thus far, there have been none
@pengale Thanks for the feedback!
The only thing I am aware that is not working is the built in microk8s integration which allows you to just juju bootstrap micrk8s out of the box.
You need to do add microk8s manually, just like any other k8s cluster you might want to deploy to, eg microk8s config | juju add-k8s myk8s
(to support micrk8s as a built in cloud we need to do a bunch of work in both juju and microk8s snaps).