-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/18/2010 09:55 AM, Dmitri Pal wrote: > Steve can you summarize where we are and what we agreed to, please, and > identify the questions that we need to answer.
Simo, Adam and I had a long discussion on IRC regarding the time rules today (complete log attached). The short version is that we're going to continue (mostly) with the current grammar for the time rules, with a few changes. 1) We need to replace week-of-the-month with day-of-the-septet. This day should not be a range or multi-valued to eliminate confusion 2) We need to replace the time range with a duration 3) We should add startDate and endDate as attributes on the HBAC object (separate from the accessTime). I propose these should be in LDAP generalizedTime so that it's possible to construct filters around them. This effectively sets the beginning and end of a periodic schedule. I've drawn up a new grammar definition and published it to the SSSD wiki (not currently linked from anywhere): https://fedorahosted.org/sssd/wiki/HBAC_Grammar Please review and give feedback. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkzllFMACgkQeiVVYja6o6PNIwCfQeLMCrWS0dW3t+pD8raTJ7d5 /7oAmwUAFMY1XAb289ysIGzSq3sPMjJF =a0mt -----END PGP SIGNATURE-----
(12:51:03 PM) sgallagh: simo, ayoung: Can we discuss the time grammar live? (12:51:21 PM) sgallagh: dpal wants a summary, but we have two opposing proposals on the list 12:55 (12:55:46 PM) ayoung: sure sgallagh (12:58:01 PM) sgallagh: ayoung, simo: So the two proposals are: (12:58:18 PM) sgallagh: 1) Modify the current interface slightly to support septets and try to make the UI work with that (12:58:31 PM) sgallagh: 2) Replace the current grammar entirely with cron+duration (12:58:37 PM) ***ayoung hates the word septets. (12:58:48 PM) sgallagh: ayoung: It was less ambiguous than "week" (12:59:31 PM) ayoung: sgallagh, what does the current grammar do that that the cron grammer doesn't? (12:59:56 PM) sgallagh: ayoung: Save us a week of rewriting the parsers and HBAC provider in SSSD? 13:00 (01:00:40 PM) sgallagh: Also, we will need to discuss the UTC vs Local Time situation, but we'll hold that until later (01:00:40 PM) ayoung: sgallagh, no, I mean, what doesn't it represent? (01:00:55 PM) ayoung: OK, TZ is one issue. (01:01:11 PM) sgallagh: That's an issue for both grammars, so that can wait (01:02:25 PM) sgallagh: ayoung: I don't know that there's any huge difference between the capabilities of the current grammar and the cron grammer (01:02:29 PM) sgallagh: *grammar (01:02:46 PM) sgallagh: Actually, I take that back. The current grammar can do individual events (01:03:04 PM) sgallagh: For example, "this rule only applies on this ONE date in all time" (01:03:09 PM) sgallagh: Cron mandates repetition (01:03:17 PM) sgallagh: Once a year at minimum (01:04:42 PM) ayoung: sgallagh, yep, because the Unix apprao9ch assumes you' (01:04:51 PM) ayoung: ll use at for that. OK, that is two issues 13:05 (01:05:56 PM) ayoung: Here's my take: we are going to try to get people to use IPA. The principal of "least surprise" says that if it is scheduling, make it look like that standard for scheduling. (01:06:04 PM) ayoung: cron is posix. (01:06:25 PM) sgallagh: As an aside, regardless of which grammar we choose, I also want to add an optional startDate and endDate attribute to the HBAC object. So we can define whether certain rules start "next year" and end "in three years" (for example) (01:07:00 PM) sgallagh: But that's easy and an aside (01:07:07 PM) ayoung: sgallagh, agreed. (01:07:46 PM) ayoung: well...hmm, maybe not (01:07:55 PM) sgallagh: ? (01:08:10 PM) ayoung: I'm wondering if we want to split it into a cron part and an at part (01:08:25 PM) ayoung: at says : deploy this rule, undeploy this rule (01:08:34 PM) ayoung: cron is just the repitition (01:08:57 PM) sgallagh: I thought at just said "Do this AT this time" and only fired once (01:08:58 PM) ayoung: not sure if "start this 3 months from now" is really that useful. (01:09:06 PM) ayoung: sgallagh, that is correct (01:09:31 PM) sgallagh: ayoung: Example: you've hired a group of contract workers to start in January and work for one year. (01:09:39 PM) dpal: EnigmaObfuscate, ping, I am very busy this week but I see the mails about SUDO. I will reply and comment early next week. (01:09:48 PM) ayoung: you would use "at" to deploy the rules when they start 13:10 (01:10:02 PM) sgallagh: ayoung: That's not how we'd do it in SSSD (01:10:27 PM) ayoung: sgallagh, understood. I'm just thinking here.... (01:10:28 PM) sgallagh: For us, it would be easier to have our LDAP search filter be able to say startDate <= now(), endDate > now() (01:10:48 PM) sgallagh: Then we don't have to process those objects because they won't come down to us (01:10:58 PM) ayoung: If the grammar is a done deal, and it works in sssd, and it isn't that hard to learn, I'm not going to hold up progress. (01:11:26 PM) sgallagh: ayoung: Well, it's not a done deal (01:11:41 PM) sgallagh: As we've mentioned, it needs at minimum to switch to the septet view (01:11:53 PM) sgallagh: But I think this might be less work than switching to a cron-based format (01:12:15 PM) sgallagh: However, I'm willing to do the extra work if we can prove it's a better long-term solution (01:12:35 PM) sgallagh: We still need to address how to handle periods that cross midnight boundaries (01:12:48 PM) sgallagh: And doing things as start_time + duration would address that (01:13:09 PM) ayoung: sgallagh, if we do start time + duration, crossing boundaries goes away. (01:13:11 PM) sgallagh: I proposed a way to do it with the current grammar, but it's somewhat one-way. Easy to set, harder to view in reverse (01:13:43 PM) sgallagh: So there are definite pros and cons to both approaches (01:14:35 PM) ayoung: sgallagh, I don't like the septet view. could we make the current grammar at least use the same logic as cron? (01:14:50 PM) sgallagh: What "view" ? (01:14:56 PM) ayoung: view of things. 13:15 (01:15:10 PM) sgallagh: Could you please elaborate? (01:15:31 PM) ayoung: Septet is month oriented, right? (01:15:54 PM) sgallagh: It literally means "between days 1*n and 7*n of the month", where n is the septet number (01:16:17 PM) sgallagh: So, the first saturday of the month would be the saturday within the first septet (01:16:29 PM) sgallagh: (For the record, this would NOT be a user-visible term) (01:16:38 PM) ayoung: yeah. So if 1 is wednesday, it will be every wednesday fo that month, and then next month it will be every...whatever? (01:16:48 PM) ayoung: ah ok (01:16:51 PM) sgallagh: No no no (01:17:20 PM) sgallagh: It would always be the same named weekday, wherever it fell within the septet (01:17:32 PM) sgallagh: So it would LITERALLY mean "The nth wednesday of every month" (01:18:05 PM) sgallagh: I meant user-visible in the Web UI. The CLI might have to be literal 13:20 (01:21:06 PM) ayoung: sgallagh, so the trade off is "cron-like will be easier to learn, but current grammar is mostly implemented and more succinct?" (01:21:18 PM) sgallagh: I don't know about more succinct (01:21:29 PM) sgallagh: And as I said, it will have issues with displaying times that cross midnight (01:22:22 PM) sgallagh: ayoung: Ok, let's try rating the pros and cons in order of importance (01:22:30 PM) ayoung: sgallagh, can't help but tink that this is a solved problem somewhere...COndor os something like that (01:22:38 PM) ayoung: os->or (01:22:51 PM) sgallagh: 1) How important do we feel single events (or exceptions) are? (01:23:04 PM) sgallagh: 2) How important is the midnight overlap problem? (01:23:31 PM) sgallagh: 3) Are we willing to do a little work or a lot? (01:24:41 PM) sgallagh: ayoung: I'm beginning to lean towards the cron-like grammar, but I need to be sure it's worth the extra effort of rewriting the parser 13:25 (01:25:04 PM) ayoung: sgallagh, t least there is code we can steal in cron, right? (01:25:18 PM) sgallagh: ayoung: Not as much as you might think (01:25:28 PM) sgallagh: The duration may have more to do with it (01:25:58 PM) sgallagh: But of course we'll borrow what we can, if we do this (01:26:25 PM) sgallagh: gah, I just figured out how to do single events, too :) (01:26:28 PM) ayoung: OK, you have my $0.02. (01:26:30 PM) sgallagh: in cron (01:26:48 PM) sgallagh: ayoung: Just to be clear, you're backing the cron approach? (01:26:49 PM) ayoung: ? (01:27:20 PM) sgallagh: Well, if we do add the startTime and endTime attributes, then a single event is one where the repetition would only ever happen once during that interval :) (01:28:17 PM) ayoung: sgallagh, yes, but I am a pragmatist. I back it if it can be done without undermining other critical things that should be done before the deadline (01:28:31 PM) simo: sgallagh, wht do you say there is a UTC issue with the grammar > (01:28:31 PM) simo: ? (01:28:35 PM) simo: (I haven't read all the backlog) (01:29:08 PM) simo: ayoung, in general cron sucks IMO, so you need compelling arguments to make me think of using its "grammar" (01:29:39 PM) sgallagh: I don't remember saying that there was a UTC issue with the grammar... (01:29:41 PM) ayoung: simo, all software sucks. 13:30 (01:31:57 PM) simo: ayoung, if you say again "cron is easy to learn" I'll chop you in a half with an old AOL cd :) (01:32:05 PM) ayoung: simo, given a custom grammar vs. something that is an established standrad, you have to prove the superiority of the custom grammar. (01:32:23 PM) ayoung: simo, No, I say that most *nix sysadmins have already paid that price (01:32:27 PM) simo: ayoung, given I and dmitri worked on it extensively back then I can say so (01:33:33 PM) ayoung: simo, the engineer that designed a device is the last person you can trust on its usability. (01:33:44 PM) simo: of course :) (01:34:14 PM) simo: ayoung, but given cron can't do duration anyway ... (01:34:44 PM) ayoung: I'm pragmatic. If the current grammar is clos to ready to go, is relatively non-confusing, and just needs to be tweaked, than lets go with it. If OTOH any of those assumptions are wrong... 13:35 (01:35:12 PM) ayoung: simo, agreed on the duration bit. (01:35:25 PM) sgallagh: simo: At minimum, we need to move the current grammar away from time ranges and into start + duration (01:35:52 PM) simo: sgallagh, I am trying to think if we did the range onpurpose for some reaon (01:36:08 PM) simo: but I do not see why time +duration is not ok (01:36:27 PM) sgallagh: simo: I think the range causes too much trouble with the midnight problem (01:39:29 PM) sgallagh: simo: Ok, so should we change the grammar to replace week-of-the-month with septet-of-the-month and change ranges to start+duration? 13:40 (01:40:57 PM) simo: sgallagh, I think it is a reasonable proposal, I see no ill effects from the change (01:40:57 PM) sgallagh: Also, I think with septet-of-the-month we want to limit it to picking a single day-of-the-septet. Because picking "The first tuesday and thursday of the month" can be somewhat confusing if the month starts on a Wednesday. (Since the Tuesday in septet 1 would be in the second calendar week) (01:41:06 PM) simo: sgallagh, do we want to allow more than 24h duration ? (01:41:19 PM) ayoung: simo, yes (01:41:38 PM) sgallagh: No, I don't think so. (01:41:55 PM) ***simo thinks something is wrong though (01:42:29 PM) simo: I remember when we decided to use start stop dates that we wer going to put the whole start and the whle stop dates (01:42:31 PM) sgallagh: ayoung: What benefit is there to specifying more than 24 hours instead of just adding the next day to the repetition? (01:42:37 PM) simo: so duration should never have been a problem (01:42:45 PM) simo: I wonder if the grammar got mangled in the process (01:43:12 PM) sgallagh: simo: Did you see my proposals above for handling startDate and endDate of the HBAC rule as a separate attribute? (01:43:14 PM) ayoung: sgallagh, because that is how some people will think of it. (01:43:32 PM) sgallagh: ayoung: That's a fair point. (01:43:33 PM) ayoung: we don't have to force "there is only one way to do it" (01:43:40 PM) simo: sgallagh, yes, that has merit too (01:44:00 PM) simo: ayoung, multiple ways are dangerous though (01:44:31 PM) ayoung: OK, you guys have my iput, I'm headed back into webui land (01:44:39 PM) ***ayoung goes in search of lunch 13:45 (01:45:54 PM) sgallagh: simo: Ok, I'm going to try to summarize. Please correct me if I'm wrong (01:47:44 PM) simo: I will (01:48:16 PM) sgallagh: 1) We need to replace week-of-the-month with day-of-the-septet. This day should not be a range or multi-valued to eliminate confusion (01:48:16 PM) sgallagh: 2) We need to replace the time range with a duration (01:48:16 PM) sgallagh: 3) We should add startDate and endDate as attributes on the HBAC object (separate from the accessTime). I propose these should be in UNIX time 13:50 (01:54:10 PM) simo: sgallagh, define UNIX time (01:54:21 PM) sgallagh: date +%s (01:54:33 PM) simo: if you mean seconds from Jan 1 1970 I am not so big a fan but I understand why you may want that (01:54:45 PM) simo: sgallagh, whats wrong with an ISO date though ? 13:55 (01:55:05 PM) sgallagh: simo: This format would be easier to write an LDAP search filter around (01:55:11 PM) simo: generalized time is a fundamental type in LDAP (01:55:13 PM) sgallagh: ... Or of course we could use LDAP' (01:55:15 PM) sgallagh: s time (01:55:27 PM) sgallagh: Right, I had a moment of incompetence there (01:55:37 PM) simo: sgallagh, wich is generalizedTime and I would strongly prefer it (01:55:43 PM) simo: with the assumption it is written as UTC (01:56:16 PM) sgallagh: agreed (01:58:55 PM) sgallagh: simo: Ok, do you have any other comments, or should I write this up? (01:59:53 PM) simo: ha ther it is 14:00 (02:00:10 PM) sgallagh: ? (02:00:16 PM) simo: I think someone mistakenly interpreted the grammar to think XX-YY ranges meant only hours (02:00:32 PM) simo: while in our original creation it meant ranges would encompass everything (02:00:45 PM) simo: so duration wasn;t going to be a problem because you would say (02:01:04 PM) simo: from monday 22:00 to friday 04:00 (02:01:12 PM) simo: sgallagh, sorry I need to jump on a call (02:01:20 PM) simo: sgallagh, but hold on for a few minutes please (02:01:24 PM) sgallagh: simo: I don't think that works... (02:01:31 PM) sgallagh: I'll explain when you return 14:15 (02:16:12 PM) sgallagh: simo: Wait, are you trying to tell me that "periodic monthly week 2 day Sat,Sun 0900-1300" (the example on the page) would actually read as "Saturday 0900 until Sunday 1300" instead of as "Saturday 0900-1300 and Sunday 0900-1300"? (02:16:23 PM) sgallagh: Because if so... that's extremely ambiguous and ugly. 14:20 (02:24:49 PM) simo: sgallagh, no 14:25 (02:26:10 PM) simo: the - is the separator between start and stop (02:26:27 PM) simo: but the example looks "wrong" (02:28:37 PM) edewata: sgallagh, just a question, why not support both traditional week (sunday - saturday, or whatever) and septet, just in case someone needs it? (02:29:28 PM) edewata: sgallagh, and probably cron too, just in case someone needs it? :) (02:29:48 PM) sgallagh: simo: Please explain what you meant, then 14:30 (02:30:06 PM) sgallagh: edewata: "Traditional week" is too ambiguous. I'd much prefer not to confuse people. (02:30:28 PM) sgallagh: edewata: And I'm not implementing a second grammar "just in case" (02:30:31 PM) edewata: sgallagh, the grammar can start with the <type> which can be absolute/periodic/cron, or some future type (02:31:48 PM) edewata: sgallagh, in the ui we can ask user to select whether he wants the week to start from 1st or from sunday. just a thought (02:31:59 PM) simo: sgallagh, that you always say something like (02:32:09 PM) sgallagh: edewata: That gets really tricky to parse on the client (02:32:14 PM) simo: periodic monthly week 2 day Sat 0900-week 2 day Sat 1300 (02:32:43 PM) simo: and if you want that on Sunday too you have to add another rule (02:32:52 PM) sgallagh: That... doesn't match up at all with the grammar on that page (02:32:59 PM) simo: sgallagh, but switching to start + duration is fine by me (02:33:08 PM) simo: sgallagh, I know sbose SEJeff_work sgallagh simo (02:33:17 PM) simo: sgallagh, I was just saying that we started with that idea (02:33:53 PM) sgallagh: simo: That seems like it would be reasonable, but I'm not sure that's how it's implemented 14:35 (02:35:07 PM) simo: yeah I don;t know, I didn't implement it (02:35:15 PM) sgallagh: I think jhrozek did (02:35:30 PM) sgallagh: His is the only name in 'git blame ipa_timerules.c' at least :) (02:35:56 PM) sgallagh: jhrozek: Are you around? (02:38:55 PM) simo: sgallagh, reading the grammar further I think that example is wrong (02:38:57 PM) sgallagh: simo: Ok, we need to change the formal grammar to one or the other of these two approaches: a better-specified range, or a start and duration (02:39:21 PM) sgallagh: Monthly = "monthly" WSP M-specifier WSP HHMM WSP "~" WSP HHMM (02:39:31 PM) sgallagh: Looks like it matches to me (02:39:38 PM) simo: the grammar calls for dates to be separated by ~ 14:40 (02:40:02 PM) sgallagh: Well, ok. Yeah, the hyphen should be ~ (02:40:14 PM) sgallagh: Otherwise it matches, I think (02:40:40 PM) simo: ah no (02:40:40 PM) simo: I read it wrong (02:40:50 PM) sgallagh: HHMM ~ HHMM (02:41:57 PM) simo: I think your proposal to fix periodic are fine anyway (02:42:15 PM) simo: sgallagh, just make sure you take in account "local" time vs UTC time (02:42:36 PM) sgallagh: simo: Which proposal do you mean? Duration or fixing the ranges? (02:42:43 PM) sgallagh: Both would work (02:43:21 PM) sgallagh: simo: According to the grammar spec, all periodic events are specified for "local" and all absolute events are UTC (02:43:31 PM) simo: we wanted to be able to say 9:00-16:00 "local" time as well as "9:00-16:00 UTC" (02:43:37 PM) simo: they are 2 very different things (02:43:44 PM) sgallagh: I know that they are (02:43:52 PM) sgallagh: Unless of course you happen to live in Greenwich, of course (02:44:24 PM) simo: sgallagh, exactly but I gues that even in "local" time you may still want to cross to the next day for a range (02:44:29 PM) sgallagh: simo: However, that's not how the grammar is defined right now (02:44:42 PM) sgallagh: And THAT may be a sizeable change (02:44:43 PM) simo: it's only that I've seen someone saying the the local time would be converted into UTC mixed with the periodic discussion and that din't make sense (02:44:53 PM) sgallagh: huh? 14:45 (02:45:23 PM) sgallagh: As it's described right now, ALL periodic values are treated as local on the machine receiving them. (02:45:31 PM) simo: sgallagh, the grammar says periodic is always local (02:45:37 PM) sgallagh: There is no specifier for UTC vs. local (02:45:39 PM) simo: absolute always UTC (02:45:39 PM) sgallagh: I just said that (02:45:54 PM) sgallagh: So what are you asking me to change? (02:46:12 PM) simo: local means 9-16 of the client, ie dependent on the timezone the client is in (02:46:24 PM) simo: sgallagh, exactly (02:46:27 PM) sgallagh: If we're going to allow periodic events to be specified in UTC, that's a sizeable change to the parser/evaluator (02:46:49 PM) sgallagh: Is that what you're asking for? (02:46:56 PM) simo: yeah but you also discussed how to convert from Sun 22:00-23:59 + Mon 00:00-04:00 to UTC (02:47:05 PM) simo: which didn't make sense to me (02:47:14 PM) simo: sgallagh, again I am not saying I want to (02:47:22 PM) simo: just that I've seen people discussing conversions to UTC for ranges that span over the midniaght (02:47:25 PM) simo: and it *shouldn't* make sense to discuss those with this grammar (02:47:42 PM) sgallagh: I didn't say anything about that. You're confusing me (02:47:59 PM) simo: sgallagh, ok let's just forget about that for now (02:48:03 PM) sgallagh: Forgotten :) (02:48:24 PM) simo: sgallagh, but the UI muct be ultraclear that the time is the time on the target machine (02:48:35 PM) simo: for periodic events (02:49:11 PM) simo: so if you assigne the HBAC to a group of machines and they are not in the same timezone then the admin must understand the rule will not apply to all machines at the same time (02:49:49 PM) simo: I do not know how to make that clear in the UI but I think we must make sure Ben understand the difference between local/periodic and UTC/absolute 14:50 (02:50:04 PM) sgallagh: simo: Direct that at ayoung. I'm only concerned about the grammar and its impact on SSSD. How it's presented to the user is outside my job description right now (02:51:04 PM) simo: sgallagh, uh right :-) (02:51:10 PM) simo: and ayoung conveniently left :) (02:51:34 PM) sgallagh: simo: I'm going to write up a proposal for the changes to the grammar and send it to the list.
hbac_timerules_discussion.txt.sig
Description: PGP signature
_______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
