Re: vsphere support
Quoting Dmitrii Shcherbakov (dmitrii.shcherba...@canonical.com): > Hi Serge, > > >From my perspective Juju will continue getting more support for vSphere > provider as VMware is used by some customers that do not want to go with a > full-blown bare-metal deployment and just have spare VMs. Ok, that's encouraging. > I personally had to do a deployment of K8s on ESX (don't remember which > version they had) but I had to use the manual provider because a custom > provisioning method and IPAM was used on-site without DHCP so there was no > way to use the proper vSphere provider. I've got a DNS server, but it's separate from the juju server right now. Hopefully that is ok. > >From the commercial perspective VMware is listed in a (fresh) datasheet > below and we do have that demand. > > https://assets.ubuntu.com/v1/b35eca50-Enterprise-Kubernetes-datasheet.pdf?_ga=2.138877683.1310562253.1507133746-467575700.1507133746 > > Best Regards, > Dmitrii Shcherbakov > > Field Software Engineer > IRC (freenode): Dmitrii-Sh Thanks, -serge -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: vsphere support
Hi I have a openstack charm installation and kubernetes cluster running currently. I remember trying vsphere support as well but it didnt work. sorry but that just came to my mind. so i was bound to use maas in order to use vsphere and juju. BR Christian Quoting "Serge E. Hallyn" : Well if using MAAS would be easier, I'm happy to do that. I actually just hadn't considered it a possibility, but I see at https://askubuntu.com/questions/870624/configuring-maas-with-vmware-esxi-nodes-and-virsh that it may be :) I wonder what would be the difference in range of charms that I can actually use if I use MAAS vs directly use juju vsphere support. -serge Quoting christian.set...@freies-franken.org (christian.set...@freies-franken.org): Hi Thats typical me. I implied that you use maas and have trouble setting it up with juju as a cloud. Pardon me. Thats how i work ;-) BR Christian Quoting "Serge E. Hallyn" : Quoting christian.set...@freies-franken.org (christian.set...@freies-franken.org): Hi 6.0 should work. It does for me and even 6.5. Ok - like I say I only have the one 6.0 so not ideal, but a starting point. I already have offered the devs that they can use my environment to sort out all the open bugs. But so far nobody was willing to do so. ... What i did maybe helpful do you... #!/bin/bash maas - machines add-chassis chassis_type='vmware' username='\' password='' protocol='https+unverified' hostname= prefix_filter= domain= Pardon my ignorance - but I don't know what I'm looking at :) Do you run that on the juju server then target juju at that maas instance? Without the https+unverified i couldnt get it to work adding a chassis because in the GUI the protocol field is missing. BR Christian thanks,-serge pub 2048R/DF0339A2 2017-09-10 Christian Setzer sub 2048R/68E412B2 2017-09-10 -- Juju mailing list Juju@lists.ubuntu.comModify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju binOPBg1iQWxH.bin Description: PGP Public Key -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: vsphere support
There really shouldn't be any difference in the charms that are deploy-able on MAAS vs vSphere. The Juju team has made a lot of strides in 2.2 and the upcoming 2.3 release to support vSphere directly. MAAS management of vSphere is slightly different than Juju if I recall correctly, but shouldn't impact charm compatibility. Marco On Wed, Oct 4, 2017 at 1:28 PM Serge E. Hallyn wrote: > Well if using MAAS would be easier, I'm happy to do that. I actually just > hadn't > considered it a possibility, but I see at > > https://askubuntu.com/questions/870624/configuring-maas-with-vmware-esxi-nodes-and-virsh > that it may be :) > > I wonder what would be the difference in range of charms that I can > actually use > if I use MAAS vs directly use juju vsphere support. > > -serge > > Quoting christian.set...@freies-franken.org ( > christian.set...@freies-franken.org): > > Hi > > > > Thats typical me. I implied that you use maas and have trouble > > setting it up with juju as a cloud. Pardon me. Thats how i work ;-) > > > > BR > > > > > > > > Christian > > > > Quoting "Serge E. Hallyn" : > > > > >Quoting christian.set...@freies-franken.org > > >(christian.set...@freies-franken.org): > > >>Hi > > >> > > >>6.0 should work. It does for me and even 6.5. > > > > > >Ok - like I say I only have the one 6.0 so not ideal, but a starting > > >point. > > > > > >>I already have offered the devs that they can use my environment to > > >>sort out all the open bugs. But so far nobody was willing to do so. > > > > > >... > > > > > >>What i did maybe helpful do you... > > >> > > >>#!/bin/bash > > >>maas - machines add-chassis chassis_type='vmware' > > >>username='\' password='' > > >>protocol='https+unverified' hostname= > > >>prefix_filter= domain= > > > > > >Pardon my ignorance - but I don't know what I'm looking at :) Do > > >you run that on the juju server then target juju at that maas > > >instance? > > > > > >>Without the https+unverified i couldnt get it to work adding a > > >>chassis because in the GUI the protocol field is missing. > > >> > > >>BR > > >> > > >>Christian > > > > > >thanks,-serge > > > pub 2048R/DF0339A2 2017-09-10 Christian Setzer < > christian.set...@freies-franken.org> > > sub 2048R/68E412B2 2017-09-10 > > > -- > 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: vsphere support
Well if using MAAS would be easier, I'm happy to do that. I actually just hadn't considered it a possibility, but I see at https://askubuntu.com/questions/870624/configuring-maas-with-vmware-esxi-nodes-and-virsh that it may be :) I wonder what would be the difference in range of charms that I can actually use if I use MAAS vs directly use juju vsphere support. -serge Quoting christian.set...@freies-franken.org (christian.set...@freies-franken.org): > Hi > > Thats typical me. I implied that you use maas and have trouble > setting it up with juju as a cloud. Pardon me. Thats how i work ;-) > > BR > > > > Christian > > Quoting "Serge E. Hallyn" : > > >Quoting christian.set...@freies-franken.org > >(christian.set...@freies-franken.org): > >>Hi > >> > >>6.0 should work. It does for me and even 6.5. > > > >Ok - like I say I only have the one 6.0 so not ideal, but a starting > >point. > > > >>I already have offered the devs that they can use my environment to > >>sort out all the open bugs. But so far nobody was willing to do so. > > > >... > > > >>What i did maybe helpful do you... > >> > >>#!/bin/bash > >>maas - machines add-chassis chassis_type='vmware' > >>username='\' password='' > >>protocol='https+unverified' hostname= > >>prefix_filter= domain= > > > >Pardon my ignorance - but I don't know what I'm looking at :) Do > >you run that on the juju server then target juju at that maas > >instance? > > > >>Without the https+unverified i couldnt get it to work adding a > >>chassis because in the GUI the protocol field is missing. > >> > >>BR > >> > >>Christian > > > >thanks,-serge > pub 2048R/DF0339A2 2017-09-10 Christian Setzer > > sub 2048R/68E412B2 2017-09-10 -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: vsphere support
Hi Thats typical me. I implied that you use maas and have trouble setting it up with juju as a cloud. Pardon me. Thats how i work ;-) BR Christian Quoting "Serge E. Hallyn" : Quoting christian.set...@freies-franken.org (christian.set...@freies-franken.org): Hi 6.0 should work. It does for me and even 6.5. Ok - like I say I only have the one 6.0 so not ideal, but a starting point. I already have offered the devs that they can use my environment to sort out all the open bugs. But so far nobody was willing to do so. ... What i did maybe helpful do you... #!/bin/bash maas - machines add-chassis chassis_type='vmware' username='\' password='' protocol='https+unverified' hostname= prefix_filter= domain= Pardon my ignorance - but I don't know what I'm looking at :) Do you run that on the juju server then target juju at that maas instance? Without the https+unverified i couldnt get it to work adding a chassis because in the GUI the protocol field is missing. BR Christian thanks,-serge bins1Cqe7aYAn.bin Description: PGP Public Key -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: vsphere support
Quoting christian.set...@freies-franken.org (christian.set...@freies-franken.org): > Hi > > 6.0 should work. It does for me and even 6.5. Ok - like I say I only have the one 6.0 so not ideal, but a starting point. > I already have offered the devs that they can use my environment to > sort out all the open bugs. But so far nobody was willing to do so. ... > What i did maybe helpful do you... > > #!/bin/bash > maas - machines add-chassis chassis_type='vmware' > username='\' password='' > protocol='https+unverified' hostname= > prefix_filter= domain= Pardon my ignorance - but I don't know what I'm looking at :) Do you run that on the juju server then target juju at that maas instance? > Without the https+unverified i couldnt get it to work adding a > chassis because in the GUI the protocol field is missing. > > BR > > Christian thanks, -serge -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: vsphere support
Hi Serge, >From my perspective Juju will continue getting more support for vSphere provider as VMware is used by some customers that do not want to go with a full-blown bare-metal deployment and just have spare VMs. I personally had to do a deployment of K8s on ESX (don't remember which version they had) but I had to use the manual provider because a custom provisioning method and IPAM was used on-site without DHCP so there was no way to use the proper vSphere provider. >From the commercial perspective VMware is listed in a (fresh) datasheet below and we do have that demand. https://assets.ubuntu.com/v1/b35eca50-Enterprise-Kubernetes-datasheet.pdf?_ga=2.138877683.1310562253.1507133746-467575700.1507133746 Best Regards, Dmitrii Shcherbakov Field Software Engineer IRC (freenode): Dmitrii-Sh On Wed, Oct 4, 2017 at 12:08 PM, Serge E. Hallyn wrote: > Hi, > > I've inherited a few vsphere machines where I was hoping to use juju > to fire off openstack etc. I've been trying to use the vsphere > provider (which I was excited to see existed), but am seeing a few > inconsistencies, so had a few questions. > > The first blunt question - is this going to be a maintained driver, > or am I in 6 months likely to find the vsphere driver dropped? > > The second is motivating the first - when I looked at > https://jujucharms.com/docs/2.1/help-vmware it says hardware version > 8 (ESX 5.0) should be sufficient. But in fact juju has a ubuntu.ovf > hardcoded in it that specifies 'vmx-10', which is ESX 5.5.. I currently > have 5 ESX 5.1 machines and one 6.0. > > Even with a custom DC using only the 6.0 host, I have some (probably > proxy) issues bootstrapping, which I'm sure are surmountable - but the > answer to Q1 will decide whether it's worth pursuing that further, or > whether I should spend my time elsewhere :) > > thanks, > -serge > > -- > 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: vsphere support
Hi 6.0 should work. It does for me and even 6.5. I already have offered the devs that they can use my environment to sort out all the open bugs. But so far nobody was willing to do so. What i did maybe helpful do you... #!/bin/bash maas - machines add-chassis chassis_type='vmware' username='\' password='' protocol='https+unverified' hostname= prefix_filter= domain= Without the https+unverified i couldnt get it to work adding a chassis because in the GUI the protocol field is missing. BR Christian Quoting "Serge E. Hallyn" : Hi, I've inherited a few vsphere machines where I was hoping to use juju to fire off openstack etc. I've been trying to use the vsphere provider (which I was excited to see existed), but am seeing a few inconsistencies, so had a few questions. The first blunt question - is this going to be a maintained driver, or am I in 6 months likely to find the vsphere driver dropped? The second is motivating the first - when I looked at https://jujucharms.com/docs/2.1/help-vmware it says hardware version 8 (ESX 5.0) should be sufficient. But in fact juju has a ubuntu.ovf hardcoded in it that specifies 'vmx-10', which is ESX 5.5.. I currently have 5 ESX 5.1 machines and one 6.0. Even with a custom DC using only the 6.0 host, I have some (probably proxy) issues bootstrapping, which I'm sure are surmountable - but the answer to Q1 will decide whether it's worth pursuing that further, or whether I should spend my time elsewhere :) thanks, -serge -- Juju mailing list Juju@lists.ubuntu.comModify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju binoDYal2_104.bin Description: PGP Public Key -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
vsphere support
Hi, I've inherited a few vsphere machines where I was hoping to use juju to fire off openstack etc. I've been trying to use the vsphere provider (which I was excited to see existed), but am seeing a few inconsistencies, so had a few questions. The first blunt question - is this going to be a maintained driver, or am I in 6 months likely to find the vsphere driver dropped? The second is motivating the first - when I looked at https://jujucharms.com/docs/2.1/help-vmware it says hardware version 8 (ESX 5.0) should be sufficient. But in fact juju has a ubuntu.ovf hardcoded in it that specifies 'vmx-10', which is ESX 5.5.. I currently have 5 ESX 5.1 machines and one 6.0. Even with a custom DC using only the 6.0 host, I have some (probably proxy) issues bootstrapping, which I'm sure are surmountable - but the answer to Q1 will decide whether it's worth pursuing that further, or whether I should spend my time elsewhere :) thanks, -serge -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: set_state not setting the state immediately
These sound like good steps to me. I would just encourage us to look at the worst examples of charms people have written or questions that are common and attempt to defend against that sort of thing. People invent things out of perceived necessity and if we can find those and provide solutions I think we'll have a better product in the end. On Wed, Oct 4, 2017 at 9:00 AM Marco Ceppi wrote: > So, I've not actually checked the logs in a while, but if visibility is an > issue, it seems reasonable that the reactive framework should print in the > log that X flags are being reset due to hook failure. Things like > set_flag_immediate has farther reaching consequences than simply stating > that flags only get set on success of a hook run. > > I know there are further reaching initiatives to alleviate this by > decoupling the reactive state engine from the juju hooks system. In this > case each successive loop of the reactive runtime could better snapshot > state and make failures more granular. > > * state is being renamed to flag in the next major version of reactive. > > On Wed, Oct 4, 2017 at 8:52 AM Mike Wilson > wrote: > >> So as a new charm writer coming to Juju I would first do this: >> >> def get_ready(): >> func0() >> func1_fails() >> >> Then I would, hopefully, test and notice issues. I would investigate and >> see that I needed to be idempotent. My next attempt would be to wrap those >> functions inside state checks with sets after they complete. This would >> also fail and now the charm creator is left with nothing in the api that >> can help. They are now off to their own devices to start doing random >> things to attempt to make this work the way they want it to work. >> Hopefully, the solution is as straight-forward as touching random files, >> but we just never know. >> >> I would expect the name of set_state to be something like >> set_state_on_success and I would further expect some sort of immediate >> state thing like set_state or set_state_immediate. This would give the user >> the tools we know that they need in order to create bug-free charms. >> >> Now to compound that confusion, we have the issue of a hook can call >> multiple functions inside the charm code and if any of those functions have >> something that fails the whole thing is unwrapped. I understand from a Juju >> perspective why this is the case, but as a user, I would be completely >> taken by surprise here. The only real fix here is documentation so that we >> can set expectations, but people will most likely look at examples instead >> of documentation. This means that we need to make sure to call out any >> potential issues like this in the example charms we release. >> >> >> On Wed, Oct 4, 2017 at 6:34 AM Stuart Bishop >> wrote: >> >>> On 4 October 2017 at 00:51, Mike Wilson >>> wrote: >>> > So the best practice here is to touch a file and test for the >>> existence of >>> > that file before running must_be_called_exactly_once()? >>> > >>> > I think part of the issue here is that without knowing the extent of >>> the >>> > hook it is hard to enforce idempotency as a charm writer. It's easy to >>> look >>> > at the code above and say that is it idempotent since the init >>> function is >>> > wrapped in a when_not and the initialized state is set at the bottom of >>> > init. >>> >>> Individual handlers should be idempotent, so it doesn't matter about >>> the extent of the hook, or even if the chained handlers being triggers >>> are running in the same hook. Assume your handlers get called multiple >>> times, because they may be. Yes, it looks idempotent but it isn't. An >>> assumption is being made that the state changes get committed >>> immediately, but these changes are actually transactional and >>> following the same transactional behaviour as the Juju hook >>> environment [1]. I think this can certainly be explained better in the >>> docs, but I can't think of a way to stop this being an easy error to >>> make. >>> >>> [1] spot the DBA >>> >>> -- >>> Stuart Bishop >>> >> -- > > >> 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: set_state not setting the state immediately
So, I've not actually checked the logs in a while, but if visibility is an issue, it seems reasonable that the reactive framework should print in the log that X flags are being reset due to hook failure. Things like set_flag_immediate has farther reaching consequences than simply stating that flags only get set on success of a hook run. I know there are further reaching initiatives to alleviate this by decoupling the reactive state engine from the juju hooks system. In this case each successive loop of the reactive runtime could better snapshot state and make failures more granular. * state is being renamed to flag in the next major version of reactive. On Wed, Oct 4, 2017 at 8:52 AM Mike Wilson wrote: > So as a new charm writer coming to Juju I would first do this: > > def get_ready(): > func0() > func1_fails() > > Then I would, hopefully, test and notice issues. I would investigate and > see that I needed to be idempotent. My next attempt would be to wrap those > functions inside state checks with sets after they complete. This would > also fail and now the charm creator is left with nothing in the api that > can help. They are now off to their own devices to start doing random > things to attempt to make this work the way they want it to work. > Hopefully, the solution is as straight-forward as touching random files, > but we just never know. > > I would expect the name of set_state to be something like > set_state_on_success and I would further expect some sort of immediate > state thing like set_state or set_state_immediate. This would give the user > the tools we know that they need in order to create bug-free charms. > > Now to compound that confusion, we have the issue of a hook can call > multiple functions inside the charm code and if any of those functions have > something that fails the whole thing is unwrapped. I understand from a Juju > perspective why this is the case, but as a user, I would be completely > taken by surprise here. The only real fix here is documentation so that we > can set expectations, but people will most likely look at examples instead > of documentation. This means that we need to make sure to call out any > potential issues like this in the example charms we release. > > > On Wed, Oct 4, 2017 at 6:34 AM Stuart Bishop > wrote: > >> On 4 October 2017 at 00:51, Mike Wilson >> wrote: >> > So the best practice here is to touch a file and test for the existence >> of >> > that file before running must_be_called_exactly_once()? >> > >> > I think part of the issue here is that without knowing the extent of the >> > hook it is hard to enforce idempotency as a charm writer. It's easy to >> look >> > at the code above and say that is it idempotent since the init function >> is >> > wrapped in a when_not and the initialized state is set at the bottom of >> > init. >> >> Individual handlers should be idempotent, so it doesn't matter about >> the extent of the hook, or even if the chained handlers being triggers >> are running in the same hook. Assume your handlers get called multiple >> times, because they may be. Yes, it looks idempotent but it isn't. An >> assumption is being made that the state changes get committed >> immediately, but these changes are actually transactional and >> following the same transactional behaviour as the Juju hook >> environment [1]. I think this can certainly be explained better in the >> docs, but I can't think of a way to stop this being an easy error to >> make. >> >> [1] spot the DBA >> >> -- >> Stuart Bishop >> > -- > 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: set_state not setting the state immediately
So as a new charm writer coming to Juju I would first do this: def get_ready(): func0() func1_fails() Then I would, hopefully, test and notice issues. I would investigate and see that I needed to be idempotent. My next attempt would be to wrap those functions inside state checks with sets after they complete. This would also fail and now the charm creator is left with nothing in the api that can help. They are now off to their own devices to start doing random things to attempt to make this work the way they want it to work. Hopefully, the solution is as straight-forward as touching random files, but we just never know. I would expect the name of set_state to be something like set_state_on_success and I would further expect some sort of immediate state thing like set_state or set_state_immediate. This would give the user the tools we know that they need in order to create bug-free charms. Now to compound that confusion, we have the issue of a hook can call multiple functions inside the charm code and if any of those functions have something that fails the whole thing is unwrapped. I understand from a Juju perspective why this is the case, but as a user, I would be completely taken by surprise here. The only real fix here is documentation so that we can set expectations, but people will most likely look at examples instead of documentation. This means that we need to make sure to call out any potential issues like this in the example charms we release. On Wed, Oct 4, 2017 at 6:34 AM Stuart Bishop wrote: > On 4 October 2017 at 00:51, Mike Wilson wrote: > > So the best practice here is to touch a file and test for the existence > of > > that file before running must_be_called_exactly_once()? > > > > I think part of the issue here is that without knowing the extent of the > > hook it is hard to enforce idempotency as a charm writer. It's easy to > look > > at the code above and say that is it idempotent since the init function > is > > wrapped in a when_not and the initialized state is set at the bottom of > > init. > > Individual handlers should be idempotent, so it doesn't matter about > the extent of the hook, or even if the chained handlers being triggers > are running in the same hook. Assume your handlers get called multiple > times, because they may be. Yes, it looks idempotent but it isn't. An > assumption is being made that the state changes get committed > immediately, but these changes are actually transactional and > following the same transactional behaviour as the Juju hook > environment [1]. I think this can certainly be explained better in the > docs, but I can't think of a way to stop this being an easy error to > make. > > [1] spot the DBA > > -- > Stuart Bishop > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Private Icons for a charm.
Hi All, I've created custom icons.svg for charms but in the juju gui it doesn't show up. The url for the icon when I inspect the webpage looks like this. https://user-admin@local:password@10.60.1.20:17070/model/f7872e93-5cbf-46dd-814b-2c63031686cd/charms?url=local:centos7/radius-27&icon=1 If use this url in a browser it works it brings up the icon. But in the juju webgui it shows up a generic icon. Is there a fix for this? I am currently starting the charm like this juju deploy /home/ubuntu/charms/radius --constraints mem=4G Regards, Michael -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: set_state not setting the state immediately
On 4 October 2017 at 00:51, Mike Wilson wrote: > So the best practice here is to touch a file and test for the existence of > that file before running must_be_called_exactly_once()? > > I think part of the issue here is that without knowing the extent of the > hook it is hard to enforce idempotency as a charm writer. It's easy to look > at the code above and say that is it idempotent since the init function is > wrapped in a when_not and the initialized state is set at the bottom of > init. Individual handlers should be idempotent, so it doesn't matter about the extent of the hook, or even if the chained handlers being triggers are running in the same hook. Assume your handlers get called multiple times, because they may be. Yes, it looks idempotent but it isn't. An assumption is being made that the state changes get committed immediately, but these changes are actually transactional and following the same transactional behaviour as the Juju hook environment [1]. I think this can certainly be explained better in the docs, but I can't think of a way to stop this being an easy error to make. [1] spot the DBA -- Stuart Bishop -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
