Monday, 2016-12-12

*** Mudpuppy has joined #craton02:51
*** Mudpuppy has quit IRC02:55
*** Mudpuppy has joined #craton06:52
*** Mudpuppy has quit IRC06:57
*** tojuvone has quit IRC08:11
*** VW has quit IRC08:57
*** valw has joined #craton09:04
*** valw has quit IRC09:09
suloo/09:20
*** VW has joined #craton09:58
*** VW has quit IRC10:03
*** tojuvone has joined #craton10:18
*** VW has joined #craton10:44
*** VW has quit IRC10:51
*** VW has joined #craton10:52
*** VW has quit IRC10:57
*** valw has joined #craton13:06
*** valw has quit IRC13:10
*** Mudpuppy has joined #craton14:06
sigmavirussulo: FWIW,  conversation on  https://review.openstack.org/409281 is exactly what I wanted. I should warn you that I only have strong opinions give a set of parameters. That spec is meant to discern some of those parameters by juxtaposing them to parameters that I thought were informing the current design :)14:33
sigmavirusIOW, expect me to push you on some of your assertions but don't take it personally. The purpose of this is to document our justification for later down the road and so everyone has a document they can refer to explaining why certain decisions were made14:33
jimbakermeeting in #openstack-meeting-4 in just under one minute14:59
*** valw has joined #craton15:01
-openstackstatus- NOTICE: The Gerrit service on review.openstack.org is restarting now to address acute performance issues, and will be back online momentarily.15:05
*** Syed__ has joined #craton15:07
*** valw has quit IRC15:18
*** valw has joined #craton15:22
*** chrisspencer has left #craton15:32
*** Syed__ has quit IRC15:35
*** Syed__ has joined #craton15:35
*** jovon has joined #craton15:38
*** jovon has quit IRC15:39
*** jovon has joined #craton15:40
sigmavirusjimbaker: most businesses are celebrating New Years on Jan 2. Should we cancel that meeting as well?15:42
jimbakersigmavirus, good point. yes15:42
sigmavirusokay15:42
jimbakeri just hadn't looked that far in the calendar. but of course the treatment for new years exactly parallels christmas day, given the  7 day separation15:43
sulojimbaker: sigmavirus: was in a meeting so had to miss community meeting here .. will read the logs16:01
sigmavirussulo: A+16:02
sigmavirussulo: http://eavesdrop.openstack.org/meetings/craton/2016/craton.2016-12-12-15.00.log.html for your convenience ;)16:03
sulosigmavirus: thanks16:03
sulosigmavirus: jimbaker: +1 on getting this url spec review prioritized16:14
suloi have left my comments :)16:15
sigmavirussulo: I saw :)16:23
jimbakersulo, cool16:44
*** jcannava has quit IRC16:46
*** jcannava has joined #craton16:47
*** rainya has joined #craton16:52
*** rainya has quit IRC16:57
*** valw has quit IRC16:58
*** rainya has joined #craton17:01
*** valw has joined #craton17:23
*** openstack has joined #craton17:59
*** Mudpuppy has quit IRC18:18
*** Mudpuppy has joined #craton18:19
*** harlowja has joined #craton18:20
*** valw has quit IRC18:20
*** Mudpuppy has quit IRC18:24
*** valw has joined #craton18:26
*** valw has quit IRC18:27
*** valw has joined #craton18:40
*** valw has quit IRC18:44
*** valw has joined #craton19:04
*** valw_ has joined #craton19:17
*** valw_ has quit IRC19:19
*** valw__ has joined #craton19:20
*** valw has quit IRC19:21
*** valw__ has quit IRC19:52
*** valw has joined #craton19:57
jimbakersigmavirus, sulo, responded to the url query spec20:12
jimbakeri just want to differentiate between a required parent in the db modeling; vs the types of queries we might want to perform20:13
jimbakerpagination is the well-known approach to supporting flat queries in a reasonable fashion20:14
git-harryAre labels going to support variables?20:28
*** valw has quit IRC20:40
git-harry^ jimbaker sulo20:41
jimbakergit-harry, we used to have this support20:45
jimbakerthere's actually a bit of such labels support still buried in the alembic migration script, which i have fixed on a local edit (part of an overall alembic cleanup)20:46
git-harryjimbaker: why was it removed?20:46
jimbakergit-harry, simplification. labels make variable resolution more complicated because there's no defined ordering20:47
jimbakerwe did impose a specific ordering via sorting of the label names20:47
*** valw has joined #craton20:47
jimbakeralso this simplified the actual modeling. now labels could just be strings, without associated entries in a labels table20:47
jimbakerand doing many-to-many through a separate table20:48
git-harryjimbaker: so a variable now has to be applied to individual hosts if it is for to a subset of hosts in a region or cell?20:49
jimbakergit-harry, but obviously we lose something with this removal. so the arg in favor was that having a label like service:compute meant we could specifically associate variables for service:compute; and intersect these configuration settings with other admin aspects, like from region/cell (and arguably project)20:50
jimbakerand looks like i'm wrong about that labels support needing to be removed from the alembic migration script. so thanks for asking, always good to question assumptions!20:53
git-harryjimbaker: so to confirm, a variable can be set on the project/region/cell/device and any other level of granularity will require the operator to develop a naming convention for variables and/or labels?20:56
jimbakergit-harry, there's an outstanding bug for project. i think we always assumed we would do this, but i made this recently explicit21:05
jimbakerby reporting a bug21:06
jimbakerfor example this could be used to set a default security policy for an entire project21:06
jimbakerin terms of naming convention: that's pretty much the essence of the variables based approach21:06
jimbakeri personally expect most variables to be either set at the top of the resolution hierarchy (so project); or at the bottom21:07
jimbakerinterestingly, if we put credentials into variables, which i'm suggesting, this would actually be more likely to use the full hierarchy21:08
jimbakerincluding other hierarchies we have discussed, such as for project -> workflow def -> workflow21:08
*** valw has quit IRC21:13
git-harryjimbaker: so if a combination or labels and variables is the expected way to associate variables with hosts outside of regions/cells, what is the benefit of having regions/cells? It seems like the operator ends up having to code for two types of mechanism.21:24
jimbakergit-harry, i fully expect that most clouds, on some sort of size distribution curve, will be single region/no (or implicit) cell21:29
jimbakerbut we did want to model openstack at a range of scales21:30
jimbakerand consequently we also now have easier support for region/availability zone modeling seen in AWS21:30
jimbakerwith respect to labels: they could be a good way to introduce full DAG support in what we are doing; and associating variables with them. we did have issues specifically looking at these additions, but chose to not go down this path21:32
git-harryjimbaker: I'm not criticising or trying to suggest there is a better way, I still just trying to understand the why of the decisions that have been made.21:32
jimbakerbut it would be straightforward to add, without introducing backwards breaking changes. assuming we got the modeling right21:32
jimbakergit-harry, sure, definitely taking these questions in this fashion :)21:33
jimbakerif we did add variables back to labels; and we did support a label hierarchy, i would suggest implementing something like C3, as used by python's method resolution order (yes, we got our ideas from somewhere)21:35
jimbakerand of course requiring some label ordering, either explicit (so the user could specify) or implicit (lexicographically sorted)21:36
git-harryjimbaker: I'd like to see this trialled in RPC in concert will some of the other internal projects that are going on to try and get some data about usage before we look to change the API any more.21:44
git-harryUnless that info already exists somewhere21:44
*** Mudpuppy has joined #craton22:07
*** Mudpuppy has quit IRC22:12
jimbakergit-harry, we have requirements that imply virtualized variables (or some equivalent, but such variables require no api changes); rbac of some form is assumed; and virtualized variables and workflows require credential storage (and therefore some secure mgmt)22:17
jimbakerother than that, i don't see any changes in inventory except relaxing region_id in the search query22:18
jimbakerand obvious scalability concerns like pagination. which at least is easy because of sqlalchemy22:19
*** jovon has quit IRC22:20
jimbakerso obvious bug fixes, sanding rough edges off. but no deep changes. not until we get requirements :)22:20
*** valw has joined #craton22:56
*** valw_ has joined #craton22:59
*** valw has quit IRC23:02
jimbakergit-harry, also auditing/governance. how could i forget. but again we are tracking with a bug. https://bugs.launchpad.net/craton/+bug/160688423:14
openstackLaunchpad bug 1606884 in craton "Variables should support governance" [Undecided,New] - Assigned to Jim Baker (jimbaker)23:14
*** valw_ is now known as valw23:16
*** Mudpuppy has joined #craton23:33
*** valw has quit IRC23:35

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!