Thursday, 2017-03-09

*** david-lyle has joined #craton00:08
*** david-lyle has quit IRC00:15
*** david-lyle has joined #craton00:54
*** david-lyle has quit IRC00:54
*** Syed__ has quit IRC00:55
*** david-lyle has joined #craton01:52
*** VW has joined #craton02:17
*** VW_ has joined #craton02:18
*** VW has quit IRC02:21
*** VW_ has quit IRC04:14
*** VW has joined #craton05:12
*** VW has quit IRC06:54
suloo/10:08
openstackgerritgit-harry proposed openstack/craton master: Add http_codes decorator where missing  https://review.openstack.org/44356510:56
openstackgerritgit-harry proposed openstack/craton master: Validate parent_id is neither id nor a descendant  https://review.openstack.org/44356610:56
sulogit-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-harrysulo: 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 properly12:01
sulogit-harry: rgr, i didnt catch the partial-fix part12:02
*** VW has joined #craton13:10
openstackgerritSulochan Acharya proposed openstack/craton master: Adds project/user bootstrap command to dbsync  https://review.openstack.org/44317014:13
*** VW has quit IRC14:17
*** VW has joined #craton14:18
*** VW has quit IRC14:18
*** VW has joined #craton14:18
openstackgerritSulochan Acharya proposed openstack/craton master: Adds project/user bootstrap command to dbsync  https://review.openstack.org/44317014:26
fsaadmorning all14:41
thomasemhihi15:00
sulomorning fsaad, thomasem15:05
sulogit-harry: are you going to take this: https://bugs.launchpad.net/craton/+bug/166501515:06
openstackLaunchpad bug 1665015 in craton "All text errors reported by the Craton REST API should be JSON encoded" [High,New]15:06
sulo?15:06
sulootherwise i can poke on that ... i dont have anything else i am looking at right now15:06
thomasemsulo: 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
thomasemsigmavirus's preference (and mine too) was the former.15:07
thomasemAnd we already use that here: https://github.com/openstack/craton/blob/master/craton/api/v1/base.py#L2315:07
git-harrysulo: I can pick it up, I probably should given I've already done a bit.15:08
thomasemsulo: added a question, a couple nits, and one bug I found on your bootstrap/dbsync patch.15:08
sulogit-harry: rgr15:08
sulothomasem: cool, thanks15:08
thomasemYou bet. Sorry I didn't get a chance to look more thoroughly until today.15:09
sulothomasem: lol, thats wrong thing i uploaded15:10
sulothomasem: thanks for catching that ..15:11
thomasemSure thing!15:11
thomasemLol :P15:11
sulothomasem: but the rest of the suggestion is good .. ill make those changes too15:14
sulothomasem: actually, re: defaulting to some sane value .. not sure it will work for user15:19
sulosince project id is required15:20
*** valw has joined #craton15:22
*** Syed__ has joined #craton15:23
*** valw has quit IRC15:28
*** valw has joined #craton15:31
thomasemsulo: maybe default-bootstrap creates a project and uses that project ID?15:32
thomasemAnd then we leave around bootstrap-user until we can create root users via the API?15:33
thomasemYeah.. it's tricky. I'm not wild about the requirement to have a root user associated with a project, lol.15:33
sulothomasem: so add a new default-bootstrap command ?15:33
thomasemYeah, as the "easy" button.15:33
thomasemAnd then we can address the others as we shore up gaps in the API.15:34
thomasemThe 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
thomasems/deployers/operators/15:35
thomasemSo, 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
sulothomasem: yeah i guess thats a valid way to look at it15:35
thomasemFrom there they can create projects and users via the API.15:35
sulothomasem: so, hrm, the problem with that is15:36
thomasemAnybody going in after-the-fact and doing out-of-band project/user creation runs the risk of messing some things up.15:36
thomasemSince it goes around the API15:36
sulowe still need the user and project creation so that15:36
suloraw mysql is not needed anymore15:36
sulolike in docker_run.sh15:36
thomasemIf we fix the API, it won't be.15:36
thomasemYou could make API calls instead.15:37
thomasemonce the initial bootstrap is done15:37
thomasemWhich 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
sulohow do you mean fix the api ?15:38
thomasemThe only issue I saw so far is you can't create root users with the API.15:38
thomasemOther than that, it'll work just fine.15:38
thomasemYou would use dbsync to get your initial credentials15:38
thomasemthen use those credentials to set up other users and projects as needed.15:38
suloright15:38
thomasemWhich would eliminate the need for bootstrap-project and bootstrap-user via dbsync15:39
thomasemAnd the only thing you'd need then is a default bootstrap to start with.15:39
thomasemBut, again, until we support creating root users via the API, that won't solve the case entirely.15:39
suloactually15:39
sulothis prolly works now15:39
sulothe need to have those user in docker_run was func tests15:39
suloand we prolly dont need it anymore15:40
suloso just ahving a default bootstrapped user should do just fine15:40
thomasemI'm cool w/ that, too.15:40
thomasem:)15:40
thomasemI don't mind generate_fake_data setting up the other users for us.15:40
thomasemfor dev purposes15:40
thomasemIf that makes sense.15:40
thomasemYou can always use the initially bootstrapped user for root things in dev15:41
thomasemand the functional tests set up their own things separately, intentionally.15:41
thomasemiiuc.15:41
sulothe initial user should work for every use case i think15:41
thomasemI think so, too.15:41
suloalright, let me fix this up quickly, thanks for the suggestion15:42
thomasemSure thing!15:42
*** VW has quit IRC16:08
jimbakersulo, 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 good16:11
jimbakeri think the easy button is the right approach16:11
jimbakerand the rest api should only be used to create additional users/projects16:12
jimbakerlet's rephrase that'16:12
jimbakeronly the rest api should be...16:12
jimbakerusing a backchannel, not a good idea16:12
jimbakerthis 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 up16:13
jimbakeralso 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
jimbakerbut we can revisit - no need to forward to that list16:15
sulojimbaker: whats this cryptographic strong api_key ?16:16
jimbakeralso this discussion is related to the session in milan in two weeks - https://etherpad.openstack.org/p/MIL-ops-inventory-and-fleet-management16:16
jimbakersulo, for the user16:17
suloi mean whats the difference between that and uuid?16:17
jimbakersulo, a uuid is highly predictable16:17
jimbakerwe cannot use a uuid as a secret. ever16:17
jimbakermight as well have the secret be "password"16:18
sulojimbaker: so we are going to introduce this in the server code ?16:18
jimbakersulo, we need to do it for all users in terms of api_key gen, so yes16:19
jimbakerthe alternative is the user provides a secret, and we need to securely hash (with salting, rounds, etc) on it16:19
jimbakeragain, this is for the no keystone case16:20
jimbakerbut  we should still be reasonable about our security16:20
fsaadjimbaker: feel free to forward/add people to thread btw, meant to put that in e-mail, knew I Wasn't covering all that was needed16:21
jimbakerhttps://cryptography.io/en/latest/fernet/#using-passwords-with-fernet is the way to go for this byw16:21
suloyeah, can you create a bug for this16:21
suloshould be a straight forward thing to fix16:22
jimbakersulo, for the general user case? sure. we can just use a token gen as the default value for api_key in the model16:22
jimbakerwe can override to make it a specific known secret for testing. or we can our testing slightly smarter16:22
sulotoken gen ? from secrets ?16:23
jimbakerthis is why i suggested the whole eval $(dbsync some-command-that-does-get-or-create-my-project-and-user) approach16:23
jimbakerfor bootstrap16:24
jimbakerso we could populate OS_PROJECT_ID, OS_PASSWORD, OS_USERNAME16:24
jimbakersulo, so the secrets module is python 3.616:24
suloyeah i know16:24
jimbakerbut it's obviously trivial - really just doing it the right way16:24
jimbakerjust need to ensure we use os.urandom16:25
suloanyway, i am reading up on some uuid gen16:25
jimbakeros.urandom is *the way* to get random entropy16:25
suloi thought they were done the same way using random num gen16:25
sulobrb16:25
jimbakeruuid gen does not guarantee enough entropy16:25
jimbakeryeah, me too16:26
jimbakerbiab16:26
*** jovon has joined #craton16:52
jimbakeralso milan is next week! timing is good, but we need to prepare to help tojuvone; i added to agenda for today16:58
jimbakerso ready?17:00
thomasem#startmeeting craton17:00
openstackMeeting 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
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:00
openstackThe meeting name has been set to 'craton'17:00
thomasem#chair sigmavirus sulo jimbaker thomasem17:00
openstackCurrent chairs: jimbaker sigmavirus sulo thomasem17:00
thomasem#link https://etherpad.openstack.org/p/craton-meetings17:00
thomasem#topic Roll Call17:00
jimbakero/17:00
fsaado/17:00
thomasemo/17:00
antonymo/17:00
suloo/17:00
git-harryhi17:00
tojuvonehi17:01
jovono/17:01
thomasem#topic Roadmap planning - email to openstack-dev [craton]17:02
jimbakershould we start with that?17:02
thomasemIt's on the list17:02
jimbakeri understand, but maybe consume our standing agenda first - namely standup/reviews17:03
jimbakerbut it's ok, we can start here17:03
*** VW has joined #craton17:03
thomasemNah, i'm cool w/ that. The template needs to be updated17:03
thomasemif we're wanting to do something different for this meeting.17:03
thomasem#undo17:03
openstackRemoving item from minutes: #topic Roadmap planning - email to openstack-dev [craton]17:03
thomasem#topic Stand Up17: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 :: jimbaker17:04
jimbakeri have two changes to fix up, namely var search respecting resolution (will block thomasem's work since dependency); alembic schema17:05
jimbakeralso some outstanding discussion re bootstrap17:05
jimbakerlook forward to today's road map discussion, because we need to get that onto openstack-dev17:06
thomasem+117:06
jimbakerand we also have a forthcoming meeting by the openstack-operators in milan, which tojuvone needs our help prepping him for17:06
jimbaker(it's a team effort!)17:06
jimbakerdome17:06
jimbakerdone17:06
thomasem#topic Stand Up :: fsaad17:07
fsaadthink 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 tuesday17:08
fsaaddone17:08
thomasem#topic Stand Up :: thomasem17:09
*** zz_pwnall1337 is now known as pwnall133717:09
thomasemOvercoming 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
thomasemdone17:10
thomasem#topic Stand Up :: antonym17:10
antonymsure, 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 craton17:11
antonymhttps://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 boot17:12
antonymdone17:12
jimbakerantonym, like to hear that experience report17:13
thomasem+117:13
jimbakertopic after standup?17:13
thomasem#topic Stand Up :: sulo17:13
antonymsure we can catch up after17:13
suloi am finishing up the patch adding bootstrap command to dbsync17:13
*** valw has quit IRC17:13
sulowill pick up something else from the milestone list after17:14
sulodone17:14
thomasem#topic Stand Up :: git-harry17:14
git-harryPatches are up for https://bugs.launchpad.net/craton/+bug/166653617:15
openstackLaunchpad bug 1666536 in craton "Cyclical hierarchies using parent_id" [Critical,In progress] - Assigned to git-harry (git-harry)17:15
git-harryNow working on https://bugs.launchpad.net/craton/+bug/166501517:15
openstackLaunchpad 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-harrydone17:15
thomasem#topic Stand Up :: tojuvone17:15
tojuvoneWell I just worked the docker doc17:15
tojuvoneand now would be interested to have the milan etherpad in shape17:16
jimbakerso that's a blocker for you17:16
tojuvonedocker install17:16
thomasemWait, which is a blocker?17:17
jimbakerthomasem, milan etherpad17:17
thomasemGotcha17:17
thomasemOkay, cool17:17
jimbakerbut will be discussed momentarily as a separate topic...17:17
tojuvoneYes, to know what we like to shere there about Craton17:17
tojuvoneyep17:17
thomasemSound good!17:17
tojuvonedone17:18
thomasem#topic Stand Up :: jovon17:18
jovonwhile 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 study17:19
jimbakerjovon, cool, maybe we can explore in a forthcoming meeting?17:21
jovonsounds good17:21
jimbakeri suggest you put this on the agenda17:21
jovon+117:21
jovondone17:21
thomasemCool. Ready to go into topics now?17:22
jimbakeryes17:22
thomasem#topic Roadmap planning - email to openstack-dev [craton]17:22
jimbakerfsaad, git-harry, sulo - probably want to start with you on this17:23
thomasemfsaad: 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
thomasemAnd start thinking about what we want to be when we grow up17:23
fsaadthat sounds good to me, with an additional 30 mins per email suggestion17:24
jimbaker30 min earlier sounds good17:24
jimbakerto better accommodate UK17:24
thomasem+117:24
fsaad+117:24
jimbakerand finland for that matter :)17:24
tojuvone+1 :)17:24
thomasemI updated the etherpad accordingly17:25
thomasemNot sure where else that needs to be updated?17:25
jimbakerthe 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
thomasemThe question wasn't about integration, it was about whether they both belong in the same project.17:26
thomasems/project/repository/17:26
jimbakerthomasem, ok. fair enough17:26
jimbakerso one possibility that i think may make sense is that the db aspects of workflows should be in the same project17:27
jimbakerbut the specific worker implementation - celery? taskflow? - is pluggable17:27
jimbakerjust throwing it out there17:27
thomasemLemme scare up some stuff here17:27
jimbakerfwiw - when we first started the project, we had it more decoupled than it is now17:27
jimbakerso just want to say there is some history here17:28
thomasemWhat was the original reason for including workflows in the same repository as the craton API?17:28
jimbakermostly because craton is not so big17:28
thomasemIs there any technical reason?17:28
jimbakerand it's not clear to me we need to make this distinction17:28
jimbakerclearly we can always link17:29
jimbakerthe major technical reason however17:29
thomasemWhat I mean is, can the workflow engine utilize the Craton API?17:29
jimbakeris that we want our models to be shared17:29
thomasemAh17:29
thomasemSo, why's that necessary?17:29
jimbakerbecause simplicity. not necessity17:29
thomasemWhat if the workflow engine was a client of the Craton API?17:29
jimbakerthomasem, so the engine itself, yes17:30
git-harryWe seem to be discussing specific roadmap items, was that the purpose of this topic?17:30
fsaadthink that's what the tue meeting is for :)17:30
thomasemgit-harry: you're correct, we can punt this discussion to that.17:30
jimbakerthe 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 for17:30
jimbakeri certainly agree here!17:31
jimbakerwith git-harry and fsaad17:31
git-harrySo 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
thomasemOkay. Let's table this for a more involved discussion of roadmap items.17:31
jimbakergit-harry, well sulo and i are technically part of OSIC17:31
thomasem(I am, too)17:32
jimbakerand tojuvone is at nokia17:32
fsaadworks. 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 there17:32
thomasem(I found out)17:32
jimbakercool17:32
jimbakerso we have to put on our upstream hats :)17:32
jimbakerthat rackspace is the first customer, this is awesome17:32
jimbakerof course we are going to work very closely with our customers. everyone should expect that17:33
jimbakerand i think the biggest prioritization we see is cmdb17:34
jimbakerguess what, this is the most important thing for nokia too. win win!17:34
fsaado/17:34
tojuvoneI just spoke today with Vitrage, and they should be happy to have notifications from Craton.17:34
jimbakerand notifications are essential for rackspace too17:34
tojuvoneAlso putting up feature where Craton coudl update something on Nova17:34
jimbakerand webhooks on the rackspace side, which is we can implement17:35
jimbaker*how we can*17:35
thomasem^^ fits under workflow engine umbrella, btw.17:35
thomasemat least that's my opinion :)17:35
tojuvoneyes, workflow + notif17:35
openstackgerritSulochan Acharya proposed openstack/craton master: Adds project/user bootstrap command to dbsync  https://review.openstack.org/44317017:35
tojuvoneand namespace17:36
jimbakerthomasem, fwiw not as we originally envisioned. but highly open to other ways to get there17:36
antonymsulo: yay17:36
thomasemAlright, so these are things that we need to collect and get into, say, Story Board.17:36
suloantonym: heh, hopefully that will help a bit :)17:37
jimbakerthomasem, everything here is in a blueprint or bug17:37
thomasemOkay, good.17:37
jimbakerbut yes, moving to storyboard will help highlight it much better17:37
jimbakerand needs to be done regardless17:37
thomasemAlright. So, what did we want to get out of discussing this topic today?17:38
jimbakerand especially capture details like, yes we need notifications. but let's link to a specific way to implement17:38
fsaadI 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
jimbakerthomasem, 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 meeting17:38
jimbakerfsaad, hah, yes17:39
fsaadso, seems like we at least got the time and recurrency of it mostly OK'd, every tuesday, half hour earlier17:39
thomasemYep17:39
fsaadand do sprint plan one week and retrospective the next ?17:39
jimbakerfsaad, not every tues17:39
jimbakerjust next week's meeting17:39
jimbakeri think we are good with the slot time for now, until we find otherwise17:39
thomasemjimbaker: 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
fsaadsame17:40
jimbakerthomasem, it has become an extension of monday's meeting17:40
jimbakerso backing up17:40
jimbakeroriginally we had tues & thurs meetings that were dev focused; monday was to be focused on the wider community17:40
jimbakercommunicate with them, here's what we are doing17:41
jimbakerexcept it turned out that only the devs were showing up for monday's meeting. so we repurposed accordingly17:41
pwnall1337hosts/id/variables doesn't do pagination right?17:41
pwnall1337just giant wall of text17:41
jimbakerpwnall1337, no pagination, correct17:41
pwnall1337thanks17:41
thomasemjimbaker: Okay, so, are you against us changing the purpose to planning/retro alternating?17:42
jimbakerto be honest, i think the monday meeting works well17:42
jimbakerthomasem, for tues, i think it works to look at planning/retrospective17:42
jimbakeri just don't expect it to take 90 minutes every single tues that's all17:43
thomasemWe could just keep it at an hour and increase if we find it's not enough?17:43
fsaadcool we can kick jokes and drink coffee for the remaining for team bonding17:43
jimbakerbut we have built up quite a backlog17:43
fsaadI mean, cut it short and get back to work17:43
fsaad:P17:43
thomasemlol fsaad17:43
sulostart early, add that 30 min and end early if needed17:44
suloit does not work well for UK folks to extend17:44
jimbakersulo, correct17:44
suloif we ever have to do that17:44
jimbakerso i don't think we need to do extend. except next tues17:44
jimbakerand we are extending early of course :)17:45
suloyeah, i agree .. i dont think it will take that long every tues17:45
*** valw has joined #craton17:45
jimbakerso let's see. we can always revisit. but next tues starts 30 min early17:45
thomasemI'm personally fine with either. I imagine we'll adjust as needed.17:46
sulois this open discussion17:46
fsaadalso 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 need17:46
jimbakersulo, we somehow drifted here17:46
thomasemBut, 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
jimbakerwe were discussing openstack-dev email17:46
thomasemAnd this allows us to not add on additional meetings17:46
sulothomasem: agreed17:46
jimbakerre roadmap17:47
jimbakerand i think the point is: that's tuesday17:47
thomasemyep17:47
sulodid we decide to sprint or is that up for discussion next meeting17:47
thomasemIt'll resemble sprints, sans story points (I hope).17:47
jimbakersulo, so we were discussing yesterday17:47
jimbakeryeah, no need for story points17:47
jimbakerbut the net of it was, two week iterations17:48
jimbakerwe will see if that's workable or not for this project. but it's more of a question of 2 weeks, or longer; not shorter17:48
jimbakeri don't think any of our tasks are adjust the web interface type of stuff17:48
git-harryI'd vote for more of a kanban based approach, I don't know if storyboard supports it.17:49
jimbakerwell it is a board...17:49
thomasemgit-harry: +1, I am hoping the planning is simply for us to prioritize things regularly.17:49
jimbakerinterestingly it's possible to support multiple board views, which hopefully can help us look at stuff from a customer perspective17:50
jimbakernot to mention integration with say what rackspace is doing via supposedly an easy to use API17:50
thomasemso, 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 process17:50
jimbaker(but has to be better than the LP API)17:50
suloso thomasem git-harry jimbaker fsaad do we need to decide on kanban sprint somethingelse ?17:50
sulocombo of17:51
fsaadnot right now, I'll get my learn on kanban cause I've only done pseudo sprints (no points)17:51
jimbakerthomasem, yeah, i think that's the combo approach right17:51
fsaadthen can probably have more educated conversation17:51
thomasemjimbaker: I guess? Agile's pretty bastardized these days.17:51
jimbakertrue sprints have everything aligned on two week iterations17:51
jimbakeror something. i don't know17:51
thomasemI think we'll just start with the raw clay and mold what we want as we go17:52
thomasemThis sounds like a good starting point.17:52
jimbakerwhereas we will likely do the bastardized approach. the raw clay in other words17:52
*** valw has quit IRC17:52
thomasemAs long as the process works for us and not the other way around, we should be okay.17:52
jimbakerpersonally 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/planning17:53
thomasemWho will draft up the e-mail to openstack-dev?17:53
suloright, so are we doign to discuss that tues too ?17:53
jimbakerthomasem, i suggest we start with fsaad's email thread, and edit accordingly. most important17:53
jimbakerit must link against our corresponding blueprints17:53
jimbakereven better: what if it did this against storyboard? ...17:53
jimbakerwin!17:53
jimbakerfrom a public relations perspective17:54
thomasemWe only have 6 minutes for remaining topics. :\17:54
suloare we discussing what our process is next tuesday too ??17:54
sulofsaad: ^^17:54
jimbakersulo, absolutely17:54
jimbakerhence extra time17:54
sulolets make sure we have enough time for that + discussing priority work17:54
jimbakerbut we should be prepped to do so17:54
fsaadwell, collation of items from thread is a starting point17:55
jimbakeragain tues is better. mon morning is rough to have a planned agenda17:55
jimbakerso this repurposing is much more realistic17:55
fsaaddiscussion of them I mean, and write up a draft of what we want to see as end game17:55
fsaadI agree we should have an agenda to keep focus17:55
thomasemSounds good. Can we take the rest of this into #craton after this meeting so we can get to tojuvone's topic?17:56
jimbakerso basically this meeting, plus the current emai threadl - should be a good start17:56
*** pwnall1337 is now known as zz_pwnall133717:56
jimbakerthomasem, +117: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-management17:56
fsaadcool, need to step away but will catch up in a bit, thanks guys17:56
thomasemtojuvone: take it away17:56
thomasemfsaad: cheers!17:56
*** zz_pwnall1337 is now known as pwnall133717:56
jimbakeri 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
jimbakerbut in the context of engaging with our previous meeting at the op summit in nyc17:57
*** valw has joined #craton17:57
jimbaker+ barcelona17:57
jimbakerwe need to take concrete use cases17:58
jimbakersuch as maintenance mgmt, and describe mapping to craton17:58
jimbakeranother good example: antonym's work on plip17:58
jimbakerand of course the use cases we have been recently working through, and corresponding demo17:59
tojuvoneI will have the maintenance MIL-ops-telco-nfv17:59
*** valw has quit IRC17:59
jimbakertojuvone volunteered to lead this session on behalf of craton, since he will be in milan. but we need to fully support him17:59
jimbakerthomasem, we are over our time limit...18:00
thomasemYep18:01
tojuvoneso what we want to share there. Some current status, roadmap18:01
jimbakeranyway, let me conclude: let's just all look at the etherpad18:01
thomasemLol yeah18:01
thomasem#endmeeting18:01
openstackMeeting ended Thu Mar  9 18:01:39 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:01
openstackMinutes:        http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-03-09-17.00.html18:01
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-03-09-17.00.txt18:01
openstackLog:            http://eavesdrop.openstack.org/meetings/craton/2017/craton.2017-03-09-17.00.log.html18:01
jimbakerfsaad, thomasem, probably the best way to craft that email is put in an etherpad too18:02
tojuvoneSo if there doesn't naturally come Discussion items to etherpad18:02
jimbakerso we can extract that content, discuss here, and have something great to discuss18:02
tojuvoneThen I could share what we have today and what is next18:02
jimbakertojuvone, +1, sounds like a great plan18:03
thomasemtojuvone: yeah, we can fill in with use-cases we have been working towards, some known future goals, maybe record our demo?18:03
jimbakerthomasem, +1, at least it's on the etherpad18:03
jimbakereven if tojuvone doesn't have a chance to play18:03
tojuvoneBut still it is something you guys are the best to come up with18:03
jimbakertojuvone, agreed18:04
tojuvoneI can have Craton up and running and could demonstrate some18:04
thomasemThat'd be good.18:04
tojuvoneSurely if the internet access there happens to work ;)18:04
tojuvonenot running on local laptop I mean18:05
thomasemLOL18:05
jimbakeri hope whoever planned that meeting in MIL thought about internet. but it something that we can never count on even then18:05
jimbakeryeah, so local laptop is good18:05
jimbakeri like the idea of showing off plip. putting antonym on the spot of course...18:06
tojuvoneSo have my linux machines at office and can do remote to there18:06
thomasemWhen is this event, btw?18:06
jimbakermar 15 & 1618:06
thomasemOh wow18:06
jimbakerlike real soon now!18:06
thomasemOkay18:06
thomasemSeriously18:06
thomasemLol18:06
antonymjimbaker: there's not really much to it, just lets me make jinja templates really, https://gist.github.com/antonym/14a7da3b302fc77f9e772ae3cc1bd3f318:07
jimbakerwe have been sort of focused on rpc support18:07
thomasemAlright, I'll make a note to review. Do we already have the Craton etherpad made? This is a template.18:07
tojuvoneSo if there would be ready set of CLI commands and DB, could show there features we want to show18:07
thomasemhttps://etherpad.openstack.org/p/MIL-ops-Craton, right?18:07
tojuvoneNo, there is jsut template18:07
jimbakerit is in the meeting etherpad18:07
jimbakerhttps://etherpad.openstack.org/p/MIL-ops-inventory-and-fleet-management18:07
jimbakeris the correct one18:07
*** valw has joined #craton18:07
thomasemI saw that one. But aren't we supposed to use that template to create https://etherpad.openstack.org/p/MIL-ops-Craton?18:08
jimbakerright now it's just a template. clearly need to make it awesome18:08
antonymi'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 inventory18:08
thomasemOH18:08
thomasemI'm sorry, I misunderstood18:08
thomasemneeeevermind18:08
thomasemCool, got it.18:08
jimbakeryeah, copies, no worries18:08
thomasemAlright. 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
jimbakerwe are "ops inventory and fleet mgmt". or at least we hope to be18:09
thomasemNeed to start time-boxing these things.18:09
jimbakerthomasem, np, we can always make it better!18:09
*** VW has quit IRC18:14
*** VW has joined #craton18:21
*** valw has quit IRC18:28
*** valw has joined #craton18:31
*** valw has quit IRC18:42
openstackgerritSulochan Acharya proposed openstack/craton master: Adds project/user bootstrap command to dbsync  https://review.openstack.org/44317018:48
openstackgerritSulochan Acharya proposed openstack/craton master: Adds project/user bootstrap command to dbsync  https://review.openstack.org/44317018:50
thomasemjimbaker: indeed!19:01
openstackgerritThomas Maddox proposed openstack/craton master: JSON Path-like querying for variables  https://review.openstack.org/44394119:07
thomasemVery WIP ^^ :)19:09
thomasemThinking 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
thomasems/regulary/regular/19:10
*** david-lyle has quit IRC19:14
*** pwnall1337 is now known as zz_pwnall133719:16
jimbakerthomasem, yeah, it would be very cool if we come up with a good syntax. so there's some interesting aspects here19:27
thomasemWell, there's a subset of JSON Path that makes sense... I'm not sure it all does.19:28
jimbaker1. 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
thomasemDo you mean could I treat key:value as JSON path?19:29
thomasemBecause that's what I'm changing it into right now19:29
jimbakerso if it's foo.fum.bar:value19:29
thomasemsince, in a way, it is.19:29
jimbakerthat's the most obvious way for people to think about a nested search19:30
jimbakeri would think at least19:30
thomasemYes, that's the plan. I'm looking to implement it to be like GET /v1/hosts?vars=foo.fum.bar:value19:30
jimbakervalue would be a literal19:30
thomasemyes19:30
thomasemNot doing globs or anything19:30
jimbakerthen we could also come up a syntax such that we mean it's a path. but we can do that later19:31
thomasemWell, one implication is people cannot effectively use '.' in the key19:31
thomasemwhen storing19:31
thomasemor it won't be retrievable via the API, meaning we probably need to do some validation there19:31
thomasemand restrict what a variable key can be at storage.19:31
jimbakerstandard escaping problem19:31
jimbakerwe see this in the same way for namespaces19:32
thomasemYes, except it's rougher UX, because now we'd expect users to escape things in their query.19:32
thomasemIs there a legitimate case for having periods or brackets in a key?19:32
jimbakerthomasem, 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 fashion19:34
jimbakerbasically we never clarified exactly what it should be :)19:34
thomasemOkay, so, maybe now it's time to specify the allowed characters in a key name, to set expectations?19:34
jimbakerineed19:34
jimbakerindeed19:34
thomasemI think we can greatly simplify our problem by setting those expectations. :P19:34
thomasemand therefore simplify the solution19:35
thomasemI don't mind taking a shot at handling escapes and such, but, if we don't have to...19:35
jimbakerit's been more of a question of, what is a valid superset of ansible (i believe restricted to python identifiers), puppet hiera, etc19:35
thomasemRight. So, they will all be snake-case, essentially?19:35
thomasempretty much [a-zA-Z_]19:35
jimbakerthomasem, one perfectly valid approach here is to restrict as follows19:36
thomasem[a-zA-Z0-9_]19:36
thomasemI mean19:36
jimbakeri'm not certain why not unicode19:36
jimbakervalid python 3 identifiers19:36
jimbakerand reasonable for international usage19:36
thomasemOkay, that's fair.19:36
jimbakerbut the punctuation could be restricted19:37
thomasemLet's be sure to do a testcase for that scenario.19:37
jimbakeri would remove - as a valid char19:37
thomasemfwiw, that wasn't a valid char in my expression.19:38
thomasemthe '-' was indicating a range, not a valid character.19:38
jimbakerhttps://docs.puppet.com/puppet/4.9/lang_reserved.html#acceptable-characters-in-names19:38
jimbakeroh sorry, yes, my bad reading19:38
thomasemNo worries19:38
thomasemWe'll need to see how this handles dollar signs, too.19:38
thomasemBut, I suspect I can escape those well enough?19:38
thomasemSince a path query looks like $.key.key...19:39
thomasem$ being root19:39
thomasemAlright, lemme see if I can get this working with the simpler cases before trying to think of every edge-case. :P19:40
jimbakerthomasem, agreed about that19:41
jimbakerthat's why we deferred some of these questions until now19:41
jimbaker:)19:41
jimbakerat least $ is valid in a url19:42
tojuvonebtw, do we have a recorded demo video?19:42
jimbakertojuvone, sulo has done this a number of times, but we need to prepare a new one19:42
jimbakerto show latest functionality19:42
tojuvoneyes19:43
thomasemPro tip: rm -rf .tox before doing dev deploy... goes WAY faster.19:43
jimbakerso ideally this is done with respect to osic cluster data, including facts;19:43
jimbakeras well as the nested search that thomasem is currently working on19:43
tojuvonefiltering with vars?19:44
* thomasem crosses fingers19:44
jimbakertojuvone, yeah19:44
jimbakerlast minute additions, but pretty essential19:44
jimbakerwithout doing flattening19:44
tojuvoneSo things should be ready on last minute before Milan19:46
tojuvoneMy concern mostly that I can be prepared19:50
*** valw has joined #craton19:54
*** VW_ has joined #craton19:56
*** VW has quit IRC19:59
*** VW_ has quit IRC20:00
*** VW has joined #craton20:02
openstackgerritThomas Maddox proposed openstack/craton master: JSON Path-like querying for variables  https://review.openstack.org/44394120:04
jimbakertojuvone, we will certainly help do that for you!20:06
tojuvonejimbaker, thanks20:07
*** VW has quit IRC20:20
*** VW has joined #craton20:21
*** valw has quit IRC20:50
thomasemGot a company meeting coming up, so I'll be unavailable for a good 1.5 hrs20:51
* thomasem gulps20:51
tojuvoneHave a nice meeting, I go get some sleep20:52
thomasemI will try. :)21:01
*** VW has quit IRC21:29
*** VW has joined #craton21:32
*** Syed__ has quit IRC23:05
thomasemjimbaker: 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
thomasemOf course, I may think of something in my sleep, but, for now I'm a bit stumped. :)23:21
thomasemOther 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!