Strictly confined juju snap available for testing

juju
21

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 =)

22

You shouldn’t need to install any runtime dependencies just to build juju.

make go-install should do the trick

1 Like
23

I’ll try right away

24

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]#
1 Like
25

Awesome, looks like it worked :slight_smile:

1 Like
26

This is a good start @wallyworld

This was my path here.

Spawn a lxc with centos

lxc launch images:centos/7/cloud c7

Get in to the container

lxc shell c7

Install deps

yum install make
yum install git

Get go

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

Setup go

echo 'export PATH=$PATH:/usr/local/go/bin' >> ~/.bash_profile
source ~/.bash_profile
mkdir -p ~/go/src/
cd ~/go/src/

Clone juju sources

git clone https://github.com/juju/juju.git

Build

make go-install
make

Check out binaries

ls _build/linux_amd64/bin/
containeragent  juju  jujuc  jujud  juju-metadata  juju-wait-for  pebble

Take it for a spin

cd  _build/linux_amd64/bin/
./juju version
2.9.28-centos-amd64

Success.

27

Thanx to you! I think this would be a starting point for something that might look like a RPM in a week or so.

28

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

  • Accurate build instructions are deep down in the repo and didn’t work for me at least when I tried them.
  • I needed @wallyworld to get me through it and some step we took was not the same as the instructions.
  • I’m not sure how to build explicit components, such as a a controller vs a client vs a jujud (machine agent daemon) - This is useful for someone that might take on specific tasks or try solving easy issues.
  • I couldn’t find instructions on how to build the snap - this would be good for packagers/ops.
  • I couldn’t find instructions on how to build for other architectures - this would be good for anyone trying to use juju on non-server hardware, for example RPI, Nvidia Jetson, IoT devices etc.
  • I couldn’t find instructions on how to build packages for different OS:es… - This would be good for @heitor @jamesbeedy etc.
  • I couldn’t find instructions on how to build and work with the web-front (dashboard). - This would be good for me aswell.
  • I couldn’t find instructions on how to build and work with the controller-hub (jimm). - This would be good for paying clients of enterprise grade juju.

Further

  • The README.md file is 90% sales/propaganda of juju rather than useful information to a developer community. The README in a code repo, should in my opinion manage the code/development. Sales, marketing and whatever already have other platforms such as juju.is etc.
  • The better README.md tagetting NEW, external and intermediate level developers. the more contributors will have a chance to help.
  • Build instructions for target platforms helps grow a project. Picking a as-neutral-as-possible build environment (eliminate the snap requirement ?) helps achieve this.
  • The README.md states that bug-reports are filed in Launchpad. This means I have to learn (and alter my workflows) on how to work with code via BZR (!), while code is also in github. That is a massive problem for anyone trying to contribute to juju really. It makes no sense at all for a contributor. I’m sure its great or policy for Canonical. But, it raises the bar tremendously to generate new contributors or get help from other entities.

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.

3 Likes
29

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.

2 Likes
30

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 :wink:

[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.

1 Like
31

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.

2 Likes
32

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 :slight_smile:

1 Like
33

@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).

1 Like