Apache Zeppelin

[guillau...@gmail.com]

Hi guys,

first of all, let me tell you I love what you are doing. Sandstorm is just a gigantically good idea taking form.

In case you lack ideas for packaging new apps (which I'm sure you are not), please consider Apache Zeppelin as a candidate. It would be a great fit in the current app app market as it is gaining momentum along with Spark (https://zeppelin.incubator.apache.org).

Keep up the good work.
Guillaume .

[Asheesh Laroia]

Hi Guillaume !

Thanks for emailing. You're very kind to say such appreciative things!

I've added it to the list. I should also say - if you want to package it yourself, I'd be very very happy to help you. Are you possibly interested? (-:

https://docs.sandstorm.io/en/latest/vagrant-spk/packaging-tutorial/ is the link to the tutorial, and you're always welcome to email me for help or with questions.

--
You received this message because you are subscribed to the Google Groups "Sandstorm Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sandstorm-de...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Guillaume Giles]

Hi, 

I had a look at those docs and gave a try at running Zeppelin in Sandstorm. I am almost there, but I'm stuck with a web socket connection, so maybe you could help. 

Here's what I've done so far:

  - install the vagrant-spk kit

  - created a sandstorm dev VM in virtual box

  - install zeppelin application which is based on java Servlets

I can start the application with vagrant-spk dev and launch it by creating a grain. The problem I have is the HTML UI fails to load completely because a web socket connection cannot be established (this is what I see from the browser). 

If I ssh to the vm and launch zeppelin from the command line, I can connect to port 8000, including the web socket,  and it works like a charm. 

Is there any trick for using web sockets with the Sandstorm HTTP bridge, or any way to hook into the container so I can troubleshoot what is happening on the app side ? 

Thanks for your help.

Guillaume    

---

From: Asheesh Laroia <ash...@sandstorm.io>
Sent: Friday, February 5, 2016 8:32 PM
To: guillau...@gmail.com
Cc: Sandstorm Development
Subject: Re: [sandstorm-dev] Apache Zeppelin

 

Hi Guillaume !

Thanks for emailing. You're very kind to say such appreciative things!

I've added it to the list. I should also say - if you want to package it yourself, I'd be very very happy to help you. Are you possibly interested? (-:

https://docs.sandstorm.io/en/latest/vagrant-spk/packaging-tutorial/ is the link to the tutorial, and you're always welcome to email me for help or with questions.

Packaging tutorial - Sandstorm docs.sandstorm.io Packaging tutorial (Generic) Style: Hands-on introductory tutorial. This tutorial will show you how to package an app for Sandstorm in five minutes.

[Asheesh Laroia]

Hi Guillaume! Great that you got so far. Thanks for trying this; Sandstorm is a bit of a strange platform, mostly in ways that have positive long-term effects, but it results in some pain for app packagers. We're always trying to decrease the amount of pain that Sandstorm app packagers experience.

If you're willing to, could you give a link to the .sandstorm/ directory, perhaps by posting it on GitHub? That helps us make sure we're seeing the same thing you're seeing.

WebSockets are generally supported fine, so that's probably a symptom of some deeper underlying difficulty. What does the contents of the grain log say? See https://docs.sandstorm.io/en/latest/using/top-bar/ for information on how to get access to the grain log.

You can hook into the container by following these somewhat roundabout instructions: https://github.com/sandstorm-io/vagrant-spk/issues/56

The most important thing for me is if you can let me know the contents of the grain log - my guess is there's some deeper insanity that the grain log will help us see.

[Guillaume Giles]

Thanks for the quick reply. I'll try to give you more info tomorrow when I'm back in the office (night time already in Europe :-) )

The grain log looks good. I actually tweaked that a bit with a tail of Zeppelin logs. No problem there. 

I investigated a bit more after sending you my message and spotted an error in the sandstorm logs. From the top of my head, the message says that the app doesn't support web sockets (error 101) and the cause is Forbidden (403).

I looked for that error message I the sandstorm bridge code but I'm afraid I'll have to spend more time understanding what it is supposed to do.

I'll try to look more tomorrow and post the whole thing on github if I cannot progress.

Have a nice day.

[Asheesh Laroia]

Error 101... hmm. I wonder if we managed to break websockets while we weren't looking... or... are you using nginx, I wonder, in front of Sandstorm? If so, see https://docs.sandstorm.io/en/latest/administering/reverse-proxy/ - and look specifically at the sample nginx configuration for websockets mumbo-jumbo.

[Guillaume Giles]

No, there's no ngnix in front. I tried to put one between the sandstorm bridge and Zeppelin at some point but it didn't help.

[Guillaume Giles]

Hi Asheesh,

I investigated a bit more and it appears the 403 message is generated by the application server (jetty) when the client try to establish the web socket connection. I then sniffed the network in and out the sandstorm bridge and realised it is tempering with the Sec-Websocket-Key header. You can see the http requests in the attached files. The funny thing is the client tries several times to establish the ws and generates new sec key value each time. On the other side of the sandstorm-bridge, there's always the same value.

I'm not very familiar with the web socket implementation in Jetty, but don't you think altering the WebSocket Key value along the way could cause troubles and lead to some sort of security breach? 

Cheers,

Guillaume 

---

From: Asheesh Laroia <ash...@sandstorm.io>
Sent: Thursday, February 11, 2016 7:48 PM
To: Guillaume Giles

Cc: Sandstorm Development
Subject: Re: [sandstorm-dev] Apache Zeppelin

Error 101... hmm. I wonder if we managed to break websockets while we weren't looking... or... are you using nginx, I wonder, in front of Sandstorm? If so, see https://docs.sandstorm.io/en/latest/administering/reverse-proxy/ - and look specifically at the sample nginx configuration for websockets mumbo-jumbo.

Reverse Proxy - Sandstorm docs.sandstorm.io This document helps you serve Sandstorm with HTTPS and take the port (6080) out the URL. nginx will listen on port 80 to redirect HTTP to HTTPS on port 443.

[Guillaume Giles]

Second thought, 

  the issue could also be related to the fact the Origin header is removed by the sandstorm-bridge. 

Cheers.

---

From: Guillaume Giles <g_g...@outlook.com>
Sent: Friday, February 12, 2016 10:21 AM
To: Asheesh Laroia

[David Renshaw]

On Fri, Feb 12, 2016 at 4:58 AM, Guillaume Giles <g_g...@outlook.com> wrote:

Second thought, 

  the issue could also be related to the fact the Origin header is removed by the sandstorm-bridge. 

Cheers.

I think the Origin header is the likely culprit.

I opened a pull request that makes sandstorm-http-bridge fill in that header: https://github.com/sandstorm-io/sandstorm/pull/1524

- David

 

[Guillaume Giles]

Yes, I can confirm that. 

I was able to replicate the issue outside of sandstorm by removing the Origin header. 

---

From: David Renshaw <da...@sandstorm.io>
Sent: Friday, February 12, 2016 3:17 PM
To: Guillaume Giles
Cc: Asheesh Laroia; Sandstorm Development

Subject: Re: [sandstorm-dev] Apache Zeppelin

[Guillaume Giles]

Hi,

I've installed an nginx reverse proxy in front of Zeppelin which is adding an Origin header. This seems to fix the problem.

I'm now hitting another problem related to the IP stack. Java tries to resolve the local hostname and throws the exception java.net.UnknownHostException: sandbox

I then wrote a little test program in C calling the gethostbyname and getaddrinfo and both are failing. I guess is is another restriction in the sandstorm container. Is there anyway to workaround this one ?

Thanks.

Guillaume 

---

From: Guillaume Giles <g_g...@outlook.com>
Sent: Friday, February 12, 2016 4:18 PM
To: David Renshaw

Cc: Asheesh Laroia; Sandstorm Development
Subject: Re: [sandstorm-dev] Apache Zeppelin

[David Renshaw]

That `java.net.UnknownHostException` may be due to the Host header being set to "sandbox".  Does the exception only occur for API requests? For some related discussion, see this issue with this resolution.

- David

[Asheesh Laroia]

One option is to create an /etc/hosts file that says:

127.0.0.1 localhost sandbox

​

But make sure to also modify .sandstorm/sandstorm-pkgdef.capnp to make sure you don't have it in hidePaths.

But I don't know how far that will take you.

(Presumably we should stop doing hidePaths /etc/hosts within vagrant-spk?)

[Guillaume Giles]

Thanks guys ! After removing the /etc/hosts from hidePath it is now working.

I can now start playing with Zeppelin in Sandstorm.

---

From: Asheesh Laroia <ash...@sandstorm.io>
Sent: Tuesday, February 16, 2016 6:38 AM
To: Guillaume Giles; sandst...@googlegroups.com

Subject: Re: [sandstorm-dev] Apache Zeppelin

[Asheesh Laroia]

Awesome.

The usual next step is to send a package to sandstorm-dev for feedback, if you're willing! Let me know if you want help before that point, or just go ahead and do it. (-:

[Guillaume Giles]

Hi, 

I've hit another issue related to users when starting the spark interpreter. I don't have much time to look at this now but maybe next week.  

---

From: Asheesh Laroia <ash...@sandstorm.io>
Sent: Wednesday, February 17, 2016 6:08 PM
To: Guillaume Giles
Cc: sandst...@googlegroups.com

Subject: Re: [sandstorm-dev] Apache Zeppelin

[Asheesh Laroia]

You might need to similarly remove etc/hosts from the file blacklist!