14:01:35 <tflink> #startmeeting fedora-qadevel
14:01:35 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:01:35 <zodbot> The meeting name has been set to 'fedora-qadevel'
14:01:35 <tflink> #meetingname fedora-qadevel
14:01:35 <zodbot> The meeting name has been set to 'fedora-qadevel'
14:01:35 <tflink> #topic Roll Call
14:01:51 * kparal is here
14:01:53 <tflink> 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 <tflink> ok, let's get started, then
14:03:55 <tflink> #topic Announcements and Information
14:04:03 <tflink> Does anyone have announcements and/or information?
14:04:18 <mkrizek> #info taskotron-trigger sent for package review
14:04:39 <tflink> #chair mkrizek kparal lbrabec coremodule garretraziel omiday
14:04:39 <zodbot> Current chairs: coremodule garretraziel kparal lbrabec mkrizek omiday tflink
14:05:22 <tflink> mkrizek: can you do that again now that you've been #chair-ed?
14:05:44 <mkrizek> #info taskotron-trigger sent for package review
14:05:47 <tflink> thanks
14:06:13 <garretraziel> that reminds me, I belive that jskladan sent some python library package up for review and AFAIK was looking for sponsor
14:06:29 <tflink> i thought he was a packager already
14:06:43 <garretraziel> he wasn
14:06:46 <tflink> ah
14:06:46 <garretraziel> wasn't
14:09:27 <tflink> 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 <tflink> moving on to the larger discussion topic
14:10:10 <tflink> #topic Task Namespaces
14:12:18 <tflink> why are the qa-devel archives private?
14:13:17 * tflink is looking for a link to the namespace discussion
14:13:22 <kparal> no idea
14:14:04 <Dodji> tflink: https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org/message/P5UOHY5W7PTEIFPUZB4LEUASBM6CVSZU/
14:14:08 <Dodji> that's the link to my post
14:14:15 <kparal> seems we have a mailing list gremlin who sets all the options incorrectly :)
14:14:28 <tflink> bah
14:14:32 <Dodji> 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 <tflink> #action tflink to make qa-devel@ archives public
14:15:04 <tflink> Dodji: thanks
14:15:07 <Dodji> np
14:15:28 <tflink> #link https://lists.fedoraproject.org/archives/list/qa-devel@lists.fedoraproject.org/thread/XJTD2KSGDGAYPEQEUJGDTNT2EV42PBE4/
14:15:37 <tflink> i suppose that was auto-linked
14:15:39 <tflink> oh well
14:15:50 <Dodji> mkrizek: just curious, did you post the blog entry to announce the new tasks yet?
14:16:03 <mkrizek> Dodji: not yet, we hit some blockers on that
14:16:09 <Dodji> no problem
14:16:13 <mkrizek> one of them is namespaces :)
14:16:16 <Dodji> I was just wondering if I missed something
14:16:19 <tflink> 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 <tflink> 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 <tflink> not sure about the ACL service but the documentation, definitely
14:19:03 <tflink> granted, i suspect most of those tasks are going to be associated with a specific rpm or layered image
14:19:32 <kparal> 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 <tflink> not sure we're going to get too many distro-wide tasks
14:19:36 <kparal> but still, quite KISS
14:20:11 <tflink> kparal: what if we put the maintainer information in the logs?
14:20:22 <tflink> IIRC, we're not doing anything with that YAML field
14:20:38 <kparal> 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 <kparal> so I'm not a big fan of that
14:20:55 <tflink> 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 <Dodji> yeah, qa.* doesn't seem to convey any meaning information
14:22:11 <tflink> other than ownership
14:22:15 <kparal> originally I proposed group.qa
14:22:17 <Dodji> granted, all this task business is for qa purposes :-)
14:23:07 <tflink> 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 <Dodji> I think the ownership should be better documented in a wiki page or something like that for now
14:23:30 <Dodji> because, as tflink put it, I think that ownership concept is quite fluid
14:23:31 <kparal> tflink: do you think we can make it easily visible?
14:23:34 <tflink> we do have an ownership field in the formulas
14:23:43 <kparal> the primary artifact might be something completely different
14:23:47 <kparal> how will people see our logs?
14:23:56 <tflink> kparal: why not? it's a required field of the formulas, no?
14:24:11 <tflink> kparal: aren't they linked from the fedmsgs?
14:24:18 <Dodji> <kparal> how will people see our logs?
14:24:28 <Dodji> kparal: there is a link to the logs when you receive a notification.
14:24:43 <Dodji> I believe :-)
14:24:45 <tflink> 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 <kparal> Dodji: no, to the primary artifact, which happens to be the main log for our tasks
14:25:21 <kparal> but not for task-dockerautotest, for example
14:25:39 <tflink> that's something we could fix, though
14:25:57 <kparal> yes, I'm just not sure how
14:26:01 <tflink> link to execdb
14:26:20 <kparal> 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 <tflink> why would we need that?
14:26:48 <kparal> I'm sure it's solveable, it's just seems so... unnecessarily complicated
14:27:07 <kparal> 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 <tflink> we could add a tag, I suppose
14:27:47 <Dodji> 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 <kparal> I don't have hard feelings about this, I just think we're overengineering it
14:28:16 <Dodji> I thought I receive this http://taskotron-dev.fedoraproject.org/resultsdb/results/6437765
14:28:17 <kparal> but if people prefer it this way, ok
14:28:38 <Dodji> and from there, I can just get to the logs.
14:28:38 <tflink> how is adding some lines to the logs based on yaml content overengineering?
14:28:42 <Dodji> or what am I missing?
14:29:06 <Dodji> sorry, I don't have enough vocabulary to understand what you mean by "primary artifact".
14:29:12 <kparal> 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 <tflink> Dodji: I think he wants to have the owner visible from the resultsdb page, not just in the logs
14:29:56 <kparal> that would be nice, yes
14:30:12 <Dodji> so from this link http://taskotron-dev.fedoraproject.org/resultsdb/results/6437765 ?
14:30:12 <tflink> kparal: that's probably a use case where a fas namespace makes sense
14:30:19 <tflink> either that or scratch
14:31:27 <tflink> I'd rather not have to deal with auth for a fas namespace, though
14:31:36 <tflink> but that's a different issue
14:31:54 <Dodji> 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 <Dodji> if the solution is simpler than the problem, we usually end up with a solution that doesn't "fit".
14:32:20 <tflink> Dodji: which part do you think is harder than it needs to be?
14:32:43 <Dodji> tflink: I think it's the other way around.  Encoding everything in namespaces doesn't scale IMHO.
14:33:26 <Dodji> but for now, it'll do, I guess.  we just have a handful of tasks ...
14:33:34 <tflink> maybe not everything but I think that most information can be inferred by functional namespace
14:33:47 <kparal> 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 <Dodji> yeah, it won't be intuitive for people to name things if we do that.
14:34:22 <tflink> rpm.<package name>.unicornsarereal would imply that the <package name> people may have something to do with it
14:34:51 <kparal> however, using `distro.<testname>` doesn't work with our current implementation of access checking
14:35:03 <tflink> it doesn't?
14:35:17 <tflink> i thought that used git repo urls
14:35:19 <kparal> no, all people granted access to `distro` will be able to overwrite anything in `distro`
14:35:36 <Dodji> what we could do is to define a generic nameing scheme
14:35:40 <kparal> the access checks are performed on namespaces only, not on namespace+taskname
14:35:40 <Dodji> and make all task follow that
14:35:42 <tflink> and anyone who gets access to a beaker client could wreak havoc in our infrastructure
14:35:44 <Dodji> for instance:
14:35:51 <kparal> mkrizek: correct me if I'm wrong
14:35:53 <Dodji> <domain>.<blocking-ness>.<package-kind>.task-name
14:36:21 <Dodji> domain would be something that defines how broadly the task is meant to touch the distro or something like that
14:36:30 <Dodji> a possible domain would be "distro".
14:36:30 <tflink> after a certain point, we can't make everything perfectly secure
14:36:43 <tflink> can't realistically
14:36:53 <kparal> Dodji: but I consider this very inflexible, why encode _this_ information into a namespace?
14:36:58 <Dodji> then blocking-ness could be either blocking or info
14:37:10 <kparal> you don't want ownership there, but so much other information is ok?
14:37:16 <tflink> i'd rather leave blocking information out of the namespace
14:37:23 <tflink> that's something that we don't decide
14:37:35 <kparal> right, and different tools can use different settings
14:37:41 <tflink> nor does the task author, at least on the distro level
14:37:45 <Dodji> kparal: ah, I am trying to accomodate the various needs here
14:37:46 <mkrizek> kparal: unless we make namespace.taskname. a namespace, then taskname people couldn't write into namespace.anything else, right
14:38:05 <Dodji> kparal: ideally, I wouldn't follow this scheme if we had the other necessary infrastructure ...
14:38:16 <tflink> why is it so important to make sure people can't overwrite things in the same namespace?
14:38:30 <tflink> how many people are going to have access to repos which could write to qa.* or distro.*?
14:38:44 <Dodji> 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 <tflink> couldn't the same people go into bodhi and give false karma?
14:39:28 <kparal> 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 <Dodji> 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 <tflink> 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 <kparal> Dodji: I actually wanted to encode just one thing - ownership == access rights (the same thing)
14:41:06 <kparal> and leveraging other fedora infrastructure for our needs, like FAS accounts and FAS groups
14:41:11 <tflink> it makes sense to me that each package would be restricted to rpm.<package-name>.* or layered images to docker.<image-name>.* but I'm not sure it's worth worrying so much about the distro.* namespace
14:41:23 <Dodji> kparal: and each time the ownership changes you'd change the namespace?
14:41:57 <tflink> 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 <Dodji> it seems to me the ownership is the most fluid of all the properties of a task
14:42:21 <kparal> 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 <tflink> same thing with packages
14:42:48 <kparal> that was the "preventing mistakes" part of the namespaces
14:43:06 <tflink> kparal: how would namespacing them to fas.<baduser>.usefulcheck be an improvement?
14:43:13 <kparal> 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 <kparal> tflink: in that case they can't overwrite other people's tasks
14:44:24 <tflink> I'd rather have an automated setup to check things, honestly
14:44:32 <kparal> what do you mean?
14:45:30 <tflink> 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 <tflink> which has pitfalls, I think
14:46:04 <kparal> 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 <tflink> because I'm worried about the costs and potential issues of that safe system
14:46:36 <Dodji> yeah I agree with kparal
14:46:38 <tflink> long term
14:46:47 <tflink> alternate ideas welcome
14:47:00 <tflink> if I'm missing something here, i assume someone will point it out
14:47:27 <Dodji> we could say that *by default*, a task in namespace foo can only write in namspace foo.
14:47:58 <kparal> 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 <Dodji> and give the idea open to add an indirection to decide which task has the right to write where.
14:48:15 <tflink> kparal: that's a strawman and not at all what I was proposing
14:49:00 <kparal> I guess we could dist.foo restrict only to dist.foo somehow, I'm just not clear on the implementation changes
14:49:01 <tflink> yes, I did suggest getting rid of fas namespace but I thought we talked about that earlier
14:49:13 <kparal> currently, dist.foo is able to write to dist.*
14:49:47 <tflink> why can't we have "fas.id.<username>" available to all and dist.* only available to tasks which we deem to be of sufficient quality?
14:49:50 <kparal> because namespace is dist and task name is foo, and we do only namespace checking
14:50:23 <kparal> tflink: sure, we can
14:51:24 <tflink> 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.<taskname>.*?
14:51:38 <kparal> 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 <tflink> which is mostly why I'm not too worried about it
14:52:42 <tflink> us == fedora-qe folks, in this case
14:52:48 <mkrizek> tflink: not sure off top of my head, but I suspect it wouldn't be a lot of work
14:53:04 <kparal> it might need task registration service
14:53:15 <tflink> i think we're going to end up there, anyways
14:53:31 <tflink> it's somewhat part of the PoC I'm working on
14:53:57 <kparal> the current idea was "all git repos from phabricator.com/group/qa/* can write to namespace qa"
14:54:10 <kparal> with task name checking, we'll probably need to list all one by one
14:54:20 <tflink> for dist.*, sure
14:54:38 <tflink> but how many dist.* checks do you think we're going to have?
14:55:35 <kparal> I don't expect that many
14:55:51 <tflink> so we can list them all in a config file like we currently do, no?
14:56:08 <kparal> I'm not sure how it's going to impact distgit and fas checking
14:56:23 <tflink> distgit is formulaic, that doesn't need registration
14:56:43 <kparal> in my mind it used a similar format - all tasks from fedorapeple.org/user/* can write to fas.user.*
14:57:21 <tflink> "is the repo checks/rpms/<pkgname>?" "if yes, it's allowed to post to pkgs.<pkgname>.*
14:57:25 <kparal> which allows people to host their git on fedorapeople and write to their namespace without too much hassle
14:57:57 <kparal> without any registration, even
14:58:21 <kparal> but yeah, sure, we can work it out somehow
14:58:24 <tflink> 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 <tflink> ie, a good place
14:59:00 <kparal> the main thing I want to avoid is people contacting us "please add our task to the system"
14:59:02 <tflink> kparal: is this making enough sense or am I just being stubborn?
14:59:15 <tflink> kparal: if we get much of that, we need to have self-registration
14:59:31 <tflink> but I'm OK with keeping that in mind but adding it later
14:59:32 <kparal> tflink: we both are, no change :)
14:59:37 <tflink> :)
15:00:02 <tflink> we're pretty much out of time but I would like to get this mostly figured out today
15:00:13 <kparal> 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 <tflink> I'm fine with that unless it ends up being a crazy amount of work
15:00:34 <tflink> omiday: thanks for coming
15:00:35 <kparal> don't get rid of fas namespace
15:00:41 <tflink> also works for me
15:00:50 <kparal> and use dist.* for distribution level tasks
15:00:57 <tflink> so long as fas.id.* cannot be release blocking
15:01:16 <kparal> still not sure about compose checks, though. will we add `compose` namespace?
15:01:22 <kparal> or other types of tasks
15:01:27 <tflink> that makes sense to me
15:01:49 <tflink> compose.*, maybe live.kde.*, live.workstation.*
15:02:02 <tflink> I'm sure there will be use cases that we haven't thought of yet
15:02:18 <tflink> so, to quickly summarize:
15:02:26 <kparal> 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 <kparal> e.g. defining it for every spin available, etc
15:03:04 <kparal> that's why I wanted fas.group.workstation, and "do whatever you like in it"
15:03:07 <tflink> kparal: would compose.kde.* or live.kde.* work for that?
15:03:10 <tflink> ah
15:03:32 <kparal> 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 <tflink> compose.* seems worthy of keeping as a separate top-level namespace
15:04:47 <tflink> as does openqa, dist, rpms, docker etc.
15:05:40 <kparal> it probably makes sense when there's a system we can interact with
15:05:42 <kparal> like dist-git
15:05:49 <tflink> so, assuming I've understood the conversation thus far ...
15:05:53 <kparal> so we can make some integration
15:06:01 <tflink> 1. keep the fas.* namespace
15:06:29 <tflink> 2. fas.id.<username> is effectively wide open, maybe some restrictions on where the repo can live
15:06:55 <tflink> 3. fas.group.<groupname>.* can be release-blocking and will have stuff like workstation, server, cloud etc.
15:07:17 <tflink> 4. dist.* will have all the distro-level checks (depcheck, upgradepath, abicheck, rpmgrill etc.)
15:07:51 <tflink> 5. multi-level namespace whitespacing will be implemented
15:08:07 <tflink> did I miss or misunderstand anything?
15:08:18 <kparal> so, we're killing `qa` namespace, right?
15:08:39 <tflink> that makes sense to me
15:08:41 <tflink> oh
15:08:58 <tflink> 6. add code to libtaskotron to dump maintainer in a somewhat obvious manner
15:09:01 <tflink> er
15:09:03 <tflink> dump to logs
15:09:46 <kparal> we could shorten `fas.group` to just `group`, but that's cosmetic details
15:09:56 <kparal> in general, fine with me
15:10:06 <kparal> I'd like to show the maintainer in a better way than logs, though
15:10:14 <kparal> *than just in logs
15:11:14 <kparal> but that's also future-improvement
15:11:19 <tflink> 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 <kparal> 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 <tflink> putting it in execdb or as a tag in resultsdb makes the most sense to me
15:12:18 <tflink> and/or generating html from the tasks, kinda like how we do docs for directives
15:12:38 <tflink> 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 <tflink> 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 <tflink> 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 <tflink> if anyone's still around ...
15:16:48 <kparal> ack
15:16:50 <mkrizek> ack
15:17:28 * tflink self acks even though that's not worth much :)
15:17:42 <tflink> but we're more than 15 minutes over, so I'm inclined to accept it
15:17:49 <tflink> #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 <tflink> well, that and I don't expect resistance, we can adjust if there is
15:18:16 <tflink> anything else on this topic?
15:18:31 <tflink> 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 <tflink> #topic Open Floor
15:19:20 <tflink> anything else to _quickly_ bring up?
15:19:32 <tflink> otherwise, I'm setting the fuse
15:21:27 <kparal> nope
15:21:34 <kparal> let's close this
15:21:34 <tflink> ok, thanks for coming, everyone
15:21:46 <tflink> sorry we went over, hopefully it was useful enough to justify this time
15:21:46 <kparal> thanks everyone
15:21:53 * tflink will send out minutes shortly
15:21:55 <tflink> #endmeeting