17:59:35 #startmeeting next-cloud-next-steps 17:59:35 Meeting started Tue Aug 27 17:59:35 2019 UTC. The chair is gaba. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:35 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:59:37 Hi! 17:59:41 Hey Have I joined? 17:59:43 who is here for the nextcloud meeting? 17:59:47 yes sabt :) 17:59:50 I am! 17:59:52 gaba: o/ 17:59:53 o/ 17:59:54 Wow first time! 17:59:55 o/ 17:59:56 hey 18:00:01 <- 18:00:11 nice! 18:00:24 agenda and refeferences are here: https://pad.riseup.net/p/A3KznPZJy4ZOpqSXEwT5 18:00:29 note: this channel is being logged, contents might be published on the internets 18:00:49 the goal for this meeting is to discuss pros/cons of nextcloud and figure out how/if to move forward with it 18:00:51 thanks ln5 18:00:59 nextcloud as a replacement for storm.torproject.org 18:01:16 I added a few user cases in the pad and a places for pros/cons 18:02:12 gaba: are these strictly for nc vs. storm? 18:02:12 i guess the kanban is better as well compared to what we have at storm? 18:02:13 Maybe we can start talking about pros and cons of nextcloud for people that have been using it since it was presented by ln5. 18:02:37 i'm thinking about the decision tree here 18:02:39 ln5: were you thinking about any other use outside of what we use in storm? there is the issue of replacing gdoc as much as possible 18:03:13 GeKo: kanban is better but not good enough in nextcloud 18:03:35 GeKo: we are thinking that gitlab could be a better kanban that replaces the storm one. 18:03:47 specifically, re cons, is that a comparison against storm or gdoc? or: do storm have collaborative editing? 18:04:34 the collaborative storm app is not good at all. 18:04:39 ok 18:04:53 gaba: fine with me as this makes the nc instance have one app less 18:05:01 and less attack surface etc. 18:05:16 is everyone using storm for kanban things migrating to gitlab? 18:05:17 and a non-official one too 18:05:24 yeah 18:05:26 we have to things: 1) nc replacing storm as the first priority 2) onlyoffice in nc possible replacing the use of google docs at some point. 18:05:40 good 18:05:44 GeKo: at metrics, network and anti-censorship we are moving out of storm for kanban 18:05:47 i wonder if there are users of the storm kanban that would not be gitlab kanban users 18:05:58 how so? 18:06:22 there could be non-coding folks tracking tasks in kanban 18:06:33 the nc app for kanban boards is very simple. It could be used if anybody needs to use it for something that is not related to specific tickets. 18:06:52 yeah 18:07:03 but i guess we can cross that bridge if needed 18:07:07 yes 18:07:09 so, seems good 18:09:19 does anybody have any other use case and pros or cons to add to the pad? 18:09:50 heya - i’m here, just have a spotty connection 18:09:55 i've never been a storm user, so i don't have much pros/cons to contribute 18:10:57 i don’t have anything else to add to the pad 18:11:08 one thing that I would have to have back in nc is the etherpads 18:11:22 gaba: did they work well? why did they go away? 18:12:51 not sure why they go away. We use a lot the pads. We use them in pad.riseup.net but it would be good to have pads in nc to use those and store some of them longer time 18:13:10 not sure whey they *did* go away 18:13:13 i can see the upsides 18:13:29 anybody else knows? or i'll try to find micah online. 18:13:39 micah may be the best to check 18:14:06 i thought pad.riseup.net had some short default expiration times for pads? 18:14:32 About cons of nc, it seems to me that we are ready to have nc instead of storm. For the case of needing collaborative editing with track changes and comments system, we can still temporary use gdoc until onlyoffice gets what we need. 18:14:34 in the meantime, is that a showstopper for the decision of whether to storm->nc or not? 18:14:44 i do not think so 18:14:51 catalyst: it does 18:14:53 gaba: sounds good to me 18:16:10 gaba: i think that's a reasonable conclusion, unless there are some major objections 18:16:14 those should be raised now 18:16:18 bdavila, sabt, alsmith, sstevenson: are you ok of us moving to nextcloud instead of storm? 18:16:25 yes 18:16:36 yes 18:16:44 I rarely used storm 18:16:51 +1 18:17:27 yes, for the fundraising team nc can have anything that we may not need to store long term in granthub 18:17:56 ggus: hi! are you here for the nextcloud meeting? 18:18:48 gaba as it is rn i see nc as a place to store ‘finished’ / static docs 18:18:51 yes 18:18:53 yes 18:19:21 I rarely used storm as well 18:19:48 we use the shared calendar a lot and that can be much better in nc 18:20:08 alsmith: but for Grants anyways, isn't that what GrantHub is for? 18:20:24 gaba: can be but isn't right now? 18:20:46 ln5: shared calendars works fine in nc 18:20:52 ok good 18:21:10 ln5: how we would go with the migration of stuff stored in storm? 18:21:49 sabt yes. 18:22:24 gaba: that's going to be interesting 18:23:24 we need someone with a decent overview of what we've got there. then we need someone with some technical skills to try to automate the move as much as possible. and then somone to doublecheck most or some of the results. some of these roles could be filled by the same individual. 18:23:35 we use the calendar and some people (like mikeperry) have kanban boards 18:24:00 i first attempt would be to ask people to try to move their own stuff, with some technical help 18:24:07 +1 18:24:08 s/would/could/1 18:24:27 I think that could be the best. Give some time for people to move things. 18:24:54 small amounts of some type of data could be done manually, by the owner (if there is one) 18:25:13 we'd have to start with listing all the _types_ of data in storm 18:25:34 and then look for migrations tools, if it's more (kind of) data than what can be cut'n'pasted 18:25:46 I wonder if there is a way to download and keep somewhere all the docs in storm. 18:26:04 calendars is an example of non-cutnpastable, but they usually have export/import functionality reachable by the calendar owner 18:26:42 but maybe this is its own topic -- migration 18:27:16 we've got to have a nextcloud instance to move to, to begin with. which might not have to be discussed here though. 18:27:32 ohh, we are not going to use the riseup one? 18:27:38 i hope not 18:27:52 we're sharing that with non-tor people. i don't think that's optimal. 18:28:04 also, we might want to run the instance on our own infrastructure. 18:28:11 but we also might not want that. 18:28:30 ok. That could be a converation to have with anarcat and sysadmin team then. 18:28:47 yes 18:28:51 assuming that we are moving forward with next cloud replacing storm, next steps? 18:29:00 and whoever-holds-the-dough 18:30:18 for the record, we might want to get this service from someone else. riseup would be one strong contender, if they want to provide it in a way that we like. 18:30:45 1ok 18:31:12 1. Fill a ticket to decide on own nextcloud instance versus an instance from someone else like riseup. 18:31:18 2. Migrate all used files from storm into nextcloud. The migration will happen by its owners, for data that does have an owner. 18:31:27 and 3, turn off storm :) 18:32:01 gaba: i just ruined the list by inserting a new #2 18:32:07 micah: yay! 18:32:07 (i guess there will be a 2a) and 2b) etc. :) 18:32:19 hi, sorry I'm late. construction on my street cut my power :( 18:32:26 hihi 18:32:42 micah: so now you're powering your gear using a rebuilt bicycle? 18:32:59 micah: do you know why pads disappeared from nc.riseup.net? 18:33:08 etherpad like things 18:34:23 how are pads being created? 18:34:34 gaba: ^ 18:34:48 it is a type of document 18:34:58 we were using them when we started using nc.riseup.net 18:35:16 that type of document only existed for about a week when I was trying that pad plugin integration 18:35:17 it said 'New pad' when creating a new file 18:35:22 yes 18:35:23 that 18:35:26 i dont think it is there anymore 18:36:01 the reason why it was removed was because the riseup pad deletion policy, makes it so pads will disappear from NC, but still be there, and cause confusion 18:36:10 which is what you are talking about, I suspect 18:36:41 riseup pads are removed by default in 60 days if they are not changed, unless you pick a different deletion policy when you create the pad 18:37:14 which does not work well with nextcloud, to have the pads be removed underneath nextcloud, because the "files" still appear in NC, but the pad contents are gone 18:37:15 oh, I see 18:37:15 ok 18:37:53 micah: can the implementation of that policy be improved to use "some NC api" to remove pads? 18:38:11 it was something I experimented with and didn't think was on when tor started using the NC install, so I'm sorry if you got bit by that... but if its something that is useful, we could consider making a permanent pad that wont be deleted ever, and hook the plugin into creating those 18:38:53 ok. I think we are ok with pads right now. We can add it later if needed. 18:38:58 ln5: the pad system is completely independent of NC, and has a tight deletion policy that is handled outside of NC, so its totally isolated from NC 18:39:07 it is not a blocker to move into nc 18:39:08 gaba: +1 18:39:28 i was afraid of exactly this problem where people would be surprised to find disappearing pads :( 18:41:02 (are there logs from this meeting, so I can see what I missed?) 18:41:14 micah: i see. perhaps it could learn how to delete "pads in NC" too? i guess that today its action is "rm $file" 18:41:49 ln5: i think that if pad integration is something desired, then we could come up with a strategy at that point that meets everyone's needs 18:42:04 wonderful 18:42:16 micah: the meeting bot is running, so yes. but i don't know where. 18:42:24 and perhaps not accessible yet 18:43:11 It seems that the decision is to move forward with trac. ln5: do you mind creating a ticket for next step? we can close #30869 18:43:25 http://meetbot.debian.net/tor-meeting/2019/tor-meeting.2019-08-27-17.59.log.txt <-- meetbot minutes 18:43:30 s/trac/nc/ 18:43:39 hehe 18:43:40 yes 18:43:43 ;) 18:43:54 but i know you want to move forward with *that* one, too :) 18:44:11 gaba: will create a ticket for next steps 18:44:15 thanks! 18:44:26 about #29415 we still have the stuff of replacing SVN 18:44:34 but I think that is a decision that people can make later 18:45:58 it sounds like the plan is to have tor have its own NC instance, and to migrate to that one, instead of continuing to use the 'shared' one of riseup. 18:46:32 micah: i suggested that since it's been discussed before, but i'd like to hear more ppl say something on that before we decide 18:46:33 i think that's one option 18:46:44 micah: what do you think about keeping tor in your current instance? 18:47:29 riseup is happy to continue with what is there now, but we are also happy to setup and manage a separate NC instance that would be exclusive to tor as well 18:47:40 that's good news 18:47:54 do you even have cost estimates for that second option? 18:47:59 i know i'm asking a lot 18:48:04 we are also happy to help if tor wants to have a service admin run NC internally or something, as well 18:48:16 so many options :) 18:48:27 micah: great! 18:48:28 and all good ones! 18:48:31 indeed 18:48:40 we are also happy if everyone wants to go have a swim 18:48:47 lol 18:48:48 hmm 18:49:13 ok, riseup is generally happy 18:49:14 that's good 18:49:15 cost estimates, I would expect it wouldn't be very different from what tor is paying now. 18:49:32 sounds good 18:49:33 that's a great answer 18:49:49 thanks 18:50:09 the differences from how things are now are: 1. migration work; 2. managing two instances; 3. allocating resources for a second instance 18:50:09 anything else? 18:50:23 micah: setup work? 18:50:40 yeah, I was kind of thinking #3 would include the setup work, but yeah, that is part of it 18:50:55 i think gaba asked about it above, but there is any chance to download all storm docs? and also are you planning to set a deadline for it? 18:50:56 makes sense 18:51:27 antonela: who knows most about storm? maybe tjr knows some? 18:51:43 and yes, without a deadline it won't happen, will it? :) 18:51:47 I think that #1 will be ok, because we call can work on it together; #2 isn't really a big issue, as I've got the management of instances more or less automated now; #3 is basically the same as how it is now, just on a separated machine, which brings a little overhead (and the setup) 18:52:19 In5 - maybe?, re:deadline agreed 18:52:24 micah: automation finally pays off! i'd like to thank riseup for a lot of things. this is one of them. <3 18:52:46 we could have 1 year for moving stuff into nc until we shutdown storm 18:53:02 and have a header in storm with the deadline for people to move things 18:53:20 personally, my experience with getting people to move things is the more time you give them, the less likely it will happen 18:53:52 and the more often you will need to ping/remind people to do it 18:53:53 2 days then? :P 18:53:59 micah: would you be able to set up a separate instance ~(within weeks) or does it take more time? 18:54:11 :D on the other side.... the less time you give people, the less likely as well haha 18:54:30 ln5: definitely could do it ~(within weeks) 18:54:30 gaba: there _has_ to be a number between 2 and 365 that we can use :) 18:54:35 micah: thanks 18:54:46 any idea how much dataz is on storm? 18:55:02 * ln5 shrugs 18:55:15 any idea who might have a clue about how much data is on storm? :) 18:55:29 isis? 18:55:30 I'm pretty sure we are barely using storm right now. 18:56:06 ok, so in that case... I would recommend this: 18:56:31 1. notify storm people that its being closed down, and they will need to move their stuff. Do not create new things in storm 18:56:40 2. the "real" tor NC is setup 18:57:07 3. storm people are told that they have 2 weeks to move anything off of storm to NC, and then it will be shutdown 18:57:43 4. storm is shutdown, but the data and install is left untouched for 6months-1year, and someone is tasked with hand cranking it alive when someone realizes they have a document there that they didn't move 18:58:08 5. after a year, its put into some backup and the service is removed 18:58:12 6. there was much rejoicing 18:58:24 sounds like a good plan to me 18:58:31 sounds good to me 18:58:32 #1 and #2 can happen in parallel 18:58:52 +1 to the plan 18:58:54 #6 can start early 18:58:59 * micah wonders who put him in enumeration mode? Was it: ln5, gaba, or GeKo? 18:59:07 * GeKo hides 18:59:35 ok, we're at 1h 18:59:38 :) 18:59:39 ok 18:59:44 it seems that we are good and have a plan 18:59:47 thanks for doing it folks <3 <3 18:59:54 thank you all 19:00:05 thanks! 19:00:06 thanks! 19:00:10 #endmeeting