-
Notifications
You must be signed in to change notification settings - Fork 71
April 27, 2016
This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join. Here is the info:
- Time: 1:00pm Eastern Daylight Time US (UTC-4)
- Dial-in Number: (641) 715-3570
- Participant Code: 304589#
- International numbers: Conference Call Information
- Web Access: https://www.freeconferencecallhd.com/wp-content/themes/responsive/flashphone/flash-phone.php
- IRC:
- Join the #islandora chat room via Freenode Web IRC (enter a unique nick)
- Or point your IRC client to #islandora on irc.freenode.net
- Nick Ruest
- Jared Whiklo
- Ed Fugikawa
- Melissa Anez ✨ 🌟
- Peter Murray
- Diego Pino
- Ben Rosner
- Organize Thyselves
- Project Plan
- Drupal 8 Prospectus
- Sprint discussion
- ... (feel free to add agenda items)
Nick: Now that Nigel's Docker and Ansible stuff is over, we need to talk about how we want to proceed. Breaking things up into tasks. Centers around #182. Splitting stuff out into their own repos. Original intent was to have it all in one module, and we still might get that from sub-modules. Might be a task for the next sprint? Getting the dev branch over into Ansible and maybe Docker. We need to talk about how to break out Camel. This would be a good conversation to rope in Aaron. We have yet to do a release on the Camels tuff and we should soon.
Jared: the clearest split is between microservices and the Drupal stuff. It's all in CLAW right now. We could split it out relatively easily. A third split could be the vagrant stuff. Could also split the camel stuff. It's a lot of splitting given that we didn't want to split to start with, but it's all sort of separate already.
Nick: Notes that no one person is the expert on all of CLAW at this point. It's a bunch of Venn diagrams of expertise. Also, while we can break stuff out and move it around, it would be great to get a stable link for the documentation. Perhaps an islandora.ca url that points to the docs.
Ed: How much is it going to take to maintain the different projects? Ansible, Vagrant, Docker, etc.
Nick: We need to make a decision between the vagrant and bash scripts that Nick built, or Ansible. Thinking maybe we take all of the bash scripts (which will be archived in Git history) and translate those into technical install docs, and put the focus on Ansible from here out.
Peter: has worked with Ansible more than most, but it's a new tool. Likes it for his own work, but not sure if it will be favored by others. Bash is universal, but it's complicated to do what Ansible does more simply. Ansible is straightforward, but quirky if you haven't worked with it before.
Jared: Maybe we should bite the bullet and kill vagrant. Docker and/or Ansible has a lot of features over Vagrant. Vagrant is just simple. It seems like we should be moving to use Docker regardless.
Nick: The way we did the Ansible stuff, you don't need Ansible installed. Easier than vagrant, where getting your local environment up can be a hassle.
Ed: It has to be easy for someone without a lot of experience if we want to get more people on here. This is one reason for #192.
Nick: The cool thing about Ansible is that what Nigel did is take that install folder and port the bash scripts and wrap them in Ansible framework. To run it is the same - you get that same vagrant up feedback, but wrapped in Ansible coloring. Easier to red and with more usable feedback that before. Give it a try and see.
Diego: What's the idea on our end to keep up with Fedora 4 versions? They are coming quickly and are major changes.
Nick: We need coordination around all communities. Jared and Nick are Fedora 4 Committers. Diego taught a Fedora 4 camp. We need to keep in touch with Fedora 4 and know what's going on, and keep track of what we have to do to keep up. The last one, it was as simple as changing the branch number in our config file. We can't be isolated. Hydra is dealing with this more than we are, because of the way they set up ActiveFedora in their gem.
Ed: What are some places where you need people to participate?
Nick: PCDM listserv and github and wiki (and someday website), Fedora Tech, Hydra, APIX, Interest groups (especially the ones shared with Hydra). Basically, where you can. Don't overextend yourself, but do speak up for CLAW where you can. If you want to check in with this group about it, that's cool too.
Nick: Since we're getting more people on the project, this is a good time to take a look at the Project Plan and flesh it out. A section at the bottom titles "priorities" has a list of tasks we will need in the near future. Once we get those in place, a lot of other pieces may be able to fall into place.
Ben: Might want to link in this document by Danny detailing PHP microservices.
Nick: Was planning to drop that whole thing in as an appendix, but it has comments that needs to be resolved and the document owner is on leave for several months.
Diego: It's a good plan, but we need to keep in mind that it's not written in stone. There are some sections here we might (or already have) done something different.
Nick: Could take the doc and move it to Markdown in our docs folder, so it's versioned and we're not stuck on ownership issues. New issue #211 to take care of that. Ben's going to take it on.
Diego: before we move on, a quick conversation about how slim/simple microservices should be. Separation is nice, but when you wan tot make things work, it gets more messy.
Ben: When we hit one of these pages, are we going through layers of microservices to get a page? What are the performance impacts? are there benefits to consolidating? Separation is good, but how many requires are we going through before we deliver a page?
Diego: When we started, the first resource service was one file. Pretty fast. Once we started building applications that work with coding standards, and debugging, and independent parts, we ended up with services that were more complex. At the next stage,t he idea is to reuse as much code as possible, making one service dependant on others. In the end, the idea is not to use every service- just the upper levels ones. But it will still be slower than having one file to everything. How much slower is still a question. What are our expectations?
Ben: Wonders about php 7 too.
Diego: That will makes things much faster. But at the end, putting RDF into Fedora 4is fast. Putting in binaries is faster than Fedora 3, but still slow. Everything we do on that side will be slow. So, no one answer. Wishes we had a way to make services that are simple to code and mix and match, but once we start building more complicated tools, the services will get more complicated, bother the upper and lower level dependencies. For example, LDP is a need in Fedora. It's managed now inside each service. But it's not part of the RDF spec in terms of modelling data, so we don't sync LDP containers to Drupal. Drupal does not need to know anything about LDP, nor should we expose it to LDP. So maybe that whole LDP thing goes into a separate service. So, splitting but reusing code. We don't need an LDP template on every service. Change it once instead of in every service. The choice is more distributed code, or faster performance. For now, our concern is not speed but getting things working, so we can gain collaborators.
Jared: My concern is creating a lot of very thin layers of services. With some, it's plain where we would mix and match, but for some it's less clear. Putting them all as Silex services, we seem to get stuck creating all these webservices. Chullo is built at the bottom so that if you didn't want to have a web service you could us the recommend line. Then we put a resource service on top of it. And then we add a layer for proxies. Now we put another layer on top for "PCDM" concerns? We end up with all of these thin layers that call each other through sub-requests. It's very flexible, but it feels like it's also got the potential for failure.
Diego: maybe we can move a lot of the services functionalities to chullo. Right now it's not being actively developed.
[a lot of great discussion that the notetaker completely missed transcribing and didn't understand well enough to post from memory. Sorry!]
Please have a look at it and comment. Pretty pretty please.
Nigel's work is complete. We have funding leftover. We need to think about what projects we could select where hiring a contract work would be helpful.
Next Week: Nick, Diego, and Melissa will be gone for iCampFL. The CLAW Call soldiers on.
You may be looking for the islandora-community wiki · new to islandora? · community calendar · interest groups · roadmap