09:00:25 <oneswig> #startmeeting scientific_wg
09:00:26 <openstack> Meeting started Wed Nov 23 09:00:25 2016 UTC and is due to finish in 60 minutes.  The chair is oneswig. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:00:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:00:29 <openstack> The meeting name has been set to 'scientific_wg'
09:00:55 <oneswig> #link today's agenda https://wiki.openstack.org/wiki/Scientific_working_group#IRC_Meeting_November_23rd_2016
09:01:37 <oneswig> Blair says he'll be in-and-out today - you hear yet Blair?
09:02:16 <oneswig> Lets give people a minute or two to gather
09:03:00 <oneswig> #topic Wrap up from Supercomputing 2016
09:03:04 <oneswig> #chair b1airo
09:03:04 <openstack> Current chairs: b1airo oneswig
09:03:18 <b1airo> Howdy
09:03:27 <oneswig> Evening b1airo
09:03:35 <oneswig> Just getting started on SC wrap-up
09:03:48 <b1airo> Kewl
09:04:02 <oneswig> Well it was a good show, my first time.  The level of OpenStack interest was high but I have no prior experience to gauge the upward trend
09:04:06 <b1airo> I only got home from SLC yesterday!
09:04:16 <oneswig> Go by bike? :-)
09:04:41 <b1airo> Ha! Just left via Bryce Canyon
09:05:01 <b1airo> It was a good conference for OpenStack I think
09:05:14 <oneswig> The nice people at SuperUser invited us to write a trip report based on the roundup I wrote on the company blog
09:05:44 <oneswig> #link http://www.stackhpc.com/stackhpc-at-supercomputing-2016.html
09:05:54 <oneswig> Not massively detailed though...
09:06:29 <b1airo> Heh - are they paying for our expenses? :-)
09:06:30 <priteau> Great job on getting science on the openstack.org homepage!
09:06:36 <oneswig> priteau: Kate did a great job in the panel session, it was good to meet her again
09:06:45 <oneswig> priteau: I know - incredible isn't it!
09:07:17 <StefanPaetowJisc> Good morning all
09:07:17 <priteau> Will you get statistics on number of book downloads?
09:07:18 <oneswig> So quite a few expectations to live up to there
09:07:22 <oneswig> morning StefanPaetowJisc
09:07:36 <verdurin> Morning.
09:07:39 <oneswig> priteau: I expect I could ask, that would be good to know
09:07:45 <oneswig> Hi verdurin
09:08:21 <oneswig> I don't think there was any more to add on SC - anyone else?
09:09:00 <oneswig> OK lets go to the next item
09:09:04 <oneswig> #item Scientific datasets - update from Sofiane
09:09:09 <oneswig> #topic Scientific datasets - update from Sofiane
09:09:10 <oneswig> oops
09:09:11 <sofianes_> hi all
09:09:19 <sofianes_> I just shared a document with you
09:09:24 <oneswig> Hi Sofiane, how are you doing
09:09:34 <sofianes_> https://goo.gl/Rqb9qg
09:09:53 <sofianes_> There's a summary of what we are doing
09:10:20 <sofianes_> We are building an academic cloud for Swiss Universities
09:10:44 <sofianes_> and have numerous services on top of the infrastructure
09:10:50 <sofianes_> which runs on OpenStack
09:11:11 <sofianes_> SWITCH is hosting and operating the infrastructure
09:11:34 <sofianes_> among the applications, we have big data and data science in general
09:11:41 <sofianes_> and we need to host large datasets
09:11:55 <sofianes_> compute has to be done close to the data
09:12:13 <oneswig> What do you expect the interface to be for users seeking access to specific datasets?
09:12:39 <sofianes_> direct access from any application susing S3 or SWIFT
09:12:56 <sofianes_> or specific access with higher level APIs
09:13:39 <oneswig> Are you thinking of creating a directory service?
09:13:57 <sofianes_> We will definitely build a catalog
09:14:05 <sofianes_> with appropriate search functionalities
09:14:35 <oneswig> Do you expect it to be integrated with Horizon, or a separate freestanding catalog?
09:14:35 <sofianes_> but there are many things that need improvment in the OpenStack ecosystem
09:14:39 <verdurin> sofianes_: the higher level APIs are for applications that don't understand objects?
09:14:46 <sofianes_> Sahara, bare emtal
09:14:50 <sofianes_> bare metal
09:15:09 <sofianes_> verdurin: yes
09:15:56 <sofianes_> we are also thinking about the possibility to co-host datasets
09:16:03 <sofianes_> with other interested insititutions
09:16:23 <sofianes_> saverio has already initiated that with other NRENs
09:16:30 <oneswig> Do you also expect to provide access control to the datasets or can every user access every dataset all the time?
09:16:38 <sofianes_> both
09:16:46 <b1airo> IMHO this sort of hosting may be better served by something like CVFS
09:16:49 <sofianes_> public data will be open
09:16:59 <oneswig> b1airo: new to me, got a link?
09:17:01 <verdurin> sofianes_: do you have details on what's missing for your use-case, that might be turned into blueprints?
09:17:01 <sofianes_> private data will requires ACLs
09:17:08 <verdurin> b1airo: do you mean CVMFS?
09:17:21 <oneswig> As in CERN VM FS?
09:17:22 <b1airo> It would offer a more familiar interface for legacy applications and is already designed to distribute data around the Internet
09:17:32 <b1airo> Yes, CVMFS sorry
09:17:39 <sofianes_> I am not famililar with CVMFS
09:17:44 <sofianes_> but will look at it
09:18:19 <sofianes_> performance is very important
09:18:19 <b1airo> And I should clarify - I don't mean instead of Swift, but as potential complim
09:18:36 <b1airo> *compliment (sorry, on phone)
09:18:49 <sofianes_> the direction in which we will go will be directed by the use cases
09:19:04 <oneswig> sofianes_: my understanding is that it is an HTTP-delivered filesystem overlay.  The particle physics people use it with a minimal VM image to attach specific code/data - right?
09:19:20 <sofianes_> we have aleady posted a bug report for sahara
09:19:23 <verdurin> oneswig: yes, that's right
09:20:02 <verdurin> oneswig: it has wider uses than that, i.e. not just for Micro-CernVM
09:20:10 <sofianes_> our typical use cases come from machine learning, text analysis, genomics
09:20:16 <oneswig> sofianes_: I notice billing in the SWITCH diagram - any plans to charge for access?
09:20:28 <sofianes_> we have two directions
09:20:43 <sofianes_> either have the datasets as an added value to attract users
09:21:00 <sofianes_> or build a market place for data (not trivial)
09:21:35 <sofianes_> oneswig: could you tell us more about the paricle physics use case?
09:21:53 <oneswig> I don't know if there is a precedent for charging for datasets, might be problematic...
09:22:09 <sofianes_> Microsoft is actually doing that on Azure
09:22:12 <oneswig> I agree - good to have them as an attractor to your platform (which might then be charged for in usual ways)
09:22:33 <oneswig> sofianes_: interesting!
09:22:37 <StefanPaetowJisc> Possibly cross charging...
09:22:48 <sofianes_> it makes sense for commercial applications where you consume data and sell services. You basicaly act as a broker in that case
09:22:58 <oneswig> sofianes_: I'm not sure I have a link to CVMFS - anyone?
09:23:00 <StefanPaetowJisc> *nod*
09:23:18 <sofianes_> https://cernvm.cern.ch/portal/filesystem
09:23:34 <StefanPaetowJisc> https://wiki.gentoo.org/wiki/CVMFS
09:23:35 <verdurin> sofianes_: they have a minimal VM image that pulls in experiment-specific software via CVMFS
09:23:35 <sofianes_> this?
09:24:40 <verdurin> So in WLCG it's primarily used for distributing software, but could be used for datasets too
09:25:05 <sofianes_> there are also alternatives to expose S3 as a file system
09:25:13 <oneswig> WLCG?
09:25:20 <verdurin> worldwide LHC computing group
09:25:22 <StefanPaetowJisc> Especially since it's read-only... :-)
09:25:32 <oneswig> 2 level acronym!
09:25:40 <sofianes_> like this: https://github.com/s3fs-fuse/s3fs-fuse
09:25:40 <verdurin> De rigeur.
09:25:57 <StefanPaetowJisc> Damn that HEP community... :-D
09:26:11 <verdurin> sofianes_: I'm sure I came across a US group that was using it for data, but can't remember where right now
09:26:20 <verdurin> (i.e. a non-HEP group)
09:26:30 <sofianes_> if you find out, please let me know
09:26:40 <StefanPaetowJisc> verdurin: possibly Jim Basney's group?
09:26:45 <sofianes_> we are open to collaboration/sharing experience
09:26:47 <StefanPaetowJisc> I can ask
09:26:58 <b1airo> We could ask Tim et al
09:27:09 <oneswig> What do Globus do in this area?
09:27:25 <oneswig> #link https://www.globus.org/
09:27:54 <sofianes_> our interest is not only about making data available for download
09:28:05 <sofianes_> but mainly to bring computation to where data sits
09:28:17 <sofianes_> that's at the heart of the hadoop principles
09:28:22 <oneswig> The holy grail...
09:28:31 <priteau> oneswig: they have data publication and discovery capabilities https://www.globus.org/data-publication
09:28:36 <sofianes_> for very large data, it's cheaper to move computation
09:29:05 <priteau> it seems to be a commercial hosted service
09:29:09 <verdurin> Some of the genomics data at Sanger is made available via Globus Connect
09:29:24 <sofianes_> actually we have a mirror of that data
09:29:30 <sofianes_> I want to add one thing
09:29:36 <sofianes_> some datasets are so large
09:29:44 <sofianes_> that you simply can't download them
09:29:53 <oneswig> sofianes_: do you think there is value in a user story here?  I think there could be.
09:30:14 <sofianes_> human genome which can be obtined through Globus is more than 100TB
09:30:29 <StefanPaetowJisc> :-O
09:30:35 <sofianes_> common crawl, which is a crawl of the web is 500+ TB
09:30:52 <sofianes_> this is said for static data
09:31:07 <sofianes_> but we also have users interested in real time data
09:31:15 <oneswig> Hence moving code to the data
09:31:20 <sofianes_> they need to subscribe to streams
09:31:31 <sofianes_> these can be weather or traffic data
09:31:44 <sofianes_> or anything that comes from IOT
09:31:51 <sofianes_> we are also working on such use cases
09:32:25 <sofianes_> we receive data in real time, and users can selecte specific feeds
09:32:42 <sofianes_> data can also be persisted and becomes historical data
09:32:47 <oneswig> What are the gaps in OpenStack or does everything discussed build upon today's OpenStack?
09:33:05 <sofianes_> we have sahara and bare metal
09:33:21 <sofianes_> but solutions don't seem to be mature enough
09:34:03 <oneswig> I haven't heard of anyone using bare metal with swift - does it work?
09:34:21 <sofianes_> ceph and swift have also issues with large objects
09:34:53 <priteau> oneswig: We use Swift from bare-metal instances. There's no reason for it not to work, it's all HTTP requests
09:35:05 <sofianes_> support for hadoop is still not very established
09:35:23 <oneswig> priteau: I guess so - wasn't sure which network they'd be transported over
09:35:58 <oneswig> sofianes_: there was a bug mentioned in Barcelona on Sahara with large objects - any news on that?
09:36:23 <sofianes_> I have nothing new on that
09:36:31 <sofianes_> I will ask saverio
09:36:45 <oneswig> Saverio not here?  Saverio...?
09:37:21 <b1airo> Wasn't that an issue with the related hdfs plugin rather than Swift?
09:37:32 <oneswig> ah, think you're right
09:37:38 <sofianes_> if any of you is interested in our topic, your welcome to contact me
09:37:59 <oneswig> sofianes_: would you be interested in transferring the google doc into a user story?
09:38:07 <b1airo> We are working on deploying Sahara in NeCTAR at the moment too
09:38:28 <sofianes_> yes for the user story
09:38:36 <oneswig> Great, thanks sofianes_
09:38:58 <oneswig> #action sofianes_ to transfer the google doc on data sharing into a user story
09:39:29 <oneswig> b1airo: any comment on how Sahara is working in Nectar?
09:40:24 <b1airo> Main issue we've found is that current version defaults to putting Hadoop job binaries in rdbms
09:41:21 <b1airo> Should be in object store for a large prod cloud, especially where users are not trusted/known
09:41:59 <oneswig> How responsive are the sahara crowd?
09:42:18 <sofianes_> using object as back end for hadoop seems to be the current trned at least in public clouds (AWS, Azure, GCP)
09:42:47 <b1airo> Reasonably, problem is already being addressed
09:42:59 <sofianes_> when you deploy a cluster, storage is embeded in HDFS within the cluster
09:43:17 <sofianes_> using objectr storage is a good compromise to share data
09:43:38 <oneswig> I'd be interested to see performance comparisons, does seem to me to be breaking some assumptions about hadoop (unless I'm misunderstanding it)
09:44:10 <sofianes_> we have that on our roadmap
09:44:14 <oneswig> Anyway, we have other topics, any more on big data & sahara?
09:44:19 <sofianes_> performance  comparison
09:44:22 <sofianes_> S3 vs HDFS
09:44:32 <oneswig> sofianes_: would be interested to see that
09:44:41 <sofianes_> and otjer dimensions as well
09:44:49 <sofianes_> we will share our findings
09:45:01 <oneswig> OK thanks sofianes_
09:45:06 <sofianes_> typo: other dimensions as well
09:45:19 <oneswig> #topic Federation user story up for review
09:45:32 <oneswig> Saverio's not here but there is a WG user story in review
09:45:38 <oneswig> on identity federation
09:45:51 <oneswig> #link https://review.openstack.org/#/c/400738/
09:46:40 <oneswig> Please comment if it's an area of interest for you - I recall aloga had some questions about the original etherpad this user story came from
09:46:57 <StefanPaetowJisc> I'll have to review that story again...
09:46:59 <b1airo> Cool - I will seek input locally
09:47:24 <oneswig> Great!  Want to make sure it's consistent with global experience
09:48:02 <oneswig> Don't think there's any more to cover on this... anyone?
09:48:47 <oneswig> #topic Cloud workload traces
09:49:05 <oneswig> Late addition to the agenda - b1airo want to cover this?
09:49:41 <aloga> sorry guys, I arrived late
09:49:50 <oneswig> Hi aloga
09:50:02 <b1airo> Sure - briefly
09:50:15 <oneswig> aloga: Got backscroll?  Feedback here: https://review.openstack.org/#/c/400738/
09:50:28 <aloga> oneswig: yes, I was catching up
09:51:13 <b1airo> Kate Keahey's BoF at SC raised the topic of getting cloud workload traces for ComSci work (e.g. scheduling simulation etc)
09:51:35 <oneswig> Is this infrastructure or higher-level?
09:51:44 <aloga> oneswig: I will go through the review and comment there, I still have concerns about the 2nd use case that is described there (i.e. L156-160)
09:52:17 <aloga> i.e. who will benefit from that use case
09:52:36 <aloga> (same applies for user story 3)
09:52:39 <b1airo> She isn't sure what data they want yet, needs to do a review of existing archives from prior grid work, but we discussed the potential to have the work supported through this community so as to gain wider audience
09:53:03 <oneswig> We have a project for OpenStack distributed profiling.  For user applications, how about http://zipkin.io/
09:53:22 <oneswig> ... which I would also love to see ...
09:54:33 <oneswig> b1airo: I'd love to hear more, hopefully we can do a monitoring & telemetry session next week and she might attend?
09:54:56 <b1airo> Yes we need to invite her or a team member
09:55:11 <oneswig> ... know anyone ... ? :-)
09:55:42 <priteau> oneswig: I am not sure we are on the same page, the traces we have in mind are the equivalent of job traces in hpc, ie instance creation / update / termination events
09:56:28 <b1airo> priteau: yes that's what I thought, at least for initial data
09:56:34 <oneswig> priteau: possibly more on the same page than you think!  We've been looking at connecting SLURM with Monasca
09:56:35 <b1airo> So e.g. nova-scheduler logs
09:56:54 <oneswig> So this is infrastructure event tracing?
09:56:59 <b1airo> But the more data the better I assume
09:57:28 <oneswig> Now I am even more interested.
09:57:58 <priteau> oneswig: I was referring to your link to zipkin which seems to be more about inter-service call timings?
09:58:12 <oneswig> OK, I previously took an action to define our use case - will do that for next week
09:58:24 <oneswig> priteau: wasn't sure if you were looking at infrastructure or application profiling
09:59:23 <oneswig> we are looking at profiling "infrastructure-plus", ie a bit of the stuff above
10:00:13 <oneswig> #action oneswig to write up the profiling telemetry use case for next wee
10:00:18 <verdurin> Have to go - bye.
10:00:18 <oneswig> ahem. week
10:00:23 <oneswig> out of time!
10:00:37 <oneswig> Thanks all, we'd better clear the channel
10:00:38 <aloga> priteau: we are interested on that
10:00:52 <oneswig> #endmeeting