14:01:35 #startmeeting fedora-qadevel 14:01:35 Meeting started Mon Jun 6 14:01:35 2016 UTC. The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:35 Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:01:35 The meeting name has been set to 'fedora-qadevel' 14:01:35 #meetingname fedora-qadevel 14:01:35 The meeting name has been set to 'fedora-qadevel' 14:01:35 #topic Roll Call 14:01:51 * kparal is here 14:01:53 who all's ready for some meeting fun time despite the fact that I forgot to send out an announcement? 14:01:58 * lbrabec is here 14:02:20 * mkrizek is here 14:02:33 * coremodule standing by. 14:02:39 * garretraziel is here 14:02:54 * omiday most listening 14:03:45 ok, let's get started, then 14:03:55 #topic Announcements and Information 14:04:03 Does anyone have announcements and/or information? 14:04:18 #info taskotron-trigger sent for package review 14:04:39 #chair mkrizek kparal lbrabec coremodule garretraziel omiday 14:04:39 Current chairs: coremodule garretraziel kparal lbrabec mkrizek omiday tflink 14:05:22 mkrizek: can you do that again now that you've been #chair-ed? 14:05:44 #info taskotron-trigger sent for package review 14:05:47 thanks 14:06:13 that reminds me, I belive that jskladan sent some python library package up for review and AFAIK was looking for sponsor 14:06:29 i thought he was a packager already 14:06:43 he wasn 14:06:46 ah 14:06:46 wasn't 14:09:27 I don't know if this is worthy of an #info but I'm still working on a PoC for some future Taskotron features. Was hoping to have screencasts ready last week, may happen this week but I'm going to be at the cloud FAD tuesday and wednesday 14:09:49 * tflink assumes there's nothing else 14:10:03 moving on to the larger discussion topic 14:10:10 #topic Task Namespaces 14:12:18 why are the qa-devel archives private? 14:13:17 * tflink is looking for a link to the namespace discussion 14:13:22 no idea 14:14:04 tflink: https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org/message/P5UOHY5W7PTEIFPUZB4LEUASBM6CVSZU/ 14:14:08 that's the link to my post 14:14:15 seems we have a mailing list gremlin who sets all the options incorrectly :) 14:14:28 bah 14:14:32 the thread seems to start at https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org/thread/XJTD2KSGDGAYPEQEUJGDTNT2EV42PBE4/#P5UOHY5W7PTEIFPUZB4LEUASBM6CVSZU 14:14:43 * tflink just changed the settings, seems not to have taken yet 14:14:57 #action tflink to make qa-devel@ archives public 14:15:04 Dodji: thanks 14:15:07 np 14:15:28 #link https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org/thread/XJTD2KSGDGAYPEQEUJGDTNT2EV42PBE4/ 14:15:37 i suppose that was auto-linked 14:15:39 oh well 14:15:50 mkrizek: just curious, did you post the blog entry to announce the new tasks yet? 14:16:03 Dodji: not yet, we hit some blockers on that 14:16:09 no problem 14:16:13 one of them is namespaces :) 14:16:16 I was just wondering if I missed something 14:16:19 so, thoughts on the issue? 14:16:24 * Dodji is happy he didn't miss anything :-) 14:16:35 * tflink would like to get this figured out today, if possible 14:17:25 I also think that Dodji made a good point, though - if we're expecting hundreds of tasks, planning to do that without some sort of documentation or ACL service may be ... unwise 14:18:36 not sure about the ACL service but the documentation, definitely 14:19:03 granted, i suspect most of those tasks are going to be associated with a specific rpm or layered image 14:19:32 I've read the emails now. in my opinion, encoding ownership and acl in namespaces allows us to avoid all those extra services, at some cost 14:19:34 not sure we're going to get too many distro-wide tasks 14:19:36 but still, quite KISS 14:20:11 kparal: what if we put the maintainer information in the logs? 14:20:22 IIRC, we're not doing anything with that YAML field 14:20:38 encoding "task meaning" in the namespace (all blocking tasks in one particular namespace) has a similar problem as the problems already mentioned, it might change often 14:20:46 so I'm not a big fan of that 14:20:55 how many blocking tasks do you think we'll have? 14:21:26 * tflink wonders if getting rid of qa.* and putting distro-wide tasks into distro.* would work better 14:22:02 yeah, qa.* doesn't seem to convey any meaning information 14:22:11 other than ownership 14:22:15 originally I proposed group.qa 14:22:17 granted, all this task business is for qa purposes :-) 14:23:07 kparal: do you think that the namespace will be a more clear indication of ownership than if we put "this task is maintained by XXXXXXXX, please address questions to them" in the logs? 14:23:13 I think the ownership should be better documented in a wiki page or something like that for now 14:23:30 because, as tflink put it, I think that ownership concept is quite fluid 14:23:31 tflink: do you think we can make it easily visible? 14:23:34 we do have an ownership field in the formulas 14:23:43 the primary artifact might be something completely different 14:23:47 how will people see our logs? 14:23:56 kparal: why not? it's a required field of the formulas, no? 14:24:11 kparal: aren't they linked from the fedmsgs? 14:24:18 how will people see our logs? 14:24:28 kparal: there is a link to the logs when you receive a notification. 14:24:43 I believe :-) 14:24:45 if someone starts firing off emails without looking at the logs first, I suspect that there's little hope of them figuring out who to contact based on the namespace 14:24:56 Dodji: no, to the primary artifact, which happens to be the main log for our tasks 14:25:21 but not for task-dockerautotest, for example 14:25:39 that's something we could fix, though 14:25:57 yes, I'm just not sure how 14:26:01 link to execdb 14:26:20 it's true that we have a field in formula as well, but I think we don't have a link between formula and resultsyaml submission 14:26:44 why would we need that? 14:26:48 I'm sure it's solveable, it's just seems so... unnecessarily complicated 14:27:07 tflink: to display the maintainer in resultsdb 14:27:09 * tflink was talking about just dumping information into the logfiles for now 14:27:29 we could add a tag, I suppose 14:27:47 hmh so when I receive a notification about abicheck failing, I don't get a link to one of these ? http://taskotron-dev.fedoraproject.org/resultsdb/results?testcase_name=scratch.abicheck 14:28:00 I don't have hard feelings about this, I just think we're overengineering it 14:28:16 I thought I receive this http://taskotron-dev.fedoraproject.org/resultsdb/results/6437765 14:28:17 but if people prefer it this way, ok 14:28:38 and from there, I can just get to the logs. 14:28:38 how is adding some lines to the logs based on yaml content overengineering? 14:28:42 or what am I missing? 14:29:06 sorry, I don't have enough vocabulary to understand what you mean by "primary artifact". 14:29:12 tflink: you said you'd get rid of fas. namespace. where do you see people submitting their private/niche task results to? 14:29:39 Dodji: I think he wants to have the owner visible from the resultsdb page, not just in the logs 14:29:56 that would be nice, yes 14:30:12 so from this link http://taskotron-dev.fedoraproject.org/resultsdb/results/6437765 ? 14:30:12 kparal: that's probably a use case where a fas namespace makes sense 14:30:19 either that or scratch 14:31:27 I'd rather not have to deal with auth for a fas namespace, though 14:31:36 but that's a different issue 14:31:54 that is where I kind of disagree with try too hard to stay at a KISS level. We should try had to keep things simple, but not harder. 14:32:19 if the solution is simpler than the problem, we usually end up with a solution that doesn't "fit". 14:32:20 Dodji: which part do you think is harder than it needs to be? 14:32:43 tflink: I think it's the other way around. Encoding everything in namespaces doesn't scale IMHO. 14:33:26 but for now, it'll do, I guess. we just have a handful of tasks ... 14:33:34 maybe not everything but I think that most information can be inferred by functional namespace 14:33:47 we can also generate a random uuid namespace for any task, and maintain access right in a database. it makes the system more flexible, but definitely not simpler 14:34:15 yeah, it won't be intuitive for people to name things if we do that. 14:34:22 rpm..unicornsarereal would imply that the people may have something to do with it 14:34:51 however, using `distro.` doesn't work with our current implementation of access checking 14:35:03 it doesn't? 14:35:17 i thought that used git repo urls 14:35:19 no, all people granted access to `distro` will be able to overwrite anything in `distro` 14:35:36 what we could do is to define a generic nameing scheme 14:35:40 the access checks are performed on namespaces only, not on namespace+taskname 14:35:40 and make all task follow that 14:35:42 and anyone who gets access to a beaker client could wreak havoc in our infrastructure 14:35:44 for instance: 14:35:51 mkrizek: correct me if I'm wrong 14:35:53 ...task-name 14:36:21 domain would be something that defines how broadly the task is meant to touch the distro or something like that 14:36:30 a possible domain would be "distro". 14:36:30 after a certain point, we can't make everything perfectly secure 14:36:43 can't realistically 14:36:53 Dodji: but I consider this very inflexible, why encode _this_ information into a namespace? 14:36:58 then blocking-ness could be either blocking or info 14:37:10 you don't want ownership there, but so much other information is ok? 14:37:16 i'd rather leave blocking information out of the namespace 14:37:23 that's something that we don't decide 14:37:35 right, and different tools can use different settings 14:37:41 nor does the task author, at least on the distro level 14:37:45 kparal: ah, I am trying to accomodate the various needs here 14:37:46 kparal: unless we make namespace.taskname. a namespace, then taskname people couldn't write into namespace.anything else, right 14:38:05 kparal: ideally, I wouldn't follow this scheme if we had the other necessary infrastructure ... 14:38:16 why is it so important to make sure people can't overwrite things in the same namespace? 14:38:30 how many people are going to have access to repos which could write to qa.* or distro.*? 14:38:44 kparal: but since you want to use namespace to encode several things, I think you need to define a structure that would let people query thing 14:38:55 couldn't the same people go into bodhi and give false karma? 14:39:28 tflink: ok, good question. I considered this a matter of principle. if we're ok with some people having the ability to mess up other people's results, we don't need to be so strict when designing the namespaces 14:39:48 kparal: and I agree it then makes the use namespace less flexible than if it was just meant to convey some logical categorization decided by the author. 14:39:57 i get not wanting to make mistakes but we do have control over which tasks can report to qa.* or distro.*, can't we realistically assume that anyone we grant access to a distro.* namespace will test their stuff first and not be evil? 14:40:31 Dodji: I actually wanted to encode just one thing - ownership == access rights (the same thing) 14:41:06 and leveraging other fedora infrastructure for our needs, like FAS accounts and FAS groups 14:41:11 it makes sense to me that each package would be restricted to rpm..* or layered images to docker..* but I'm not sure it's worth worrying so much about the distro.* namespace 14:41:23 kparal: and each time the ownership changes you'd change the namespace? 14:41:57 mostly because I think it would be easy to figure out the package/image specific stuff and any ownership is relatively obvious 14:42:03 it seems to me the ownership is the most fluid of all the properties of a task 14:42:21 tflink: I wanted to avoid the situation where there's a person which has a useful task but I'm not sure if I trust him/her technically not to mess up anything else 14:42:21 same thing with packages 14:42:48 that was the "preventing mistakes" part of the namespaces 14:43:06 kparal: how would namespacing them to fas..usefulcheck be an improvement? 14:43:13 Dodji: I don't think group ownership will change that often 14:43:31 * tflink wonders if having a mentoring process of sorts would be a better idea overall, even if it means a bit more work 14:43:33 tflink: in that case they can't overwrite other people's tasks 14:44:24 I'd rather have an automated setup to check things, honestly 14:44:32 what do you mean? 14:45:30 ignoring reality for a second, a way for a task to be tested against a known set of input and make sure it's not doing anything "bad" 14:45:33 * Dodji still think that a namespace is not at the same conceptual level as granting an access to a resource 14:45:39 which has pitfalls, I think 14:46:04 why are we trying to hope for best when we can design the system in a safe way? that's what I don't understand 14:46:34 because I'm worried about the costs and potential issues of that safe system 14:46:36 yeah I agree with kparal 14:46:38 long term 14:46:47 alternate ideas welcome 14:47:00 if I'm missing something here, i assume someone will point it out 14:47:27 we could say that *by default*, a task in namespace foo can only write in namspace foo. 14:47:58 the difference is "everyone has fas.id namespace available, knock yourselves out" versus "we give you access to dist, but please be careful" 14:48:01 and give the idea open to add an indirection to decide which task has the right to write where. 14:48:15 kparal: that's a strawman and not at all what I was proposing 14:49:00 I guess we could dist.foo restrict only to dist.foo somehow, I'm just not clear on the implementation changes 14:49:01 yes, I did suggest getting rid of fas namespace but I thought we talked about that earlier 14:49:13 currently, dist.foo is able to write to dist.* 14:49:47 why can't we have "fas.id." available to all and dist.* only available to tasks which we deem to be of sufficient quality? 14:49:50 because namespace is dist and task name is foo, and we do only namespace checking 14:50:23 tflink: sure, we can 14:51:24 mkrizek: would it be a lot of work to update the namespace checking code to say that a task allowed to post to dist.* can only post to dist..*? 14:51:38 tflink: I just went one step further and instead of shared dist.* imagined fas.group.*. but I'm not set in stone for that 14:52:04 * tflink will be surprised if we end up with more than 10 dist.* tasks not maintained by us 14:52:24 which is mostly why I'm not too worried about it 14:52:42 us == fedora-qe folks, in this case 14:52:48 tflink: not sure off top of my head, but I suspect it wouldn't be a lot of work 14:53:04 it might need task registration service 14:53:15 i think we're going to end up there, anyways 14:53:31 it's somewhat part of the PoC I'm working on 14:53:57 the current idea was "all git repos from phabricator.com/group/qa/* can write to namespace qa" 14:54:10 with task name checking, we'll probably need to list all one by one 14:54:20 for dist.*, sure 14:54:38 but how many dist.* checks do you think we're going to have? 14:55:35 I don't expect that many 14:55:51 so we can list them all in a config file like we currently do, no? 14:56:08 I'm not sure how it's going to impact distgit and fas checking 14:56:23 distgit is formulaic, that doesn't need registration 14:56:43 in my mind it used a similar format - all tasks from fedorapeple.org/user/* can write to fas.user.* 14:57:21 "is the repo checks/rpms/?" "if yes, it's allowed to post to pkgs..* 14:57:25 which allows people to host their git on fedorapeople and write to their namespace without too much hassle 14:57:57 without any registration, even 14:58:21 but yeah, sure, we can work it out somehow 14:58:24 that being said, I think that getting to the point where we can't keep everything in a single, sane config file will be a similar place to "what if we run out of hardware capacity?" 14:58:45 ie, a good place 14:59:00 the main thing I want to avoid is people contacting us "please add our task to the system" 14:59:02 kparal: is this making enough sense or am I just being stubborn? 14:59:15 kparal: if we get much of that, we need to have self-registration 14:59:31 but I'm OK with keeping that in mind but adding it later 14:59:32 tflink: we both are, no change :) 14:59:37 :) 15:00:02 we're pretty much out of time but I would like to get this mostly figured out today 15:00:13 ok, so, we'll try to restrict task dist.foo to writing only to dist.foo, correct? 15:00:25 * omiday must leave to start his dayjob 15:00:29 I'm fine with that unless it ends up being a crazy amount of work 15:00:34 omiday: thanks for coming 15:00:35 don't get rid of fas namespace 15:00:41 also works for me 15:00:50 and use dist.* for distribution level tasks 15:00:57 so long as fas.id.* cannot be release blocking 15:01:16 still not sure about compose checks, though. will we add `compose` namespace? 15:01:22 or other types of tasks 15:01:27 that makes sense to me 15:01:49 compose.*, maybe live.kde.*, live.workstation.* 15:02:02 I'm sure there will be use cases that we haven't thought of yet 15:02:18 so, to quickly summarize: 15:02:26 I'd like to avoid maintaining huge lists of top-level namespaces 15:02:36 * tflink thinks that the next meeting in here isn't for ~ 30 min 15:02:36 e.g. defining it for every spin available, etc 15:03:04 that's why I wanted fas.group.workstation, and "do whatever you like in it" 15:03:07 kparal: would compose.kde.* or live.kde.* work for that? 15:03:10 ah 15:03:32 again, not encode too much information in namespaces 15:04:15 * tflink doesn't care much on the fas.group.kdespinfolks.* vs. live.kde.* thing 15:04:30 compose.* seems worthy of keeping as a separate top-level namespace 15:04:47 as does openqa, dist, rpms, docker etc. 15:05:40 it probably makes sense when there's a system we can interact with 15:05:42 like dist-git 15:05:49 so, assuming I've understood the conversation thus far ... 15:05:53 so we can make some integration 15:06:01 1. keep the fas.* namespace 15:06:29 2. fas.id. is effectively wide open, maybe some restrictions on where the repo can live 15:06:55 3. fas.group..* can be release-blocking and will have stuff like workstation, server, cloud etc. 15:07:17 4. dist.* will have all the distro-level checks (depcheck, upgradepath, abicheck, rpmgrill etc.) 15:07:51 5. multi-level namespace whitespacing will be implemented 15:08:07 did I miss or misunderstand anything? 15:08:18 so, we're killing `qa` namespace, right? 15:08:39 that makes sense to me 15:08:41 oh 15:08:58 6. add code to libtaskotron to dump maintainer in a somewhat obvious manner 15:09:01 er 15:09:03 dump to logs 15:09:46 we could shorten `fas.group` to just `group`, but that's cosmetic details 15:09:56 in general, fine with me 15:10:06 I'd like to show the maintainer in a better way than logs, though 15:10:14 *than just in logs 15:11:14 but that's also future-improvement 15:11:19 kparal: suggestions as to how? 15:11:30 * tflink can think of ways to do that, not sure which makes the most sense 15:11:52 no idea atm. we can still ask them to create the wiki page under https://fedoraproject.org/wiki/Taskotron/Tasks , but that's obviously not a long-term solution 15:11:53 putting it in execdb or as a tag in resultsdb makes the most sense to me 15:12:18 and/or generating html from the tasks, kinda like how we do docs for directives 15:12:38 but I don't see what we talked about in 1-6 getting in the way of those things 15:12:53 * kparal nods 15:13:58 so we can do the manual thing for now and figure out which route(s) we want to take towards better task registration/documentation/contact info later, I think 15:16:06 proposed #agreed the items 1-6 above seem reasonable at this time and is good enough to start working on but a more detailed document should be sent out to qa-devel@ for final approval 15:16:14 if anyone's still around ... 15:16:48 ack 15:16:50 ack 15:17:28 * tflink self acks even though that's not worth much :) 15:17:42 but we're more than 15 minutes over, so I'm inclined to accept it 15:17:49 #agreed the items 1-6 above seem reasonable at this time and is good enough to start working on but a more detailed document should be sent out to qa-devel@ for final approval 15:18:07 well, that and I don't expect resistance, we can adjust if there is 15:18:16 anything else on this topic? 15:18:31 the releng meeting starts in ~ 10, so we don't really have much time left 15:19:07 * tflink assumes that silence == no 15:19:13 #topic Open Floor 15:19:20 anything else to _quickly_ bring up? 15:19:32 otherwise, I'm setting the fuse 15:21:27 nope 15:21:34 let's close this 15:21:34 ok, thanks for coming, everyone 15:21:46 sorry we went over, hopefully it was useful enough to justify this time 15:21:46 thanks everyone 15:21:53 * tflink will send out minutes shortly 15:21:55 #endmeeting