| *** matsuhashi has joined #openstack-trove | 00:28 | |
| *** amcrn has quit IRC | 00:42 | |
| *** nosnos has joined #openstack-trove | 00:45 | |
| *** jrodom has quit IRC | 00:55 | |
| *** jrodom has joined #openstack-trove | 00:59 | |
| openstackgerrit | Mike Metral proposed a change to openstack/trove-integration: Sets correct MYSQL_HOST needed to run stack.sh https://review.openstack.org/49659 | 01:06 |
|---|---|---|
| *** yogeshmehra has joined #openstack-trove | 01:10 | |
| *** yogeshmehra has quit IRC | 01:14 | |
| *** jrodom has quit IRC | 01:25 | |
| *** erkules has quit IRC | 01:27 | |
| *** erkules has joined #openstack-trove | 01:45 | |
| *** showka has joined #openstack-trove | 01:51 | |
| openstackgerrit | A change was merged to openstack/trove-integration: Sets correct MYSQL_HOST needed to run stack.sh https://review.openstack.org/49659 | 02:12 |
| *** jrodom has joined #openstack-trove | 02:20 | |
| *** jrodom has quit IRC | 02:41 | |
| *** vipul has quit IRC | 02:45 | |
| *** vipul has joined #openstack-trove | 02:46 | |
| *** haomaiwang has quit IRC | 03:03 | |
| hub_cap | vipul: around? | 03:06 |
| vipul | hub_cap: yea | 03:07 |
| hub_cap | Why is a slave node not treated as a node, what's so special about it that it needs to be different | 03:07 |
| hub_cap | did u mean for replication? | 03:07 |
| hub_cap | or clustering | 03:07 |
| vipul | Yea for replication | 03:07 |
| hub_cap | for replication, a slave is different | 03:07 |
| hub_cap | u want to know the ip | 03:07 |
| hub_cap | like a read slave | 03:07 |
| hub_cap | u also may want to shirnk the ram | 03:07 |
| hub_cap | cuz it doesnt do a bunch of updates | 03:07 |
| hub_cap | u also might want to push a custom config for better read performance | 03:08 |
| hub_cap | those things make u want to make it a independent isntance | 03:08 |
| vipul | But I would argue that you'd want those things for clusters too | 03:09 |
| vipul | I want to know the IPs of other nodes in a cluster | 03:09 |
| hub_cap | not normally | 03:09 |
| vipul | because I could potentially use them as read only salves | 03:10 |
| hub_cap | not for a cluster | 03:10 |
| hub_cap | cassandra has no read slaves | 03:10 |
| hub_cap | galera, if used in active-active (true cluster) doesnt either | 03:10 |
| vipul | Galera.. I may only want to write to a single node | 03:11 |
| vipul | but read from the other nodes | 03:11 |
| vipul | Or put them behind haproxy | 03:11 |
| hub_cap | sure and u can get their ips | 03:11 |
| hub_cap | itll likely be in the data u get back from a instance get | 03:11 |
| hub_cap | but u wuldnt want to make one bigger or smaller than the rest | 03:11 |
| vipul | But how is that different from a replication slave | 03:11 |
| hub_cap | or put a different configuration on it | 03:12 |
| hub_cap | u _just_ want its ip | 03:12 |
| vipul | Sure.. | 03:12 |
| hub_cap | thats the difference | 03:12 |
| hub_cap | a cluster is homogenous | 03:12 |
| hub_cap | replication is not | 03:12 |
| hub_cap | a cluster resize = resize all nodes | 03:12 |
| hub_cap | read replica resize = just shrink node X | 03:12 |
| vipul | Ok, that's fair.. configuration and flavor might be homogenous | 03:13 |
| hub_cap | i think everything is | 03:13 |
| hub_cap | except u might want to know the IPs | 03:13 |
| hub_cap | and sure ill give u that, that makes sense | 03:13 |
| hub_cap | but wrt replication, _most_ of the time its not homogenous | 03:14 |
| vipul | I just feel like we're bastardizing the replication concept.. besides it not being homogenious.. it's still managed | 03:14 |
| vipul | like it still supports failover, etc | 03:14 |
| hub_cap | not automatic | 03:14 |
| hub_cap | clusters self promote | 03:14 |
| hub_cap | mysql master-maste does not | 03:14 |
| vipul | Why not.. why couldn't we make replication do that too | 03:14 |
| hub_cap | the differnce is | 03:14 |
| hub_cap | _we_ vs builtin cluster software | 03:15 |
| hub_cap | replication is not HA / fault tolerant by design | 03:15 |
| hub_cap | its HA but not fault tolerant | 03:15 |
| vipul | sure.. but it's very likely that Trove would make it fault tolerant | 03:15 |
| hub_cap | eventually sure | 03:15 |
| vipul | and when we do | 03:15 |
| vipul | why does it feel different | 03:16 |
| hub_cap | lets figure taht out when we do | 03:16 |
| vipul | why is it a completely differnt experience provisioning it | 03:16 |
| hub_cap | because clustering != replication | 03:16 |
| vipul | I feel like you could still put it in the same instace->node concept.. | 03:16 |
| vipul | throwing out the homogenious factor | 03:16 |
| hub_cap | ya but then you have a scenario where u cant muck w/ nodes of a particular service_type | 03:17 |
| hub_cap | so the nodes are no longer equal | 03:17 |
| hub_cap | in terms of what u can do to them across diff service types wrt clusters | 03:17 |
| vipul | Ok.. let's talk about the service type aspect.. | 03:17 |
| hub_cap | sure | 03:17 |
| vipul | are we going to allow somone to migrate between service types? | 03:17 |
| hub_cap | eventually i think its fine | 03:17 |
| vipul | as a user.. i may choose to start small.. single instance | 03:17 |
| *** demorris has joined #openstack-trove | 03:18 | |
| hub_cap | right off the bat i dont think so | 03:18 |
| vipul | however to upgrade, it's really a different service type | 03:18 |
| hub_cap | hell the codership guys recommend creating a new cluster and migrating to it | 03:18 |
| hub_cap | rahter than doing it in place | 03:18 |
| hub_cap | and codership wrote galera :) | 03:18 |
| vipul | But you couldn't do a cluster of 1... | 03:19 |
| hub_cap | so i think its perfectly sane to say | 03:19 |
| hub_cap | make a backup | 03:19 |
| vipul | so you really can't add nodes if you start small | 03:19 |
| hub_cap | pass in a backupUUID to a create | 03:19 |
| hub_cap | service_type=galera, backupUUID=blah | 03:19 |
| hub_cap | and it spins up a new cluster given that uuid | 03:19 |
| hub_cap | if u just want master/slave, u can just add a slave via POST /instance | 03:19 |
| *** Barker has quit IRC | 03:24 | |
| vipul | still digesting the etherpad.. just seems slightly odd to me that we're treating it differnt | 03:26 |
| vipul | just the fact that it's something done by US vs. built-in shouldn't be a reason to expose it differently | 03:27 |
| vipul | if i choose to do master-master-master.. it's likely that i'm going to make it homogenious | 03:27 |
| vipul | yet.. it's treated as a diffrent animal in Trove | 03:28 |
| vipul | Because in either case.. as a user.. i just may want to add nodes | 03:29 |
| vipul | however doing so is very differnt depending on whether i chose Galera or not | 03:29 |
| vipul | Do you see other use cases (other service types) that would behave like master/slave.. besides mysql | 03:35 |
| hub_cap | i believe redis deos teh same | 03:35 |
| hub_cap | *Does | 03:35 |
| hub_cap | but i think thats it | 03:35 |
| hub_cap | im open to suggestions | 03:36 |
| hub_cap | we just assumed that for the most part u wouldnt care about the ips of each node for clustering | 03:37 |
| vipul | I do like tying everything to /instances .. making 'node' a subresource of an instance | 03:37 |
| hub_cap | for sure | 03:37 |
| vipul | i dislike treating replication different | 03:37 |
| vipul | since to the end user.. does it really matter? | 03:37 |
| vipul | that they did replication vs chose a cluster | 03:37 |
| vipul | (if both support failover, etc) | 03:38 |
| hub_cap | homogenous vs heterogenous matters | 03:38 |
| hub_cap | well they dont both support failover | 03:38 |
| hub_cap | thats one of the main things | 03:38 |
| vipul | Trove does.. | 03:38 |
| vipul | regardless of the underlying tech | 03:38 |
| hub_cap | trove _may_ in the future | 03:38 |
| vipul | maybe not on day1 ..but it iwll | 03:38 |
| hub_cap | i think we all say that, but im not entirely sold on it being doable | 03:39 |
| hub_cap | :P | 03:39 |
| hub_cap | but, if you need to use galera like a replica, instead of a cluster | 03:39 |
| hub_cap | the difference between them is that w galera u _only_ need to get the ips | 03:40 |
| hub_cap | but lets chat w/ daniel tomrorow about it | 03:40 |
| hub_cap | if hes feeling ok | 03:40 |
| hub_cap | i think he got a stomach bug | 03:40 |
| hub_cap | but effectively if u set up haproxy, youre telling me "gimme a loadbalancer on top of my cluster" | 03:41 |
| hub_cap | its still a cluster | 03:41 |
| hub_cap | and you are using haproxy to do the work | 03:41 |
| vipul | sure.. but i do feel that a lot of cluster will require knowledge of every node | 03:42 |
| hub_cap | im not sure thats the case | 03:43 |
| vipul | just like master/slave/read replication will | 03:43 |
| hub_cap | that will, for sure | 03:43 |
| vipul | I could see use cases that use a cluster for sharding or something | 03:43 |
| vipul | just target a shard to a node in a cluster | 03:44 |
| vipul | and you could say the same about multi-master | 03:44 |
| hub_cap | is that a cluster tho? | 03:45 |
| hub_cap | if its got different data | 03:45 |
| hub_cap | and you have tos hard | 03:45 |
| hub_cap | *shard | 03:45 |
| hub_cap | or just a bunch of machines w/ your own hashing algoritms | 03:45 |
| hub_cap | like what happens when your shard dies? if it was a cluster, it was writen to some other node | 03:46 |
| hub_cap | and a rebalance fixes it | 03:46 |
| hub_cap | like cassandra, you write to any node | 03:46 |
| vipul | Yep, exactly.. every shard is replicatd to every other node | 03:47 |
| hub_cap | well | 03:47 |
| hub_cap | right thats a cluster, and internally the tech does it | 03:47 |
| vipul | but you still want to leverage the toehr nodes in a cluster | 03:47 |
| hub_cap | not w cassandra | 03:47 |
| hub_cap | not w a true cluster | 03:47 |
| vipul | so they aren't sitting there idle.. and waiting to be promoted | 03:47 |
| vipul | if i had a write heavy app, i'd probably shard, and span my writes amongst all nodes | 03:48 |
| vipul | as long as i'm not doing anything that would cause the same rows to be written to on differnt nodes.. the cluster hadnles it all | 03:48 |
| vipul | it replicates those shards across to the toher nodes..and i could read from anywhere | 03:49 |
| hub_cap | exactly, so u shouldnt care about what node to read from | 03:49 |
| hub_cap | u wouldnt want to hardcode ips into your client app for that | 03:49 |
| vipul | but how do i configure the IPs to write to | 03:50 |
| vipul | unless i know them all | 03:50 |
| vipul | in cassandra.. you said you could write anywhere | 03:50 |
| vipul | so wouldn't you want to know all the nodes.. and just round-robin ? | 03:51 |
| vipul | or are we assuming there is always a single endpoint exposed.. and the logic to choose a node is hidden from the user | 03:51 |
| hub_cap | i was assuming a single endpoint | 03:52 |
| hub_cap | be it haproxy, or round robin dns | 03:52 |
| hub_cap | im nto sure how apps typically write to these tho | 03:52 |
| hub_cap | sometimes client side connector code does it too | 03:52 |
| hub_cap | im not saying u dont need to know all the ips... at least i dont thnk i am lol | 03:53 |
| hub_cap | im trying to figure out if we need to enact upon cluster nodes in a different ways from replication intances | 03:53 |
| hub_cap | im trying to simplify a cluster, but give you replication flexibility | 03:53 |
| vipul | Sure.. so if it's true that you might want to know about nodes in a cluster.. it's similar to needing to know about replica nodes | 03:53 |
| vipul | i'm trying to make that connection | 03:54 |
| hub_cap | but you acdess the replicas differently | 03:54 |
| hub_cap | u dont read from nodes 6~8 in cassandra and write to nodes 1~3 | 03:54 |
| hub_cap | u read and write to any o them | 03:54 |
| hub_cap | and, in theory, same w/ galera (if it didnt have limitations and need haproxy) | 03:55 |
| hub_cap | whereas in replication, you very often have small memory, tuned read slaves | 03:55 |
| hub_cap | diff configs | 03:55 |
| hub_cap | diff ram | 03:55 |
| vipul | Yea, i think the thing that makes sense to me is.. if we're exposing a single endpoint with cluster.. then it sorta makes sense to spearate the replica instances | 03:55 |
| openstackgerrit | Steve Leon proposed a change to openstack/trove: Add tenant id to guest_info file https://review.openstack.org/49671 | 03:55 |
| vipul | because then it's like you have a uber-instance with one entrypoint | 03:56 |
| vipul | which can't be the case with replicas | 03:56 |
| hub_cap | thats what a cluster is tho right? | 03:56 |
| vipul | but if we're opneing up the uber-instance... and exposing individual nodes.. | 03:56 |
| vipul | then what makes it different | 03:56 |
| hub_cap | the actions you do to them | 03:56 |
| hub_cap | never do u want different nodes in cluster, always do u in read replicas | 03:57 |
| hub_cap | maybe master-master is a cluster... and we an think of it as such | 03:57 |
| hub_cap | and replication is really just "read replicas" | 03:57 |
| hub_cap | but im not sure, at least in the beginning, i want to be adding in haproxy stuff too lol | 03:58 |
| hub_cap | we can use quantum tho for lbaas | 03:58 |
| vipul | Ok.. so now if we say that even read-replicas could be fail'd over to.. | 03:59 |
| hub_cap | http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-replication-multi-master.html <-- calls multi-master a cluster | 03:59 |
| *** adrian_otto has joined #openstack-trove | 03:59 | |
| hub_cap | read replicas can be promoted, yes | 03:59 |
| vipul | then is it that much different besides maybe the flavors | 03:59 |
| hub_cap | well the config will have to be updated, the flavor, and the relation to the other slave | 04:00 |
| hub_cap | if there is > 1 slave | 04:00 |
| hub_cap | or read replica | 04:00 |
| vipul | What if that slave if a hidden slave..that's used for HA only | 04:00 |
| vipul | would 'hidden slave' be a service type? | 04:00 |
| *** adrian_otto has quit IRC | 04:01 | |
| vipul | becasue then there is a single endpoint | 04:01 |
| vipul | you only write to the master.. we just promote the slave | 04:01 |
| vipul | it seems in that scenario.. master/slave falls into the cluster group | 04:02 |
| vipul | It's just confusing when the user has to know about the salve | 04:02 |
| hub_cap | would the user know abotu that slave even? | 04:02 |
| hub_cap | im not sure it applies if its not known to them or in their /instances in any way | 04:03 |
| vipul | But it is a service-level they are buying.. they want only a single node.. but with soem security blanket | 04:04 |
| vipul | it could be known in /instances as a node.. but maybe not it's IP or something | 04:04 |
| hub_cap | hmm | 04:04 |
| vipul | it seems that would make sense as a new service-type | 04:04 |
| hub_cap | ya | 04:04 |
| vipul | So far the distinction of an 'Instance' = a single endpoint.. makes sense.. but the more we start exposing node details | 04:06 |
| vipul | then i question why we separate read replicas | 04:06 |
| hub_cap | sry sec | 04:08 |
| hub_cap | putting wife/baby to sleep | 04:08 |
| hub_cap | ok | 04:11 |
| vipul | Maybe that's what we gotta try to group stuff into.. if we indeed think they are separate beasts | 04:12 |
| vipul | instance is one endpoint.. period | 04:12 |
| hub_cap | a read replica in a diff AZ | 04:12 |
| hub_cap | not sure thatll be easy to grok in a single instance | 04:12 |
| hub_cap | its doable yes | 04:12 |
| hub_cap | but i see it as this (let me gist) | 04:13 |
| hub_cap | but i guess you mgith want to distribute a cluster over AZs too | 04:15 |
| vipul | definitely.. but is that something that you'd expose to user.. the ability to choose | 04:16 |
| vipul | i could see the use case wehre replica they choose | 04:16 |
| vipul | but cluster has a scheduler tat decides for them | 04:16 |
| *** haomaiwang has joined #openstack-trove | 04:19 | |
| hub_cap | https://gist.github.com/hub-cap/6820884 | 04:19 |
| hub_cap | yes that makes sense vipul | 04:20 |
| hub_cap | cluster = hands off, id think | 04:20 |
| hub_cap | replica = you choose all the details | 04:20 |
| hub_cap | i think im ok w/ saying multi-master is a cluster | 04:22 |
| hub_cap | even tho its replication lol | 04:22 |
| vipul | yea so the only thing that's make replicas differnt now is flavor | 04:23 |
| vipul | does that warrant a different API to provision | 04:23 |
| hub_cap | possibly not, so then does master-slave become a service_type? | 04:23 |
| vipul | possibly.. | 04:24 |
| hub_cap | or do we go back to service_type=mysql cluster_type=master-slave,master-master,galera,tungsten | 04:24 |
| vipul | lol | 04:24 |
| vipul | ugh | 04:24 |
| vipul | i feel like that's where we are | 04:24 |
| vipul | just changing terminology | 04:24 |
| hub_cap | ya | 04:25 |
| hub_cap | lets do this | 04:25 |
| hub_cap | im tired | 04:25 |
| hub_cap | ive got some more autocad shit to do b4 i go to bed | 04:25 |
| hub_cap | lets chat w/ dsal tomorrow | 04:25 |
| hub_cap | imsplitbit: ^ ^ | 04:25 |
| vipul | sure, it's a good start..thanks for putting something up | 04:26 |
| vipul | i think we need to think about all these use cases | 04:26 |
| *** demorris has quit IRC | 04:27 | |
| hub_cap | yup | 04:28 |
| hub_cap | cuz even cassandra, u need to know the ips i think | 04:29 |
| hub_cap | to let the clients know (client software balances reads/writes) | 04:29 |
| hub_cap | .setSeeds("h1,h2,h3") | 04:31 |
| vipul | Yea and i think regarding differences in 'actions per service type'.. we said that replicas would have diffeent supported actions vs clusters | 04:31 |
| vipul | but if you think about it.. rebalanc ewon't be supporte by all clusters | 04:31 |
| vipul | so we'd probably have some cases where all operations won't be homogenous acros cluster types | 04:32 |
| hub_cap | fo sure | 04:32 |
| *** mmcdaris has joined #openstack-trove | 04:32 | |
| vipul | anyway.. time to get some beers | 04:32 |
| vipul | talk tomororw | 04:32 |
| hub_cap | yup | 04:32 |
| hub_cap | cu | 04:32 |
| *** mmcdaris has quit IRC | 04:48 | |
| *** mmcdaris has joined #openstack-trove | 04:56 | |
| *** showka has quit IRC | 05:06 | |
| *** ashestakov_ has joined #openstack-trove | 05:19 | |
| *** SushilKM has joined #openstack-trove | 05:29 | |
| *** mmcdaris has quit IRC | 05:38 | |
| *** mmcdaris has joined #openstack-trove | 05:46 | |
| *** ashestakov_ has quit IRC | 05:48 | |
| *** matsuhashi has quit IRC | 06:01 | |
| *** yogeshmehra has joined #openstack-trove | 06:07 | |
| *** nosnos has quit IRC | 06:08 | |
| *** metral has quit IRC | 06:08 | |
| *** dmakogon_ipod has joined #openstack-trove | 06:09 | |
| openstackgerrit | Steve Leon proposed a change to openstack/trove: Add tenant id to guest_info file https://review.openstack.org/49671 | 06:13 |
| *** krow has joined #openstack-trove | 06:13 | |
| *** debasish has joined #openstack-trove | 06:15 | |
| *** rushiagr has joined #openstack-trove | 06:21 | |
| PradeepChandani | Anybody have idea how to mock a variable in python | 06:23 |
| *** Kapil has joined #openstack-trove | 06:24 | |
| *** matsuhashi has joined #openstack-trove | 06:24 | |
| *** SushilKM has quit IRC | 06:27 | |
| *** krow has quit IRC | 06:30 | |
| *** krow has joined #openstack-trove | 06:30 | |
| *** dmakogon_ has joined #openstack-trove | 06:36 | |
| *** dmakogon_ipod has quit IRC | 06:37 | |
| *** mmcdaris has quit IRC | 06:45 | |
| *** nosnos has joined #openstack-trove | 06:54 | |
| *** mmcdaris has joined #openstack-trove | 07:16 | |
| *** rushiagr has quit IRC | 07:18 | |
| *** mmcdaris has quit IRC | 07:20 | |
| *** metral has joined #openstack-trove | 07:25 | |
| *** rushiagr has joined #openstack-trove | 07:29 | |
| *** tvb has joined #openstack-trove | 07:32 | |
| *** rushiagr has quit IRC | 07:39 | |
| *** ashestakov_ has joined #openstack-trove | 07:41 | |
| *** dmakogon_ has quit IRC | 07:55 | |
| *** rushiagr has joined #openstack-trove | 08:02 | |
| *** kevinconway has quit IRC | 08:07 | |
| *** Nate2 has quit IRC | 08:07 | |
| *** Nate1 has joined #openstack-trove | 08:07 | |
| *** kevinconway has joined #openstack-trove | 08:07 | |
| *** kevinconway has quit IRC | 08:08 | |
| *** redthrux has quit IRC | 08:08 | |
| *** Nate1 has quit IRC | 08:08 | |
| *** ashestakov_ has quit IRC | 08:13 | |
| *** SushilKM has joined #openstack-trove | 08:25 | |
| *** ashestakov_ has joined #openstack-trove | 08:47 | |
| *** yogeshmehra has quit IRC | 08:57 | |
| *** yogeshmehra has joined #openstack-trove | 08:57 | |
| *** SushilKM has quit IRC | 09:00 | |
| *** Kapil has quit IRC | 09:02 | |
| *** yogeshmehra has quit IRC | 09:02 | |
| *** redthrux has joined #openstack-trove | 09:05 | |
| *** Nate1 has joined #openstack-trove | 09:14 | |
| *** rushiagr has quit IRC | 09:15 | |
| *** rushiagr has joined #openstack-trove | 09:16 | |
| *** kevinconway has joined #openstack-trove | 09:17 | |
| *** Kapil has joined #openstack-trove | 09:25 | |
| *** Kapil has quit IRC | 09:29 | |
| *** Kapil has joined #openstack-trove | 09:34 | |
| *** rushiagr has quit IRC | 09:35 | |
| *** rushiagr has joined #openstack-trove | 09:38 | |
| *** Kapil has quit IRC | 09:45 | |
| *** tvb has quit IRC | 09:52 | |
| *** tvb has joined #openstack-trove | 09:53 | |
| *** yogeshmehra has joined #openstack-trove | 09:58 | |
| *** yogeshmehra has quit IRC | 10:02 | |
| *** yogeshmehra has joined #openstack-trove | 10:08 | |
| *** yogeshmehra has quit IRC | 10:12 | |
| *** matsuhashi has quit IRC | 10:28 | |
| *** krow has quit IRC | 10:53 | |
| *** dmakogon has left #openstack-trove | 10:56 | |
| *** rushiagr has quit IRC | 10:57 | |
| *** rushiagr has joined #openstack-trove | 11:06 | |
| *** SushilKM has joined #openstack-trove | 11:21 | |
| openstackgerrit | Denis M. proposed a change to openstack/trove: Update statuses on GA timeout https://review.openstack.org/45723 | 11:21 |
| openstackgerrit | Denis M. proposed a change to openstack/trove: Security groups workflow update https://review.openstack.org/45708 | 11:25 |
| *** nosnos has quit IRC | 11:32 | |
| *** rushiagr has quit IRC | 12:00 | |
| *** pdmars has joined #openstack-trove | 12:02 | |
| *** rushiagr has joined #openstack-trove | 12:09 | |
| *** SushilKM has quit IRC | 12:21 | |
| *** dmakogon has joined #openstack-trove | 12:37 | |
| *** debasish has quit IRC | 12:40 | |
| *** showka has joined #openstack-trove | 12:49 | |
| *** Barker has joined #openstack-trove | 12:51 | |
| *** jrodom has joined #openstack-trove | 12:58 | |
| *** demorris has joined #openstack-trove | 13:10 | |
| *** yogeshmehra has joined #openstack-trove | 13:10 | |
| *** robertmyers has joined #openstack-trove | 13:15 | |
| *** jcru has joined #openstack-trove | 13:16 | |
| *** yogeshmehra has quit IRC | 13:17 | |
| *** robertmyers has quit IRC | 13:18 | |
| *** robertmyers has joined #openstack-trove | 13:18 | |
| *** amytron has joined #openstack-trove | 13:33 | |
| *** djohnstone has joined #openstack-trove | 13:41 | |
| *** djohnstone1 has joined #openstack-trove | 13:42 | |
| *** djohnstone has quit IRC | 13:45 | |
| *** russellb is now known as rustlebee | 14:11 | |
| *** rnirmal has joined #openstack-trove | 14:14 | |
| *** jcru has quit IRC | 14:17 | |
| *** jcru has joined #openstack-trove | 14:18 | |
| *** jmontemayor has joined #openstack-trove | 14:19 | |
| openstackgerrit | Robert Myers proposed a change to openstack/trove: Fix the fake nova server implementation https://review.openstack.org/49759 | 14:25 |
| *** datsun180b has joined #openstack-trove | 14:47 | |
| *** haomaiwang has quit IRC | 14:49 | |
| *** tvb has quit IRC | 14:55 | |
| *** amytron has quit IRC | 14:56 | |
| *** SushilKM has joined #openstack-trove | 15:06 | |
| *** paul_lodronio has joined #openstack-trove | 15:15 | |
| *** adrian_otto has joined #openstack-trove | 15:19 | |
| *** djohnstone1 is now known as djohnstone | 15:19 | |
| openstackgerrit | Ed Cranford proposed a change to openstack/trove: Trove-conductor. https://review.openstack.org/45116 | 15:21 |
| *** SushilKM has quit IRC | 15:22 | |
| *** djohnstone has quit IRC | 15:23 | |
| *** djohnstone has joined #openstack-trove | 15:23 | |
| *** djohnstone has quit IRC | 15:25 | |
| *** djohnstone has joined #openstack-trove | 15:25 | |
| datsun180b | oh hubris! i keep not asking pep8 if it likes my code | 15:30 |
| openstackgerrit | Ed Cranford proposed a change to openstack/trove: Trove-conductor. https://review.openstack.org/45116 | 15:35 |
| datsun180b | grumble grumble blank lines expected | 15:36 |
| *** tanisdl has joined #openstack-trove | 15:41 | |
| *** showka has quit IRC | 15:43 | |
| *** demorris has quit IRC | 15:58 | |
| *** demorris has joined #openstack-trove | 15:59 | |
| hub_cap | datsun180b: cant u set that up in vim to run flake8 automagically? | 16:01 |
| datsun180b | if i wanted an ide i'd use pycharm. i like to keep vim pretty minimal. besides, i this was happening because i was running tox -epy26 while making sure my unit tests passed | 16:03 |
| datsun180b | if i'd run tox without -e i would've seen it immediately, i just got cocky | 16:03 |
| dmakogon | hub_cap: datsun180b: what's up | 16:04 |
| hub_cap | lol datsun180b, for the record ive put flake8 into emacs and i see a nice little underline if ive got an offensive line | 16:04 |
| datsun180b | emacs | 16:04 |
| hub_cap | since ive added it i havent had issues w tox | 16:04 |
| *** amytron has joined #openstack-trove | 16:04 | |
| hub_cap | u can do teh same in vim, its not making it an "ide" | 16:04 |
| hub_cap | or u can keep submitting 'tox'ic code LULZZZZZ | 16:05 |
| dmakogon | https://review.openstack.org/#/c/45723/ |||||| https://review.openstack.org/#/c/48305/ | 16:05 |
| datsun180b | oh i know, i'm being unnecessarily unfair | 16:05 |
| hub_cap | dmakogon: hey man | 16:05 |
| hub_cap | did u see me and metral fixed the gate? | 16:05 |
| dmakogon | i've heard today is a big day for review)) | 16:05 |
| hub_cap | well metral did, i just watched | 16:05 |
| hub_cap | dmakogon: it is!!! no code for me today :( | 16:05 |
| hub_cap | just reviewing | 16:05 |
| dmakogon | nice | 16:05 |
| datsun180b | isn't today day 1 for icehouse | 16:05 |
| hub_cap | honestly it depends on the RC1's | 16:06 |
| hub_cap | but at least 1/2 of them, yes | 16:06 |
| dmakogon | also, today we are going to discuss Heat templates in Trove))) | 16:06 |
| *** mmcdaris has joined #openstack-trove | 16:06 | |
| hub_cap | yup dmakogon | 16:06 |
| datsun180b | tab groups are the best thing for gerrit reviews | 16:06 |
| datsun180b | just pull a review tab into its own group before you hit Side-by-Side | 16:06 |
| hub_cap | hmm ill have to look @it | 16:07 |
| hub_cap | are they a firefox thing? or does chrome have too? | 16:07 |
| datsun180b | beats me | 16:07 |
| datsun180b | i only use chrome for flash | 16:07 |
| hub_cap | im assumign yer using ff | 16:07 |
| datsun180b | in ff you hit command-shift-e | 16:07 |
| metral | team effort between hub_cap and i :D | 16:08 |
| hub_cap | pssh | 16:09 |
| metral | lol | 16:09 |
| hub_cap | metral: fixed it ;) | 16:09 |
| hub_cap | dmakogon: i havent reviewed (just looked over quickly) the secgrps, it looks good i thin | 16:10 |
| hub_cap | think | 16:10 |
| hub_cap | ill review more in a bit | 16:10 |
| dmakogon | ok | 16:10 |
| dmakogon | thanks | 16:10 |
| dmakogon | i've got a lot of review without +/- | 16:10 |
| dmakogon | it would be nice | 16:10 |
| dmakogon | btw, Pradeep is taking to long with his update of service registry | 16:11 |
| hub_cap | dmakogon: do u _need_ it done for some reason? are you planning on deploying a custom service? | 16:19 |
| hub_cap | if not, give him time | 16:19 |
| hub_cap | you dont have to do everything ;) | 16:20 |
| dmakogon | i know | 16:20 |
| dmakogon | i've already helped him with some troubles | 16:20 |
| hub_cap | he might be on vacation for a day or two for all we know, and have the code done on his local git | 16:20 |
| dmakogon | i thought that it would not take a lot of time to do it =( | 16:20 |
| hub_cap | its also possible hes not working on trove 100% of his time | 16:20 |
| hub_cap | datsun180b: id like you to look @ this review since u did the host work originally https://review.openstack.org/#/c/47543/ | 16:23 |
| datsun180b | on it | 16:23 |
| hub_cap | by the way datsun180b | 16:23 |
| datsun180b | i've been kind of heads-down with conductor | 16:23 |
| hub_cap | you have 2 emails on launchpad, as 2 users | 16:23 |
| hub_cap | do u mean to do that? | 16:23 |
| hub_cap | u can join accts on launchpad, fwiw | 16:23 |
| datsun180b | i thought i had | 16:23 |
| dmakogon | guys, does trove has yaml lib as requirements ? | 16:23 |
| *** jmontemayor has quit IRC | 16:23 | |
| hub_cap | oh intersting | 16:23 |
| datsun180b | i should be unified as ed--cranford | 16:23 |
| hub_cap | dmakogon: no | 16:23 |
| dmakogon | i thinks he should | 16:23 |
| hub_cap | is yaml not built in? | 16:23 |
| dmakogon | PyYAML ? | 16:23 |
| *** jmontemayor has joined #openstack-trove | 16:23 | |
| hub_cap | oh duh nm | 16:24 |
| hub_cap | see if its in global requiremetns | 16:24 |
| hub_cap | https://github.com/openstack/requirements/blob/master/global-requirements.txt#L78 | 16:24 |
| hub_cap | so we can add when yogesh does the heat work | 16:24 |
| kevinconway | dmakogon: what do you need YAML for? | 16:25 |
| dmakogon | heat templates | 16:25 |
| dmakogon | storing them in yaml files, not in code | 16:25 |
| dmakogon | easy to change | 16:25 |
| dmakogon | without recompiling | 16:26 |
| kevinconway | you know… YAML is a superset of JSON | 16:26 |
| kevinconway | I wonder how HEAT would react to being given a JSON template | 16:26 |
| kevinconway | since JSON is valid YAML | 16:26 |
| datsun180b | i don't really have a problem with that host code, but one of the tests is confusing empty for null | 16:27 |
| kevinconway | also, do we need to actually parse YAML or just generate it for HEAT? | 16:27 |
| dmakogon | kevinconway: no generation! | 16:27 |
| kevinconway | you just want static templates? | 16:28 |
| dmakogon | yes | 16:28 |
| hub_cap | kevinconway: are you sure about that? yaml doesnt quote strings, for one | 16:28 |
| dmakogon | admin could easily change it | 16:28 |
| kevinconway | hub_cap: YAML usually can't be parsed into JSON, but JSON is valid YAML | 16:28 |
| hub_cap | ok ic what u mean | 16:28 |
| hub_cap | what youre saying is to use json, and parse into yaml (maybe) when we send to heat | 16:29 |
| isvirido` | hi, everybody | 16:29 |
| kevinconway | i was half joking. you should be able to send json to HEAT and it will just understand it as YAML | 16:29 |
| kevinconway | but if we're going to do YAML we should probably just do YAML | 16:29 |
| hub_cap | dokr | 16:30 |
| hub_cap | dork | 16:30 |
| hub_cap | ;) | 16:30 |
| isvirido` | kevinconway, +1 it handles json as well | 16:30 |
| kevinconway | but if we don't actually need to load and parse the YAML then just a static file or a JINJA2 template would work | 16:30 |
| kevinconway | and JINJA2 is already a dependency | 16:30 |
| hub_cap | yes we shoudl use jinja | 16:30 |
| hub_cap | for the "pieces" | 16:31 |
| hub_cap | if possible :) | 16:31 |
| hub_cap | but at the same time, giving pyyaml a dict will turn it into a nice yaml doc for you... so im sure there will be pro's/con's | 16:32 |
| hub_cap | but there is static junk that a jinja template would be great for | 16:32 |
| datsun180b | so for my conductor work to really get through i need that devstack change to work and pass review. what's the etiquette for rechecking devstack reviews if i don't feel like i caused the test failures | 16:32 |
| isvirido` | actually we shouldn't do any parsing, template is just a string | 16:33 |
| hub_cap | datsun180b: send me the link yer talking about | 16:33 |
| hub_cap | isvirido`: its a collection of strings, that will have to be built (think clustering, or think, adding a node to an existing cluster) | 16:33 |
| datsun180b | hub_cap: https://review.openstack.org/#/c/49237/ | 16:34 |
| isvirido` | hub_cap, are you going to generate that template? What is use case? | 16:34 |
| datsun180b | jinja is great, let's use it for everything | 16:35 |
| isvirido` | To add the node, we can update instance number parameter for InstanceGroup resource | 16:35 |
| datsun180b | hungry? eat a jinja template. cold? wrap yourself up with jinja templates. | 16:35 |
| *** tvb has joined #openstack-trove | 16:35 | |
| *** demorris has quit IRC | 16:35 | |
| hub_cap | isvirido`: fair point. we may be able to externalize enough of the variables such that we dont need to | 16:36 |
| hub_cap | how bout turning a single instance into a master/slave | 16:36 |
| datsun180b | generating output from structured data? use jinja templates to keep the presentation work in one place and keep from making assumptions about use cases | 16:36 |
| datsun180b | maybe not everyone needs the ips of their instances or cares about how user and host are different fields of a user | 16:36 |
| hub_cap | datsun180b: just try a recheck no bug, i mean, its been 3 days | 16:36 |
| datsun180b | hub_cap: i don't want to invoke any ire from devs i don't know | 16:37 |
| hub_cap | then ill do it | 16:37 |
| hub_cap | just say teh word | 16:37 |
| datsun180b | i did it | 16:37 |
| datsun180b | eggs and omelettes | 16:37 |
| *** SnowDust has joined #openstack-trove | 16:37 | |
| hub_cap | LOL | 16:37 |
| SnowDust | TGIF ! | 16:37 |
| isvirido` | hub_cap, yes parametrize the template with all need parameters and keep set of templates for different service types | 16:38 |
| SnowDust | is it heat templates .. still continuing ? :) | 16:38 |
| hub_cap | lol SnowDust we havent technically started yet, we are waiting for yogesh | 16:39 |
| dmakogon | yes | 16:39 |
| hub_cap | but yes we started generalizing ideas | 16:39 |
| SnowDust | isvirido +1 from my side .. | 16:39 |
| SnowDust | i said that yesterday :) .. the gist is rock solid from dmakogon | 16:40 |
| isvirido` | For booting several instance with different configuration we can just declare ec2instance resource for master f.e. and instancegrouo for replicas. Each will have own userdata | 16:40 |
| SnowDust | but .. we should keep the template as easy .. for any admin ..who knows heat but never spent any time digging trove | 16:40 |
| hub_cap | isvirido`: awesome, SnowDust agreed | 16:41 |
| hub_cap | we should spend some time creating these templates | 16:41 |
| isvirido` | SnowDust, +1 yes, and propably in future give the possibility to tune it by admin | 16:41 |
| kevinconway | jinja supports template that let you set defaults but then another dev can import them and extend them with custom block content | 16:41 |
| hub_cap | dmakogon: that woudl be a good way to share the work, maybe one of yall does the template work, then another does the code work | 16:41 |
| hub_cap | kevinconway: im not sure we will _need_ jinja, since heat is its own templating system | 16:41 |
| isvirido` | kevinconway, with any template generation we are loosing flexibility of template tunning | 16:42 |
| dmakogon | hub_cap: lets wait for yogesh to split tasks | 16:42 |
| hub_cap | yup dmakogon | 16:42 |
| kevinconway | two different uses of the same term are they not? | 16:42 |
| hub_cap | yes but we will have to use a jinja template to turn a static template into a static string | 16:43 |
| isvirido` | oh... i mean only HEAT templates | 16:43 |
| kevinconway | a HEAT template is a kind of configuration script. a JINJA template is a parametrized block of text. | 16:43 |
| hub_cap | and then give heat the template variables | 16:43 |
| kevinconway | eeeew. does HEAT take it's own variables in a template? | 16:43 |
| hub_cap | yes | 16:43 |
| dmakogon | hub_cap: i just want to keep templates in one folder, each should be named as si_service-template.yaml and cl_service-template.yaml | 16:43 |
| kevinconway | boo | 16:43 |
| kevinconway | never mind | 16:43 |
| hub_cap | definitely dmakogon | 16:43 |
| hub_cap | lol kevinconway | 16:44 |
| hub_cap | kevinconway: https://github.com/openstack/heat-templates/blob/master/cfn/deb/MultiNode_DevStack.yaml | 16:44 |
| isvirido` | hub_cap, what do you mean "to turn"? won't we just load it and handle as a string? | 16:44 |
| hub_cap | see Parameters section | 16:44 |
| hub_cap | correst isvirido` we will, i was just point out to kevinconway why we didnt need jinja | 16:44 |
| hub_cap | when is the heat chat today? | 16:45 |
| isvirido` | yeap, it is already powerfull enogh | 16:45 |
| hub_cap | 1900 dmakogon? | 16:45 |
| hub_cap | or 1800? | 16:45 |
| dmakogon | 11 AM | 16:45 |
| SnowDust | lets keep the templates independent .. in their atomic state | 16:45 |
| hub_cap | 11am pacific? | 16:45 |
| hub_cap | SnowDust: ++ | 16:45 |
| isvirido` | SnowDust, +1 | 16:45 |
| dmakogon | probably yes | 16:46 |
| datsun180b | i'm seeing two senses of 'template' if i'm following this discussion properly | 16:46 |
| SnowDust | a admin doesnot have to fool with the class /object cruft | 16:46 |
| SnowDust | an* | 16:46 |
| hub_cap | datsun180b: you are, but we dont care about one of them (jinja) | 16:46 |
| hub_cap | lets pretend we never said jinja today | 16:46 |
| dmakogon | hub_cap: 11 AM PDT | 16:46 |
| datsun180b | just making sure i'm keeping up | 16:46 |
| hub_cap | dmakogon: <3 | 16:46 |
| hub_cap | datsun180b: yes ur :) | 16:46 |
| SnowDust | what ever we do .. on HEAT calls .. thats internal .. we can make it better no objections :) | 16:46 |
| hub_cap | HAHAHAHAH yes SnowDust | 16:46 |
| hub_cap | its impossible to make it worse at this point | 16:47 |
| SnowDust | hehehe .. understand hub_cap ;) | 16:47 |
| SnowDust | templates can be organized in directory .. for each service_type | 16:48 |
| dmakogon | SnowDust: really ?)))) | 16:48 |
| isvirido` | SnowDust, +1 | 16:48 |
| SnowDust | yeah why not .. its only os.path to fiddle it with :) | 16:48 |
| SnowDust | and get a dictionary .. for service type .. and actions .. on that service type | 16:49 |
| SnowDust | each action is the template itself .. | 16:49 |
| hub_cap | i dont think we will have > 1 template for service_type, right? | 16:49 |
| hub_cap | service_type.heat.template | 16:49 |
| SnowDust | nope .. multiple template ... 1 node .. n node cluster .. loadbalanced n node .. and so on ! | 16:50 |
| isvirido` | whould be easier to manage | 16:50 |
| *** shivamshukla_ has joined #openstack-trove | 16:51 | |
| dmakogon | hub_cap: one template per single instance, one for cluster | 16:51 |
| * isvirido` swithching locatoin but will join soon | 16:51 | |
| dmakogon | templates would be stored in etc/heat_templates | 16:52 |
| SnowDust | yeah .. demakogon .. so for a lamer .. its an action name .. .. 1_node(.yaml) .. n_node(.yaml) ... n_node_lb(.yaml) | 16:52 |
| SnowDust | dmakogon .. why not /var ? | 16:52 |
| dmakogon | why it should be there ? | 16:52 |
| SnowDust | just asking :) | 16:53 |
| SnowDust | it should be a configurable path i meant ... hehe | 16:53 |
| dmakogon | trove already hat etc dir | 16:53 |
| dmakogon | yes, in config | 16:53 |
| hub_cap | dmakogon: SnowDust ok im going AFK for ~1 hr | 16:56 |
| hub_cap | ill bbl | 16:56 |
| *** yidclare has joined #openstack-trove | 17:13 | |
| *** SushilKM has joined #openstack-trove | 17:14 | |
| *** amytron has quit IRC | 17:21 | |
| *** yogesh has joined #openstack-trove | 17:21 | |
| SnowDust | yogesh: welcome ! | 17:22 |
| yogesh | hey, whaaup | 17:23 |
| yogesh | whassup... | 17:23 |
| yogesh | we are meeting at 11:00 PT for templates...right... | 17:24 |
| SnowDust | meeting is continuing .. | 17:24 |
| SnowDust | dmakogon is here too | 17:24 |
| yogesh | awesome | 17:24 |
| yogesh | great... | 17:24 |
| SnowDust | hub_cap will be .. here in 40 mins | 17:24 |
| yogesh | i need to go in 6 mins for a meeting... | 17:24 |
| yogesh | will be back in around half an hour | 17:26 |
| yogesh | but i'll be participative.. :-) | 17:28 |
| yogesh | dmakagon: whassup....any new direction you guys thought of... | 17:29 |
| esmute | vipul, hub_cap, SlickNik: When your busy time allows. Pretty easy review. https://review.openstack.org/#/c/49671/ | 17:30 |
| *** SushilKM has quit IRC | 17:32 | |
| datsun180b | woohoo, https://review.openstack.org/#/c/49237/ passed | 17:37 |
| *** SushilKM__ has joined #openstack-trove | 17:41 | |
| *** Seal has joined #openstack-trove | 17:41 | |
| *** yogesh has quit IRC | 17:41 | |
| *** yogesh has joined #openstack-trove | 17:42 | |
| *** yogesh has quit IRC | 17:43 | |
| *** yogesh_ has joined #openstack-trove | 17:43 | |
| *** krow has joined #openstack-trove | 17:47 | |
| *** yogesh_ has quit IRC | 17:51 | |
| *** yogesh has joined #openstack-trove | 17:52 | |
| *** dmakogon_ has joined #openstack-trove | 17:52 | |
| dmakogon_ | i'm here | 17:54 |
| *** isviridov has joined #openstack-trove | 17:54 | |
| dmakogon_ | whaazzaaaaaaaaaaaa | 17:54 |
| *** yogesh_ has joined #openstack-trove | 17:54 | |
| *** yogesh has quit IRC | 17:54 | |
| SnowDust | zzzzzzzzzzz | 17:55 |
| SnowDust | yawning .. ! | 17:55 |
| dmakogon_ | today my cat is selebrating | 17:55 |
| dmakogon_ | animal-care day | 17:56 |
| dmakogon_ | he's drunk and want to fight | 17:56 |
| isviridov | you are caring about him in a strange way | 17:57 |
| dmakogon_ | yogesh, ping | 17:57 |
| dmakogon_ | isviridov | 17:57 |
| dmakogon_ | ping | 17:57 |
| dmakogon_ | it's his day, let it be | 17:58 |
| isviridov | dmakogon_, pong | 17:58 |
| dmakogon_ | hub_cap: pijg | 17:58 |
| dmakogon_ | ping | 17:58 |
| isviridov | dmakogon_, trace | 17:58 |
| SnowDust | isviridov: u insulted the cat :) | 17:58 |
| SnowDust | u called it an animal on caring day LOL | 17:58 |
| isviridov | )) | 17:59 |
| dmakogon_ | current agenda https://blueprints.launchpad.net/trove/+spec/provide-custom-heat-templates-for-each-service-in-trove | 17:59 |
| dmakogon_ | isviridov, i would like you 2 examine it | 17:59 |
| isviridov | k | 17:59 |
| *** SushilKM__ has quit IRC | 18:00 | |
| *** VinodGupta has joined #openstack-trove | 18:00 | |
| *** yogesh_ has quit IRC | 18:00 | |
| *** yogesh has joined #openstack-trove | 18:01 | |
| *** yogesh has quit IRC | 18:01 | |
| *** yogesh has joined #openstack-trove | 18:02 | |
| yogesh | hello... | 18:02 |
| SnowDust | hello again .. | 18:02 |
| isviridov | hi, yogesh | 18:02 |
| hub_cap | ok im back! let me scroll up in history | 18:03 |
| dmakogon_ | what's up, yogesh | 18:03 |
| dmakogon_ | i've updated BP a bit | 18:03 |
| yogesh | dmakagon: hub_cap: hi | 18:03 |
| dmakogon_ | yogesh: typo in my nick | 18:03 |
| yogesh | oops... | 18:04 |
| hub_cap | dmakogon_ we can never tell what version of dmakogon* you are ;) | 18:04 |
| dmakogon_ | yogesh, my name is Denis Makogon | 18:04 |
| dmakogon_ | lol | 18:04 |
| *** jasonb365 has joined #openstack-trove | 18:04 | |
| hub_cap | its dmakogon dmakogon_ dmakogon-ipod | 18:04 |
| yogesh | dmakogon: got it....thanks | 18:04 |
| dmakogon_ | hub_cap: my nicks are flexible | 18:04 |
| yogesh | yeah... | 18:04 |
| yogesh | per device... | 18:04 |
| hub_cap | lol dmakogon_ my nick is rigid, u always know who i am | 18:04 |
| hub_cap | i use a irssi proxy so i can connect to my user from anywhere | 18:04 |
| hub_cap | and see my history | 18:04 |
| dmakogon_ | nice | 18:05 |
| dmakogon_ | so, shell we ? | 18:05 |
| yogesh | thats great... | 18:05 |
| yogesh | yup... | 18:05 |
| hub_cap | ya u should look into it, cuz then u can connect to your user from > 1 device (i use it on my phone too and youd never know) | 18:05 |
| dmakogon_ | current state: keeping templates at etc/heat_templates | 18:05 |
| yogesh | absolutely...i was having tuf time with multi dvices.. | 18:05 |
| dmakogon_ | Let's keep templates in etc/heat_templates | 18:05 |
| yogesh | lemme share my gist... | 18:05 |
| dmakogon_ | 1 per service single instance, 1 per service cluster. | 18:06 |
| dmakogon_ | that is what we have discussed yesterday | 18:06 |
| yogesh | https://gist.github.com/mehrayogesh/6822849 | 18:06 |
| yogesh | this is generic and i wanted this meeting to happen before we go further... | 18:06 |
| dmakogon_ | Cluster-Flavor Management - is a part of Cluster API | 18:07 |
| yogesh | it will be the existing flavor api... | 18:07 |
| dmakogon_ | flavor API ? | 18:08 |
| yogesh | to get the flavors per sevice types... | 18:08 |
| yogesh | the service type / flavor mapping work... | 18:09 |
| dmakogon_ | yogesh: do we really need them ? | 18:09 |
| yogesh | yes...it helps in establishing the CONTEXT for the template.. | 18:09 |
| dmakogon_ | when user passing flavor, he suppose to know if it is enough for service type | 18:09 |
| yogesh | .i am assuming multiple templates per service type | 18:09 |
| dmakogon_ | what the difference ? | 18:10 |
| yogesh | the template factory needs to know what template needs to be instantiated.. | 18:10 |
| yogesh | the CONTEXT part in the gist.. | 18:10 |
| dmakogon_ | i see | 18:11 |
| isviridov | In https://wiki.openstack.org/wiki/Trove-Replication-And-Clustering-API we have clustertype, whay we need cluster flavor? | 18:11 |
| hub_cap | we dont need cluster flavor | 18:11 |
| hub_cap | sorry just got back into the conversation | 18:11 |
| yogesh | sure... | 18:11 |
| dmakogon_ | hub_cap: i think no | 18:11 |
| hub_cap | lets _not_ talk clusters for now, the cluster API will be changed in the next few weeks | 18:11 |
| yogesh | for deciding the epcific template... | 18:11 |
| hub_cap | yogesh: its entirely possible we might just make a cluster a new service_type (thats an idea i had) | 18:12 |
| dmakogon_ | yogesh: what is the difference between templates for flavors ? | 18:12 |
| isviridov | hub_cap, +1 | 18:12 |
| hub_cap | so galera-cluster will be its own service_type, making configurations and guest impl simple | 18:12 |
| yogesh | service_type for cluster? | 18:12 |
| hub_cap | and a flavor wil ljust apply to all "nodes" in a cluster | 18:12 |
| dmakogon_ | hub_cap +1 | 18:13 |
| hub_cap | see why i didnt want to talk clusters yogesh :) | 18:13 |
| yogesh | thats fine... | 18:13 |
| hub_cap | its an idea i had yesterday | 18:13 |
| hub_cap | it makes the code simpler | 18:13 |
| yogesh | so do we limit this discussion to single template...per service type | 18:13 |
| dmakogon_ | +1 | 18:13 |
| dmakogon_ | yes | 18:13 |
| hub_cap | yes lets figure out, for now | 18:13 |
| hub_cap | how to make existing heat templates better | 18:13 |
| SnowDust | hub_cap .. single template means .. callable in the code .. but templates can be nested .. as allowed by heat | 18:13 |
| dmakogon_ | i've described to to make it pluggable | 18:14 |
| yogesh | then just externalizing and making it cconfigurable... | 18:14 |
| dmakogon_ | *how to | 18:14 |
| yogesh | the point 1 in gist, where the CONTEXT is configurable per service type | 18:14 |
| dmakogon_ | yogesh +1 | 18:14 |
| hub_cap | true SnowDust | 18:14 |
| yogesh | the point 1 in the gist.. | 18:14 |
| dmakogon_ | SnowDust +1 | 18:14 |
| yogesh | allows for mnexsted templates.. | 18:14 |
| yogesh | nested* | 18:15 |
| hub_cap | so lets try to figure out how to make templates external/extensible, right? | 18:15 |
| dmakogon_ | we just loading template, no matter what would be in it | 18:15 |
| yogesh | yes... | 18:15 |
| yogesh | dmakogon: +1 | 18:15 |
| dmakogon_ | hub_cap +1 | 18:15 |
| dmakogon_ | so, could i suggest a algorithm of loading ? | 18:16 |
| hub_cap | dmakogon_ sure | 18:16 |
| yogesh | it'll be a straight template load op, rigth? | 18:16 |
| yogesh | read the template content and pass it on to HEAT... | 18:16 |
| dmakogon_ | as yogesh said we need factory which would load template according to service type | 18:17 |
| SnowDust | just make service-type a folder .. and actions .. a template_name(.yaml) inside them | 18:17 |
| dmakogon_ | templates in etc/heat_templates | 18:17 |
| dmakogon_ | SnowDust : yes | 18:17 |
| yogesh | snowdust: +1 | 18:17 |
| yogesh | actually now we don't need a factory... | 18:17 |
| dmakogon_ | hub_cap: should we keep templates in YAML ? | 18:17 |
| hub_cap | id prefer a factory-factory. lets rewrite in java!!!!! ;) | 18:18 |
| yogesh | i mean, it is loading a single flavor of the template | 18:18 |
| yogesh | :-) | 18:18 |
| dmakogon_ | we need HeatTemplateLoader | 18:18 |
| isviridov | Let it be at least /etc/trove/heat_templates | 18:18 |
| hub_cap | yes to yaml | 18:18 |
| yogesh | isviridov: +1 | 18:18 |
| dmakogon_ | and templates in *.yaml | 18:19 |
| hub_cap | itll be just like the way configuration code is | 18:19 |
| hub_cap | but w/o the need for jinja | 18:19 |
| yogesh | makes sense | 18:19 |
| SnowDust | lets .. make flavor a parameter for the template .. it can .. load any type defined as its distinguished options .. | 18:19 |
| hub_cap | but u know... if we use jinja, it will make the loader easier | 18:19 |
| dmakogon_ | hub_cap +1 | 18:19 |
| hub_cap | let me expand | 18:19 |
| hub_cap | https://github.com/openstack/trove/blob/master/trove/common/template.py#L17 | 18:19 |
| hub_cap | you can use a external directory, or a package | 18:20 |
| isviridov | Factory whould better, and used by different service types | 18:20 |
| dmakogon_ | hap_cap: we could load yaml.load(..) | 18:20 |
| dmakogon_ | isviridov +1 | 18:20 |
| isviridov | SnowDust, disctinary of parameters? | 18:20 |
| hub_cap | does load work on files dmakogon_? | 18:20 |
| dmakogon_ | yes | 18:20 |
| SnowDust | in heat .. u can define a list of values as an acceptable parameter .. | 18:20 |
| yogesh | what parameters do we envision? | 18:21 |
| dmakogon_ | http://pyyaml.org/wiki/PyYAMLDocumentation | 18:21 |
| dmakogon_ | stream = file('document.yaml', 'r') | 18:21 |
| isviridov | SnowDust, yes. Let us leave it flexible to define any parameter in template and pass them via dictionary to heat | 18:21 |
| dmakogon_ | yaml.load(stream) | 18:21 |
| SnowDust | but why we are loading the YAML ? | 18:21 |
| isviridov | ? | 18:21 |
| SnowDust | if heat -client api has that function ? | 18:22 |
| hub_cap | i dont think we need to use yaml if we arent manipulating it right? | 18:22 |
| hub_cap | its just a string that u pass to heat | 18:22 |
| SnowDust | true : hub_cap ! | 18:22 |
| hub_cap | SnowDust: can u find docs for that? or the code? | 18:22 |
| dmakogon_ | hub_cap: yes | 18:22 |
| dmakogon_ | we can | 18:22 |
| hub_cap | so i say we say _no_ to pyyaml unless we need to manipulate yaml | 18:22 |
| isviridov | yes, actually of can be json as well if admin prefers | 18:22 |
| hub_cap | agreed? | 18:22 |
| dmakogon_ | hub_cap: agreed | 18:22 |
| hub_cap | id guess u can pass a file to heat client | 18:23 |
| SnowDust | didnt understand .. why manupulate .. | 18:23 |
| yogesh | hub_cap: +1 | 18:23 |
| isviridov | strongly agreed | 18:23 |
| hub_cap | SnowDust: we arent manipulating | 18:23 |
| SnowDust | an admin authors the template .. / changes it ! | 18:23 |
| hub_cap | correct | 18:23 |
| dmakogon_ | +1 | 18:23 |
| SnowDust | we just pass the parameters .. flexibly to it :) | 18:23 |
| SnowDust | for each .. service type | 18:23 |
| SnowDust | thats the discussion .. | 18:23 |
| hub_cap | we should cfg.template_dir the directory too | 18:23 |
| hub_cap | so a operator can change it | 18:23 |
| yogesh | yes... | 18:23 |
| hub_cap | with the default to etc/trove/heat_templates | 18:24 |
| SnowDust | hub_cap : agreed | 18:24 |
| hub_cap | and then we will have to add them to the distribution too (manifest.mf stuff) | 18:24 |
| hub_cap | *manifest.in | 18:24 |
| isviridov | yeap | 18:24 |
| yogesh | where do the parameter get loaded... | 18:24 |
| yogesh | parameters... | 18:25 |
| dmakogon_ | hub_cap: template dir in taskmanager.conf | 18:25 |
| hub_cap | yes dmakogon_ | 18:25 |
| yogesh | right now they get done from within taskmanager.. | 18:25 |
| hub_cap | teh applicaiton will define most of the parameters | 18:25 |
| yogesh | are we saying that same set of params will be required for all service types.. | 18:25 |
| hub_cap | the things tha can be external are user_data (like dmakogon_'s gist) | 18:25 |
| isviridov | prepared by service_type implementation and passed as dictionary | 18:25 |
| SnowDust | can be .. the same "parameter=value;parameter2=value2;" approach .. | 18:25 |
| dmakogon_ | hub_cap: <3 | 18:25 |
| SnowDust | over command line .. | 18:25 |
| hub_cap | yogesh: lets figure that out when we have > 1 service lol | 18:25 |
| yogesh | technically, we have... :-) | 18:26 |
| dmakogon_ | for now we are blocking parameters list | 18:26 |
| hub_cap | ok lets figure that out when we have > 1 service that needs different parameters ;) | 18:26 |
| dmakogon_ | just using fixed set of parameters | 18:26 |
| hub_cap | we can refactor later :) | 18:26 |
| SnowDust | hub_cap : thats why i said .. | 18:26 |
| SnowDust | keep it over command line | 18:26 |
| SnowDust | so that every service type .. receives a parameter string .. | 18:26 |
| yogesh | hub_cap: it is about peer-peer clustering and master-slave clustering... | 18:27 |
| SnowDust | which will be parsed .. | 18:27 |
| dmakogon_ | hub_cap: i thinks we only need custom userdata, nothing else | 18:27 |
| *** krow has quit IRC | 18:27 | |
| dmakogon_ | should be easy | 18:27 |
| yogesh | does it align with the cluster implementationt hat is being worked upon... | 18:27 |
| dmakogon_ | yes | 18:27 |
| isviridov | why not dictinary? | 18:27 |
| isviridov | why we have to parse anything? | 18:27 |
| dmakogon_ | yogesh: perfectly | 18:28 |
| SnowDust | isviridov .. after parsing .. it can be a dict .. | 18:28 |
| dmakogon_ | sorry, i missed something, dict for what ? | 18:28 |
| yogesh | dict for params | 18:28 |
| isviridov | SnowDust, where we getting that parameters for parsing? | 18:28 |
| SnowDust | isviridov .. if u dont parse .. u are limited to a service type .. by your dict .. in config .. | 18:28 |
| dmakogon_ | wowowoow | 18:28 |
| kevinconway | SnowDust: what's the desire to parse? | 18:28 |
| dmakogon_ | let's stop a bit | 18:28 |
| dmakogon_ | for now we are blocking parameters | 18:29 |
| SnowDust | ;) yes ! NP | 18:30 |
| yogesh | what will be the params? | 18:30 |
| isviridov | parameters for heat template | 18:30 |
| isviridov | the data we are sending to heat together with template as a string | 18:30 |
| dmakogon_ | for the next sprint we could store or get parameters from somewhere | 18:30 |
| yogesh | thats fine... | 18:30 |
| yogesh | but we are talking about a single param list for all service types...would it be same as defined int he heat template in template.py | 18:31 |
| SnowDust | yogesh: it cant be same for all service type .. | 18:31 |
| isviridov | It can be really different | 18:31 |
| yogesh | yup...so we need to have different params... | 18:31 |
| isviridov | disctionary? | 18:31 |
| SnowDust | isviridov : parsed to dictionary :) | 18:32 |
| dmakogon_ | isviridov: could we look at template and than define what parameters we need and how much ? | 18:32 |
| SnowDust | so that .. during the client request .. its parsed into key/values | 18:32 |
| yogesh | so template manipulation is required....to add the param values per service type.. | 18:32 |
| hub_cap | when its different we will talk about this i think | 18:32 |
| hub_cap | for now it should be same right? | 18:32 |
| hub_cap | for percona/mysql | 18:33 |
| dmakogon_ | yes | 18:33 |
| dmakogon_ | hub_cap + | 18:33 |
| dmakogon_ | 1 | 18:33 |
| yogesh | true | 18:33 |
| hub_cap | its just for provisioning an instance for now | 18:33 |
| hub_cap | once we do cool stuff w/ clusters, lets focus on fixing it | 18:33 |
| hub_cap | for now, lets make heat for instances not suck lol | 18:33 |
| isviridov | Ok. Let us just resume to it when we will be closer | 18:33 |
| dmakogon_ | let's discuss about tasks ? | 18:33 |
| SnowDust | hub_cap : its same cuz .. we never thought this week .. redis will hit us :) | 18:33 |
| hub_cap | im not sure it will | 18:34 |
| yogesh | snowdust: elaborate | 18:34 |
| hub_cap | itll still need an instance of a certain flavor/disk | 18:34 |
| hub_cap | all the _different_ things will be in the redis.heat.template | 18:34 |
| SnowDust | i saw redis .. is getting into trove .. | 18:34 |
| hub_cap | yes it is | 18:34 |
| hub_cap | but remember the differences, like what packages to install, will be in the tempalte itslef | 18:34 |
| hub_cap | *itself | 18:34 |
| dmakogon_ | hub_cap: who we delegate task for configuration if template loading ? | 18:34 |
| openstackgerrit | A change was merged to openstack/trove: Add tenant id to guest_info file https://review.openstack.org/49671 | 18:34 |
| hub_cap | i think yogesh was the one who brought this up, so ill let him decide that dmakogon_ | 18:35 |
| isviridov | hub_cap, with cloud init you can define list of packages to install | 18:35 |
| hub_cap | isviridov correct | 18:35 |
| hub_cap | so the redis.heat.template will define that | 18:35 |
| yogesh | i can get it done.. | 18:35 |
| hub_cap | and the mysql.heat.template will define something else | 18:35 |
| hub_cap | as well as the percona.heat.template | 18:35 |
| yogesh | the params still stay same, right? | 18:35 |
| hub_cap | what im sayin is that the _differences_ will be defined in the template | 18:36 |
| hub_cap | correct yogesh | 18:36 |
| hub_cap | the userdata shoudl be loaded externally though | 18:36 |
| hub_cap | as in, you can do custom goofy things if u want | 18:36 |
| dmakogon_ | true | 18:36 |
| yogesh | why can't it be a part of the template itself... | 18:36 |
| hub_cap | i guess thats a good point | 18:36 |
| isviridov | userdata can be also paramatrizeds | 18:36 |
| hub_cap | if u want to do goofy stuff | 18:36 |
| hub_cap | put it in the custom template in your installation | 18:36 |
| hub_cap | right? | 18:36 |
| SnowDust | we are mixing it :) | 18:37 |
| hub_cap | if you want to use pypy instead of stock python | 18:37 |
| hub_cap | then put that in your template. we wont support it | 18:37 |
| hub_cap | like the example dmakogon_ had was to add custom java stuff | 18:37 |
| hub_cap | but we migth need that for cassandra anyway, so it might be in the stock cassandra.heat.template | 18:37 |
| *** krow has joined #openstack-trove | 18:37 | |
| hub_cap | and if its not, u can edit your template in /etc/trove/heat_templates in your installation, right? | 18:38 |
| dmakogon_ | hub_cap: true | 18:38 |
| hub_cap | instead of putting a bunch of commands in the configuration file for taskmgr | 18:38 |
| dmakogon_ | hub_cap +1 | 18:38 |
| dmakogon_ | so, what about custom userdata ? | 18:38 |
| yogesh | i am slightly confused... :-) | 18:38 |
| yogesh | let me recollect myself... | 18:38 |
| hub_cap | dmakogon_ custom userdata = edit the template in your installation | 18:38 |
| SnowDust | hub_cap : understood .. but that means .. an admin has to fix the code by navigating to redis.heat.template ? | 18:39 |
| hub_cap | no need for "custom" userdata | 18:39 |
| isviridov | hub_cap, true | 18:39 |
| dmakogon_ | ok | 18:39 |
| *** jasonb365 has quit IRC | 18:39 | |
| SnowDust | if he needs .. some more params .. on the same template ? | 18:39 |
| hub_cap | lets deal with that when someone needs it SnowDust | 18:39 |
| hub_cap | that will complicate things cuz ther is no way to inject parameters | 18:39 |
| hub_cap | in the first version of what we are doing | 18:39 |
| isviridov | hub_cap, true | 18:40 |
| SnowDust | ok .. makes sense ! | 18:40 |
| hub_cap | i do see that we could need it in the future tho SnowDust | 18:40 |
| yogesh | so, UserData stays in the template and if there is a modification required the template gets updated by the admin... | 18:40 |
| hub_cap | correct yogesh | 18:40 |
| dmakogon_ | true | 18:40 |
| dmakogon_ | yogesh +1 | 18:40 |
| yogesh | great... | 18:40 |
| yogesh | all the instances in the instancegroup :-) get created of the flavor provided in the instance creation api... | 18:41 |
| dmakogon_ | yogesh: any estimates for this task? | 18:41 |
| dmakogon_ | yogesh: yes | 18:41 |
| yogesh | i think we have taken the complications away | 18:42 |
| dmakogon_ | agreed | 18:42 |
| yogesh | in the wake of clustering api... | 18:42 |
| hub_cap | yes we have some people working on that today | 18:42 |
| yogesh | so it lies in SIMPLE category now | 18:42 |
| yogesh | the task breakup is: | 18:43 |
| SnowDust | service_type = string = many possibilities .. GR8 ! | 18:43 |
| yogesh | 1. finalize the directory structure | 18:43 |
| dmakogon_ | hub_cap: https://review.openstack.org/#/c/48305/ | 18:43 |
| dmakogon_ | 2. template loader | 18:44 |
| yogesh | 2. load the template | 18:45 |
| dmakogon_ | i'm faster, yogesh ;) | 18:45 |
| yogesh | 3. define what configurations... | 18:45 |
| yogesh | you absolutely are... :-) | 18:45 |
| *** krow has quit IRC | 18:45 | |
| hub_cap | dmakogon_ there is outstanding comments on https://review.openstack.org/#/c/48305/5/trove/taskmanager/models.py | 18:45 |
| dmakogon_ | what do you mean about #3 ? | 18:45 |
| hub_cap | are you going to fix? | 18:45 |
| dmakogon_ | i think a suppose | 18:46 |
| dmakogon_ | yes | 18:46 |
| yogesh | dmakogon: we may have to think more on what gets picked from conf... | 18:46 |
| yogesh | will share more.. | 18:47 |
| dmakogon_ | we need only template dir | 18:47 |
| SnowDust | i guess the config = template directory | 18:47 |
| dmakogon_ | nothing else | 18:47 |
| dmakogon_ | SnowDust + | 18:47 |
| SnowDust | yeah .. thats it ! | 18:47 |
| yogesh | defining in conf, what is going to be the template directiry | 18:47 |
| dmakogon_ | yogesh: what do you mean ? | 18:48 |
| yogesh | what if template needs to be laoded from an external package.. | 18:48 |
| dmakogon_ | really template dir is enough | 18:48 |
| SnowDust | /etc/trove/heat_templates/ should be the base dir | 18:48 |
| dmakogon_ | that mean default = /etc/trove/heat_templates/ | 18:49 |
| SnowDust | /etc/trove/ already takes trove.conf / trove-taskmanager.conf .. | 18:49 |
| hub_cap | SnowDust: not entirely true | 18:49 |
| SnowDust | then .. we will append service type to it | 18:49 |
| dmakogon_ | taskmanager conf should store teml.dir | 18:49 |
| hub_cap | if u want it to work with the app, u need it to be pybasedir/etc/trove/templates | 18:49 |
| yogesh | it will be driven teh same way as service_registry | 18:49 |
| dmakogon_ | yogesh why ? | 18:50 |
| yogesh | just a sec | 18:50 |
| yogesh | for an external service, the templates will not be in trove, right? | 18:51 |
| dmakogon_ | we have dir, than we os.exists(CONF.template_dir + '%(service_type).heat.template' % {'service_type': self.service_type}) | 18:51 |
| dmakogon_ | yogesh: we have base dir | 18:52 |
| dmakogon_ | yogesh: templates should be there | 18:52 |
| yogesh | even for a service which is external? | 18:52 |
| dmakogon_ | and what do you mean 'external service' ? | 18:52 |
| yogesh | they should be loaded from an external source, right? | 18:52 |
| * isviridov went to away | 18:52 | |
| SnowDust | inside the basedir ... we are creating a subfolder for each service type | 18:52 |
| SnowDust | no ..distinction of service ttype .. internal / external | 18:53 |
| hub_cap | yogesh: u can define where the templates live | 18:53 |
| yogesh | yup | 18:53 |
| yogesh | that was the point | 18:53 |
| yogesh | so, tehre could be some conf settings like this , per point 3 | 18:53 |
| dmakogon_ | we should keep templates in one dir, without anyh subfolders | 18:53 |
| yogesh | why? | 18:53 |
| dmakogon_ | why should we ? | 18:54 |
| SnowDust | dmakogon .. why will u do this ? | 18:54 |
| dmakogon_ | why do we need to make comlicated tree | 18:54 |
| yogesh | well...how would the templates be placed in the base dir for an external service, manually? | 18:54 |
| yogesh | coz they won't be a part of repo...the service being external | 18:55 |
| *** tanisdl has quit IRC | 18:55 | |
| SnowDust | anyone can untar their folders .. with their template package .. if we give a service type directory ... | 18:55 |
| dmakogon_ | yogesh: https://github.com/openstack/heat-templates/tree/master/cfn/F17 | 18:55 |
| dmakogon_ | i would like to store them like that | 18:55 |
| yogesh | these are heat samples... | 18:55 |
| yogesh | we are talking about template implementations in trov.. | 18:56 |
| SnowDust | yeah .. dmakogon .. thats also a tree :) | 18:56 |
| dmakogon_ | i'm showing you order | 18:56 |
| yogesh | for the defined service types | 18:56 |
| dmakogon_ | simle order | 18:56 |
| *** dmakogon__ has joined #openstack-trove | 18:57 | |
| dmakogon__ | lol | 18:57 |
| dmakogon__ | reconnect | 18:57 |
| SnowDust | dmakogon__ is long tail now ! | 18:57 |
| dmakogon__ | yep | 18:57 |
| yogesh | its from a device with an antenna | 18:57 |
| yogesh | ;-) | 18:57 |
| SnowDust | in celebration ..to animal care day .. | 18:57 |
| SnowDust | feelings for a pet cat .. :D | 18:57 |
| dmakogon__ | so, i'm insisting at storing templates in one di | 18:58 |
| dmakogon__ | r | 18:58 |
| dmakogon__ | one repo | 18:58 |
| yogesh | dmakogon__: which repo? | 18:58 |
| SnowDust | one base dir ! :) | 18:58 |
| dmakogon__ | yes | 18:58 |
| yogesh | would theey be in openstack/heat-templates? | 18:58 |
| yogesh | or within trove? | 18:59 |
| dmakogon__ | trove/etc/trove/heat-templates | 18:59 |
| SnowDust | just keep that base dir + service type + template_file path logic .. | 18:59 |
| SnowDust | from where ever u are bringing it :) | 18:59 |
| yogesh | why should we have templates of a service in trove, which is not a part of the trove... | 18:59 |
| dmakogon__ | if you want external repo please do support of git/svn/ppa/rhel repo | 19:00 |
| yogesh | as yet...i mean | 19:00 |
| *** dmakogon_ has quit IRC | 19:00 | |
| yogesh | when it becomes a part then its templates move into the base dir...and the config path changes accordingly... | 19:00 |
| dmakogon__ | yogesh: have ypu heard about symlinks ? | 19:00 |
| yogesh | yes | 19:00 |
| yogesh | :-) | 19:00 |
| *** jodom has joined #openstack-trove | 19:01 | |
| dmakogon__ | if external dir - make simlink of each template | 19:01 |
| dmakogon__ | only one base dir is acceptable | 19:01 |
| SnowDust | dmakogon__ : just keep that base dir + service type + template_file path logic .. | 19:01 |
| yogesh | you know what, i was even thinking of making the template laoder specific to the service... | 19:01 |
| SnowDust | bring it from anywhere .. :) | 19:02 |
| yogesh | :-) | 19:02 |
| dmakogon__ | yogesh: yes | 19:02 |
| SnowDust | that can be a good option ! | 19:02 |
| yogesh | like our guest agent can be from anywhere and works with trove, completely conf driven now, with your gust.. | 19:02 |
| SnowDust | yogesh: +1 | 19:02 |
| dmakogon__ | here you go, the path to template CONF.template_dir + '%(service_type).heat.template' % {'service_type': self.service_type} | 19:02 |
| dmakogon__ | guestagent works with trove via rpc | 19:03 |
| SnowDust | CONF.template_dir + '%(service_type)' % {'service_type': self.service_type} why not ? | 19:03 |
| dmakogon__ | SnowDust %(name)s | 19:04 |
| SnowDust | ooops ! | 19:04 |
| SnowDust | copy paste .. as they are ! | 19:04 |
| yogesh | example... | 19:04 |
| yogesh | plz | 19:04 |
| dmakogon__ | each template has next name structure: service_type.heat.template | 19:05 |
| dmakogon__ | mysql.heat.template | 19:05 |
| *** jrodom has quit IRC | 19:05 | |
| yogesh | in case of multiple templates, eg. nesting... | 19:05 |
| SnowDust | it wont trouble .. in nesting .. | 19:05 |
| yogesh | namingwise? | 19:06 |
| dmakogon__ | yes | 19:06 |
| dmakogon__ | just time correct path to nested one | 19:06 |
| dmakogon__ | i see no problem in it | 19:06 |
| dmakogon__ | it is really easy to manipulate with only one dir | 19:06 |
| dmakogon__ | as it done with each trove conf | 19:07 |
| yogesh | mysql.heat.template, mysql.constituent1.template, mysql.constituent2.template... | 19:07 |
| dmakogon__ | wowwowow | 19:07 |
| dmakogon__ | no | 19:07 |
| yogesh | :-) | 19:07 |
| dmakogon__ | 1 template per service type | 19:07 |
| dmakogon__ | in single instance | 19:07 |
| dmakogon__ | i thought you got it | 19:08 |
| openstackgerrit | A change was merged to openstack/trove: Correct the fake implementation of UsageVerifier https://review.openstack.org/49546 | 19:08 |
| yogesh | snowdust: can two templates be defined in a single yaml file? | 19:08 |
| SnowDust | nope .. | 19:08 |
| yogesh | anyways, i think it is leading to somewhere nowhere... :-) | 19:08 |
| SnowDust | two templates can work .. together :) | 19:08 |
| openstackgerrit | A change was merged to openstack/trove: Adding location attribute to Fake Backup object. https://review.openstack.org/49601 | 19:08 |
| yogesh | so, we for nesting, we will need to have more than one template.. | 19:09 |
| dmakogon__ | why can't you write template without nesting ? | 19:10 |
| SnowDust | we can define .. base.yaml( as convention) as entry point .. and other templates to be called from it | 19:10 |
| dmakogon__ | so, we are ok with it ? | 19:10 |
| yogesh | this is imposing restrictions on the template crestor.. | 19:10 |
| dmakogon__ | SnowDust: to comlicated | 19:10 |
| SnowDust | this is making decipline .. :) | 19:10 |
| yogesh | enforcing discipline... :-) no never... | 19:11 |
| SnowDust | discipline* | 19:11 |
| SnowDust | ok .. ! | 19:11 |
| yogesh | basically, what doesn't fit well for me is, having templates in trove for the services which don't exist in trove by default.. | 19:12 |
| SnowDust | who wants that ? | 19:12 |
| openstackgerrit | A change was merged to openstack/python-troveclient: Remove trove as default value for Service Name https://review.openstack.org/47653 | 19:13 |
| yogesh | it thoguht that was the point of debate.. | 19:13 |
| SnowDust | basedir + service_type + template_file (base.yaml) | 19:13 |
| yogesh | which leads to a template /etc/<service_not_in_trove>template_file | 19:14 |
| hub_cap | yogesh: time out | 19:14 |
| yogesh | ok | 19:14 |
| hub_cap | if you change the directory in the config | 19:14 |
| hub_cap | u can put them anywhere | 19:14 |
| hub_cap | and u can add services that dont exist in trove | 19:14 |
| yogesh | cool... | 19:14 |
| yogesh | yup | 19:14 |
| hub_cap | done and done | 19:14 |
| SnowDust | yep .. basedir is also configurable :) | 19:15 |
| yogesh | all configurable.. | 19:15 |
| yogesh | awesome.. | 19:15 |
| yogesh | we are good | 19:15 |
| hub_cap | yup SnowDust i think just the config_dir in general should be configurable | 19:15 |
| dmakogon__ | how much paramters do we suppose to have in conf file ? | 19:15 |
| hub_cap | and the default will be _in_ the application | 19:15 |
| yogesh | you mean, heat_teplate_parameters or generally... | 19:16 |
| dmakogon__ | heat templates | 19:16 |
| *** paul_lodronio has quit IRC | 19:16 | |
| SnowDust | summerize ? | 19:16 |
| SnowDust | sleepy ... | 19:17 |
| dmakogon__ | yogesh: how much parameters are you going to bring ? | 19:17 |
| yogesh | very minimal.. | 19:17 |
| dmakogon__ | how much ? | 19:17 |
| yogesh | the directory settings in conf | 19:17 |
| yogesh | and the number of nodes... | 19:18 |
| dmakogon__ | ? | 19:18 |
| yogesh | thats pretty much it... | 19:18 |
| dmakogon__ | number of nodes ? | 19:18 |
| *** paul_lodronio has joined #openstack-trove | 19:18 | |
| hub_cap | !!!im free for reviewing code!!! | 19:18 |
| openstack | hub_cap: Error: "!!im" is not a valid command. | 19:18 |
| hub_cap | anyone need anythign reviewed | 19:18 |
| hub_cap | I HATE U openstack | 19:18 |
| hub_cap | ^ ^ the bot, not the foundation LOL | 19:18 |
| yogesh | well....that can also be skipped i guess... | 19:19 |
| yogesh | can be configured within template... | 19:19 |
| SnowDust | hub_cap ..expect a checkin around pluggable extention | 19:19 |
| yogesh | directory setting only.. | 19:19 |
| yogesh | snowdust: can u share the bp around it.. | 19:20 |
| dmakogon__ | yogesh: what do you mean under number of nodes ?? | 19:20 |
| yogesh | i was thinking if the template contains more than one nodes...then can it brought from conf.. | 19:20 |
| yogesh | but thats a template property, depends ont he person who is defining a template.. | 19:21 |
| hub_cap | SnowDust: sweet | 19:21 |
| yogesh | so only one setting for the directoty | 19:21 |
| yogesh | thats it | 19:21 |
| dmakogon__ | finally | 19:21 |
| dmakogon__ | yogesh: <3 | 19:21 |
| dmakogon__ | <3 <3 <3 | 19:21 |
| yogesh | me too... :-) | 19:21 |
| yogesh | so first level done... | 19:22 |
| yogesh | i am onto it | 19:22 |
| SnowDust | hehe | 19:22 |
| dmakogon__ | waiting for review | 19:22 |
| yogesh | cool | 19:23 |
| yogesh | thanks much guys... | 19:23 |
| dmakogon__ | thanks to you 2 | 19:24 |
| openstackgerrit | Dmitriy Ukhlov proposed a change to openstack/trove: Task manager refactoring done https://review.openstack.org/45238 | 19:24 |
| dmakogon__ | good conversation | 19:24 |
| yogesh | yup...relaxing conversation...lol | 19:24 |
| dmakogon__ | to relaxed, my friend | 19:25 |
| yogesh | checkin out... | 19:25 |
| yogesh | thanks much guys... | 19:25 |
| yogesh | appreciate the patience... :-) | 19:26 |
| dmakogon__ | we are all interested in making trove better | 19:29 |
| SnowDust | its good .. btw ! | 19:30 |
| dmakogon__ | btw, who wants review with tone of lines ? | 19:30 |
| SnowDust | many things are snap ! | 19:30 |
| dmakogon__ | SnowDust: what about fixing PEP8 rule with alphabetic import ? | 19:30 |
| dmakogon__ | it is about 300-400 lines of code | 19:31 |
| SnowDust | didnt understand .. | 19:34 |
| SnowDust | i will autopep :D ! | 19:34 |
| openstackgerrit | A change was merged to openstack/trove-integration: Importing poll_until method from correct place https://review.openstack.org/48008 | 19:35 |
| openstackgerrit | A change was merged to openstack/trove: Remove Duplicate trove_auth_url Property https://review.openstack.org/49609 | 19:40 |
| *** SnowDust has quit IRC | 19:54 | |
| *** VinodGupta has quit IRC | 20:02 | |
| *** jodom has quit IRC | 20:05 | |
| *** jrodom has joined #openstack-trove | 20:05 | |
| *** shivamshukla_ has quit IRC | 20:06 | |
| *** arborism has joined #openstack-trove | 20:21 | |
| *** jodom has joined #openstack-trove | 20:23 | |
| *** jrodom has quit IRC | 20:25 | |
| *** tvb has quit IRC | 20:29 | |
| *** jodom has quit IRC | 20:30 | |
| *** tanisdl has joined #openstack-trove | 20:33 | |
| *** yidclare has quit IRC | 20:34 | |
| *** paul_lodronio has left #openstack-trove | 20:38 | |
| *** vipul is now known as vipul-away | 20:51 | |
| *** vipul-away is now known as vipul | 20:52 | |
| *** esp_ has joined #openstack-trove | 20:57 | |
| *** esp_ has quit IRC | 20:59 | |
| *** tvb has joined #openstack-trove | 21:01 | |
| *** yidclare has joined #openstack-trove | 21:03 | |
| *** krow has joined #openstack-trove | 21:06 | |
| *** tanisdl has quit IRC | 21:07 | |
| *** tanisdl has joined #openstack-trove | 21:08 | |
| *** tanisdl has quit IRC | 21:10 | |
| *** tanisdl has joined #openstack-trove | 21:11 | |
| *** krow has quit IRC | 21:11 | |
| *** pdmars has quit IRC | 21:13 | |
| *** rnirmal has quit IRC | 21:16 | |
| openstackgerrit | A change was merged to openstack/trove: Fix the fake nova server implementation https://review.openstack.org/49759 | 21:29 |
| *** dmakogon__ has quit IRC | 21:29 | |
| *** djohnstone has quit IRC | 21:32 | |
| *** ashestakov_ has quit IRC | 21:41 | |
| *** krow has joined #openstack-trove | 21:41 | |
| *** Barker has quit IRC | 21:43 | |
| *** yogesh has quit IRC | 21:43 | |
| *** yogesh has joined #openstack-trove | 21:44 | |
| *** jcru has quit IRC | 21:46 | |
| *** isviridov has quit IRC | 21:46 | |
| *** yogesh has quit IRC | 21:48 | |
| openstackgerrit | Steve Leon proposed a change to openstack/trove: Fix quota issue where usages can drop to negative value https://review.openstack.org/49301 | 21:54 |
| *** krow has quit IRC | 21:54 | |
| *** metral has quit IRC | 21:58 | |
| *** robertmyers has quit IRC | 22:02 | |
| openstackgerrit | Steve Leon proposed a change to openstack/trove: Fix quota issue where usages can drop to negative value https://review.openstack.org/49301 | 22:04 |
| *** krow has joined #openstack-trove | 22:25 | |
| *** krow has quit IRC | 22:34 | |
| *** jmontemayor has quit IRC | 23:07 | |
| *** krow has joined #openstack-trove | 23:12 | |
| openstackgerrit | Dmitriy Ukhlov proposed a change to openstack/trove: Task manager refactoring done https://review.openstack.org/45238 | 23:18 |
| *** tanisdl has quit IRC | 23:20 | |
| *** datsun180b has quit IRC | 23:22 | |
| *** dukhlov_ has joined #openstack-trove | 23:26 | |
| *** dukhlov_ has quit IRC | 23:28 | |
| *** krow has quit IRC | 23:32 | |
| *** krow has joined #openstack-trove | 23:43 | |
| openstackgerrit | Justin Hopper proposed a change to openstack/trove: Allow service_id per service_type for Usage Events https://review.openstack.org/45309 | 23:46 |
| *** adrian_otto has quit IRC | 23:47 | |
| openstackgerrit | A change was merged to openstack/trove: Allow early host % on validate https://review.openstack.org/47543 | 23:51 |
| juice | hub_cap: vipul: this was approved and needed to be rebased and merged. https://review.openstack.org/#/c/45309/7 Please reapprove | 23:54 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!