| *** Mudpuppy has joined #craton | 02:51 | |
| *** Mudpuppy has quit IRC | 02:55 | |
| *** Mudpuppy has joined #craton | 06:52 | |
| *** Mudpuppy has quit IRC | 06:57 | |
| *** tojuvone has quit IRC | 08:11 | |
| *** VW has quit IRC | 08:57 | |
| *** valw has joined #craton | 09:04 | |
| *** valw has quit IRC | 09:09 | |
| sulo | o/ | 09:20 |
|---|---|---|
| *** VW has joined #craton | 09:58 | |
| *** VW has quit IRC | 10:03 | |
| *** tojuvone has joined #craton | 10:18 | |
| *** VW has joined #craton | 10:44 | |
| *** VW has quit IRC | 10:51 | |
| *** VW has joined #craton | 10:52 | |
| *** VW has quit IRC | 10:57 | |
| *** valw has joined #craton | 13:06 | |
| *** valw has quit IRC | 13:10 | |
| *** Mudpuppy has joined #craton | 14:06 | |
| sigmavirus | sulo: 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 |
| sigmavirus | IOW, 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 made | 14:33 |
| jimbaker | meeting in #openstack-meeting-4 in just under one minute | 14:59 |
| *** valw has joined #craton | 15: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 #craton | 15:07 | |
| *** valw has quit IRC | 15:18 | |
| *** valw has joined #craton | 15:22 | |
| *** chrisspencer has left #craton | 15:32 | |
| *** Syed__ has quit IRC | 15:35 | |
| *** Syed__ has joined #craton | 15:35 | |
| *** jovon has joined #craton | 15:38 | |
| *** jovon has quit IRC | 15:39 | |
| *** jovon has joined #craton | 15:40 | |
| sigmavirus | jimbaker: most businesses are celebrating New Years on Jan 2. Should we cancel that meeting as well? | 15:42 |
| jimbaker | sigmavirus, good point. yes | 15:42 |
| sigmavirus | okay | 15:42 |
| jimbaker | i 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 separation | 15:43 |
| sulo | jimbaker: sigmavirus: was in a meeting so had to miss community meeting here .. will read the logs | 16:01 |
| sigmavirus | sulo: A+ | 16:02 |
| sigmavirus | sulo: http://eavesdrop.openstack.org/meetings/craton/2016/craton.2016-12-12-15.00.log.html for your convenience ;) | 16:03 |
| sulo | sigmavirus: thanks | 16:03 |
| sulo | sigmavirus: jimbaker: +1 on getting this url spec review prioritized | 16:14 |
| sulo | i have left my comments :) | 16:15 |
| sigmavirus | sulo: I saw :) | 16:23 |
| jimbaker | sulo, cool | 16:44 |
| *** jcannava has quit IRC | 16:46 | |
| *** jcannava has joined #craton | 16:47 | |
| *** rainya has joined #craton | 16:52 | |
| *** rainya has quit IRC | 16:57 | |
| *** valw has quit IRC | 16:58 | |
| *** rainya has joined #craton | 17:01 | |
| *** valw has joined #craton | 17:23 | |
| *** openstack has joined #craton | 17:59 | |
| *** Mudpuppy has quit IRC | 18:18 | |
| *** Mudpuppy has joined #craton | 18:19 | |
| *** harlowja has joined #craton | 18:20 | |
| *** valw has quit IRC | 18:20 | |
| *** Mudpuppy has quit IRC | 18:24 | |
| *** valw has joined #craton | 18:26 | |
| *** valw has quit IRC | 18:27 | |
| *** valw has joined #craton | 18:40 | |
| *** valw has quit IRC | 18:44 | |
| *** valw has joined #craton | 19:04 | |
| *** valw_ has joined #craton | 19:17 | |
| *** valw_ has quit IRC | 19:19 | |
| *** valw__ has joined #craton | 19:20 | |
| *** valw has quit IRC | 19:21 | |
| *** valw__ has quit IRC | 19:52 | |
| *** valw has joined #craton | 19:57 | |
| jimbaker | sigmavirus, sulo, responded to the url query spec | 20:12 |
| jimbaker | i just want to differentiate between a required parent in the db modeling; vs the types of queries we might want to perform | 20:13 |
| jimbaker | pagination is the well-known approach to supporting flat queries in a reasonable fashion | 20:14 |
| git-harry | Are labels going to support variables? | 20:28 |
| *** valw has quit IRC | 20:40 | |
| git-harry | ^ jimbaker sulo | 20:41 |
| jimbaker | git-harry, we used to have this support | 20:45 |
| jimbaker | there'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-harry | jimbaker: why was it removed? | 20:46 |
| jimbaker | git-harry, simplification. labels make variable resolution more complicated because there's no defined ordering | 20:47 |
| jimbaker | we did impose a specific ordering via sorting of the label names | 20:47 |
| *** valw has joined #craton | 20:47 | |
| jimbaker | also this simplified the actual modeling. now labels could just be strings, without associated entries in a labels table | 20:47 |
| jimbaker | and doing many-to-many through a separate table | 20:48 |
| git-harry | jimbaker: 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 |
| jimbaker | git-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 |
| jimbaker | and 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-harry | jimbaker: 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 |
| jimbaker | git-harry, there's an outstanding bug for project. i think we always assumed we would do this, but i made this recently explicit | 21:05 |
| jimbaker | by reporting a bug | 21:06 |
| jimbaker | for example this could be used to set a default security policy for an entire project | 21:06 |
| jimbaker | in terms of naming convention: that's pretty much the essence of the variables based approach | 21:06 |
| jimbaker | i personally expect most variables to be either set at the top of the resolution hierarchy (so project); or at the bottom | 21:07 |
| jimbaker | interestingly, if we put credentials into variables, which i'm suggesting, this would actually be more likely to use the full hierarchy | 21:08 |
| jimbaker | including other hierarchies we have discussed, such as for project -> workflow def -> workflow | 21:08 |
| *** valw has quit IRC | 21:13 | |
| git-harry | jimbaker: 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 |
| jimbaker | git-harry, i fully expect that most clouds, on some sort of size distribution curve, will be single region/no (or implicit) cell | 21:29 |
| jimbaker | but we did want to model openstack at a range of scales | 21:30 |
| jimbaker | and consequently we also now have easier support for region/availability zone modeling seen in AWS | 21:30 |
| jimbaker | with 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 path | 21:32 |
| git-harry | jimbaker: 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 |
| jimbaker | but it would be straightforward to add, without introducing backwards breaking changes. assuming we got the modeling right | 21:32 |
| jimbaker | git-harry, sure, definitely taking these questions in this fashion :) | 21:33 |
| jimbaker | if 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 |
| jimbaker | and of course requiring some label ordering, either explicit (so the user could specify) or implicit (lexicographically sorted) | 21:36 |
| git-harry | jimbaker: 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-harry | Unless that info already exists somewhere | 21:44 |
| *** Mudpuppy has joined #craton | 22:07 | |
| *** Mudpuppy has quit IRC | 22:12 | |
| jimbaker | git-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 |
| jimbaker | other than that, i don't see any changes in inventory except relaxing region_id in the search query | 22:18 |
| jimbaker | and obvious scalability concerns like pagination. which at least is easy because of sqlalchemy | 22:19 |
| *** jovon has quit IRC | 22:20 | |
| jimbaker | so obvious bug fixes, sanding rough edges off. but no deep changes. not until we get requirements :) | 22:20 |
| *** valw has joined #craton | 22:56 | |
| *** valw_ has joined #craton | 22:59 | |
| *** valw has quit IRC | 23:02 | |
| jimbaker | git-harry, also auditing/governance. how could i forget. but again we are tracking with a bug. https://bugs.launchpad.net/craton/+bug/1606884 | 23:14 |
| openstack | Launchpad bug 1606884 in craton "Variables should support governance" [Undecided,New] - Assigned to Jim Baker (jimbaker) | 23:14 |
| *** valw_ is now known as valw | 23:16 | |
| *** Mudpuppy has joined #craton | 23:33 | |
| *** valw has quit IRC | 23:35 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!