Making the HydraShare Platform More Resilient

@chris I just had a really confusing moment when I saw that your hydra link referred to my github:

…even though I’m not the one who uploaded that file.

Here’s what happened, yesterday I synced my hydra head fork with yours, (so I could have a local copy of all the grasshopper scripts) forgetting that my fork would then upload/sync(?) files to the main hydra website. So, for about a day, all your hydra contributions on github had been overwritten by my fork.

It was only after seeing your post that I realized what I did. So I just deleted my fork, and it looks like the hydra website has restored you as the author of these files.

And here’s the correct link:

http://hydrashare.github.io/hydra/viewer?owner=chriswmackey&fork=hydra_2&id=Full_Building_Energy_Simulatio

Lesson learned: don’t mess around with hydra forks.

S

@SaeranVasanthakumar,
Thanks for catching this and I hope that you don’t mind that I moved this to a new topic. I fixed my link on the old discussion so that we can talk specifically about what happened to hydra here.

I was wondering why we had duplicates of all of the files on Hydra for the past day and I see now that we have nothing to guard against the case where someone creates a fork of their own Hydra fork. This is something that we should definitely fix when we remake the hydra platform after hitting our next Patreon goal (if not sooner).

@mostapha, let me know if I am correct in categorizing this issue under ladybug-tools and not somewhere else. It would be good to just have a record of all of the things that we want to change on Hydra when we get around to re-doing it.

-Chris

@chris I agree it’s a good idea to make this a separate discussion. I’m sure I won’t be the only one who will break Hydra like I just did : -)

Also, I think it would be really useful if we could fork someone else’s Hydra repo without creating duplicates from a workflow perspective. I really like the idea of syncing changes across forks, and git pulling updated Hydra files into my local drive. That way we can interact with Hydra totally through our command line, which would be so much more efficient!

-S

There should be a way to separate direct forks and forks from forks using the GitHub API but we never considered it as a case. That is a bug! :thinking:

Kieth has started doing some explorations to improve Hydra. I invited him to this discussion so he can update all of us and we can continue the conversation afterwards.

@mostapha @chris @SaeranVasanthakumar

Hey Guys!

Sorry for the delay, I was on vacation last week. A few weeks ago I setup a little sample for authenticating GitHub users using OAuth2. Once the user logs in and grants the Hydra GitHub Application permission they receive a token. This token maximizes the amount GitHub API requests (which is a problem we frequently run into now) and should grant us greater freedoms to directly make modify a users repo via the website.

The next step would be to integrate this sample into the current platform. Once we have the ability to make API requests on the users behalf we should be able to circumvent the issue described above.

If this is something you guys would be interested in moving forward with I also suggest we move everything to AWS. I am doing the OAuth via an API Gateway that can simply be invoked through Lambda functions. My initial thought was that Hydra could operate as a microservice following a FAAS (functions as a service) flow. If we move the DB to DynamoDB the whole ecosystem should play very nicely and would be more robust and scalable than the existing architecture.

For more info on serverless architecture check this out