Re: Private Icons for a charm.

[Francesco Banconi]

> 
> On 5 Oct 2017, at 10:24, Merlijn Sebrechts  
> wrote:
> 
> 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.

Thanks for reporting this issue! This seems to be an instance of 
https://github.com/juju/juju-gui/issues/3067
It is possible to confirm that by trying to load the GUI with Firefox, for 
instance, as only Chrome is affected by the problem.
We are currently investigating possible solutions.

--
Francesco

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Search results

[Francesco Banconi]

> On 27 Apr 2017, at 14:44, Tom Barber  wrote:
> 
> Of course getting them recommended is also something you guys want to happen 
> and something a lot of the community charms are working towards, but this 
> seems unnecessarily restrictive.

Hey Tom,

we agree with you, and we are working on improving how we visualise results 
from the charm store. There is a high priority bug at [1], currently in 
progress. The plan is to include that on the next jujucharms.com and GUI 
releases.
Thanks for your feedback!

[1] https://github.com/juju/juju-gui/issues/2435

--
Francesco





-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: jujucharms.com authentication issues

[Francesco Banconi]

> On 29 Mar 2017, at 18:08, Francesco Banconi <francesco.banc...@canonical.com> 
> wrote:
> 
> we are currently working on fixing an identity manager misconfiguration on 
> jujucharms.com production. 

All the services are now be back to full functionality.
Please let us know if you find any remaining issues.
Sorry again for the inconvenience, and thanks!

--
Francesco





-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

jujucharms.com authentication issues

[Francesco Banconi]

Hi all,

we are currently working on fixing an identity manager misconfiguration on 
jujucharms.com production. 
The problem prevents users from logging into the system, including the JAAS 
controller, the charm store and the jujucharms.com web application itself. 
We’ll update you as soon as we have news.
Sorry for the inconvenience.
Many thanks.

--
Francesco





-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Make JaaS better for data scientists

[Francesco Banconi]

> On 8 Mar 2017, at 09:51, Merlijn Sebrechts  
> wrote:
> 
> Juju as a Service is incredibly cool. This is a great step towards making 
> Juju useful for data scientists. However, there are still a number of issues 
> that block this adoption. This email sheds some light into how, in our 
> experience, a data scientist should use Juju and identifies what issues 
> prevent data scientists from using Juju this way.

This is great feedback Merlijn, thanks a lot!
Please take a look at my comments inline for a status update on the issues you 
listed.

> The ideal workflow of a data scientist
> 
> 1. Search the Charm store for the framework you want to use.
> 2. Find the right bundle such as the Apache Spark Zeppelin bundle and click 
> on "add to new model"
> 3. login into JaaS, click deploy and add cloud credentials.
> 4. Wait until the bundle is deployed completely
> 5. Use the GUI to go to the Zeppelin UI
> 6. Do data science magic.
> 
> Blockers in this workflow
> 
>   • A bunch of Charms fail when deployed from the GUI. Juju GUI handling 
> of empty config breaks promulgated charms. [1] [2] [3]

We recently fixed this and deployed to production already, so the deployment of 
Apache Spark Zeppelin charms and all other charms affected by empty config 
issues should work now.

>   • It's not possible use the GUI to go to the Zeppelin UI because 
> Zeppelin is a subordinate. Subordinate unit details show principal unit 
> details

Interesting, I just reprioritised the issue you linked, thanks.

>   • A bunch of Big Data Charms cannot be deployed from the Charm Store 
> because it's not possible to upload large resources. [1] [2]

This has been fixed and will be made available on the next release of the charm 
tool.

>   • It's not possible to create some models with the GUI because the GUI 
> doesn't understand regular relationships to a subordinate charm

We investigated this and found the root cause for which the GUI and the CLI act 
differently. Will be fixed soon.

> Non-blocking issues:
>   • The data scientist has no idea what version of the platform he is 
> running since workload version isn't show in the GUI.

Cool, good point, we’ll figure out with UX where to include that missing piece 
of information.

> Enhancements:
>   • Bring a GUI's application address more to the front. A user now has 
> to dig into the units to see this info. This info should be front and center 
> since it's the obvious next step after the model is deployed.
>   • Bring advanced Charm states more to the front. Currently, a user has 
> to dig into the units in the sidebar to find a very badly wrapped version of 
> the unit message.

Yes this is related to the address really being a property of units, not the 
application itself. But, from the UX perspective, we should really consider 
surfacing this info, especially when there is only one unit. 

>   • Putting the public IP first in the list of IP's. 
> https://github.com/juju/juju-gui/issues/2598

Cool, trivial fix already in progress.

>   • In general, show much more info in the GUI, such as machine IP's etc.
> Next steps
> 
> If the data scientists likes what he sees, he'll have a few questions.
> 
> 1. How do I get ssh access to the machines themselves?
> 2. How do I connect my own applications to this model?

The good news is that we have these steps already in our roadmap. We already 
discussed about allowing machine access from the GUI (even if it’s not 
scheduled for the near future), the ability to relate applications cross model 
being developed by the Juju team to be available soon.

> Blockers for next steps
> 
>   • The GUI borks on the Eclipse Che Charm because it tries to parse the 
> >30.000 open ports that Eclipse Che has. The CLI shows this correctly as a 
> port range but the GUI doesn't. So we need the CLI to find the url to go to 
> eclipse che but we need access to eclipse che to get a cli. Chicken or egg?

We are already working to fix this, and it will be part of the next GUI release.

> Non-blocking issues:
>   • There is no way to export model info from the GUI and import it into 
> the CLI. Another approach to this might be to piggyback on the idea of 
> exposing the controller as an application in the "controller" model. The 
> eclipse-che charm can then connect to the controller charm to import that 
> information.

I guess this is https://github.com/juju/juju-gui/issues/2599 And yes I agree 
this must be part of your roadmap.

Thanks again for your notes: this is exactly what we need to make Juju as a 
Service better, and we’ll surely work in the direction of making it a great 
experience for data scientists.

--
Francesco





-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New jujucharms.com released -- upgrade to Juju 2.0-beta16 required

[Francesco Banconi]

> On 31 Aug 2016, at 18:39, SivaRamaPrasad Ravipati  wrote:
> 
> Is this issue solved in  JUJU version 2.0-beta16-xenial-amd64?

Yes it is: previous beta versions assumed only development and stable as valid 
channels.
Starting from beta16 this is no longer the case.

--
Francesco





-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

store migration

[Francesco Banconi]

Hi all,

FYI this morning the UI team discussed about possibile paths to migrate the 
store code from lp:juju-core to Github.
We are sharing this plan so that we can synchronize/collaborate with other 
teams with similar needs in their todo list.

Here are the store package dependencies as obtained with go list:

Deps:
$ go list -f {{range .Deps}}{{println .}}{{end}} 
launchpad.net/juju-core/store | grep juju-core
launchpad.net/juju-core/charm
launchpad.net/juju-core/charm/hooks
launchpad.net/juju-core/juju/osenv
launchpad.net/juju-core/schema
launchpad.net/juju-core/thirdparty/pbkdf2
launchpad.net/juju-core/utils
launchpad.net/juju-core/utils/set
launchpad.net/juju-core/utils/zip

Tests deps:
$ for i in `go list -f {{range .Deps}}{{println .}}{{end}} 
launchpad.net/juju-core/store`; do go list -f {{range .XTestImports}}{{println 
.}}{{end}} $i; done | grep juju-core | sort | uniq
launchpad.net/juju-core/charm
launchpad.net/juju-core/charm/testing
launchpad.net/juju-core/environs/config
launchpad.net/juju-core/juju/osenv
launchpad.net/juju-core/schema
launchpad.net/juju-core/testing
launchpad.net/juju-core/testing/filetesting
launchpad.net/juju-core/testing/testbase
launchpad.net/juju-core/utils
launchpad.net/juju-core/utils/set
launchpad.net/juju-core/utils/zip

As you can see, there are some incremental steps we will need to follow to 
achieve our goal, I’ll try to describe them below including notes from William. 
I suppose we can encounter complications in this path, but hopefully at the end 
we’ll have a good starting point for the store.
William agreed on the goals of this migration (having a common/separate module 
which can be reused by both juju-core and the GUI).

Just two notes before sketching a possible plan:
- the store must be able to be configured to use its own db or the juju-core 
one based on the context it is used;
- we need a way to migrate partial Bazaar commit history to git (perhaps 
someone has already experience with this?).

A possible plan is as follow:

1) Migrate juju-core/thirdparty to juju/thirdparty (Github).
Since there are no dependencies here, this seems to be a good first candidate. 

2) Migrate juju-core/utils to juju/utils (Github).
package:
 launchpad.net/juju-core/utils
deps:
 launchpad.net/juju-core/juju/osenv
 launchpad.net/juju-core/thirdparty/pbkdf2
tests deps:
 launchpad.net/juju-core/juju/osenv
 launchpad.net/juju-core/testing/testbase

I did not look at juju/osenv: we might want to migrate that as well, or just 
refactor the code to remove the dependency. Note that each time we move a 
package we need to also move the relevant code in juju-core/testing to 
juju/testing. The latter already exists on Github. The juju-core/testing module 
has lots of dependencies on other packages in juju-core, so if we encounter 
those we will need to handle that (I presume by refactoring test code). In the 
utils case, juju-core/testing/testbase does not seem to depend on anything, so 
we should be ok.

3) Migrate juju-core/schema to juju/utils/schema. The schema package has no 
juju-core dependencies.

4) Migrate juju-core/charm. This has some pre-requisites. Basically IIUC charm 
defines config and meta and those definitions are tangled with the underlaying 
Mongo documents. William suggested to decouple that, implementing separate data 
structures to be used to (de)serialize data. This way, changes to charm 
database structure can be detected earlier and core developers are able to 
react accordingly. Soon this could also involve actions data. 

5) Move the store.

For each step AFAICT what we need to do is similar to the following:
1) possible preliminary work to move the testing stuff;
2) create Github project (if it does not exist);
3) add readme, copying, license files etc;
4) notify developers we are locking the package;
5) migrate the code;
6) fix package imports if required (e.g. for sub-packages);
7) fix package tests;
8) land a juju-core branch which:
   - removes the package;
   - fixes all the imports;
   - includes the new dependency info in the dependencies.tsv file;
9) notify developers about the new external dependency.

Thanks!

--
Francesco


-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New Juju Plugin: git-deploy

[Francesco Banconi]

On 07 Apr 2014, at 19:37, Adam Stokes adam.sto...@ubuntu.com wrote:

 I think it would be cool if that was utilizing the existing code by
 Kapil for the api interactions:
 
 https://launchpad.net/python-jujuclient

Hi Adam,

yeah, of course it would be nice.
The first step in that direction would be making the jujuclient work with 
Python3, and that was out of my “weekend hacking” scope.

--
Francesco





-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New Juju Plugin: git-deploy

[Francesco Banconi]

On 08 Apr 2014, at 16:33, Joshua Strobl truthfroml...@gmail.com wrote:

 You clearly didn't see the juju-git-charm, which deploys and manages charms 
 through git, and it isn't limited to GitHub.

Hey Joshua,

Your plugin is this, right?
https://github.com/juju/plugins/blob/master/juju-git-charm

AFAICT that seems to help configuring a git-based development environment for 
working on charms, and automating the creation/update of a local charm 
repository. 
That’s not what juju-git-deploy is about: it does not clone/update git 
repositories, it just deploys charms hosted on Github, e.g.:

  juju git-deploy hatched/ghost-charm

After running the command above, the charm at 
https://github.com/hatched/ghost-charm is actually deployed on the current Juju 
environment, and no local repositories (i.e. ~/charms/) are created. 
As I mentioned, those two projects seem to have different goals to me. Am I 
missing something?

--
Francesco





-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New juju-quickstart available

[Francesco Banconi]

On 22 Nov 2013, at 20:57, Jorge O. Castro jo...@ubuntu.com wrote:

 What is juju quickstart? It's a Juju plugin that guides you through
 initialization and bootstrap of Juju quickly so you type less and
 deploy more.

Thank you Jorge, I’ll just add some bits of information below.

The quickstart plugin is developed by the GUI Team. It’s in a early stage of 
development, but it’s already useful in our opinion. Its goal is to guide the 
user from zero to a fully functional, bootstrapped Juju environment (including 
the GUI and bundle deployments) in the quickest way possible. 
We appreciate any feedback; bugs can be filed here:
https://bugs.launchpad.net/juju-quickstart/+bugs

Thank you!

--
Francesco


-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju