*** david-lyle has joined #craton | 00:08 | |
*** david-lyle has quit IRC | 00:15 | |
*** david-lyle has joined #craton | 00:54 | |
*** david-lyle has quit IRC | 00:54 | |
*** Syed__ has quit IRC | 00:55 | |
*** david-lyle has joined #craton | 01:52 | |
*** VW has joined #craton | 02:17 | |
*** VW_ has joined #craton | 02:18 | |
*** VW has quit IRC | 02:21 | |
*** VW_ has quit IRC | 04:14 | |
*** VW has joined #craton | 05:12 | |
*** VW has quit IRC | 06:54 | |
sulo | o/ | 10:08 |
---|---|---|
openstackgerrit | git-harry proposed openstack/craton master: Add http_codes decorator where missing https://review.openstack.org/443565 | 10:56 |
openstackgerrit | git-harry proposed openstack/craton master: Validate parent_id is neither id nor a descendant https://review.openstack.org/443566 | 10:56 |
sulo | git-harry: https://review.openstack.org/#/c/443565 i wonder if any tests were missing for those method for how exeption were handled .. or would that not matter (with or without http_codes) ? | 11:59 |
git-harry | sulo: I added that so that my tests in https://review.openstack.org/#/c/443566/ would be testing for 400 instead of 500. Yes, there is are additional tests that could be made. I marked the commit as a partial fix because I was only doing the minimum and there is an existing bug to address this properly | 12:01 |
sulo | git-harry: rgr, i didnt catch the partial-fix part | 12:02 |
*** VW has joined #craton | 13:10 | |
openstackgerrit | Sulochan Acharya proposed openstack/craton master: Adds project/user bootstrap command to dbsync https://review.openstack.org/443170 | 14:13 |
*** VW has quit IRC | 14:17 | |
*** VW has joined #craton | 14:18 | |
*** VW has quit IRC | 14:18 | |
*** VW has joined #craton | 14:18 | |
openstackgerrit | Sulochan Acharya proposed openstack/craton master: Adds project/user bootstrap command to dbsync https://review.openstack.org/443170 | 14:26 |
fsaad | morning all | 14:41 |
thomasem | hihi | 15:00 |
sulo | morning fsaad, thomasem | 15:05 |
sulo | git-harry: are you going to take this: https://bugs.launchpad.net/craton/+bug/1665015 | 15:06 |
openstack | Launchpad bug 1665015 in craton "All text errors reported by the Craton REST API should be JSON encoded" [High,New] | 15:06 |
sulo | ? | 15:06 |
sulo | otherwise i can poke on that ... i dont have anything else i am looking at right now | 15:06 |
thomasem | sulo: git-harry: sigmavirus and I were looking at https://flask-restful-cn.readthedocs.io/en/0.3.5/extending.html#resource-method-decorators or https://flask-restful-cn.readthedocs.io/en/0.3.5/extending.html#custom-error-handlers for that. | 15:06 |
thomasem | sigmavirus's preference (and mine too) was the former. | 15:07 |
thomasem | And we already use that here: https://github.com/openstack/craton/blob/master/craton/api/v1/base.py#L23 | 15:07 |
git-harry | sulo: I can pick it up, I probably should given I've already done a bit. | 15:08 |
thomasem | sulo: added a question, a couple nits, and one bug I found on your bootstrap/dbsync patch. | 15:08 |
sulo | git-harry: rgr | 15:08 |
sulo | thomasem: cool, thanks | 15:08 |
thomasem | You bet. Sorry I didn't get a chance to look more thoroughly until today. | 15:09 |
sulo | thomasem: lol, thats wrong thing i uploaded | 15:10 |
sulo | thomasem: thanks for catching that .. | 15:11 |
thomasem | Sure thing! | 15:11 |
thomasem | Lol :P | 15:11 |
sulo | thomasem: but the rest of the suggestion is good .. ill make those changes too | 15:14 |
sulo | thomasem: actually, re: defaulting to some sane value .. not sure it will work for user | 15:19 |
sulo | since project id is required | 15:20 |
*** valw has joined #craton | 15:22 | |
*** Syed__ has joined #craton | 15:23 | |
*** valw has quit IRC | 15:28 | |
*** valw has joined #craton | 15:31 | |
thomasem | sulo: maybe default-bootstrap creates a project and uses that project ID? | 15:32 |
thomasem | And then we leave around bootstrap-user until we can create root users via the API? | 15:33 |
thomasem | Yeah.. it's tricky. I'm not wild about the requirement to have a root user associated with a project, lol. | 15:33 |
sulo | thomasem: so add a new default-bootstrap command ? | 15:33 |
thomasem | Yeah, as the "easy" button. | 15:33 |
thomasem | And then we can address the others as we shore up gaps in the API. | 15:34 |
thomasem | The problem is: I don't want deployers to get the wrong impression and over-use bootstrap-user/bootstrap-project when we really want that stuff to go through the API once it's deployed and configured. | 15:34 |
thomasem | s/deployers/operators/ | 15:35 |
thomasem | So, that's where my suggestions are coming from. The most common case that I see is someone deploys Craton and wants their initial credentials. | 15:35 |
sulo | thomasem: yeah i guess thats a valid way to look at it | 15:35 |
thomasem | From there they can create projects and users via the API. | 15:35 |
sulo | thomasem: so, hrm, the problem with that is | 15:36 |
thomasem | Anybody going in after-the-fact and doing out-of-band project/user creation runs the risk of messing some things up. | 15:36 |
thomasem | Since it goes around the API | 15:36 |
sulo | we still need the user and project creation so that | 15:36 |
sulo | raw mysql is not needed anymore | 15:36 |
sulo | like in docker_run.sh | 15:36 |
thomasem | If we fix the API, it won't be. | 15:36 |
thomasem | You could make API calls instead. | 15:37 |
thomasem | once the initial bootstrap is done | 15:37 |
thomasem | Which is why I say I'm cool w/ leaving it in for now, but I think we ought to address the API being able to create root users, too. Once that's done, we can use the default bootstrap to get a user for development scripts and such to simply call the API to set up the rest. | 15:37 |
sulo | how do you mean fix the api ? | 15:38 |
thomasem | The only issue I saw so far is you can't create root users with the API. | 15:38 |
thomasem | Other than that, it'll work just fine. | 15:38 |
thomasem | You would use dbsync to get your initial credentials | 15:38 |
thomasem | then use those credentials to set up other users and projects as needed. | 15:38 |
sulo | right | 15:38 |
thomasem | Which would eliminate the need for bootstrap-project and bootstrap-user via dbsync | 15:39 |
thomasem | And the only thing you'd need then is a default bootstrap to start with. | 15:39 |
thomasem | But, again, until we support creating root users via the API, that won't solve the case entirely. | 15:39 |
sulo | actually | 15:39 |
sulo | this prolly works now | 15:39 |
sulo | the need to have those user in docker_run was func tests | 15:39 |
sulo | and we prolly dont need it anymore | 15:40 |
sulo | so just ahving a default bootstrapped user should do just fine | 15:40 |
thomasem | I'm cool w/ that, too. | 15:40 |
thomasem | :) | 15:40 |
thomasem | I don't mind generate_fake_data setting up the other users for us. | 15:40 |
thomasem | for dev purposes | 15:40 |
thomasem | If that makes sense. | 15:40 |
thomasem | You can always use the initially bootstrapped user for root things in dev | 15:41 |
thomasem | and the functional tests set up their own things separately, intentionally. | 15:41 |
thomasem | iiuc. | 15:41 |
sulo | the initial user should work for every use case i think | 15:41 |
thomasem | I think so, too. | 15:41 |
sulo | alright, let me fix this up quickly, thanks for the suggestion | 15:42 |
thomasem | Sure thing! | 15:42 |
*** VW has quit IRC | 16:08 | |
jimbaker | sulo, thomasem, as long as we generate the bootstrap user with cryptographic strong api_key; and the bootstrap project id is a UUID that's generated; and we only override for testing, i'm good | 16:11 |
jimbaker | i think the easy button is the right approach | 16:11 |
jimbaker | and the rest api should only be used to create additional users/projects | 16:12 |
jimbaker | let's rephrase that' | 16:12 |
jimbaker | only the rest api should be... | 16:12 |
jimbaker | using a backchannel, not a good idea | 16:12 |
jimbaker | this will only get more interesting as we add rbac. the prototype code on that blueprint assumes model support because it's even more associations to set up | 16:13 |
jimbaker | also glad to see the feedback to fsaad's email. however we should open this up as well to others to discuss. it's really belongs on openstack-dev [craton] | 16:14 |
jimbaker | but we can revisit - no need to forward to that list | 16:15 |
sulo | jimbaker: whats this cryptographic strong api_key ? | 16:16 |
jimbaker | also this discussion is related to the session in milan in two weeks - https://etherpad.openstack.org/p/MIL-ops-inventory-and-fleet-management | 16:16 |
jimbaker | sulo, for the user | 16:17 |
sulo | i mean whats the difference between that and uuid? | 16:17 |
jimbaker | sulo, a uuid is highly predictable | 16:17 |
jimbaker | we cannot use a uuid as a secret. ever | 16:17 |
jimbaker | might as well have the secret be "password" | 16:18 |
sulo | jimbaker: so we are going to introduce this in the server code ? | 16:18 |
jimbaker | sulo, we need to do it for all users in terms of api_key gen, so yes | 16:19 |
jimbaker | the alternative is the user provides a secret, and we need to securely hash (with salting, rounds, etc) on it | 16:19 |
jimbaker | again, this is for the no keystone case | 16:20 |
jimbaker | but we should still be reasonable about our security | 16:20 |
fsaad | jimbaker: feel free to forward/add people to thread btw, meant to put that in e-mail, knew I Wasn't covering all that was needed | 16:21 |
jimbaker | https://cryptography.io/en/latest/fernet/#using-passwords-with-fernet is the way to go for this byw | 16:21 |
sulo | yeah, can you create a bug for this | 16:21 |
sulo | should be a straight forward thing to fix | 16:22 |
jimbaker | sulo, for the general user case? sure. we can just use a token gen as the default value for api_key in the model | 16:22 |
jimbaker | we can override to make it a specific known secret for testing. or we can our testing slightly smarter | 16:22 |
sulo | token gen ? from secrets ? | 16:23 |
jimbaker | this is why i suggested the whole eval $(dbsync some-command-that-does-get-or-create-my-project-and-user) approach | 16:23 |
jimbaker | for bootstrap | 16:24 |
jimbaker | so we could populate OS_PROJECT_ID, OS_PASSWORD, OS_USERNAME | 16:24 |
jimbaker | sulo, so the secrets module is python 3.6 | 16:24 |
sulo | yeah i know | 16:24 |
jimbaker | but it's obviously trivial - really just doing it the right way | 16:24 |
jimbaker | just need to ensure we use os.urandom | 16:25 |
sulo | anyway, i am reading up on some uuid gen | 16:25 |
jimbaker | os.urandom is *the way* to get random entropy | 16:25 |
sulo | i thought they were done the same way using random num gen | 16:25 |
sulo | brb | 16:25 |
jimbaker | uuid gen does not guarantee enough entropy | 16:25 |
jimbaker | yeah, me too | 16:26 |
jimbaker | biab | 16:26 |
*** jovon has joined #craton | 16:52 | |
jimbaker | also milan is next week! timing is good, but we need to prepare to help tojuvone; i added to agenda for today | 16:58 |
jimbaker | so ready? | 17:00 |
thomasem | #startmeeting craton | 17:00 |
openstack | Meeting started Thu Mar 9 17:00:12 2017 UTC and is due to finish in 60 minutes. The chair is thomasem. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:00 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:00 |
openstack | The meeting name has been set to 'craton' | 17:00 |
thomasem | #chair sigmavirus sulo jimbaker thomasem | 17:00 |
openstack | Current chairs: jimbaker sigmavirus sulo thomasem | 17:00 |
thomasem | #link https://etherpad.openstack.org/p/craton-meetings | 17:00 |
thomasem | #topic Roll Call | 17:00 |
jimbaker | o/ | 17:00 |
fsaad | o/ | 17:00 |
thomasem | o/ | 17:00 |
antonym | o/ | 17:00 |
sulo | o/ | 17:00 |
git-harry | hi | 17:00 |
tojuvone | hi | 17:01 |
jovon | o/ | 17:01 |
thomasem | #topic Roadmap planning - email to openstack-dev [craton] | 17:02 |
jimbaker | should we start with that? | 17:02 |
thomasem | It's on the list | 17:02 |
jimbaker | i understand, but maybe consume our standing agenda first - namely standup/reviews | 17:03 |
jimbaker | but it's ok, we can start here | 17:03 |
*** VW has joined #craton | 17:03 | |
thomasem | Nah, i'm cool w/ that. The template needs to be updated | 17:03 |
thomasem | if we're wanting to do something different for this meeting. | 17:03 |
thomasem | #undo | 17:03 |
openstack | Removing item from minutes: #topic Roadmap planning - email to openstack-dev [craton] | 17:03 |
thomasem | #topic Stand Up | 17:03 |
thomasem | #info each team member briefly describes what they are working on this week, and describes blockers (if there are any) | 17:04 |
thomasem | #topic Stand Up :: jimbaker | 17:04 |
jimbaker | i have two changes to fix up, namely var search respecting resolution (will block thomasem's work since dependency); alembic schema | 17:05 |
jimbaker | also some outstanding discussion re bootstrap | 17:05 |
jimbaker | look forward to today's road map discussion, because we need to get that onto openstack-dev | 17:06 |
thomasem | +1 | 17:06 |
jimbaker | and we also have a forthcoming meeting by the openstack-operators in milan, which tojuvone needs our help prepping him for | 17:06 |
jimbaker | (it's a team effort!) | 17:06 |
jimbaker | dome | 17:06 |
jimbaker | done | 17:06 |
thomasem | #topic Stand Up :: fsaad | 17:07 |
fsaad | think I'll pass, other than a constructive meeting yesterday to get the loading script approved for demo by sulo/tim, and get the ball rolling for the roadmap meeting tuesday | 17:08 |
fsaad | done | 17:08 |
thomasem | #topic Stand Up :: thomasem | 17:09 |
*** zz_pwnall1337 is now known as pwnall1337 | 17:09 | |
thomasem | Overcoming the nuances I run into as I'm continuing to work on JSON path-like variables querying and made a fair amount of progress, found there are some existing sqlalchemy functions that may help with this, namedly func.json_contains and func.json_extract; plugging away at code reviews, too; | 17:10 |
thomasem | done | 17:10 |
thomasem | #topic Stand Up :: antonym | 17:10 |
antonym | sure, i've been poking around on craton a bit, mainly testing a use case for provisioning servers. been taking some stuff we did internal at rax for public cloud and porting it over to craton | 17:11 |
antonym | https://github.com/antonym/plip <- takes variables from craton given an id and converts them into variables that can be populated into iPXE for scripting server boot | 17:12 |
antonym | done | 17:12 |
jimbaker | antonym, like to hear that experience report | 17:13 |
thomasem | +1 | 17:13 |
jimbaker | topic after standup? | 17:13 |
thomasem | #topic Stand Up :: sulo | 17:13 |
antonym | sure we can catch up after | 17:13 |
sulo | i am finishing up the patch adding bootstrap command to dbsync | 17:13 |
*** valw has quit IRC | 17:13 | |
sulo | will pick up something else from the milestone list after | 17:14 |
sulo | done | 17:14 |
thomasem | #topic Stand Up :: git-harry | 17:14 |
git-harry | Patches are up for https://bugs.launchpad.net/craton/+bug/1666536 | 17:15 |
openstack | Launchpad bug 1666536 in craton "Cyclical hierarchies using parent_id" [Critical,In progress] - Assigned to git-harry (git-harry) | 17:15 |
git-harry | Now working on https://bugs.launchpad.net/craton/+bug/1665015 | 17:15 |
openstack | Launchpad bug 1665015 in craton "All text errors reported by the Craton REST API should be JSON encoded" [High,New] - Assigned to git-harry (git-harry) | 17:15 |
git-harry | done | 17:15 |
thomasem | #topic Stand Up :: tojuvone | 17:15 |
tojuvone | Well I just worked the docker doc | 17:15 |
tojuvone | and now would be interested to have the milan etherpad in shape | 17:16 |
jimbaker | so that's a blocker for you | 17:16 |
tojuvone | docker install | 17:16 |
thomasem | Wait, which is a blocker? | 17:17 |
jimbaker | thomasem, milan etherpad | 17:17 |
thomasem | Gotcha | 17:17 |
thomasem | Okay, cool | 17:17 |
jimbaker | but will be discussed momentarily as a separate topic... | 17:17 |
tojuvone | Yes, to know what we like to shere there about Craton | 17:17 |
tojuvone | yep | 17:17 |
thomasem | Sound good! | 17:17 |
tojuvone | done | 17:18 |
thomasem | #topic Stand Up :: jovon | 17:18 |
jovon | while I have investigated and experimented with several tools (beyond RAML) for simplified doc generation, most existing methods are not as comprehensive as manual generation especially for API documented in .rst format, which was a requirement of this study | 17:19 |
jimbaker | jovon, cool, maybe we can explore in a forthcoming meeting? | 17:21 |
jovon | sounds good | 17:21 |
jimbaker | i suggest you put this on the agenda | 17:21 |
jovon | +1 | 17:21 |
jovon | done | 17:21 |
thomasem | Cool. Ready to go into topics now? | 17:22 |
jimbaker | yes | 17:22 |
thomasem | #topic Roadmap planning - email to openstack-dev [craton] | 17:22 |
jimbaker | fsaad, git-harry, sulo - probably want to start with you on this | 17:23 |
thomasem | fsaad: I know we discussed this at length yesterday. Sounds like we're basically wanting to bring the idea to the group that we turn the Tuesday meeting into an alternation between retrospective and planning... | 17:23 |
thomasem | And start thinking about what we want to be when we grow up | 17:23 |
fsaad | that sounds good to me, with an additional 30 mins per email suggestion | 17:24 |
jimbaker | 30 min earlier sounds good | 17:24 |
jimbaker | to better accommodate UK | 17:24 |
thomasem | +1 | 17:24 |
fsaad | +1 | 17:24 |
jimbaker | and finland for that matter :) | 17:24 |
tojuvone | +1 :) | 17:24 |
thomasem | I updated the etherpad accordingly | 17:25 |
thomasem | Not sure where else that needs to be updated? | 17:25 |
jimbaker | the net of it seems: 1) figure out our high level goals. so cmdb for sure. but do need to integrate with workflows? (i believe we do...) | 17:26 |
thomasem | The question wasn't about integration, it was about whether they both belong in the same project. | 17:26 |
thomasem | s/project/repository/ | 17:26 |
jimbaker | thomasem, ok. fair enough | 17:26 |
jimbaker | so one possibility that i think may make sense is that the db aspects of workflows should be in the same project | 17:27 |
jimbaker | but the specific worker implementation - celery? taskflow? - is pluggable | 17:27 |
jimbaker | just throwing it out there | 17:27 |
thomasem | Lemme scare up some stuff here | 17:27 |
jimbaker | fwiw - when we first started the project, we had it more decoupled than it is now | 17:27 |
jimbaker | so just want to say there is some history here | 17:28 |
thomasem | What was the original reason for including workflows in the same repository as the craton API? | 17:28 |
jimbaker | mostly because craton is not so big | 17:28 |
thomasem | Is there any technical reason? | 17:28 |
jimbaker | and it's not clear to me we need to make this distinction | 17:28 |
jimbaker | clearly we can always link | 17:29 |
jimbaker | the major technical reason however | 17:29 |
thomasem | What I mean is, can the workflow engine utilize the Craton API? | 17:29 |
jimbaker | is that we want our models to be shared | 17:29 |
thomasem | Ah | 17:29 |
thomasem | So, why's that necessary? | 17:29 |
jimbaker | because simplicity. not necessity | 17:29 |
thomasem | What if the workflow engine was a client of the Craton API? | 17:29 |
jimbaker | thomasem, so the engine itself, yes | 17:30 |
git-harry | We seem to be discussing specific roadmap items, was that the purpose of this topic? | 17:30 |
fsaad | think that's what the tue meeting is for :) | 17:30 |
thomasem | git-harry: you're correct, we can punt this discussion to that. | 17:30 |
jimbaker | the question is, are there supporting model aspects, such as how rbac works, where it would be simpler to have a workflow model in the same model as users, the things that the workflow is for | 17:30 |
jimbaker | i certainly agree here! | 17:31 |
jimbaker | with git-harry and fsaad | 17:31 |
git-harry | So I still believe that we (Rackspace employees) need to be pushing for a roadmap that advances Rackspace goals. Until we have that internal discussion, I don't believe we can effectively (from the perspective of Rackspace) guide the direction of the project. | 17:31 |
thomasem | Okay. Let's table this for a more involved discussion of roadmap items. | 17:31 |
jimbaker | git-harry, well sulo and i are technically part of OSIC | 17:31 |
thomasem | (I am, too) | 17:32 |
jimbaker | and tojuvone is at nokia | 17:32 |
fsaad | works. Like I mentioned my intent is to gather consensus on the end goal so that we can break apart in pieces needed to get us there | 17:32 |
thomasem | (I found out) | 17:32 |
jimbaker | cool | 17:32 |
jimbaker | so we have to put on our upstream hats :) | 17:32 |
jimbaker | that rackspace is the first customer, this is awesome | 17:32 |
jimbaker | of course we are going to work very closely with our customers. everyone should expect that | 17:33 |
jimbaker | and i think the biggest prioritization we see is cmdb | 17:34 |
jimbaker | guess what, this is the most important thing for nokia too. win win! | 17:34 |
fsaad | o/ | 17:34 |
tojuvone | I just spoke today with Vitrage, and they should be happy to have notifications from Craton. | 17:34 |
jimbaker | and notifications are essential for rackspace too | 17:34 |
tojuvone | Also putting up feature where Craton coudl update something on Nova | 17:34 |
jimbaker | and webhooks on the rackspace side, which is we can implement | 17:35 |
jimbaker | *how we can* | 17:35 |
thomasem | ^^ fits under workflow engine umbrella, btw. | 17:35 |
thomasem | at least that's my opinion :) | 17:35 |
tojuvone | yes, workflow + notif | 17:35 |
openstackgerrit | Sulochan Acharya proposed openstack/craton master: Adds project/user bootstrap command to dbsync https://review.openstack.org/443170 | 17:35 |
tojuvone | and namespace | 17:36 |
jimbaker | thomasem, fwiw not as we originally envisioned. but highly open to other ways to get there | 17:36 |
antonym | sulo: yay | 17:36 |
thomasem | Alright, so these are things that we need to collect and get into, say, Story Board. | 17:36 |
sulo | antonym: heh, hopefully that will help a bit :) | 17:37 |
jimbaker | thomasem, everything here is in a blueprint or bug | 17:37 |
thomasem | Okay, good. | 17:37 |
jimbaker | but yes, moving to storyboard will help highlight it much better | 17:37 |
jimbaker | and needs to be done regardless | 17:37 |
thomasem | Alright. So, what did we want to get out of discussing this topic today? | 17:38 |
jimbaker | and especially capture details like, yes we need notifications. but let's link to a specific way to implement | 17:38 |
fsaad | I think a 10k foot view of the goal was a good start but I learned that's going to be more involved than I thought. | 17:38 |
jimbaker | thomasem, i think the key thing for us is to bring this up so we can start thinking about 1) that email to openstack-dev; 2) corresponding planning during tues meeting | 17:38 |
jimbaker | fsaad, hah, yes | 17:39 |
fsaad | so, seems like we at least got the time and recurrency of it mostly OK'd, every tuesday, half hour earlier | 17:39 |
thomasem | Yep | 17:39 |
fsaad | and do sprint plan one week and retrospective the next ? | 17:39 |
jimbaker | fsaad, not every tues | 17:39 |
jimbaker | just next week's meeting | 17:39 |
jimbaker | i think we are good with the slot time for now, until we find otherwise | 17:39 |
thomasem | jimbaker: Ah... so the proposal was for changing the purpose of that meeting, since it's really become more of an extension of Monday's meeting, really. | 17:40 |
fsaad | same | 17:40 |
jimbaker | thomasem, it has become an extension of monday's meeting | 17:40 |
jimbaker | so backing up | 17:40 |
jimbaker | originally we had tues & thurs meetings that were dev focused; monday was to be focused on the wider community | 17:40 |
jimbaker | communicate with them, here's what we are doing | 17:41 |
jimbaker | except it turned out that only the devs were showing up for monday's meeting. so we repurposed accordingly | 17:41 |
pwnall1337 | hosts/id/variables doesn't do pagination right? | 17:41 |
pwnall1337 | just giant wall of text | 17:41 |
jimbaker | pwnall1337, no pagination, correct | 17:41 |
pwnall1337 | thanks | 17:41 |
thomasem | jimbaker: Okay, so, are you against us changing the purpose to planning/retro alternating? | 17:42 |
jimbaker | to be honest, i think the monday meeting works well | 17:42 |
jimbaker | thomasem, for tues, i think it works to look at planning/retrospective | 17:42 |
jimbaker | i just don't expect it to take 90 minutes every single tues that's all | 17:43 |
thomasem | We could just keep it at an hour and increase if we find it's not enough? | 17:43 |
fsaad | cool we can kick jokes and drink coffee for the remaining for team bonding | 17:43 |
jimbaker | but we have built up quite a backlog | 17:43 |
fsaad | I mean, cut it short and get back to work | 17:43 |
fsaad | :P | 17:43 |
thomasem | lol fsaad | 17:43 |
sulo | start early, add that 30 min and end early if needed | 17:44 |
sulo | it does not work well for UK folks to extend | 17:44 |
jimbaker | sulo, correct | 17:44 |
sulo | if we ever have to do that | 17:44 |
jimbaker | so i don't think we need to do extend. except next tues | 17:44 |
jimbaker | and we are extending early of course :) | 17:45 |
sulo | yeah, i agree .. i dont think it will take that long every tues | 17:45 |
*** valw has joined #craton | 17:45 | |
jimbaker | so let's see. we can always revisit. but next tues starts 30 min early | 17:45 |
thomasem | I'm personally fine with either. I imagine we'll adjust as needed. | 17:46 |
sulo | is this open discussion | 17:46 |
fsaad | also lemme know if I need to do anything with the storyboard, I hopped on yesterday and seems I can create a new board but I'm not sure that's what we need | 17:46 |
jimbaker | sulo, we somehow drifted here | 17:46 |
thomasem | But, there is a need for planning/retro on a regular basis since we're getting into a more formal process for developing according to a roadmap. | 17:46 |
jimbaker | we were discussing openstack-dev email | 17:46 |
thomasem | And this allows us to not add on additional meetings | 17:46 |
sulo | thomasem: agreed | 17:46 |
jimbaker | re roadmap | 17:47 |
jimbaker | and i think the point is: that's tuesday | 17:47 |
thomasem | yep | 17:47 |
sulo | did we decide to sprint or is that up for discussion next meeting | 17:47 |
thomasem | It'll resemble sprints, sans story points (I hope). | 17:47 |
jimbaker | sulo, so we were discussing yesterday | 17:47 |
jimbaker | yeah, no need for story points | 17:47 |
jimbaker | but the net of it was, two week iterations | 17:48 |
jimbaker | we will see if that's workable or not for this project. but it's more of a question of 2 weeks, or longer; not shorter | 17:48 |
jimbaker | i don't think any of our tasks are adjust the web interface type of stuff | 17:48 |
git-harry | I'd vote for more of a kanban based approach, I don't know if storyboard supports it. | 17:49 |
jimbaker | well it is a board... | 17:49 |
thomasem | git-harry: +1, I am hoping the planning is simply for us to prioritize things regularly. | 17:49 |
jimbaker | interestingly it's possible to support multiple board views, which hopefully can help us look at stuff from a customer perspective | 17:50 |
jimbaker | not to mention integration with say what rackspace is doing via supposedly an easy to use API | 17:50 |
thomasem | so, how about we go the Kanban route and use planning/retro just as regular checkpoints to be sure things are prioritized and we're continuously improving our process | 17:50 |
jimbaker | (but has to be better than the LP API) | 17:50 |
sulo | so thomasem git-harry jimbaker fsaad do we need to decide on kanban sprint somethingelse ? | 17:50 |
sulo | combo of | 17:51 |
fsaad | not right now, I'll get my learn on kanban cause I've only done pseudo sprints (no points) | 17:51 |
jimbaker | thomasem, yeah, i think that's the combo approach right | 17:51 |
fsaad | then can probably have more educated conversation | 17:51 |
thomasem | jimbaker: I guess? Agile's pretty bastardized these days. | 17:51 |
jimbaker | true sprints have everything aligned on two week iterations | 17:51 |
jimbaker | or something. i don't know | 17:51 |
thomasem | I think we'll just start with the raw clay and mold what we want as we go | 17:52 |
thomasem | This sounds like a good starting point. | 17:52 |
jimbaker | whereas we will likely do the bastardized approach. the raw clay in other words | 17:52 |
*** valw has quit IRC | 17:52 | |
thomasem | As long as the process works for us and not the other way around, we should be okay. | 17:52 |
jimbaker | personally i think what we have been doing is pretty good. we just need more roadmap clarity. and more roadmap adjustment. hence the two week retro/planning | 17:53 |
thomasem | Who will draft up the e-mail to openstack-dev? | 17:53 |
sulo | right, so are we doign to discuss that tues too ? | 17:53 |
jimbaker | thomasem, i suggest we start with fsaad's email thread, and edit accordingly. most important | 17:53 |
jimbaker | it must link against our corresponding blueprints | 17:53 |
jimbaker | even better: what if it did this against storyboard? ... | 17:53 |
jimbaker | win! | 17:53 |
jimbaker | from a public relations perspective | 17:54 |
thomasem | We only have 6 minutes for remaining topics. :\ | 17:54 |
sulo | are we discussing what our process is next tuesday too ?? | 17:54 |
sulo | fsaad: ^^ | 17:54 |
jimbaker | sulo, absolutely | 17:54 |
jimbaker | hence extra time | 17:54 |
sulo | lets make sure we have enough time for that + discussing priority work | 17:54 |
jimbaker | but we should be prepped to do so | 17:54 |
fsaad | well, collation of items from thread is a starting point | 17:55 |
jimbaker | again tues is better. mon morning is rough to have a planned agenda | 17:55 |
jimbaker | so this repurposing is much more realistic | 17:55 |
fsaad | discussion of them I mean, and write up a draft of what we want to see as end game | 17:55 |
fsaad | I agree we should have an agenda to keep focus | 17:55 |
thomasem | Sounds good. Can we take the rest of this into #craton after this meeting so we can get to tojuvone's topic? | 17:56 |
jimbaker | so basically this meeting, plus the current emai threadl - should be a good start | 17:56 |
*** pwnall1337 is now known as zz_pwnall1337 | 17:56 | |
jimbaker | thomasem, +1 | 17:56 |
thomasem | #topic Upcoming meeting in Milan (March 15/16) - need to craft agenda/talking points for https://etherpad.openstack.org/p/MIL-ops-inventory-and-fleet-management | 17:56 |
fsaad | cool, need to step away but will catch up in a bit, thanks guys | 17:56 |
thomasem | tojuvone: take it away | 17:56 |
thomasem | fsaad: cheers! | 17:56 |
*** zz_pwnall1337 is now known as pwnall1337 | 17:56 | |
jimbaker | i can also discuss - this is effectively the same thing as the email, plus what we have done so far (which would be a great thing to include in that email) | 17:57 |
jimbaker | but in the context of engaging with our previous meeting at the op summit in nyc | 17:57 |
*** valw has joined #craton | 17:57 | |
jimbaker | + barcelona | 17:57 |
jimbaker | we need to take concrete use cases | 17:58 |
jimbaker | such as maintenance mgmt, and describe mapping to craton | 17:58 |
jimbaker | another good example: antonym's work on plip | 17:58 |
jimbaker | and of course the use cases we have been recently working through, and corresponding demo | 17:59 |
tojuvone | I will have the maintenance MIL-ops-telco-nfv | 17:59 |
*** valw has quit IRC | 17:59 | |
jimbaker | tojuvone volunteered to lead this session on behalf of craton, since he will be in milan. but we need to fully support him | 17:59 |
jimbaker | thomasem, we are over our time limit... | 18:00 |
thomasem | Yep | 18:01 |
tojuvone | so what we want to share there. Some current status, roadmap | 18:01 |
jimbaker | anyway, let me conclude: let's just all look at the etherpad | 18:01 |
thomasem | Lol yeah | 18:01 |
thomasem | #endmeeting | 18:01 |
openstack | Meeting ended Thu Mar 9 18:01:39 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:01 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-03-09-17.00.html | 18:01 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-03-09-17.00.txt | 18:01 |
openstack | Log: http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-03-09-17.00.log.html | 18:01 |
jimbaker | fsaad, thomasem, probably the best way to craft that email is put in an etherpad too | 18:02 |
tojuvone | So if there doesn't naturally come Discussion items to etherpad | 18:02 |
jimbaker | so we can extract that content, discuss here, and have something great to discuss | 18:02 |
tojuvone | Then I could share what we have today and what is next | 18:02 |
jimbaker | tojuvone, +1, sounds like a great plan | 18:03 |
thomasem | tojuvone: yeah, we can fill in with use-cases we have been working towards, some known future goals, maybe record our demo? | 18:03 |
jimbaker | thomasem, +1, at least it's on the etherpad | 18:03 |
jimbaker | even if tojuvone doesn't have a chance to play | 18:03 |
tojuvone | But still it is something you guys are the best to come up with | 18:03 |
jimbaker | tojuvone, agreed | 18:04 |
tojuvone | I can have Craton up and running and could demonstrate some | 18:04 |
thomasem | That'd be good. | 18:04 |
tojuvone | Surely if the internet access there happens to work ;) | 18:04 |
tojuvone | not running on local laptop I mean | 18:05 |
thomasem | LOL | 18:05 |
jimbaker | i hope whoever planned that meeting in MIL thought about internet. but it something that we can never count on even then | 18:05 |
jimbaker | yeah, so local laptop is good | 18:05 |
jimbaker | i like the idea of showing off plip. putting antonym on the spot of course... | 18:06 |
tojuvone | So have my linux machines at office and can do remote to there | 18:06 |
thomasem | When is this event, btw? | 18:06 |
jimbaker | mar 15 & 16 | 18:06 |
thomasem | Oh wow | 18:06 |
jimbaker | like real soon now! | 18:06 |
thomasem | Okay | 18:06 |
thomasem | Seriously | 18:06 |
thomasem | Lol | 18:06 |
antonym | jimbaker: there's not really much to it, just lets me make jinja templates really, https://gist.github.com/antonym/14a7da3b302fc77f9e772ae3cc1bd3f3 | 18:07 |
jimbaker | we have been sort of focused on rpc support | 18:07 |
thomasem | Alright, I'll make a note to review. Do we already have the Craton etherpad made? This is a template. | 18:07 |
tojuvone | So if there would be ready set of CLI commands and DB, could show there features we want to show | 18:07 |
thomasem | https://etherpad.openstack.org/p/MIL-ops-Craton, right? | 18:07 |
tojuvone | No, there is jsut template | 18:07 |
jimbaker | it is in the meeting etherpad | 18:07 |
jimbaker | https://etherpad.openstack.org/p/MIL-ops-inventory-and-fleet-management | 18:07 |
jimbaker | is the correct one | 18:07 |
*** valw has joined #craton | 18:07 | |
thomasem | I saw that one. But aren't we supposed to use that template to create https://etherpad.openstack.org/p/MIL-ops-Craton? | 18:08 |
jimbaker | right now it's just a template. clearly need to make it awesome | 18:08 |
antonym | i'd like to get to the point where a server could check if it existed in craton and if not, boot an image that would populate the db with a new server data entry and all of its inventory | 18:08 |
thomasem | OH | 18:08 |
thomasem | I'm sorry, I misunderstood | 18:08 |
thomasem | neeeevermind | 18:08 |
thomasem | Cool, got it. | 18:08 |
jimbaker | yeah, copies, no worries | 18:08 |
thomasem | Alright. I need to step away. Thanks for the discussions. I know we churned a bit on that Tuesday meeting thing a bit too long. | 18:09 |
jimbaker | we are "ops inventory and fleet mgmt". or at least we hope to be | 18:09 |
thomasem | Need to start time-boxing these things. | 18:09 |
jimbaker | thomasem, np, we can always make it better! | 18:09 |
*** VW has quit IRC | 18:14 | |
*** VW has joined #craton | 18:21 | |
*** valw has quit IRC | 18:28 | |
*** valw has joined #craton | 18:31 | |
*** valw has quit IRC | 18:42 | |
openstackgerrit | Sulochan Acharya proposed openstack/craton master: Adds project/user bootstrap command to dbsync https://review.openstack.org/443170 | 18:48 |
openstackgerrit | Sulochan Acharya proposed openstack/craton master: Adds project/user bootstrap command to dbsync https://review.openstack.org/443170 | 18:50 |
thomasem | jimbaker: indeed! | 19:01 |
openstackgerrit | Thomas Maddox proposed openstack/craton master: JSON Path-like querying for variables https://review.openstack.org/443941 | 19:07 |
thomasem | Very WIP ^^ :) | 19:09 |
thomasem | Thinking about how I want to distinguish between regulary k:v queries and JSON path... or how I can make them both effectively the same while keeping them easy-to-use. | 19:10 |
thomasem | s/regulary/regular/ | 19:10 |
*** david-lyle has quit IRC | 19:14 | |
*** pwnall1337 is now known as zz_pwnall1337 | 19:16 | |
jimbaker | thomasem, yeah, it would be very cool if we come up with a good syntax. so there's some interesting aspects here | 19:27 |
thomasem | Well, there's a subset of JSON Path that makes sense... I'm not sure it all does. | 19:28 |
jimbaker | 1. could we transform the match such that for k:v, one could do this such that a dotted key would be transformed to the equivalent json path? | 19:29 |
thomasem | Do you mean could I treat key:value as JSON path? | 19:29 |
thomasem | Because that's what I'm changing it into right now | 19:29 |
jimbaker | so if it's foo.fum.bar:value | 19:29 |
thomasem | since, in a way, it is. | 19:29 |
jimbaker | that's the most obvious way for people to think about a nested search | 19:30 |
jimbaker | i would think at least | 19:30 |
thomasem | Yes, that's the plan. I'm looking to implement it to be like GET /v1/hosts?vars=foo.fum.bar:value | 19:30 |
jimbaker | value would be a literal | 19:30 |
thomasem | yes | 19:30 |
thomasem | Not doing globs or anything | 19:30 |
jimbaker | then we could also come up a syntax such that we mean it's a path. but we can do that later | 19:31 |
thomasem | Well, one implication is people cannot effectively use '.' in the key | 19:31 |
thomasem | when storing | 19:31 |
thomasem | or it won't be retrievable via the API, meaning we probably need to do some validation there | 19:31 |
thomasem | and restrict what a variable key can be at storage. | 19:31 |
jimbaker | standard escaping problem | 19:31 |
jimbaker | we see this in the same way for namespaces | 19:32 |
thomasem | Yes, except it's rougher UX, because now we'd expect users to escape things in their query. | 19:32 |
thomasem | Is there a legitimate case for having periods or brackets in a key? | 19:32 |
jimbaker | thomasem, so we have occasionally stated, although never documented (at least i don't think so) that we expect such keys to be valid python identifiers, unless they are escaped in some fashion | 19:34 |
jimbaker | basically we never clarified exactly what it should be :) | 19:34 |
thomasem | Okay, so, maybe now it's time to specify the allowed characters in a key name, to set expectations? | 19:34 |
jimbaker | ineed | 19:34 |
jimbaker | indeed | 19:34 |
thomasem | I think we can greatly simplify our problem by setting those expectations. :P | 19:34 |
thomasem | and therefore simplify the solution | 19:35 |
thomasem | I don't mind taking a shot at handling escapes and such, but, if we don't have to... | 19:35 |
jimbaker | it's been more of a question of, what is a valid superset of ansible (i believe restricted to python identifiers), puppet hiera, etc | 19:35 |
thomasem | Right. So, they will all be snake-case, essentially? | 19:35 |
thomasem | pretty much [a-zA-Z_] | 19:35 |
jimbaker | thomasem, one perfectly valid approach here is to restrict as follows | 19:36 |
thomasem | [a-zA-Z0-9_] | 19:36 |
thomasem | I mean | 19:36 |
jimbaker | i'm not certain why not unicode | 19:36 |
jimbaker | valid python 3 identifiers | 19:36 |
jimbaker | and reasonable for international usage | 19:36 |
thomasem | Okay, that's fair. | 19:36 |
jimbaker | but the punctuation could be restricted | 19:37 |
thomasem | Let's be sure to do a testcase for that scenario. | 19:37 |
jimbaker | i would remove - as a valid char | 19:37 |
thomasem | fwiw, that wasn't a valid char in my expression. | 19:38 |
thomasem | the '-' was indicating a range, not a valid character. | 19:38 |
jimbaker | https://docs.puppet.com/puppet/4.9/lang_reserved.html#acceptable-characters-in-names | 19:38 |
jimbaker | oh sorry, yes, my bad reading | 19:38 |
thomasem | No worries | 19:38 |
thomasem | We'll need to see how this handles dollar signs, too. | 19:38 |
thomasem | But, I suspect I can escape those well enough? | 19:38 |
thomasem | Since a path query looks like $.key.key... | 19:39 |
thomasem | $ being root | 19:39 |
thomasem | Alright, lemme see if I can get this working with the simpler cases before trying to think of every edge-case. :P | 19:40 |
jimbaker | thomasem, agreed about that | 19:41 |
jimbaker | that's why we deferred some of these questions until now | 19:41 |
jimbaker | :) | 19:41 |
jimbaker | at least $ is valid in a url | 19:42 |
tojuvone | btw, do we have a recorded demo video? | 19:42 |
jimbaker | tojuvone, sulo has done this a number of times, but we need to prepare a new one | 19:42 |
jimbaker | to show latest functionality | 19:42 |
tojuvone | yes | 19:43 |
thomasem | Pro tip: rm -rf .tox before doing dev deploy... goes WAY faster. | 19:43 |
jimbaker | so ideally this is done with respect to osic cluster data, including facts; | 19:43 |
jimbaker | as well as the nested search that thomasem is currently working on | 19:43 |
tojuvone | filtering with vars? | 19:44 |
* thomasem crosses fingers | 19:44 | |
jimbaker | tojuvone, yeah | 19:44 |
jimbaker | last minute additions, but pretty essential | 19:44 |
jimbaker | without doing flattening | 19:44 |
tojuvone | So things should be ready on last minute before Milan | 19:46 |
tojuvone | My concern mostly that I can be prepared | 19:50 |
*** valw has joined #craton | 19:54 | |
*** VW_ has joined #craton | 19:56 | |
*** VW has quit IRC | 19:59 | |
*** VW_ has quit IRC | 20:00 | |
*** VW has joined #craton | 20:02 | |
openstackgerrit | Thomas Maddox proposed openstack/craton master: JSON Path-like querying for variables https://review.openstack.org/443941 | 20:04 |
jimbaker | tojuvone, we will certainly help do that for you! | 20:06 |
tojuvone | jimbaker, thanks | 20:07 |
*** VW has quit IRC | 20:20 | |
*** VW has joined #craton | 20:21 | |
*** valw has quit IRC | 20:50 | |
thomasem | Got a company meeting coming up, so I'll be unavailable for a good 1.5 hrs | 20:51 |
* thomasem gulps | 20:51 | |
tojuvone | Have a nice meeting, I go get some sleep | 20:52 |
thomasem | I will try. :) | 21:01 |
*** VW has quit IRC | 21:29 | |
*** VW has joined #craton | 21:32 | |
*** Syed__ has quit IRC | 23:05 | |
thomasem | jimbaker: Would you have some time to Vidyo tomorrow? I want to walk through your proposed algorithm for conjunctive resolved variable searching. There's a snag that conflicts with variable.value now being a dictionary instead of a string when you go to collect the results of the query, so I wanted to better understand the original implementation. | 23:20 |
thomasem | Of course, I may think of something in my sleep, but, for now I'm a bit stumped. :) | 23:21 |
thomasem | Other than that, I need to get running. Have a lovely evening, everyone!! | 23:22 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!