> On 8 Mar 2017, at 09:51, Merlijn Sebrechts <merlijn.sebrec...@gmail.com> > 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
