| zul | bcwaldon: so this would be like a global flag to enable file injection if i reading it correct? | 00:01 |
|---|---|---|
| *** hhoover has quit IRC | 00:06 | |
| *** dolphm has quit IRC | 00:07 | |
| bcwaldon | zul: isn't that what you are going for? | 00:07 |
| zul | bcwaldon: yeah i was more concerned at the hypervisor level though | 00:08 |
| bcwaldon | zul: ok, well I was more asking for the flag name to be made more specific | 00:08 |
| zul | bcwaldon: that i can do :) | 00:09 |
| bcwaldon | zul: and the code you changed is used by all hypervisors isn't it? | 00:10 |
| zul | bcwaldon: no just libvirt | 00:10 |
| *** bsza has quit IRC | 00:12 | |
| openstackgerrit | Verification of a change to openstack/keystone failed: Add HEAD /tokens/{token_id} (bug 933587) https://review.openstack.org/4371 | 00:13 |
| uvirtbot` | Launchpad bug 933587 in keystone "HEAD /v2.0/tokens/{token_id} returns 404" [Medium,In progress] https://launchpad.net/bugs/933587 | 00:13 |
| bcwaldon | zul: nova.virt.xenapi.vm_utils calls inject_data_into_fs | 00:15 |
| *** utlemming has quit IRC | 00:15 | |
| zul | bcwaldon: ok thanks ill take another look | 00:20 |
| *** jdg has quit IRC | 00:22 | |
| *** bodepd_ has quit IRC | 00:22 | |
| *** ohnoimdead has quit IRC | 00:22 | |
| *** nikhil__ has quit IRC | 00:22 | |
| *** mikal has quit IRC | 00:22 | |
| *** clayg_ has quit IRC | 00:22 | |
| *** comstud has quit IRC | 00:22 | |
| *** utlemming has joined #openstack-dev | 00:23 | |
| *** dwalleck_nova has quit IRC | 00:23 | |
| *** paulormg has quit IRC | 00:23 | |
| *** Remco_ has quit IRC | 00:23 | |
| *** deshantm_ is now known as deshantm | 00:24 | |
| *** hhoover has joined #openstack-dev | 00:24 | |
| *** Remco_ has joined #openstack-dev | 00:24 | |
| *** sleepsonthefloo has quit IRC | 00:24 | |
| *** bodepd_ has joined #openstack-dev | 00:28 | |
| *** ohnoimdead has joined #openstack-dev | 00:28 | |
| *** nikhil__ has joined #openstack-dev | 00:28 | |
| *** mikal has joined #openstack-dev | 00:28 | |
| *** 13WAAGXMU has joined #openstack-dev | 00:28 | |
| *** comstud has joined #openstack-dev | 00:28 | |
| *** mikal has quit IRC | 00:28 | |
| *** Remco_ has quit IRC | 00:28 | |
| *** mikal has joined #openstack-dev | 00:31 | |
| *** deshantm has quit IRC | 00:31 | |
| *** mikal has quit IRC | 00:31 | |
| *** jakedahn has joined #openstack-dev | 00:33 | |
| *** mikal has joined #openstack-dev | 00:33 | |
| *** deshantm has joined #openstack-dev | 00:34 | |
| *** sdake has quit IRC | 00:39 | |
| *** shevek__ has joined #openstack-dev | 00:40 | |
| *** hhoover has quit IRC | 00:40 | |
| *** andrewbogott is now known as andrewbogott_afk | 00:42 | |
| *** crobinso has quit IRC | 00:42 | |
| *** ohnoimdead has quit IRC | 00:44 | |
| *** jog0 has quit IRC | 00:47 | |
| *** jakedahn has quit IRC | 00:48 | |
| *** shevek__ has quit IRC | 00:51 | |
| *** dtroyer has joined #openstack-dev | 01:01 | |
| *** torgomatic has quit IRC | 01:01 | |
| *** dolphm has joined #openstack-dev | 01:06 | |
| *** ohnoimdead has joined #openstack-dev | 01:15 | |
| *** dolphm has quit IRC | 01:16 | |
| *** tomoe_ has joined #openstack-dev | 01:24 | |
| dayou | vishy:ping | 01:36 |
| mikal | bcwaldon: if you're still around, could you take a look at https://review.openstack.org/#change,4432 please? | 01:37 |
| *** ootz0rz_ has joined #openstack-dev | 01:44 | |
| *** dolphm has joined #openstack-dev | 01:44 | |
| *** ootz0rz has quit IRC | 01:48 | |
| *** akscram has joined #openstack-dev | 01:51 | |
| *** hugokuo has joined #openstack-dev | 01:54 | |
| *** bepernoot has quit IRC | 01:54 | |
| *** vricci has joined #openstack-dev | 02:02 | |
| *** andrewsmedina_ has joined #openstack-dev | 02:02 | |
| *** gyee has quit IRC | 02:04 | |
| *** andrewsmedina has quit IRC | 02:04 | |
| *** andrewsmedina_ is now known as andrewsmedina | 02:04 | |
| *** rods has quit IRC | 02:08 | |
| *** vricci has left #openstack-dev | 02:08 | |
| openstackgerrit | Verification of a change to openstack/horizon failed: Help texts and dynamic label change for entering security group rules. ICMP rules have different meanings for the from_port and to_port fields. https://review.openstack.org/4346 | 02:16 |
| *** ncode has quit IRC | 02:16 | |
| *** andrewsmedina has quit IRC | 02:21 | |
| *** Ryan_Lane has quit IRC | 02:23 | |
| *** ncode has joined #openstack-dev | 02:25 | |
| *** ncode has joined #openstack-dev | 02:25 | |
| openstackgerrit | Verification of a change to openstack-dev/devstack failed: Add exercise that boots an instance from a volume. https://review.openstack.org/4044 | 02:27 |
| openstackgerrit | Verification of a change to openstack/python-keystoneclient failed: Help output tweaks, Vol I https://review.openstack.org/4336 | 02:29 |
| *** jeremyb_ has quit IRC | 02:29 | |
| *** jeremyb_ has joined #openstack-dev | 02:29 | |
| *** jeremyb_ is now known as jeremyb | 02:30 | |
| *** ncode has quit IRC | 02:31 | |
| openstackgerrit | Verification of a change to openstack/keystone failed: Removing broken & redundant code (bug 933555) https://review.openstack.org/4406 | 02:32 |
| uvirtbot` | Launchpad bug 933555 in keystone "GET /tokens/{token_id}/endpoints response does not match spec" [Medium,In progress] https://launchpad.net/bugs/933555 | 02:32 |
| *** jakedahn has joined #openstack-dev | 02:32 | |
| *** jakedahn has joined #openstack-dev | 02:32 | |
| *** ncode has joined #openstack-dev | 02:32 | |
| *** ncode has joined #openstack-dev | 02:32 | |
| *** sandywalsh has quit IRC | 02:32 | |
| *** sandywalsh has joined #openstack-dev | 02:47 | |
| *** anotherjesse has quit IRC | 02:56 | |
| *** jakedahn has quit IRC | 02:56 | |
| *** bengrue has quit IRC | 03:00 | |
| *** andrewsben has quit IRC | 03:02 | |
| *** dolphm has quit IRC | 03:02 | |
| *** novas0x2a|laptop has quit IRC | 03:06 | |
| *** jdurgin has quit IRC | 03:07 | |
| *** shevek__ has joined #openstack-dev | 03:07 | |
| *** danwent has quit IRC | 03:12 | |
| *** dolphm has joined #openstack-dev | 03:14 | |
| *** cp16net has joined #openstack-dev | 03:18 | |
| *** cp16net has quit IRC | 03:19 | |
| *** cp16net has joined #openstack-dev | 03:19 | |
| *** jdg has joined #openstack-dev | 03:32 | |
| *** hub_cap has joined #openstack-dev | 03:34 | |
| *** cp16net_ has joined #openstack-dev | 03:44 | |
| *** jeremy_ has joined #openstack-dev | 03:46 | |
| *** ohnoimdead has quit IRC | 03:47 | |
| *** cp16net has quit IRC | 03:48 | |
| *** cp16net_ is now known as cp16net | 03:48 | |
| *** jeremy_ has quit IRC | 03:49 | |
| *** jeremy_ has joined #openstack-dev | 03:49 | |
| *** jeremy has quit IRC | 03:49 | |
| *** jeremy_ is now known as jeremy | 03:49 | |
| *** gabrielhurley has quit IRC | 03:51 | |
| *** shevek__ has quit IRC | 03:54 | |
| *** sdake has joined #openstack-dev | 03:55 | |
| *** vincentricci has joined #openstack-dev | 03:59 | |
| *** dtroyer has quit IRC | 04:04 | |
| *** anotherjesse has joined #openstack-dev | 04:07 | |
| *** dtroyer has joined #openstack-dev | 04:10 | |
| *** martine has joined #openstack-dev | 04:15 | |
| *** pixelbeat has quit IRC | 04:28 | |
| *** hub_cap has quit IRC | 04:29 | |
| *** rickfoosusa has quit IRC | 04:31 | |
| *** reed has quit IRC | 04:37 | |
| *** danwent has joined #openstack-dev | 04:44 | |
| *** martine has quit IRC | 04:46 | |
| *** maplebed has quit IRC | 04:47 | |
| *** bepernoot has joined #openstack-dev | 04:48 | |
| *** bepernoot has quit IRC | 04:49 | |
| *** jdg has quit IRC | 04:53 | |
| *** sleepsonthefloo has joined #openstack-dev | 05:03 | |
| *** davlap has quit IRC | 05:06 | |
| *** tryggvil_ has joined #openstack-dev | 05:14 | |
| *** zigo has joined #openstack-dev | 05:14 | |
| *** vincentricci has left #openstack-dev | 05:14 | |
| *** tryggvil has quit IRC | 05:16 | |
| *** tryggvil_ is now known as tryggvil | 05:16 | |
| *** bepernoot has joined #openstack-dev | 05:20 | |
| *** bepernoot has quit IRC | 05:21 | |
| mjfork | danwent: around by chance? | 05:28 |
| danwent | mjfork: hi | 05:28 |
| mjfork | i have a quick question, i cleaned up the patch and added the deafult tenant, however i had an issue in quantum/manager.py and want to know if it is a bug | 05:29 |
| mjfork | manager.py, get_instance_nw_info would NOT work with a default network | 05:30 |
| mjfork | the self.q_conn.get_network_name call about like 486 would fail because net_tenant_id was not set | 05:30 |
| mjfork | i added a check right before that if net_tenant_id is NOne net_tenant_id = FLAGS.quantum_default_tenant_id | 05:30 |
| danwent | hmm… i'm a bit surprised, as that should break a unit test. | 05:31 |
| danwent | but let me check | 05:31 |
| mjfork | thanks. | 05:31 |
| danwent | what line are you talking about? I'm looking at: https://github.com/openstack/nova/blob/master/nova/network/quantum/manager.py | 05:33 |
| mjfork | its fixed | 05:34 |
| mjfork | lines 502/503 | 05:35 |
| mjfork | have not refreshed my devstack in a a week or so | 05:35 |
| mjfork | looks like it got fixed in there | 05:35 |
| danwent | ok, great | 05:35 |
| danwent | we significantly improved test coverage recently and fixed some bugs. that might have been one of them. | 05:36 |
| mjfork | last question , then i can submit updat | 05:36 |
| mjfork | is the right way to get teh default networks from quantum client by setting the teant_id = 'default' and making a 2nd request? | 05:36 |
| mjfork | or can i get them included in a quantum_list_networks call | 05:37 |
| danwent | making a second request is best | 05:37 |
| danwent | technically, if someone changes the --default_tenant_id flag in Nova, the tenant-id may not be "default" | 05:38 |
| mjfork | can i reference FLAGS in Horizon? | 05:38 |
| danwent | so you may want to make that configurable in horizon with a default to "default" | 05:38 |
| danwent | I don't think so | 05:38 |
| mjfork | ahh, ok. that makes sense. | 05:38 |
| danwent | but I don't have a lot of experience with horizon | 05:38 |
| mjfork | thanks. i can figure that out and submit. | 05:39 |
| danwent | (or really, any experience beyond poking at network-related code) | 05:39 |
| mjfork | more than i have :-) | 05:39 |
| danwent | good to start learning though :) | 05:39 |
| mjfork | yes, agreed. have to start someplace. thanks for the help tonight. | 05:40 |
| danwent | yup, later | 05:42 |
| *** ncode has quit IRC | 05:45 | |
| *** mdomsch has quit IRC | 05:48 | |
| *** vincentricci has joined #openstack-dev | 05:50 | |
| *** vincentricci has quit IRC | 05:50 | |
| *** wallus has joined #openstack-dev | 05:50 | |
| *** bepernoot has joined #openstack-dev | 05:54 | |
| *** wallus is now known as dalang | 05:57 | |
| *** dalang has quit IRC | 06:00 | |
| *** dalang has joined #openstack-dev | 06:00 | |
| *** cp16net has quit IRC | 06:09 | |
| *** markmc has joined #openstack-dev | 06:10 | |
| *** journeeman has joined #openstack-dev | 06:15 | |
| *** mjfork has quit IRC | 06:16 | |
| *** dalang has left #openstack-dev | 06:18 | |
| *** littleidea has quit IRC | 06:19 | |
| *** Ryan_Lane has joined #openstack-dev | 06:20 | |
| *** shevek_ has joined #openstack-dev | 06:21 | |
| *** zaitcev has quit IRC | 06:23 | |
| *** bepernoot has quit IRC | 06:23 | |
| *** danwent has quit IRC | 06:27 | |
| *** zigo has quit IRC | 06:31 | |
| *** bepernoot has joined #openstack-dev | 06:35 | |
| *** mnewby has quit IRC | 06:40 | |
| *** mnewby has joined #openstack-dev | 06:44 | |
| *** anotherjesse1 has joined #openstack-dev | 06:46 | |
| *** deshantm has quit IRC | 06:47 | |
| *** dtroyer has quit IRC | 06:50 | |
| *** bepernoot has quit IRC | 06:59 | |
| *** bepernoot has joined #openstack-dev | 07:04 | |
| *** bepernoot has quit IRC | 07:05 | |
| *** vincentricci has joined #openstack-dev | 07:06 | |
| *** vincentricci has quit IRC | 07:06 | |
| *** Remco_ has joined #openstack-dev | 07:07 | |
| *** ghe_ is now known as GheRivero | 07:11 | |
| *** Remco_ has quit IRC | 07:11 | |
| *** Remco_ has joined #openstack-dev | 07:12 | |
| *** Remco_ has quit IRC | 07:16 | |
| *** naehring has joined #openstack-dev | 07:16 | |
| *** anotherjesse1 has quit IRC | 07:38 | |
| *** Remco_ has joined #openstack-dev | 07:38 | |
| *** Remco_ has quit IRC | 07:43 | |
| *** Remco_ has joined #openstack-dev | 07:43 | |
| *** Mkenneth has joined #openstack-dev | 07:46 | |
| *** Remco_ has quit IRC | 07:48 | |
| *** shang_ has quit IRC | 07:51 | |
| *** bepernoot has joined #openstack-dev | 08:10 | |
| *** jeroenhn has joined #openstack-dev | 08:19 | |
| *** zykes has joined #openstack-dev | 08:22 | |
| zykes | anotherjesse: ? | 08:22 |
| zykes | or soren_ ? | 08:22 |
| *** guaqua_ is now known as guaqua | 08:24 | |
| *** hashar has joined #openstack-dev | 08:33 | |
| *** darraghb has joined #openstack-dev | 08:34 | |
| *** tomoe_ has quit IRC | 08:35 | |
| *** Ryan_Lane has quit IRC | 08:36 | |
| *** journeeman has quit IRC | 08:48 | |
| *** journeeman has joined #openstack-dev | 08:58 | |
| *** adjohn has quit IRC | 09:02 | |
| *** adjohn has joined #openstack-dev | 09:02 | |
| *** Mkenneth1 has joined #openstack-dev | 09:04 | |
| *** Mkenneth has quit IRC | 09:05 | |
| *** adjohn has quit IRC | 09:06 | |
| *** derekh has joined #openstack-dev | 09:08 | |
| *** zigo has joined #openstack-dev | 09:11 | |
| *** shang has joined #openstack-dev | 09:16 | |
| *** dneary has joined #openstack-dev | 09:17 | |
| *** dneary has quit IRC | 09:17 | |
| *** dneary has joined #openstack-dev | 09:17 | |
| *** justinsb has quit IRC | 09:18 | |
| *** shang has quit IRC | 09:22 | |
| *** justinsb has joined #openstack-dev | 09:25 | |
| *** hashar has quit IRC | 09:34 | |
| *** shang has joined #openstack-dev | 09:36 | |
| *** zigo has quit IRC | 09:46 | |
| *** shang has quit IRC | 09:49 | |
| *** zigo has joined #openstack-dev | 09:50 | |
| journeeman | Hello Kiall :) | 10:00 |
| journeeman | Kiall: Would it be too difficult to modify devstack's script to work with an http(s) proxy? | 10:01 |
| *** sleepsonthefloo has quit IRC | 10:02 | |
| *** maploin has joined #openstack-dev | 10:04 | |
| *** maploin has quit IRC | 10:04 | |
| *** maploin has joined #openstack-dev | 10:04 | |
| *** apevec has joined #openstack-dev | 10:05 | |
| *** zigo has quit IRC | 10:14 | |
| *** pixelbeat has joined #openstack-dev | 10:16 | |
| *** kyriakos has joined #openstack-dev | 10:21 | |
| chmouel | journeeman: I think devstack have support for proxies already as long you specify the http_proxy variable properly | 10:24 |
| journeeman | chmouel: I specified http_proxy and https_proxy but, am still running into problems | 10:26 |
| chmouel | journeeman: well you probably want to fill a bug for it then | 10:26 |
| journeeman | chmouel: okay | 10:29 |
| *** shang has joined #openstack-dev | 10:33 | |
| chmouel | journeeman: thanks | 10:33 |
| *** markmc has quit IRC | 10:39 | |
| *** markmc has joined #openstack-dev | 10:40 | |
| *** Mkenneth1 has quit IRC | 10:49 | |
| *** paulormg has joined #openstack-dev | 10:53 | |
| journeeman | chmouel: sure | 10:53 |
| *** JStoker_ has joined #openstack-dev | 10:57 | |
| *** soren_ is now known as soren | 11:01 | |
| *** shang has quit IRC | 11:01 | |
| *** soren has quit IRC | 11:01 | |
| *** soren has joined #openstack-dev | 11:01 | |
| *** ChanServ sets mode: +v soren | 11:01 | |
| *** dneary has quit IRC | 11:02 | |
| *** Mkenneth has joined #openstack-dev | 11:02 | |
| *** dayou has quit IRC | 11:09 | |
| *** dayou has joined #openstack-dev | 11:10 | |
| *** shang has joined #openstack-dev | 11:12 | |
| *** dayou has quit IRC | 11:25 | |
| *** zigo has joined #openstack-dev | 11:48 | |
| *** Remco_ has joined #openstack-dev | 11:49 | |
| *** zykes has quit IRC | 11:55 | |
| *** Remco_ has quit IRC | 12:00 | |
| *** Remco_ has joined #openstack-dev | 12:00 | |
| *** hashar has joined #openstack-dev | 12:01 | |
| *** Remco_ has quit IRC | 12:02 | |
| *** dayou has joined #openstack-dev | 12:20 | |
| *** hub_cap has joined #openstack-dev | 12:27 | |
| *** dneary has joined #openstack-dev | 12:33 | |
| *** markvoelker has joined #openstack-dev | 12:33 | |
| *** bsza has joined #openstack-dev | 12:37 | |
| *** andrewsmedina has joined #openstack-dev | 12:37 | |
| *** zigo has quit IRC | 12:41 | |
| *** jeroenhn has quit IRC | 12:43 | |
| *** zigo has joined #openstack-dev | 12:44 | |
| *** jeroenhn has joined #openstack-dev | 12:48 | |
| *** mdomsch has joined #openstack-dev | 12:50 | |
| *** andrewsmedina has quit IRC | 13:02 | |
| *** andrewsmedina has joined #openstack-dev | 13:03 | |
| *** jeroenhn has quit IRC | 13:03 | |
| *** dprince has joined #openstack-dev | 13:06 | |
| ttx | ewindisch: why is zeromq-rpc-driver marked implemented, if https://review.openstack.org/#change,3955 is still in progress ? | 13:06 |
| *** crobinso has joined #openstack-dev | 13:07 | |
| *** mjfork has joined #openstack-dev | 13:07 | |
| *** jeroenhn has joined #openstack-dev | 13:07 | |
| *** journeeman has quit IRC | 13:09 | |
| *** Mkenneth has quit IRC | 13:09 | |
| *** Mkenneth has joined #openstack-dev | 13:10 | |
| *** littleidea has joined #openstack-dev | 13:11 | |
| maploin | What is the plan regarding moving common functionality to a -common module? I see that keystone now requires some top-level nova modules and some swift.common modules. It used to be independent before. | 13:15 |
| *** hashar has quit IRC | 13:15 | |
| markmc | maploin, well, there's openstack-common: http://wiki.openstack.org/CommonLibrary | 13:17 |
| markmc | maploin, but I suspect what you're talking about is keystone's nova and swift middlewares | 13:17 |
| markmc | maploin, i.e. they're part of nova and swift runtimes, the code just lives in keystone | 13:17 |
| maploin | I didn't know about that CommonLibrary, thanks! | 13:18 |
| *** mdomsch has quit IRC | 13:19 | |
| maploin | oh, wow, so then nova requires code from the keystone project to run? | 13:20 |
| markmc | yes, when you have the keystone configured in nova | 13:23 |
| markmc | looks like it just uses a single http connect method from keystone.common | 13:24 |
| *** littleidea has quit IRC | 13:31 | |
| *** littleidea has joined #openstack-dev | 13:31 | |
| *** paulormg has quit IRC | 13:36 | |
| *** rods has joined #openstack-dev | 13:41 | |
| ewindisch | ttx: I suppose I misunderstood the marking of implemented? It is *implemented*, the code is done, but didn't make from code review to being merged. | 13:41 |
| ttx | ewindisch: yeah... implemented actually means "completed". it's from a feature perspective, not code | 13:42 |
| *** stuntmachine has joined #openstack-dev | 13:42 | |
| ttx | ewindisch: will fix | 13:42 |
| ttx | ewindisch: thx for the confirmation :) | 13:42 |
| ewindisch | Put to 'needs code review'… although it won't get into essex anyway | 13:42 |
| ewindisch | or make whatever changes you need - thanks | 13:43 |
| ttx | ack | 13:43 |
| *** zigo has quit IRC | 13:45 | |
| *** stuntmachine has quit IRC | 13:46 | |
| *** rods has quit IRC | 13:50 | |
| *** stuntmachine has joined #openstack-dev | 13:53 | |
| *** mikemowgli has joined #openstack-dev | 13:53 | |
| *** Mkenneth has quit IRC | 14:03 | |
| *** mattray has joined #openstack-dev | 14:07 | |
| *** littleidea has joined #openstack-dev | 14:11 | |
| *** Mkenneth has joined #openstack-dev | 14:15 | |
| *** andrewbogott_afk is now known as andrewbogott | 14:33 | |
| *** kbringard has joined #openstack-dev | 14:33 | |
| *** dolphm has quit IRC | 14:37 | |
| *** dtroyer has joined #openstack-dev | 14:39 | |
| *** Remco_ has joined #openstack-dev | 14:45 | |
| *** wwkeyboard2 has quit IRC | 14:46 | |
| *** mancdaz has quit IRC | 14:46 | |
| *** mancdaz1203 has joined #openstack-dev | 14:47 | |
| *** lts has joined #openstack-dev | 14:48 | |
| *** GheRivero_ has joined #openstack-dev | 14:50 | |
| *** wwkeyboard has joined #openstack-dev | 14:51 | |
| *** martine has joined #openstack-dev | 14:51 | |
| *** dtroyer has quit IRC | 14:53 | |
| *** LarsErikP has joined #openstack-dev | 15:00 | |
| LarsErikP | hi, is this the right place to ask som xen-questions? | 15:01 |
| *** sandywalsh has quit IRC | 15:01 | |
| *** dtroyer has joined #openstack-dev | 15:06 | |
| chmouel | maploin: nova middleware should probably lives in nova instead of keystone | 15:06 |
| chmouel | maploin: as for swift the swift requirement are only for middleware, parse_path is trivial to extract to common module but swift_acl parsing would probably be always swift | 15:07 |
| *** Remco__ has joined #openstack-dev | 15:08 | |
| chmouel | maploin: see #917408 | 15:10 |
| andrewbogott | I am trying to attach a volume to an instance via horizon. As best I can tell, nothing at all is happening. Is this only supported by certain images? | 15:11 |
| *** Remco_ has quit IRC | 15:11 | |
| maploin | chmouel: thanks for the clarification. I think I'm just confused because I was imagining that the different components are designed to be installed independently (sometimes each on its own machine) and do not require eachother to work. | 15:13 |
| chmouel | maploin: they actually don't you don't need nova or swift to install keystone :) | 15:14 |
| *** sandywalsh has joined #openstack-dev | 15:15 | |
| *** TREllis_ is now known as TREllis | 15:16 | |
| maploin | chmouel: how about the other way around? Do you need to have keystone installed to use its authentication from nova/swift? Or how does the middleware work? | 15:19 |
| chmouel | maploin: yeah right so I guess that's why we are extracting middleware to its own components but at the end of the day this should be a packaging problem | 15:20 |
| chmouel | ie: even if it's stays in keystone | 15:20 |
| maploin | yes, it's the packaging problem that I'm concerned with :) | 15:21 |
| *** dolphm has joined #openstack-dev | 15:21 | |
| chmouel | well as far goes swift_auth packagers could just create a keystone-middleware-swift out of the keystone tree and that would be installable on the proxies | 15:22 |
| chmouel | but since swift_auth need autoken which use bufferedhttp from keystone.common this kind of stuff can probably go to something like os-common as mentionned by markmc | 15:23 |
| chmouel | s/autoken/auth_token/ | 15:23 |
| *** PotHix has joined #openstack-dev | 15:26 | |
| *** zigo has joined #openstack-dev | 15:29 | |
| maploin | so is any distro already packaging the middleware separately? is the code stable enough at this point to even try this? | 15:34 |
| chmouel | well that's a question for the distros but if the distros packaging it there would be more testing and it will be more stable :) | 15:41 |
| *** zzed has joined #openstack-dev | 15:45 | |
| *** cdub has quit IRC | 15:54 | |
| *** hhoover has joined #openstack-dev | 15:57 | |
| *** deshantm has joined #openstack-dev | 16:01 | |
| *** mattray has quit IRC | 16:04 | |
| *** Remco__ has quit IRC | 16:08 | |
| *** Remco_ has joined #openstack-dev | 16:09 | |
| *** Remco_ has quit IRC | 16:11 | |
| *** cp16net has joined #openstack-dev | 16:13 | |
| *** danwent has joined #openstack-dev | 16:14 | |
| andrewbogott | dragondm (or anyone): Would you expect me to be able to attach a nova volume to an instance in devstack? | 16:14 |
| dragondm | Hmmm.. .not sure. I don't use devstack much so I am hazy on the config it sets up... | 16:15 |
| *** zzed has quit IRC | 16:16 | |
| andrewbogott | I have a CirrOS image. mainly wondering if that distro is crippled enough that I shouldn't expect to be able to inject volumes | 16:16 |
| *** zzed has joined #openstack-dev | 16:16 | |
| *** aweiss has joined #openstack-dev | 16:23 | |
| *** mattray has joined #openstack-dev | 16:23 | |
| aweiss | hey guys, was wondering why you have to use the ID values instead of the names when when using the "add-user-role" argument? reason that it was developed this way? | 16:24 |
| *** littleidea has quit IRC | 16:27 | |
| *** jeroenhn has quit IRC | 16:28 | |
| andrewbogott | Are there any shared-volume solutions available in openstack? For example, I'd like /home to be shared across all instances in a project. | 16:40 |
| *** maploin has quit IRC | 16:42 | |
| YorikSar | andrewbogott: May be, you don't want a block storage to be shared, but some filesystem? | 16:42 |
| andrewbogott | YorikSar: Yes, a filesystem. | 16:42 |
| andrewbogott | I have only just now noticed that a nova volume can only be attached to one instance at a time. | 16:43 |
| andrewbogott | Um... it may be that I don't quite understand your question. | 16:44 |
| *** vincentricci has joined #openstack-dev | 16:44 | |
| YorikSar | andrewbogott: No, you're good. I was talking about that there is no clear way to attach block storage in several places without some adjustments at filesystem level which means some intrudion into guest os. | 16:45 |
| andrewbogott | Ok, sure. It wouldn't upset me if I have to e.g. explicitly mount the file system in each instance. | 16:46 |
| *** dubsquared has joined #openstack-dev | 16:46 | |
| YorikSar | andrewbogott: Not just mount, but handle it as a clustered fs | 16:47 |
| andrewbogott | But is there any support for something like this at all in nova? I'm expecting to create it myself from scratch, but want to make sure I'm not reinventing the wheel. | 16:47 |
| andrewbogott | So that sounds like 'from scratch' then :) | 16:47 |
| YorikSar | andrewbogott: There is nothing that can work out-of-box, but it should be not too hard to implement something cute | 16:47 |
| YorikSar | andrewbogott: In fact, it can be another aaS | 16:48 |
| andrewbogott | I was imagining that I would extent nova-volume to do this. Does that seem silly? Should it just be an unrelated standalone extension? | 16:49 |
| YorikSar | andrewbogott: You'll have to do some hacking inside a VM anyway. | 16:49 |
| YorikSar | andrewbogott: No, nova-volume provides you with block storage. What you want is some networked filesystem. | 16:50 |
| andrewbogott | ok... I need to do some homework in order to understand what that means :/ | 16:51 |
| YorikSar | andrewbogott: You can either run a VM with some NFS-like server with a volume mounted, and share filesystem over NFS | 16:51 |
| YorikSar | andrewbogott: Or you can automate a process with attaching a volume to each new VM and create some cool FS over it (like lustre) | 16:52 |
| andrewbogott | gluster is what we're planning to use. | 16:54 |
| andrewbogott | I need to read more nova-volume code to understand how it does the attaching, I think. | 16:55 |
| kbringard | it more or less carves a lun out of an LVM and iscsi exports it | 16:55 |
| YorikSar | andrewbogott: You can imagine it like another block device mysteriously appearing in your VM, I don't think you can do anything more on this level. | 16:56 |
| andrewbogott | Ah, I see. So I'll need to use a totally different approach. | 16:57 |
| kbringard | depending on the network mode you're using, you can probably export gluster mounts to specific VLANs and have your VMs mount them via user-data or something | 16:58 |
| *** maplebed has joined #openstack-dev | 17:01 | |
| *** deshantm_ has joined #openstack-dev | 17:03 | |
| *** mdomsch has joined #openstack-dev | 17:04 | |
| *** jdg has joined #openstack-dev | 17:05 | |
| *** hashar has joined #openstack-dev | 17:06 | |
| *** deshantm has quit IRC | 17:07 | |
| *** sleepsonthefloo has joined #openstack-dev | 17:12 | |
| *** mikemowgli has quit IRC | 17:12 | |
| *** deshantm_ is now known as deshantm | 17:13 | |
| *** adjohn has joined #openstack-dev | 17:19 | |
| *** hhoover has quit IRC | 17:22 | |
| *** zigo has quit IRC | 17:22 | |
| *** anotherjesse1 has joined #openstack-dev | 17:23 | |
| *** zigo has joined #openstack-dev | 17:25 | |
| *** cdub has joined #openstack-dev | 17:26 | |
| sleepsonthefloo | jeblair, dtroyer, anotherjesse: looks like we will need to pin python-novaclient to stable/diablo in devstack/stable/diablo. Right now it is riding master. | 17:28 |
| *** darraghb has quit IRC | 17:28 | |
| sleepsonthefloo | Hmm, maybe it is just as easy to be more defensive in python-novaclient: https://jenkins.openstack.org/job/gate-integration-tests-devstack-vm/1764/console | 17:29 |
| sleepsonthefloo | Do we want trunk python-novaclient to always work with previous versions still? | 17:30 |
| *** ohnoimdead has joined #openstack-dev | 17:31 | |
| *** ohnoimdead has quit IRC | 17:31 | |
| dtroyer | I would think so, at least for trunk - 1? | 17:32 |
| *** paulormg has joined #openstack-dev | 17:33 | |
| *** reed has joined #openstack-dev | 17:33 | |
| sleepsonthefloo | dtroyer - that could make sense, although we are not currently distinguishing between 1.1 and 2.0 features in novaclient. bcwaldon: also curious about your thoughts on the above | 17:34 |
| *** Mkenneth has quit IRC | 17:36 | |
| *** ohnoimdead has joined #openstack-dev | 17:37 | |
| *** dalang has joined #openstack-dev | 17:39 | |
| *** bepernoot has quit IRC | 17:39 | |
| *** dneary has quit IRC | 17:40 | |
| jeblair | sleepsonthefloo, dtroyer: yes, I think the current thinking is that we try to keep novaclient working with previous versions. because of that, it doesn't actually have a stable/diablo branch. | 17:41 |
| *** jdurgin has joined #openstack-dev | 17:41 | |
| * mtaylor agrees with jeblair | 17:46 | |
| mtaylor | strongly | 17:46 |
| mtaylor | sleepsonthefloo: I think that consumers of novaclient are not going to care (or possibly even know) what version of openstack their cloud provider is running | 17:47 |
| *** derekh has quit IRC | 17:47 | |
| mtaylor | they want to write code to connect to openstack - so I think that python-novaclient should always know how to speak 1.0, 1.1, 2.0 etc | 17:47 |
| davidkranz | novaclient currently does not work with commands such as 'pause' | 17:47 |
| davidkranz | on diablo | 17:47 |
| mtaylor | I'm not saying that all essex features should be magically backported through novaclient to work on diablo clouds | 17:48 |
| sleepsonthefloo | jeblair: mtaylor: I can see that. But atm I don't believe there is discipline or a pattern for maintaining different api versions | 17:48 |
| mtaylor | sleepsonthefloo: there was 1.0 support in novaclient recently that was deleted | 17:49 |
| *** markmc has quit IRC | 17:49 | |
| mtaylor | sleepsonthefloo: I don't think novaclient needs to care about diablo v. essex - it just needs to grok 1.0 vs. 1.1 | 17:49 |
| jaypipes | eglynn: wanna chat about the queued image not modifying metadata? | 17:50 |
| sleepsonthefloo | mtaylor - what about 2.0? | 17:50 |
| mtaylor | sleepsonthefloo: same thing | 17:51 |
| mtaylor | sleepsonthefloo: essentially I just think that it's got to support the extant API versions ... if you tell it to use 1.0, obviously 2.0 features won't work | 17:52 |
| bcwaldon | sleepsonthefloo: we ended up dropping v1.0 support (which may have been a bad idea) due to the fact that *nova* never supported it, so why leave it in *nova*client | 17:52 |
| mtaylor | bcwaldon: which is a good point | 17:52 |
| bcwaldon | I'm going to fight to keep v2 support for as long as we can | 17:52 |
| mtaylor | bcwaldon: although I'm sad about that, because that means I can't write the same script in novaclient that will work to spin up nodes on rax cloud and hp cloud - but that might just be a historical abberation | 17:52 |
| bcwaldon | so we have a scoping problem | 17:53 |
| bcwaldon | this is novaclient | 17:53 |
| bcwaldon | what you want are generic openstack comput ebindings | 17:53 |
| bcwaldon | and I dont think anybody has had that discussion as to where we draw these lines | 17:53 |
| jeblair | or for rax to switch to openstack. :) | 17:53 |
| *** hhoover has joined #openstack-dev | 17:53 | |
| bcwaldon | which we all know is happening | 17:53 |
| *** shang_ has joined #openstack-dev | 17:54 | |
| jeblair | yeah, so i think i can live with the historic aberration this time as openstack is "bootstrapped" | 17:54 |
| *** shang_ has quit IRC | 17:54 | |
| bcwaldon | that's how I've justified it in my mind up until now | 17:54 |
| jeblair | but diablo definitely is openstack so novaclient should support it | 17:55 |
| jeblair | (as long as possible) | 17:56 |
| *** shang has quit IRC | 17:56 | |
| mtaylor | ++ | 17:56 |
| bcwaldon | so here's the other problem | 17:56 |
| bcwaldon | are we writing novaclient to specs or implementations | 17:56 |
| bcwaldon | ideally we would write to the compute v2 spec with support for arbitrary extensions | 17:57 |
| bcwaldon | but I'm not sure we can support diablo and still do that | 17:57 |
| sleepsonthefloo | (back soon - have to duck to a mtg) | 17:57 |
| mtaylor | hrm. | 17:57 |
| mtaylor | so - two things I guess | 17:57 |
| mtaylor | one is that I think at the end of the day we should recognize that end users of the cloud want to be able to download a library and have that be able to talk to openstack no matter what version | 17:58 |
| mtaylor | two is that current api versions may not allow that in a sensible manner | 17:58 |
| mtaylor | yeah? | 17:58 |
| bcwaldon | I can agree with that | 17:59 |
| *** andrewsben has joined #openstack-dev | 17:59 | |
| bcwaldon | but I don't want users to have to know what release of openstack they're talking to | 17:59 |
| mtaylor | I agree with that | 17:59 |
| mtaylor | it just turns out that for diablo they might have to | 17:59 |
| bcwaldon | which really might not be a problem | 17:59 |
| eglynn | jaypipes: hey, yeah the queued image case ... | 17:59 |
| mtaylor | and we should fix it in the future so that they don't | 17:59 |
| bcwaldon | yes, since novaclient expected certain undocumented extensions | 18:00 |
| bcwaldon | and now we've fixed that in essex | 18:00 |
| mtaylor | two can kind-of be solved by putting the diablo codebase behind a different constructor so that a user can install one library and still get access to diablo | 18:00 |
| *** heckj has joined #openstack-dev | 18:00 | |
| heckj | dolpm: ping | 18:00 |
| bcwaldon | I'm trying to think if the code *needs* to be different to talk to essex vs folsom | 18:00 |
| heckj | doplhm: ping (when I can spell correctly) | 18:01 |
| bcwaldon | and as long as we write to the api spec and don't remove extensions, we should be fine | 18:01 |
| mtaylor | bcwaldon: I think that sounds sensible | 18:01 |
| bcwaldon | mtaylor: so I think moving forward we need to push for one thing: | 18:01 |
| mtaylor | bcwaldon: do you think merging in stable/diablo behind a constructor switch would work for diablo, and we just recognize that it's not a workable plan for moving forward? | 18:02 |
| bcwaldon | disable extensions in the command line interface if they aren't loaded at the specified endpoint | 18:02 |
| mtaylor | bcwaldon: ++ | 18:02 |
| clayg | sleepsonthefloo: bcwaldon: vishy: volumes meeting in #openstack-meeting, if you're interested... | 18:02 |
| bcwaldon | clayg: yes, omw | 18:02 |
| andrewbogott | YorikSar, kbringard: I have a new question. Is the block-level nature of nova-volume inherent in the API definition, or does it just happen to have been implemented that way so far? | 18:02 |
| bcwaldon | mtaylor: I don't really want to do that, as we can just release an old version and tell users to install that to speak to diablo | 18:03 |
| bcwaldon | mtaylor: is that sensible? I know it sounds frustrating | 18:03 |
| YorikSar | andrewbogott: It is intended to be a block storage service | 18:03 |
| mtaylor | bcwaldon: well... it means we'd need to add a stable/diablo branch for novaclient to be able to do CI testing properly... and then _not_ have a stable/essex because we'd expect folsom's novaclient to continue to work for essex, yeah? | 18:04 |
| bcwaldon | correct | 18:04 |
| jeblair | i'm less worried about the CI technicalities than... | 18:04 |
| jeblair | ...asking users to install multiple versions of the client to deal with multiple cloud providers. that's a big thing to ask. | 18:04 |
| bcwaldon | true | 18:05 |
| andrewbogott | YorikSar: Does that mean that when a volume is attached to an instance it actually has to be formatted via that instance? I'm trying to understand how that distinction manifests from a user's point of view. | 18:05 |
| mtaylor | I agree with jeblair on that - I think that it's a really ugly thing | 18:05 |
| mtaylor | but | 18:05 |
| *** gyee has joined #openstack-dev | 18:05 | |
| bcwaldon | I'm coming from the mindset that nobody should deploy Diablo | 18:05 |
| bcwaldon | but that's not a reasonable thing for me to expect | 18:05 |
| YorikSar | andrewbogott: Yep | 18:05 |
| mtaylor | bcwaldon: yeah - hp cloud is currently based on a fork of diablo | 18:05 |
| jeblair | bcwaldon: yeah, i think a lot of people missed that memo. :) | 18:05 |
| YorikSar | andrewbogott: Or instance that it was attached to before this one | 18:05 |
| kbringard | bcwaldon: the diablo-stable branch is getting better, but I agree, diablo was kind of a cluster | 18:06 |
| mtaylor | bcwaldon: and I'm currently using novaclient to talk to hpcloud - I would be very sad if that stoppped working | 18:06 |
| andrewbogott | But if a previous instance /has/ formatted it, then isn't the distinction between file-level and block-level largely invisible? | 18:06 |
| kbringard | the best thing about diablo was the realization that we need to have a stable branch which is maintained past release :-D | 18:06 |
| bcwaldon | mtaylor: yes, I would feel your pain too | 18:06 |
| mtaylor | kbringard: and a release lifespan idea too | 18:06 |
| kbringard | mtaylor: right | 18:07 |
| kbringard | so if I was pushing out a new deploy today, should I wait and use e4? | 18:07 |
| kbringard | instead of diablo stable? | 18:07 |
| bcwaldon | kbringard: a million times yes | 18:07 |
| mtaylor | kbringard: honestly, yes | 18:08 |
| kbringard | ok, good to know | 18:08 |
| mtaylor | kbringard: I think we've figured out now that we've got to have something deployable when we release and that people are going to need to be albe to upgrade past that | 18:08 |
| YorikSar | andrewbogott: You can still attach it to only one instance. And it appears as block device to guest os, not some gs | 18:08 |
| YorikSar | andrewbogott: *fs | 18:08 |
| mtaylor | (perhpas should have been obvious to us from the start, but wasn't :) ) | 18:08 |
| *** sleepsonthefloo_ has joined #openstack-dev | 18:08 | |
| kbringard | oh yea, I 100% agree, I started many a fight in here about that :-) | 18:08 |
| openstackgerrit | Verification of a change to openstack/glance failed: Fix exception name https://review.openstack.org/4451 | 18:09 |
| kbringard | s/fight/lively discussion/ | 18:09 |
| bcwaldon | mtaylor: so can you state the problem/fix for the record? | 18:09 |
| bcwaldon | I just want to make sure we're all on the same page | 18:09 |
| mtaylor | bcwaldon: well, I'm not sure we agreed yet ... | 18:10 |
| bcwaldon | ok | 18:10 |
| mtaylor | bcwaldon: but let me restate a couple of questoins | 18:10 |
| bcwaldon | so let's regroup | 18:10 |
| bcwaldon | yes | 18:10 |
| mtaylor | bcwaldon: a) should python-novaclient support all versions of nova starting with essex and moving forward | 18:10 |
| mtaylor | I think we are in agreement that this should be the case | 18:11 |
| *** sleepsonthefloo has quit IRC | 18:11 | |
| *** sleepsonthefloo_ is now known as sleepsonthefloo | 18:11 | |
| bcwaldon | yes, the way to state that is to code to a spec rather than an implementation | 18:11 |
| *** vincentricci has quit IRC | 18:11 | |
| mtaylor | ++ | 18:11 |
| *** vincentricci has joined #openstack-dev | 18:11 | |
| mtaylor | well, yes and no - I think if spec version 3.0 comes out | 18:11 |
| mtaylor | that python-novaclient should still also be able to talk to 2.0 spec stuff | 18:11 |
| mtaylor | but I think we're still in agreement | 18:12 |
| mtaylor | just want to be clear | 18:12 |
| bcwaldon | oh absolutely, multiple version of apis are expected | 18:12 |
| bcwaldon | just not multiple releases of nova | 18:12 |
| mtaylor | yes. from a client perspective, nova releases aren't important | 18:12 |
| mtaylor | api versions are | 18:12 |
| bcwaldon | that does raise the question of how we write a client for an experimental api spec | 18:12 |
| jeblair | however, each release of nova should implement some api, so the client should work with multiple releases | 18:13 |
| mtaylor | well... I think it's not that hard, actually... | 18:13 |
| bcwaldon | jeblair: yes, that's what I'm getting at here. How do we support a non-stable api spec in the client? | 18:13 |
| bcwaldon | ...at specific releases | 18:13 |
| mtaylor | if 3.0 is experimental, we write 3.0-supporting code in trunk ... but we're not expecting code using it to be used in production | 18:13 |
| bcwaldon | so lets say we release folsom with a non-finalized implementation of v3 | 18:14 |
| jeblair | if we do that, i'm not sure we're using api versions in the right way | 18:14 |
| mtaylor | folsom nova or folsom novaclient? | 18:14 |
| bcwaldon | nova | 18:14 |
| mtaylor | does it still speak 2.0? | 18:14 |
| bcwaldon | so first of all, does that make sense? | 18:14 |
| bcwaldon | second of all, can we add support to novaclient to hit a moving target like that | 18:14 |
| bcwaldon | since we'll have the same diablo problem | 18:15 |
| mtaylor | the words do - but I think that I agree with jim that we are potentially using api versions in an odd way in that case | 18:15 |
| mtaylor | since then folsom isn't actually speaking 2.0 or 3.0 | 18:15 |
| *** hashar has left #openstack-dev | 18:15 | |
| mtaylor | so in your scenario, folsom would actually not be a valid openstack product | 18:15 |
| bcwaldon | well it would ship with v2 that we have now, and a partial v3 | 18:15 |
| bcwaldon | so it would be valid | 18:16 |
| mtaylor | yeah - in that case, I think v3 is still just considered experimental and the fact that folsom can speak part of it won't really incite people to attempt to use it (or if things break on them, they deserve it) | 18:16 |
| mtaylor | the key is that their client would talk to their server without much effort on their part, yeah? | 18:16 |
| bcwaldon | yep | 18:17 |
| bcwaldon | so we say 'that's experimental, sorry' and move on? | 18:17 |
| mtaylor | yes | 18:17 |
| bcwaldon | they could still install a specific version if they needed to | 18:17 |
| bcwaldon | frustrating, but not impossible | 18:17 |
| jeblair | as long as each release has some fully functioning properly versioned api | 18:17 |
| bcwaldon | yes | 18:18 |
| bcwaldon | Nova will keep v2 until it is no longer possible to be supported | 18:18 |
| mtaylor | ok. so I think we know the forward moving plan: starting with essex, novaclient will implement openstack API specs and will not remove support for old specs | 18:18 |
| bcwaldon | #seconded | 18:18 |
| mtaylor | the outstanding question is: what do we do about diablo | 18:18 |
| mtaylor | you're saying that diablo nova does not support an api spec properly? | 18:19 |
| bcwaldon | it does support it correctly, but there are extra undocumented features that novaclient used to expect | 18:20 |
| bcwaldon | looking for an example now | 18:20 |
| *** vincentricci has left #openstack-dev | 18:20 | |
| mtaylor | ah. ok, I think I understand the problem you're stating then | 18:20 |
| mtaylor | it supported it, but novaclient wasn't quite so usable with _only_ the spec | 18:21 |
| mtaylor | so novaclient for diablo coded to an implementation | 18:21 |
| *** bengrue has joined #openstack-dev | 18:21 | |
| mtaylor | can I suggest that the 1.1 + extensions that novaclient supports is a defacto 1.1? and that it sucks, but it's a lesson learned at this point | 18:22 |
| bcwaldon | mtaylor: https://answers.launchpad.net/nova/+question/188546 | 18:22 |
| bcwaldon | mtaylor: can you explain that in dumber terms for me? | 18:22 |
| mtaylor | SO - we put in the diablo supporting code into trunk novaclient and call it 1.1, | 18:23 |
| *** novas0x2a|laptop has joined #openstack-dev | 18:24 | |
| bcwaldon | mtaylor: why would we do that? 1.1 is already set | 18:24 |
| mtaylor | sorry | 18:24 |
| mtaylor | I was unclear | 18:24 |
| mtaylor | 1.1 is 1.1 | 18:24 |
| mtaylor | let me ask one more question | 18:25 |
| bcwaldon | monty it's like you're speaking a different version of english | 18:25 |
| mtaylor | I do that | 18:25 |
| reed | OpenStack Governance Elections Spring 2012: Action Item For All Candidates http://www.openstack.org/blog/2012/02/openstack-governance-elections-spring-2012-action-item-for-all-candidates/ | 18:25 |
| mtaylor | (I'm trying to ask stupid enough questions so that I make sure we aren't making assumptions on how english works :) | 18:26 |
| *** zaitcev has joined #openstack-dev | 18:26 | |
| reed | make sure to register to vote for PPB | 18:26 |
| jeblair | http://ppbelectionsregistration.openstack.org/ | 18:26 |
| *** shevek_ has quit IRC | 18:26 | |
| mtaylor | bcwaldon: is esex nova releasing speaking 2.0 or 1.1? | 18:26 |
| *** zykes has joined #openstack-dev | 18:27 | |
| bcwaldon | mtaylor: they are the same thing | 18:27 |
| bcwaldon | mtaylor: v1.1 was moved to v2 | 18:27 |
| bcwaldon | mtaylor: in an effort to make versions mean something | 18:27 |
| jeblair | and diablo was supposed to implement 1.1? | 18:27 |
| bcwaldon | yes | 18:27 |
| anotherjesse1 | should I catch up on the who api discussion occurring here? | 18:28 |
| mtaylor | anotherjesse1: yes | 18:28 |
| mtaylor | bcwaldon: ok. so essex is going to speak essentially the same api, but it's going to call it 2.0 | 18:28 |
| bcwaldon | 2, but yes | 18:28 |
| mtaylor | bcwaldon: so essex novaclient will talk 2 to essex nova | 18:28 |
| mtaylor | ok | 18:28 |
| jeblair | so from novaclient's perspective, can it speak the diablo variant if it's talking to 1.1, and the more pure 2 spec with essex? | 18:28 |
| *** dtroyer has quit IRC | 18:28 | |
| mtaylor | bcwaldon: ^^ that's what I was suggesting | 18:29 |
| bcwaldon | ok, I see now | 18:29 |
| mtaylor | I think that will do what people expect in the largest number of circumstances | 18:29 |
| bcwaldon | so we still support using version '1.1' to talk to essex, and it might break clients if we make '1.1' mean something else yet again | 18:30 |
| mtaylor | but if you talk diablo 1.1 to essex, will it work? | 18:30 |
| bcwaldon | the v2 compute api is still accessible at /v1.1/ in the uri | 18:30 |
| bcwaldon | mtaylor: so *I* really don't know where the breakages are other than this undocumented stuff | 18:30 |
| mtaylor | ok, so slightly more verbose: | 18:31 |
| *** mdomsch has quit IRC | 18:31 | |
| mtaylor | by default, with no action on the part of the user, essex novaclient should default to requesting v2 | 18:31 |
| jeblair | (by essex novaclient, do you mean just "novaclient" since it's not part of the normal release process?) | 18:32 |
| mtaylor | yes | 18:32 |
| *** mdomsch has joined #openstack-dev | 18:32 | |
| mtaylor | by essex novaclient I mean trunk novaclient | 18:32 |
| bcwaldon | mtaylor: yes, that is the current default. But keep in mind 1.1 is a synonym for 2 | 18:32 |
| mtaylor | sure. but if I pass version='1.1' to the current novaclient constructor, does it attempt to hit /v1.1 or /v2 ? | 18:33 |
| jeblair | sure, but if python-novaclient talks to the v2 endpoint, that's fine. and if there is no v2 endpoint and it falls back to 1.1, then we know it's diablo and we speak the diablo variant | 18:33 |
| *** Ryan_Lane has joined #openstack-dev | 18:33 | |
| *** gabrielhurley has joined #openstack-dev | 18:33 | |
| bcwaldon | mtaylor: not actually sure on that one | 18:33 |
| anotherjesse1 | mtaylor: when you authenticate against keystone it returns a list of endpoints | 18:34 |
| anotherjesse1 | and those endpoints have the tenant and version built-in | 18:34 |
| bcwaldon | anotherjesse1: yes, good point, they would be pre-versioned | 18:34 |
| *** danwent has quit IRC | 18:35 | |
| mtaylor | yes. good point indeed | 18:35 |
| anotherjesse1 | bcwaldon: if you hit / on the endpoint you get a list of versions - correct? | 18:36 |
| bcwaldon | yes | 18:36 |
| anotherjesse1 | (it is kinda ghetto, since supposedly you are supposed to treat the url as non-meaningful - don't parse out the tenant/version/...) | 18:37 |
| anotherjesse1 | (but then assume that / is the root for the service) | 18:37 |
| anotherjesse1 | (ghetto since you might want to have /foo and /bar be different services on the same endpoint) | 18:37 |
| *** dtroyer has joined #openstack-dev | 18:38 | |
| anotherjesse1 | mtaylor: when you say "specify the version" to be 1.1 - are you assuming the compute endpoint and version and token is all supplied by the user - not by keystone? | 18:38 |
| *** littleidea has joined #openstack-dev | 18:38 | |
| mtaylor | anotherjesse1: no | 18:38 |
| mtaylor | anotherjesse1: when I say "specify the version" I mean into the Client constructor | 18:39 |
| anotherjesse1 | mtaylor: but I don't think that is used anymore if you are using the keystone path | 18:39 |
| mtaylor | ok | 18:39 |
| anotherjesse1 | (I could be VERY wrong as I haven't followed the client day to day) | 18:39 |
| mtaylor | anotherjesse1: I'm trying to solve "I want to write a python program which launches a node" | 18:39 |
| anotherjesse1 | (it probably *should* be used) | 18:39 |
| *** aweiss has quit IRC | 18:39 | |
| mtaylor | anotherjesse1: and I don't want to have to install a diablo version of novaclient if the provider happens to be running diablo | 18:40 |
| anotherjesse1 | mtaylor: agreed | 18:40 |
| mtaylor | ok. cool. just making sure. :) | 18:40 |
| *** corXi has quit IRC | 18:41 | |
| *** davidkranz has quit IRC | 18:51 | |
| *** davidkranz has joined #openstack-dev | 18:51 | |
| *** torgomatic has joined #openstack-dev | 18:52 | |
| annegentle | can I get an admin to add David Hendler to the openstack-cla membership? https://launchpad.net/~openstack-cla/+members#proposed | 19:02 |
| *** GheRivero_ has quit IRC | 19:03 | |
| *** andrewsmedina has quit IRC | 19:04 | |
| *** nati2 has joined #openstack-dev | 19:04 | |
| *** bepernoot has joined #openstack-dev | 19:05 | |
| *** hub_cap has joined #openstack-dev | 19:06 | |
| sleepsonthefloo | so, did we arrive at "trunk novaclient must support diablo/stable?" | 19:12 |
| anotherjesse1 | I think we did, but we need to add tests for it ... | 19:15 |
| sleepsonthefloo | anotherjesse1: yes, could be as simple as re-running diablo/stable ci periodically | 19:16 |
| sleepsonthefloo | If we don't want to full-on add a gate | 19:16 |
| *** bepernoot has quit IRC | 19:19 | |
| *** ayoung-afk has quit IRC | 19:26 | |
| *** sleepsonthefloo has quit IRC | 19:28 | |
| *** sleepsonthefloo has joined #openstack-dev | 19:29 | |
| *** Yak-n-Yeti has joined #openstack-dev | 19:29 | |
| openstackgerrit | Verification of a change to openstack/python-keystoneclient failed: Fix --tenant_id corner case with ec2-create-creds command https://review.openstack.org/4295 | 19:32 |
| jeblair | anotherjesse1, sleepsonthefloo: i filed this bug so we'll remember to do that: https://bugs.launchpad.net/openstack-ci/+bug/939699 | 19:37 |
| uvirtbot` | Launchpad bug 939699 in openstack-ci "client lib integration tests should hit multiple branches" [Undecided,New] | 19:37 |
| annegentle | mtaylor: or jeblair: or LinuxJedi - I'm walking another writer through the Contributor process, and it seems he entered the "wrong" username in Gerrit when first logging on. How can he change his username in Gerrit? | 19:38 |
| jeblair | annegentle: what are the two usernames in question? | 19:38 |
| annegentle | jeblair: dshendler and david-hendler. dshendler is his Github ID. | 19:39 |
| annegentle | jeblair: and in Launchpad, dshenlder is his "user name" and david-henlder is his user ID I guess? | 19:39 |
| annegentle | jeblair: http://launchpad.net/~david-hendler | 19:40 |
| jeblair | what username did he change to in gerrit? | 19:41 |
| annegentle | jeblair: well it's my fault, I had him enter david-hendler. now he sees "Permission denied (public key) " when doing git review -s. So far I am leading people astray this week! :) | 19:43 |
| jeblair | annegentle: ^ ? | 19:43 |
| LinuxJedi | jeblair: david-hendler | 19:43 |
| LinuxJedi | jeblair: according to gerrit's db | 19:43 |
| *** eglynn_ has joined #openstack-dev | 19:43 | |
| annegentle | jeblair: LinuxJedi I'm a horrible onboarder :) | 19:44 |
| *** novas0x2a|laptop has quit IRC | 19:44 | |
| jeblair | LinuxJedi: yes, i see that, but i don't see any other "%hendler%" usernames | 19:44 |
| jeblair | which means gerrit username == launchpad username, which is the way it's supposed to be | 19:44 |
| LinuxJedi | indeed | 19:44 |
| LinuxJedi | annegentle: he may be using the wrong ssh key | 19:44 |
| jeblair | annegentle: so if he sees "david-hendler" when he logs into gerrit, then what LinuxJedi says. :) | 19:45 |
| *** novas0x2a|laptop has joined #openstack-dev | 19:45 | |
| *** eglynn has quit IRC | 19:45 | |
| *** bepernoot has joined #openstack-dev | 19:45 | |
| annegentle | LinuxJedi: jeblair no he sees dshendler <david.hendler@rackspace.com> in the upper right corner | 19:45 |
| jeblair | annegentle: that's actually his "full name", which you can set here: https://review.openstack.org/#settings,contact | 19:46 |
| *** littleidea has quit IRC | 19:46 | |
| jeblair | the username is visible at: https://review.openstack.org/#settings | 19:46 |
| jeblair | (don't ever change it, the sync script will set it correctly) | 19:47 |
| annegentle | jeblair: LinuxJedi: so he has no other public keys than this one, first time setting up the computer, etc. What can I do to confirm the public keys are ok? | 19:48 |
| *** eglynn_ has quit IRC | 19:48 | |
| LinuxJedi | annegentle: ok, so he needs to add his new public key to Launchpad and make sure that is public | 19:49 |
| LinuxJedi | annegentle: the sync script will then pick it up on its next run (every 15 minutes) | 19:49 |
| *** mnewby has joined #openstack-dev | 19:49 | |
| jeblair | he can also add it directly to gerrit | 19:50 |
| LinuxJedi | ah, that too :) | 19:51 |
| annegentle | LinuxJedi: ok, thanks… esp. for the shortcut around the 15 min wait :) | 19:51 |
| *** mattray1 has joined #openstack-dev | 19:51 | |
| jeblair | https://review.openstack.org/#settings,ssh-keys | 19:51 |
| LinuxJedi | annegentle: also, in the mean time, jeblair was kind enough to fix the swift docs for you ;) | 19:52 |
| *** jakedahn has joined #openstack-dev | 19:52 | |
| annegentle | jeblair: LinuxJedi aw thanks! | 19:52 |
| *** mattray has quit IRC | 19:52 | |
| annegentle | jeblair: LinuxJedi ok he did the add to the #settings.ssh-keys then went over to the terminal, did git review -s and still gets the same "Permission denied (public key)" | 19:53 |
| annegentle | LinuxJedi: so on the swift docs, was it just an omission in one of the merges that went in that deleted the doc/build dir? Or was it something else? | 19:54 |
| jeblair | LinuxJedi: at this point, i usually check the gerrit ssh logs on the server, want to do that? | 19:54 |
| LinuxJedi | annegentle: are you 100% sure, the DB is still showing the same key | 19:54 |
| jeblair | I'm going to butt out and let LinuxJedi primarily handle this. ping if you need me. | 19:55 |
| LinuxJedi | annegentle: the swift docs require an extra python library that the normal build bots didn't have. The job now points to the swift build bot. We are discussing better fixes for the future, but for now it works fine | 19:55 |
| LinuxJedi | jeblair: lol, no problem, I'm in the server already | 19:55 |
| *** mattray1 has quit IRC | 19:55 | |
| *** jdg has quit IRC | 19:56 | |
| *** mattray has joined #openstack-dev | 19:56 | |
| *** gabrielhurley has quit IRC | 19:57 | |
| *** gabrielhurley has joined #openstack-dev | 19:58 | |
| *** andrewsmedina has joined #openstack-dev | 20:00 | |
| *** eglynn_ has joined #openstack-dev | 20:00 | |
| annegentle | LinuxJedi: good to know on the swift docs. Gah give me internet! | 20:00 |
| annegentle | LinuxJedi: so uh er I don't know what other key to have him enter? | 20:00 |
| *** n0ano has joined #openstack-dev | 20:01 | |
| LinuxJedi | jeblair: he is coming in as dshendler via. ssh. Should the user match gerrit's user? | 20:03 |
| andrewbogott | YorikSar: The question I was going to ask in the volume meeting (well, one of them) is: Does anyone but me care about shared volumes? Should I try to implement this in a general, harmonious-with-openstack way, or just write a one-off version for internal use? | 20:03 |
| andrewbogott | Do you have any guess about that? | 20:03 |
| *** bepernoo1 has joined #openstack-dev | 20:03 | |
| annegentle | LinuxJedi: that's my theory, the mismatch username | 20:03 |
| *** bepernoot has quit IRC | 20:03 | |
| LinuxJedi | annegentle: well, his incoming username doesn't match his ssh key username of david.hendler. Which makes me think he still hasn't uploaded his new public ssh key | 20:05 |
| annegentle | LinuxJedi: ohhh. okay. the ssh key was created with a (Mac) user name of david.hendler. So…. what can he do about that? | 20:07 |
| *** anotherjesse1 has quit IRC | 20:08 | |
| *** danwent has joined #openstack-dev | 20:08 | |
| LinuxJedi | annegentle: he needs to generate a new ssh key on his current computer with his current username (ssh-keygen will do this) and then add it in gerrit | 20:08 |
| *** paulormg has quit IRC | 20:08 | |
| annegentle | LinuxJedi: ok, will do! | 20:09 |
| LinuxJedi | annegentle: the file contents he will need after he has run ssh-keygen is in ~/.ssh/id_rsa.pub | 20:09 |
| *** mdomsch has quit IRC | 20:09 | |
| *** jdg has joined #openstack-dev | 20:12 | |
| *** rickfoosusa has joined #openstack-dev | 20:20 | |
| jeblair | sorry, was away. you don't need to generate a new ssh key -- it doesn't encode the username in it | 20:23 |
| jeblair | (that's just a comment at the end of the key for reference) | 20:23 |
| jeblair | it's okay if you've already done it, it doesn't matter either way | 20:23 |
| jeblair | the main thing is that git-review needs to be told about what the username is | 20:23 |
| *** mdomsch has joined #openstack-dev | 20:23 | |
| jeblair | so that it puts the right username on the ssh command line | 20:23 |
| jeblair | "git remote rm gerrit" | 20:24 |
| jeblair | "get review -s" | 20:24 |
| jeblair | should give him another chance to set up git-review with the correct username (david-hendler) | 20:24 |
| jeblair | annegentle, LinuxJedi: ^ | 20:24 |
| openstackgerrit | Verification of a change to openstack/python-keystoneclient failed: Fix --tenant_id corner case with ec2-create-creds command https://review.openstack.org/4295 | 20:25 |
| *** berendt has joined #openstack-dev | 20:25 | |
| berendt | who can i contact if i want to suggest to rename "python-keystoneclient" into "keystoneclient" ? | 20:26 |
| annegentle | jeblair: thanks! | 20:26 |
| berendt | i don't understand the name at the moment.. is not python-nova or not python-keystone | 20:26 |
| annegentle | jeblair: yep, that did the trick. | 20:29 |
| *** pixelbeat has quit IRC | 20:31 | |
| *** sandywalsh has quit IRC | 20:35 | |
| *** sandywalsh has joined #openstack-dev | 20:38 | |
| YorikSar | andrewbogott: I really don't see any way to implement freely shared volumes | 20:41 |
| andrewbogott | ? | 20:42 |
| YorikSar | andrewbogott: I think, this should be something one level above volumes | 20:42 |
| andrewbogott | Maybe I am using the word 'volume' differently from how you're using it. | 20:43 |
| andrewbogott | If I restate my question saying 'file system' instead of 'volume' does it make more sense? | 20:43 |
| YorikSar | andrewbogott: Maybe. I think, in Nova terminology 'volume' means a block device, possibly attached to a VM (or just laying around) | 20:44 |
| * andrewbogott nods | 20:44 | |
| YorikSar | andrewbogott: Oh, yes, sorry | 20:44 |
| *** vincentricci has joined #openstack-dev | 20:44 | |
| *** vincentricci has left #openstack-dev | 20:44 | |
| YorikSar | andrewbogott: Then this is fs, not volumes, so it should be done on top of existing volumes... | 20:45 |
| andrewbogott | OK. Regardless of implementation, though -- do you think this is something of general interest, or an arcane wikimedia-specific topic? | 20:45 |
| YorikSar | andrewbogott: Well... I think, it can be implemented as some shared fs that can be mounted to any VM | 20:47 |
| YorikSar | andrewbogott: Which should be very attractive for some clouds | 20:48 |
| andrewbogott | ok. I will try to go through the openstack design process then. | 20:48 |
| andrewbogott | I agree that it should be on top, inasmuch as /where/ the file system is is kind of unrelated to the problem of sharing. | 20:49 |
| YorikSar | andrewbogott: But the problem now is that it should be somewhere between nova-compute and nova-volume, so it'll be hard to make it outside Nova before the separation | 20:50 |
| andrewbogott | YorikSar: Here is an only slightly related question. I would like to be able to use the nova API to create and attach (non-shared) gluster file-systems. Even though they are not block-level, the api to create/attach/delete/etc. would look more or less identical. | 20:51 |
| andrewbogott | So it feels reasonable to me to extend the existing nova-volume driver system to that end. Is that madness? | 20:51 |
| YorikSar | andrewbogott: I even see idealistic picture like: VM <-virtio fs mount-> host dir <-lustre mount-> blockdev <-iSCSI-> nova-volume | 20:52 |
| * andrewbogott nods | 20:53 | |
| *** hhoover has quit IRC | 20:54 | |
| YorikSar | andrewbogott: I'm not sure how LXC root mounts look like, I guess, you need something like they have. | 20:54 |
| YorikSar | andrewbogott: Oh, and I don't think there is a way to online attach/detach a fs | 20:54 |
| andrewbogott | hm... that's probably true without an additional agent running on the guest | 20:55 |
| YorikSar | andrewbogott: So it should be separated from nova-volume | 20:55 |
| YorikSar | andrewbogott: It should be possible to use any volume configuration with this | 20:55 |
| YorikSar | andrewbogott: Looks like it should be some compute api extension + nova-compute enhancement | 20:57 |
| justinsb | Has anyone got cloud-init working with an OVF config_drive? | 20:57 |
| *** hhoover has joined #openstack-dev | 20:59 | |
| *** Yak-n-Yeti1 has joined #openstack-dev | 20:59 | |
| *** Yak-n-Yeti has quit IRC | 21:01 | |
| YorikSar | andrewbogott: It's very interesting if lustre (gluster) on top of iSCSI can perform good enough | 21:02 |
| *** anotherjesse1 has joined #openstack-dev | 21:05 | |
| *** dprince has quit IRC | 21:07 | |
| *** reed has quit IRC | 21:07 | |
| *** bepernoo1 has quit IRC | 21:09 | |
| *** zigo has quit IRC | 21:13 | |
| *** ootz0rz_ has quit IRC | 21:15 | |
| *** Remco_ has joined #openstack-dev | 21:16 | |
| *** reed has joined #openstack-dev | 21:23 | |
| *** adjohn has quit IRC | 21:23 | |
| *** dubsquared has quit IRC | 21:24 | |
| *** dubsquared has joined #openstack-dev | 21:24 | |
| jdg | bcwaldon: ping | 21:27 |
| berendt | what could be wrong if i run keystone-manage -v -d db_sync (without creating the tables) and without any output? | 21:29 |
| *** Yak-n-Yeti1 has quit IRC | 21:29 | |
| *** GheRivero_ has joined #openstack-dev | 21:29 | |
| *** dolphm_ has joined #openstack-dev | 21:32 | |
| *** stuntmachine has quit IRC | 21:34 | |
| *** Yak-n-Yeti has joined #openstack-dev | 21:34 | |
| *** dolphm has quit IRC | 21:35 | |
| adam_g | termie: if you get a minute, https://review.openstack.org/#change,4464 i imagine this will need some work but i'd love to have it land before e4 | 21:37 |
| heckj | berendt: what's the issue? That you're not getting any response, or a traceback? | 21:37 |
| *** cp16net has quit IRC | 21:37 | |
| *** sannes has quit IRC | 21:37 | |
| gyee | heckj, where are the wadls for ksl? I can't seem to find them | 21:38 |
| heckj | I believe they're all being managed in the documentation project at this point. I don't have a direct link for you now, but they're what are being used by Anne and the doc team to generate http://api.openstack.org/ | 21:39 |
| gyee | can Anne email me the link? I want to double check to make sure bug 924029 still applicable | 21:41 |
| uvirtbot` | Launchpad bug 924029 in keystone "services.xsd has incorrect service type for Glance" [Undecided,Invalid] https://launchpad.net/bugs/924029 | 21:41 |
| *** reed_ has joined #openstack-dev | 21:41 | |
| gyee | also, bug 924578 is not legacy | 21:42 |
| uvirtbot` | Launchpad bug 924578 in keystone "swift_auth middleware does not allow non-authenticated access allow via referrer" [Undecided,New] https://launchpad.net/bugs/924578 | 21:42 |
| gyee | it is applicable to ksl | 21:42 |
| *** dolphm_ has quit IRC | 21:43 | |
| *** hashar has joined #openstack-dev | 21:43 | |
| *** reed has quit IRC | 21:45 | |
| vishy | comstud, sandywalsh: see anything wrong with this patch? https://review.openstack.org/#change,4459,patchset=1 | 21:45 |
| comstud | looking | 21:45 |
| comstud | hm | 21:46 |
| *** anotherjesse1 has quit IRC | 21:48 | |
| openstackgerrit | Verification of a change to openstack/nova failed: Don't delete security group in use from OS API. https://review.openstack.org/4457 | 21:49 |
| sandywalsh | vishy, looking | 21:49 |
| comstud | looks fine, other than there's a unit test failure | 21:49 |
| comstud | er | 21:49 |
| comstud | ah | 21:50 |
| comstud | he needs to add himself to Authors | 21:50 |
| bcwaldon | jdg: what's up | 21:50 |
| *** anotherjesse1 has joined #openstack-dev | 21:50 | |
| sandywalsh | what is launch index anyway? Just the N in "N of M" ? | 21:51 |
| jdg | bcwaldon: Just trying to figure out when a good time to get some info from you on that bug. | 21:55 |
| sandywalsh | vishy, comstud, seems reasonable. Don't know the purpose/value of tracking N though | 21:55 |
| termie | adam_g: sure thing | 21:55 |
| jdg | Unfortunatley I haven't had a chance to look at it yet | 21:55 |
| jdg | bcwaldon: I have yet another meeting in 5 mins | 21:55 |
| bcwaldon | jdg: ok, I should be available the rest of the day | 21:56 |
| jdg | bcwaldon: Ok, thanks! I'll try to take look you up in an hour | 21:56 |
| anotherjesse1 | adam_g: is sql catalog something you guys need in esesx? | 22:03 |
| adam_g | anotherjesse1: its certainly better than a template config file, and its more in-line with what we've had in essex up until last week | 22:05 |
| heckj | gyee - marking them as legacy doesn't mean they're not valid for KSL, just that they're older sets and not new things we've found in the late E3/E4 timeframe. It's just for project mgmt to keep track and a close eye on new issues | 22:06 |
| gyee | heckj, I see. Thanks for the clarification | 22:07 |
| *** heckj has quit IRC | 22:07 | |
| *** lts has quit IRC | 22:10 | |
| *** apevec has quit IRC | 22:10 | |
| *** GheRivero_ has quit IRC | 22:12 | |
| vishy | sandywalsh: it is uesed in the ec2api | 22:15 |
| vishy | sandywalsh: and shows up in metadata. Some user data scripts key off of it to figure out how to set themselves up. I don't know of any other use for it. | 22:16 |
| *** deshantm has quit IRC | 22:17 | |
| *** mdomsch has quit IRC | 22:19 | |
| *** sandywalsh has quit IRC | 22:19 | |
| *** dolphm has joined #openstack-dev | 22:19 | |
| *** deshantm has joined #openstack-dev | 22:21 | |
| *** dolphm has quit IRC | 22:24 | |
| *** hub-cap has joined #openstack-dev | 22:24 | |
| *** hub_cap has quit IRC | 22:25 | |
| *** deshantm has quit IRC | 22:27 | |
| *** hashar has quit IRC | 22:31 | |
| *** martine has quit IRC | 22:32 | |
| *** dubsquared1 has joined #openstack-dev | 22:35 | |
| *** sandywalsh has joined #openstack-dev | 22:35 | |
| *** berendt has quit IRC | 22:37 | |
| *** dubsquared has quit IRC | 22:39 | |
| *** adjohn has joined #openstack-dev | 22:41 | |
| *** adjohn has quit IRC | 22:41 | |
| *** dolphm has joined #openstack-dev | 22:48 | |
| *** Yak-n-Yeti has quit IRC | 22:56 | |
| *** markvoelker has quit IRC | 22:57 | |
| *** spinningcog has quit IRC | 23:04 | |
| *** spinningcog has joined #openstack-dev | 23:04 | |
| jdg | bcwaldon: Finally have a few minutes if you're available? | 23:12 |
| bcwaldon | jdg: yep | 23:13 |
| *** stuntmachine has joined #openstack-dev | 23:14 | |
| jdg | Ok, so I'm looking to see where we set this ID an dhow we derive it... | 23:14 |
| bcwaldon | jdg: on create, you just call utils.gen_uuid() and use that in a varchar(36) field rather than allowing autoinc | 23:15 |
| bcwaldon | jdg: the hardest part is updating the tests and writing the migration | 23:15 |
| clayg | sandywalsh: comstud: do you think it would be ok for distributed scheduler to inherit from multi scheduler? | 23:15 |
| *** tomoe_ has joined #openstack-dev | 23:16 | |
| jdg | bcwaldon: got it... so I guess it's just grunt work at that point | 23:16 |
| *** Remco_ has quit IRC | 23:16 | |
| bcwaldon | jdg: yeah, unfortunately | 23:16 |
| jdg | bcwaldon: trying to determine somehow if it breaks things by inspection or by testing. | 23:16 |
| jdg | bcwaldon: Ok, well I guess that pretty much sums it up then. Now it's just up to me to put forth the time | 23:17 |
| clayg | go jdg go! | 23:17 |
| bcwaldon | jdg: haha, yep | 23:17 |
| jdg | bcwaldon: I guess I'll just grep for volume_id to start and weeeeeeeeeee. | 23:18 |
| bcwaldon | that's it | 23:18 |
| bcwaldon | jdg: also volume['id'] | 23:18 |
| bcwaldon | jdg: and volume_ref['id'] | 23:18 |
| bcwaldon | jdg: and double quotes... | 23:18 |
| jdg | bcwaldon: Ok, thanks. Good thing is I should learn quite a bit about the volume code :) Yeah, just noticed that in api.py... crap. Ok, off I go. | 23:19 |
| bcwaldon | jdg: you'll have to update the foreign key on snapshots too | 23:19 |
| *** pixelbeat has joined #openstack-dev | 23:20 | |
| *** zzed has quit IRC | 23:20 | |
| jdg | bcwaldon: models: foreign_keys=volume_id...... | 23:21 |
| bcwaldon | jdg: I don't know off hand, just know that volume shapshots have a volume_id fkey | 23:21 |
| bcwaldon | jdg: I'm assuming you'll just need to update the type of that column and update it with the uuids you generate in the migration | 23:22 |
| jdg | bcwaldon: Yeah, ok I think I've found what you're talking about. The good thing is there aren't as many places where we actually set or check the type, alot of shuffling/storing/passing. But TONS of places to check | 23:23 |
| bcwaldon | jdg: good luck | 23:23 |
| jdg | bcwaldon: Thanks, I'll check back with you some time soon I'm sure :) | 23:23 |
| openstackgerrit | Verification of a change to openstack/keystone failed: Update cfg from openstack-common https://review.openstack.org/4422 | 23:26 |
| *** kordless has joined #openstack-dev | 23:34 | |
| *** shang has joined #openstack-dev | 23:34 | |
| *** stuntmachine has quit IRC | 23:36 | |
| mtaylor | bcwaldon: nitpicking - but how about store gen_uuid() in a 16-byte binary column or | 23:41 |
| bcwaldon | mtaylor: I remember having this discussion at some point... | 23:42 |
| bcwaldon | mtaylor: ended up using varchar but not sure why | 23:42 |
| mtaylor | bcwaldon: this is what happens when one of the db geeks drops in to the middle of the conversation :) | 23:42 |
| s1rp | mtaylor: does the efficiency gain merit the hassle of having the UUID data stored different than how its presented in all of the logs? | 23:44 |
| mtaylor | s1rp: possibly not - some databases have UUID columns which would actually be the _right_ choice ... but you're probably right about that | 23:45 |
| *** mattray has quit IRC | 23:45 | |
| *** kbringard has quit IRC | 23:57 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!