| *** littleidea has quit IRC | 00:09 | |
| *** littleidea has joined #openstack-meeting | 00:10 | |
| *** jaypipes has quit IRC | 00:14 | |
| *** reed has quit IRC | 00:18 | |
| *** dwalleck has quit IRC | 00:27 | |
| *** dwalleck has joined #openstack-meeting | 00:32 | |
| *** donaldngo_hp has quit IRC | 00:33 | |
| *** dwalleck has quit IRC | 00:36 | |
| *** vladimir3p_ has quit IRC | 00:49 | |
| *** novas0x2a|laptop has quit IRC | 00:49 | |
| *** nati2 has quit IRC | 00:53 | |
| *** littleidea has quit IRC | 00:58 | |
| *** dwalleck has joined #openstack-meeting | 01:01 | |
| *** adjohn has quit IRC | 01:05 | |
| *** adjohn has joined #openstack-meeting | 01:07 | |
| *** nati2 has joined #openstack-meeting | 01:18 | |
| *** dragondm has quit IRC | 01:27 | |
| *** nati2 has quit IRC | 01:30 | |
| *** dwalleck has quit IRC | 01:31 | |
| *** dwalleck has joined #openstack-meeting | 01:38 | |
| *** hggdh has quit IRC | 01:49 | |
| *** hggdh has joined #openstack-meeting | 01:50 | |
| *** adjohn has quit IRC | 01:53 | |
| *** mattray has joined #openstack-meeting | 01:54 | |
| *** mattray has quit IRC | 01:55 | |
| *** adjohn has joined #openstack-meeting | 01:57 | |
| *** adjohn has quit IRC | 02:03 | |
| *** adjohn has joined #openstack-meeting | 02:05 | |
| *** bengrue has quit IRC | 02:06 | |
| *** HowardRoark has quit IRC | 02:08 | |
| *** shang has quit IRC | 02:10 | |
| *** adjohn has quit IRC | 02:17 | |
| *** med_out is now known as medberry | 02:18 | |
| *** dwalleck_ has joined #openstack-meeting | 02:37 | |
| *** dwalleck has quit IRC | 02:41 | |
| *** HowardRoark has joined #openstack-meeting | 02:43 | |
| *** martine has joined #openstack-meeting | 03:02 | |
| *** shang has joined #openstack-meeting | 03:13 | |
| *** tsuzuki_ has joined #openstack-meeting | 03:13 | |
| *** medberry is now known as med_out | 03:19 | |
| *** zns has joined #openstack-meeting | 03:22 | |
| *** dwalleck_ has quit IRC | 03:57 | |
| *** dwalleck has joined #openstack-meeting | 03:57 | |
| *** HowardRoark has quit IRC | 03:59 | |
| *** dwalleck_ has joined #openstack-meeting | 04:02 | |
| *** martine has quit IRC | 04:03 | |
| *** dwalleck_ has quit IRC | 04:04 | |
| *** troytoman-away is now known as troytoman | 04:04 | |
| *** dwalleck_ has joined #openstack-meeting | 04:04 | |
| *** dwalleck has quit IRC | 04:05 | |
| *** troytoman is now known as troytoman-away | 04:05 | |
| *** zns has quit IRC | 04:07 | |
| *** dwalleck has joined #openstack-meeting | 04:19 | |
| *** dwalleck_ has quit IRC | 04:23 | |
| *** dendrobates is now known as dendro-afk | 04:29 | |
| *** dendro-afk is now known as dendrobates | 04:32 | |
| *** dwalleck has quit IRC | 04:41 | |
| *** dwalleck has joined #openstack-meeting | 04:41 | |
| *** dwalleck_ has joined #openstack-meeting | 04:47 | |
| *** dwalleck has quit IRC | 04:49 | |
| *** adjohn has joined #openstack-meeting | 04:51 | |
| *** adjohn has quit IRC | 05:00 | |
| *** deshantm has quit IRC | 05:35 | |
| *** deshantm has joined #openstack-meeting | 05:39 | |
| *** adjohn has joined #openstack-meeting | 05:40 | |
| *** dwalleck_ has quit IRC | 05:43 | |
| *** dwalleck has joined #openstack-meeting | 05:44 | |
| *** adjohn has quit IRC | 06:07 | |
| *** dwalleck_ has joined #openstack-meeting | 06:38 | |
| *** dwalleck has quit IRC | 06:41 | |
| *** dwalleck has joined #openstack-meeting | 06:43 | |
| *** ranjang has joined #openstack-meeting | 09:05 | |
| *** darraghb has joined #openstack-meeting | 09:12 | |
| *** ranjang has quit IRC | 09:25 | |
| *** tsuzuki_ has quit IRC | 11:38 | |
| *** dwalleck has quit IRC | 11:47 | |
| *** dendrobates is now known as dendro-afk | 12:01 | |
| *** dendro-afk is now known as dendrobates | 12:04 | |
| *** tsuzuki_ has joined #openstack-meeting | 12:38 | |
| *** med_out is now known as medberry | 12:42 | |
| *** jaypipes has joined #openstack-meeting | 12:44 | |
| *** martine has joined #openstack-meeting | 12:49 | |
| *** blamar has joined #openstack-meeting | 12:54 | |
| *** jaypipes has quit IRC | 12:55 | |
| *** tsuzuki_ has quit IRC | 13:01 | |
| *** dendrobates is now known as dendro-afk | 13:04 | |
| *** mattray has joined #openstack-meeting | 13:10 | |
| *** mattray has joined #openstack-meeting | 13:10 | |
| *** joesavak has joined #openstack-meeting | 13:13 | |
| *** jsavak has joined #openstack-meeting | 13:20 | |
| *** jsavak has quit IRC | 13:22 | |
| *** joesavak has quit IRC | 13:23 | |
| *** dendro-afk is now known as dendrobates | 13:34 | |
| *** hggdh has quit IRC | 13:54 | |
| *** hggdh has joined #openstack-meeting | 14:02 | |
| *** notmyname has joined #openstack-meeting | 14:32 | |
| *** deshantm has quit IRC | 14:34 | |
| *** reed has joined #openstack-meeting | 14:39 | |
| *** deshantm has joined #openstack-meeting | 14:47 | |
| *** adjohn has joined #openstack-meeting | 14:53 | |
| *** rnirmal has joined #openstack-meeting | 14:57 | |
| *** HowardRoark has joined #openstack-meeting | 15:00 | |
| *** dragondm has joined #openstack-meeting | 15:04 | |
| *** dendrobates is now known as dendro-afk | 15:36 | |
| *** dendro-afk is now known as dendrobates | 15:39 | |
| *** dendrobates is now known as dendro-afk | 15:57 | |
| *** HowardRo_ has joined #openstack-meeting | 16:06 | |
| *** HowardRoark has quit IRC | 16:06 | |
| *** martine_ has joined #openstack-meeting | 16:09 | |
| *** martine has quit IRC | 16:09 | |
| *** jakedahn has joined #openstack-meeting | 16:24 | |
| *** creiht has joined #openstack-meeting | 16:24 | |
| *** anotherjesse has joined #openstack-meeting | 16:27 | |
| *** jdg has joined #openstack-meeting | 16:35 | |
| *** jaypipes has joined #openstack-meeting | 16:35 | |
| *** HowardRo_ has quit IRC | 16:46 | |
| *** jakedahn has quit IRC | 16:51 | |
| *** HowardRoark has joined #openstack-meeting | 16:54 | |
| *** dendro-afk is now known as dendrobates | 17:04 | |
| *** dendrobates is now known as dendro-afk | 17:07 | |
| *** novas0x2a|laptop has joined #openstack-meeting | 17:14 | |
| *** vladimir3p has joined #openstack-meeting | 17:22 | |
| *** ogelbukh has joined #openstack-meeting | 17:23 | |
| *** jakedahn has joined #openstack-meeting | 17:39 | |
| *** vladimir3p has quit IRC | 18:02 | |
| *** vladimir3p_ has joined #openstack-meeting | 18:04 | |
| *** jaypipes has quit IRC | 18:09 | |
| *** jaypipes has joined #openstack-meeting | 18:24 | |
| *** jk0 has joined #openstack-meeting | 18:26 | |
| *** jakedahn has quit IRC | 18:37 | |
| *** jakedahn has joined #openstack-meeting | 18:38 | |
| *** jakedahn has quit IRC | 18:42 | |
| *** darraghb has quit IRC | 18:46 | |
| *** jdg has quit IRC | 18:46 | |
| *** renuka has joined #openstack-meeting | 19:04 | |
| *** df_ has joined #openstack-meeting | 19:05 | |
| *** df_ is now known as df111 | 19:05 | |
| *** df111 is now known as df1 | 19:05 | |
| *** jdg has joined #openstack-meeting | 19:27 | |
| *** jdg has left #openstack-meeting | 19:28 | |
| *** dwalleck has joined #openstack-meeting | 19:34 | |
| *** df1 has quit IRC | 19:35 | |
| *** jaypipes has quit IRC | 19:38 | |
| *** jaypipes has joined #openstack-meeting | 19:39 | |
| *** clayg has joined #openstack-meeting | 19:49 | |
| vishy | hello | 20:01 |
|---|---|---|
| *** mirrorbox has joined #openstack-meeting | 20:01 | |
| renuka | hi Vish, could we start the nova volume meeting? | 20:01 |
| vladimir3p_ | hi | 20:01 |
| vishy | yes | 20:01 |
| vishy | renuka, can you try startmeeting? | 20:02 |
| vishy | i don't know if you have to be an admin | 20:02 |
| vishy | if it doesn't work, I will start it | 20:02 |
| renuka | I think I do... you'd probably have to do that | 20:02 |
| vishy | try typing #startmeeting | 20:02 |
| vishy | lets see what happens :) | 20:02 |
| renuka | #startmeeting | 20:02 |
| openstack | Meeting started Thu Oct 13 20:02:56 2011 UTC. The chair is renuka. Information about MeetBot at http://wiki.debian.org/MeetBot. | 20:02 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic. | 20:02 |
| vishy | yay, I thought that might work :) | 20:03 |
| vladimir3p_ | cool :-) | 20:03 |
| renuka | Right, I tried to change the topic before, but that didn't work | 20:03 |
| vishy | you should be able to now with #topic | 20:03 |
| vishy | anyone can do #info #idea and #link | 20:03 |
| vishy | not sure about action | 20:04 |
| vishy | #help | 20:04 |
| renuka | ok | 20:04 |
| *** jdg has joined #openstack-meeting | 20:04 | |
| renuka | So going by the agenda, we could let Vladimir start, since he has a concrete list of what he would like to bring up | 20:04 |
| clayg | o/ | 20:05 |
| vishy | renuka is the agenda in the wiki? | 20:05 |
| vladimir3p_ | ok, not really concrete | 20:05 |
| vishy | if not i will add it | 20:05 |
| *** pandemicsyn has joined #openstack-meeting | 20:05 | |
| renuka | no I haven't added it... just in the email | 20:05 |
| vladimir3p_ | so, starting with our points. some history: | 20:05 |
| vladimir3p_ | we've implemented our own driver & scheduler that are using report_capabilities and reporting our special info | 20:06 |
| vladimir3p_ | in general I suppose it will be great if we could either standardize this info or make it completely up to vendor | 20:06 |
| clayg | vladimir3p_: sidebar regarding the VSA impl in trunk - can I test it w/o ZadaraDriver? | 20:06 |
| vladimir3p_ | but on scheduler level it should recognize what type of info it is getting for volume | 20:06 |
| vladimir3p_ | nope :-) | 20:07 |
| clayg | :( | 20:07 |
| vladimir3p_ | we are working on "generalizing" it | 20:07 |
| clayg | other people could help if they could run it :-) | 20:07 |
| clayg | maybe you can give me a trial license ;) | 20:07 |
| vladimir3p_ | yep, agree | 20:07 |
| renuka | vladimir3p_: are the capabilites for volumes or storage backends? | 20:07 |
| *** hggdh has quit IRC | 20:08 | |
| *** dendro-afk is now known as dendrobates | 20:08 | |
| vladimir3p_ | for us - they are storage backend capab | 20:08 |
| renuka | and are they dynamic? could you give an example | 20:08 |
| vladimir3p_ | there is a special package that we install on every node (where volume is running) and recognize what types of drives are there | 20:08 |
| clayg | vladimir3p_: and also to confirm on caps - they are only aggregated in the scheduler not dropped into db? | 20:08 |
| vladimir3p_ | yes, it is dynamically updated | 20:08 |
| vladimir3p_ | yes | 20:08 |
| vladimir3p_ | (only dynamic in sched) | 20:09 |
| vishy | # link http://wiki.openstack.org/NovaVolumeMeetings | 20:09 |
| vladimir3p_ | moreover, there is a small code for verification if they were changed or not (to avoid sending the same data over and over) | 20:09 |
| vishy | #link http://wiki.openstack.org/NovaVolumeMeetings | 20:09 |
| clayg | vladimir3p_: I've read the blueprint a couple of times, and the impl deviated slightly because of some other depends - but in import ways... did docs ever get released? | 20:09 |
| *** hggdh has joined #openstack-meeting | 20:10 | |
| clayg | s/import/important | 20:10 |
| vladimir3p_ | docs - still in progress. we have some outdated ones | 20:10 |
| vladimir3p_ | anyway, I suppose VSA is not the main topic of this meeting :-) | 20:10 |
| clayg | ok, sorry to grill you :D - zadara has made the most dramatic changes to volumes lately (no disrespect to vishy's latest fixes!) | 20:10 |
| vladimir3p_ | we would be glad to generalize this stuff or at least to use some of our concepts | 20:10 |
| renuka | So (forgive my ignorance) what part of the capabilities is dynamic? | 20:11 |
| *** df1 has joined #openstack-meeting | 20:11 | |
| vladimir3p_ | hmm... everything ... | 20:11 |
| jdg | :) | 20:11 |
| clayg | vladimir3p_: honestly I think generalization of what we already have is the most important chater of this group starting out | 20:11 |
| vladimir3p_ | report capabilities goes to driver (periodic task) and checks what is there, what used/free/etc | 20:11 |
| clayg | renuka: just the reporting of capabilities... the scheduler just reacts to the constant stream of data being fed up from the drivers | 20:12 |
| clayg | change the storage backend and let it propogate up | 20:12 |
| clayg | *dynamic* | 20:12 |
| jdg | I would push towards the generalization/abstraction as vladimir mentions rather than worry much about details of Zadara (although I'm very interested) | 20:12 |
| renuka | makes sense | 20:12 |
| jdg | The question I have is what are you proposing in terms of the generalization? | 20:13 |
| clayg | jdg: zadara is already all up in trunk, understanding what's there and how it falls short of greater needs seems relevant | 20:13 |
| jdg | Fair enough | 20:13 |
| clayg | jdg: what does soldfire need? | 20:13 |
| vladimir3p_ | from the scheduler part - it is also very specific to Zadara today. The cheduler knows to correspond volume types to whatever reported by driver | 20:13 |
| vladimir3p_ | *scheduler | 20:13 |
| * clayg goes to look at scheduler | 20:14 | |
| renuka | vladimir3p_: could you please link the blueprint here | 20:14 |
| jdg | clayg: Very long list... :) My main interest is getting san.py subclasses written (my issue of course), and future possibilities of boot from vol | 20:14 |
| clayg | jdg: the transport is ultimately iscsi, yes? | 20:15 |
| vishy | i would suggest a simple general scheduler | 20:15 |
| jdg | Correct | 20:15 |
| clayg | doesn't kvm already do boot from volume? | 20:15 |
| vishy | i would guess many storage vendors need to get specific and change it. | 20:15 |
| * clayg has never tried it | 20:15 | |
| vishy | clayg: yes it does | 20:15 |
| clayg | is hp here? | 20:16 |
| vishy | a general volume type scheduler that does something dumb like match volume type to a single reported capability would be great | 20:16 |
| vishy | and a more advanced one that does json matching and filtering as well like the ones on the compute side | 20:17 |
| vladimir3p_ | vishy: yep, something like that. the question if we would like to have schedulers per volume type | 20:17 |
| df1 | vishy: agreed on the basic, and advanced sounds nice too | 20:17 |
| renuka | how would this scheme react if we have restrictions about which hosts can access which storage? | 20:17 |
| vishy | #idea A very basic volume type scheduler that can redirect to different backends based on a single reported capability called "type" | 20:17 |
| df1 | vladimir3p_: as in a meta-scheduler which chooses a scheduler based on the requested type and passes on to that? | 20:18 |
| vishy | #idea A more advanced scheduler that does json filtering similar to the advanced schedulers in compute | 20:18 |
| vladimir3p_ | df1: yep | 20:18 |
| vishy | renuka: i would think that we should have a simlar concept to host-aggregates for volumes | 20:18 |
| df1 | renuka: That would fall under the advanced scheduler - pass in arguments to say something about which sorts of volumes are ok | 20:19 |
| vishy | renuka: i think it could use the same set of apis as proposed by armando | 20:19 |
| renuka | vishy: right... that's what I was getting to | 20:19 |
| renuka | so the scheduler would need the knowledge of host aggregates as well, then? | 20:19 |
| vishy | renuka: you could implement it through capabilities, but it wouldn't be dynamically modifyable in that case | 20:19 |
| df1 | vishy, renuka: missed amando's proposal - what was it? | 20:20 |
| clayg | link pls | 20:20 |
| vladimir3p_ | renuka: it also means that during volume creation you need to know associated instance | 20:20 |
| vishy | renuka: yes the scheduler will need access. I would think that the easy version would be to add the host-aggregate metadata in the capability reporting | 20:20 |
| renuka | #link https://blueprints.launchpad.net/nova/+spec/host-aggregates | 20:20 |
| vishy | #link https://blueprints.launchpad.net/nova/+spec/host-aggregates | 20:20 |
| vishy | you beat me | 20:20 |
| vishy | :( | 20:20 |
| renuka | :) | 20:20 |
| clayg | vladimir3p_: it may be sufficient to know project_id depending on how you're scheduling instances | 20:20 |
| clayg | vishy, renuka: thnx for link | 20:21 |
| renuka | vladimir3p_: good point... I am expecting this to be used most for things like boot from volume | 20:22 |
| renuka | so I assumed there would be more control over where the volume got created when it did | 20:22 |
| vladimir3p_ | I suppose that aggregates is a very important part, but more like an "advanced" add-on | 20:23 |
| vishy | #idea report host agreggate metadata through capabilities to the scheduler so that we don't have to do separate db access in the scheduler. | 20:23 |
| renuka | vishy: that means information like which backend can be accessed by which host-aggregate? | 20:24 |
| vladimir3p_ | I'm trying to understand the entire flow ... when volume will be created, should aggregates/host relations be stored in volume types extra specs? | 20:24 |
| df1 | vishy: how does this work out with a very large number of host agreggates? | 20:24 |
| vishy | #topic capability reporting | 20:24 |
| vishy | renuka can you change the topic? Only the chair can do it | 20:25 |
| renuka | now at this point, if we do not have a heirarchy of some sort, and there happens to be storage reachable from a large number of hosts but not all within that zone, it gets a little tricky via capabilities | 20:25 |
| vishy | df1: each host only reports the host aggregate metadata that it is a part of | 20:25 |
| renuka | #topic capability reporting | 20:25 |
| *** openstack changes topic to "capability reporting" | 20:25 | |
| vishy | thx | 20:25 |
| renuka | when did I become chair :P | 20:25 |
| vishy | when you typed #startmeeting | 20:25 |
| vishy | :) | 20:26 |
| vishy | #info the previous conversation was also about capability reporting, and the need for host aggregates to play a part | 20:26 |
| clayg | so is capability reporting _mainly_ reporting the volume_types that are available? | 20:26 |
| vladimir3p_ | I suppose it should be also total quantity / occupied / etc | 20:27 |
| vladimir3p_ | (per each volume type) | 20:27 |
| renuka | and which hosts it can access, per vish's suggestion | 20:27 |
| vladimir3p_ | the reporting itself we could leave as is | 20:27 |
| vladimir3p_ | renuka: which host - it will be up to driver | 20:27 |
| clayg | so you know all the storage node endpoints, what volume types they can create and how much space/how many volumes they have? | 20:27 |
| vladimir3p_ | I mean every driver could add whatever additional info | 20:27 |
| clayg | renuka: will the storage node _know_ which hosts it can "reach" | 20:28 |
| vladimir3p_ | clayg: yes | 20:28 |
| vishy | clayg: the capability reporting is meant to be general, so it depends on the scheduler. Generally the idea is for complicated scheduling you might report all sorts of capabilities | 20:28 |
| renuka | ok so there is some way for the driver to specify implementation specific/connection details | 20:28 |
| vishy | clayg: but i think most use cases can be solved by just reporting the types that the driver supports | 20:28 |
| clayg | vladimir3p_: but unless every driver is going to run their own scheduler (totally an option) they'll want to agree on what goes where and what it means. | 20:28 |
| vishy | lets get the simple version working first | 20:29 |
| clayg | renuka: the driver can have it's own flags, or get config from wherever I suppose, but it wouldn't need/want to report that to the scheudler? | 20:29 |
| renuka | vishy, valdimir3p_: is there a one-many relation between types and storage backends? | 20:29 |
| vishy | there isn't an explicit relationship | 20:30 |
| vladimir3p_ | clayg: that's where we will do "generalization": we will report {volume_type, quantity_total, quantity_used, other_params={}} | 20:30 |
| clayg | is quantity megs, gigs, # of volumes? | 20:30 |
| vishy | volume_type doesn't have any default definitions currently | 20:30 |
| vladimir3p_ | some abstract numbers | 20:30 |
| vladimir3p_ | depends on volume type | 20:31 |
| clayg | vladimir3p_: yeah gotcha, agreed between type - makes sense | 20:31 |
| vishy | renuka: volume_driver_type (which is how compute knows how to connect currently has: 'iscsi', 'local', 'rbd', 'sheepdog' | 20:31 |
| vladimir3p_ | the scheduler will be only able to perform some comparisons | 20:31 |
| vishy | and currently multiple backends export 'iscsi' | 20:31 |
| clayg | vishy: but in the context of scheduling type is more granular - the host may connect via iscsi to "gold" and "silver" volume_types | 20:32 |
| renuka | yes, my point was, more than 1 backend can be associated with a type as abstract as gold | 20:32 |
| renuka | because if gold means netapp backends... we could still have more than one of those, correct? | 20:33 |
| clayg | renuka: well... the backend may just be the driver/message_bus - and then that driver can speak to multiple "nodes" ? (one idea) | 20:33 |
| *** dwalleck has quit IRC | 20:33 | |
| vishy | clayg, renuka: +1 | 20:33 |
| clayg | renuka: in the sm impl, where does nova-volume run? | 20:34 |
| renuka | it is meant to be a control plane. so on a node of its own | 20:34 |
| vishy | #idea lets define 3 simple types: bronze, silver, gold and make the existing drivers just export all three types. This will allow us to write a scheduler that can differentiate the three | 20:34 |
| clayg | yeah... I guess I really mean like how manY/ | 20:34 |
| renuka | by node i mean xenserver host | 20:34 |
| vishy | clayg: depends on the backend | 20:35 |
| vishy | clayg: in the simple lvm/iscsi you have X volume hosts and one runs on every host | 20:35 |
| jdg | vishy: Can you expand on your bronze, silver, gold types? | 20:35 |
| vishy | clayg: in HPSan you run one that just talks to the san | 20:35 |
| vladimir3p_ | renuka: how about to report list of volume types, where details like gold/silver connection, etc might be hidden in additional params. The dimple scheduler should be able to "consolidate" all together, but more granular schedulers could really understand if gold or silver should be used | 20:35 |
| clayg | vishy: but in renuka's sm branch the the xenapi kinda abstracts the different backends | 20:35 |
| renuka | so in SM, the volume driver instances have equal capabilities at this point... we expect the requests to be distributed accross them... and then can all see all of the storage | 20:35 |
| vishy | jdg: they are just names so that we can prove that we support different tiers of storage | 20:36 |
| clayg | renuka: but they still have to figure out placement as far as reaching the node? Or the scheduler already did that for them? | 20:36 |
| vishy | jdg: and that the scheduling and driver backends use them. | 20:36 |
| jdg | vishy: thanks | 20:37 |
| renuka | clayg: at this point, the scheduler is a first fit... | 20:37 |
| clayg | vladimir3p_, renuka: I really don't understand when why a report_capabilities would ever send up "connection" | 20:37 |
| renuka | so it treats all the storage equally for now | 20:37 |
| renuka | clayg: connection here means more like access control info | 20:38 |
| renuka | maybe that was a bad word again... more like which hosts can reach this storage | 20:38 |
| clayg | that did not disambiguate the concept for me :P | 20:38 |
| clayg | what is "access control info" | 20:38 |
| vladimir3p_ | clayg: I suppose I understand Renuka's use case - you may have different storage controllers connected to different nodes (Active Optimized/Non-optimized, etc.) | 20:38 |
| vladimir3p_ | the access from "preferred" controller might be more preferable | 20:39 |
| renuka | Looking at the time, do we want to continue this discussion or touch more of the topics (i vote to continue) | 20:40 |
| vishy | renuka: do you have a solution in mind when there is no knowledge about which vm the storage will be attached to? | 20:40 |
| renuka | vishy: for a scheduler you mean? | 20:41 |
| renuka | or which storage backend will be used when there is no knowledge? | 20:41 |
| vishy | the second | 20:42 |
| *** masumotok has joined #openstack-meeting | 20:42 | |
| vishy | for example, creating a volume through the ec2 api gives you no knowledge of where it will be attached | 20:42 |
| renuka | in that case, the assumption is that reachability is not an issue, correct? So I agree with Vladimir's capability based decision | 20:42 |
| vladimir3p_ | vishy: for EC2 - you could have default type | 20:43 |
| renuka | having said that, I would expect some knowledge of the project/user to be used | 20:43 |
| vishy | type is not the concern | 20:43 |
| vladimir3p_ | so, do we have an agreement re reporting capabilities? It will report the list of ... {volume type id, quantities (all, used), other info} | 20:43 |
| vishy | the concern is for top-of-rack storage | 20:44 |
| vishy | you have to put it somewhere | 20:44 |
| clayg | renuka: when you say "storage backend" is that a type of backend or a specific node/instances/pool that can create volumes? | 20:44 |
| vladimir3p_ | in other_info we could put some sort of UUID for storage array ... | 20:44 |
| renuka | clayg: it could be anything ranging from local storage on the volume node to netapp backends | 20:44 |
| vladimir3p_ | we have only 15 min left ... prior to Vish's meeting | 20:45 |
| vishy | do we have specific blueprints for these features? | 20:45 |
| vishy | I would suggest blueprints for the first scheduler with simple capability reporting | 20:46 |
| vishy | at the very least | 20:46 |
| vishy | and someone taking lead on getting it implemented | 20:46 |
| renuka | yes, it would be a really good idea to have as many details of the implementation written down, so we have something more concrete | 20:46 |
| vladimir3p_ | jsut to compare if storage is there? | 20:46 |
| *** comstud has joined #openstack-meeting | 20:47 | |
| renuka | vladimir3p_: would it be possible for you to put the design details into a scheduler blueprint? | 20:48 |
| vladimir3p_ | yeah, I could create something small ... sorry, on this stage cant commit for full implementation | 20:48 |
| renuka | sure... we should just have a point where we have a concrete design | 20:49 |
| vladimir3p_ | yep, I will write down what I think about simple scheduler & simple reporting | 20:49 |
| clayg | blue print could link to a etherpad we could flesh it out more async | 20:49 |
| renuka | makes sense | 20:50 |
| clayg | update blueprint when we're happy (same time next week?) | 20:50 |
| vladimir3p_ | we could review it and decide if it is good for everyone as a first step | 20:50 |
| df1 | sounds good | 20:50 |
| renuka | we should discuss the time ... turns out netapp and hp couldn't make it to this one | 20:50 |
| jdg | I vote for same time next week | 20:50 |
| vladimir3p_ | fine with me | 20:51 |
| *** bcwaldon has joined #openstack-meeting | 20:51 | |
| renuka | can anyone make it earlier on any day? It is 8 pm UTC which might be late for some | 20:51 |
| vladimir3p_ | I will create an etherpad for this design .. or should we put it on wiki? | 20:51 |
| vladimir3p_ | how about 10am PST? | 20:51 |
| renuka | vladimir3p_: yes | 20:51 |
| vladimir3p_ | so, next Thu @ 10am. Renuka, will you send an update to everyone on ML? | 20:53 |
| clayg | vladimir3p_: 10am PST is good | 20:53 |
| vishy | #action vladimir3p_ to document plans for simple reporting and scheduler | 20:53 |
| jdg | 10am works | 20:53 |
| df1 | 10am is good | 20:53 |
| renuka | that works too | 20:53 |
| *** PhilDay has joined #openstack-meeting | 20:53 | |
| vladimir3p_ | re document location: wiki or etherpad? | 20:53 |
| vladimir3p_ | do we have a blueprint for it? | 20:53 |
| vishy | #info next meeting moved to 10 am | 20:53 |
| vishy | vladimir3p_: pls make a blueprint | 20:54 |
| renuka | etherpad is good for hashing out design | 20:54 |
| vishy | you can link to either imo | 20:54 |
| vladimir3p_ | ok, will do | 20:54 |
| vishy | #info the rest of the agenda will be discussed next week | 20:56 |
| renuka | vladimir3p_: what did you mean by -Volume-type aware drivers | 20:56 |
| vishy | renuka: if we're done could you issue an #endmeeting | 20:56 |
| *** jaypipes has quit IRC | 20:56 | |
| vladimir3p_ | renuka: to be able to have multiple drivers on the same node responsible for different volume types | 20:56 |
| renuka | #endmeeting | 20:57 |
| *** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/" | 20:57 | |
| openstack | Meeting ended Thu Oct 13 20:57:00 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 20:57 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-13-20.02.html | 20:57 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-13-20.02.txt | 20:57 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-13-20.02.log.html | 20:57 |
| vishy | everyone look at the minutes: | 20:57 |
| vishy | they are much more useful if everyone is contributing to with #info #link #action #idea | 20:58 |
| pvo | o/ | 20:58 |
| bcwaldon | #agree | 20:58 |
| *** mikeyp-3_ has joined #openstack-meeting | 20:59 | |
| comstud | #winning | 21:00 |
| vishy | nice | 21:00 |
| vishy | ok here we go | 21:00 |
| vishy | #startmeeting | 21:00 |
| openstack | Meeting started Thu Oct 13 21:00:36 2011 UTC. The chair is vishy. Information about MeetBot at http://wiki.debian.org/MeetBot. | 21:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic. | 21:00 |
| vishy | #topic Blueprint list | 21:00 |
| *** openstack changes topic to "Blueprint list" | 21:00 | |
| vishy | #link http://etherpad.openstack.org/essex | 21:01 |
| vishy | i've gotten most of the blueprints added there | 21:01 |
| vishy | please everyone look and see if there is anything I missed | 21:01 |
| *** rjh has joined #openstack-meeting | 21:02 | |
| pvo | looks good Vish. | 21:02 |
| pvo | I think there is a lot of work here for Essex | 21:02 |
| comstud | i probably should create a XenServer ConfigDrive BP | 21:03 |
| vishy | comstud: pls do | 21:03 |
| comstud | no feature parity there yet | 21:03 |
| bcwaldon | vishy: do you want to assign any of these today? | 21:03 |
| vishy | note that the admin apis has nothing yet | 21:03 |
| vishy | bcwaldon: first I want to make sure that we haven't missed any major ones | 21:04 |
| PhilDay | #info you missed the two blueprints I created yesterdat for VM State Machine and Image Cache Management | 21:04 |
| vishy | PhilDay: can you cpy them in pls | 21:04 |
| comstud | #action comstud to create xenserver config drive BP | 21:04 |
| pvo | comstud: I think there is an old one for that | 21:05 |
| comstud | maybe | 21:05 |
| comstud | might have been marked done with the libvirt part | 21:05 |
| comstud | I'll take a look | 21:05 |
| *** mikeyp-3_ has quit IRC | 21:05 | |
| comstud | yeah | 21:06 |
| comstud | #link https://blueprints.launchpad.net/nova/+spec/configuration-drive | 21:06 |
| comstud | says implemented | 21:06 |
| *** dwalleck has joined #openstack-meeting | 21:06 | |
| pvo | comstud: gotcha | 21:06 |
| comstud | i'm supposed to create the story for our sprints anyway :) | 21:06 |
| *** dwalleck has quit IRC | 21:06 | |
| comstud | i'm slacking | 21:06 |
| vishy | can someone add a blueprint for vnc console cleanup? Basically just combining the two vnc paths somehow | 21:07 |
| comstud | did the research, haven't written it yet | 21:07 |
| _0x44 | It was implemented with the understanding/expectation that someone with access to XenServer who cared about config-drive would ensure that it worked. | 21:07 |
| _0x44 | I think the only thing needed is to attach it | 21:07 |
| _0x44 | _think_ | 21:07 |
| pvo | _0x44: I think there was a bit more to do. Create the VDIs and such. | 21:07 |
| comstud | there's more than that | 21:07 |
| comstud | but yeah | 21:08 |
| sleepsonthefloor | vishy - i can add one for vnc | 21:09 |
| vishy | sleepsonthefloor: thx | 21:09 |
| *** jakedahn has joined #openstack-meeting | 21:09 | |
| PhilDay | vishy - added the VM state machine under ""Workflow State Machine" but not sure if that's quite the right place for it | 21:09 |
| vishy | PhilDay: that is fine | 21:10 |
| vishy | so we are still missing a few blueprints related to volumes | 21:10 |
| vishy | other than that i think we have everything in | 21:10 |
| vishy | well we are missing a few in the security session as well | 21:12 |
| *** mikeyp-3 has joined #openstack-meeting | 21:13 | |
| _0x44 | vishy: Are the BP's bengrue worked on in Diablo already listed? | 21:13 |
| pvo | vishy: are you going to prioritize these from your perspective as PTL? | 21:14 |
| vishy | which are those? | 21:14 |
| vishy | pvo: that is what I want input on | 21:14 |
| *** salv-orlando has joined #openstack-meeting | 21:14 | |
| pvo | ok | 21:14 |
| vishy | pvo: I need to know which ones are required by teams | 21:14 |
| _0x44 | vishy: Bringing bengrue in here to answer that. | 21:14 |
| *** df1 has left #openstack-meeting | 21:14 | |
| vishy | there are definitely some missing | 21:15 |
| *** bengrue has joined #openstack-meeting | 21:15 | |
| vishy | is westmaas here? | 21:15 |
| pvo | westmaaaaaaaaaaaaaaaaaaasssssssss | 21:15 |
| _0x44 | bengrue: What are the blueprints you were working on in Diablo around volumes? | 21:15 |
| pvo | I was just chatting with him. | 21:16 |
| vishy | so we have a few very big ones | 21:16 |
| vishy | and we need to decide if we want to tackle them in diablo | 21:16 |
| vishy | * essex | 21:16 |
| bengrue | Sec. That was a bit ago. | 21:16 |
| vishy | or push to f | 21:16 |
| pvo | vishy: what do you think are the biggest? | 21:16 |
| pvo | top 5 | 21:16 |
| vishy | so the big ones as I see it are: | 21:17 |
| vishy | 1) DB Cleanup and testing | 21:17 |
| comstud | Do we have an overall goal for Essex? | 21:17 |
| vishy | 2) Zone Aggregation | 21:17 |
| pvo | stablility, performance and scalability | 21:17 |
| vishy | 3) Workflow State Machine | 21:17 |
| comstud | pvo: perfect | 21:17 |
| vishy | 4) Secure Databases | 21:17 |
| bhall_ | pvo: is that all? :) | 21:17 |
| pvo | bhall_: over features, I would think so | 21:18 |
| pvo | I would prefer those 3, over any new features | 21:18 |
| bhall_ | agreed | 21:18 |
| vladimir3p_ | vishy: under Workflow state machine do you mean "orchestration, jobs, retries, etc..." | 21:18 |
| vishy | the problem is i think all of those are required | 21:18 |
| PhilDay | #agree with pvo | 21:18 |
| vishy | vladimir3p_: I'm referring to sandy's proposal of actually having workflow management | 21:19 |
| vladimir3p_ | vishy: yep | 21:19 |
| vishy | I don't thing we can hit all 4 of those | 21:19 |
| vishy | and they are listed in priority as i see them | 21:19 |
| vishy | #topic large blueprints | 21:19 |
| *** openstack changes topic to "large blueprints" | 21:19 | |
| vishy | #info Largest blueprints: db cleanup and testing, zone aggregation, workflow state machine, secure databases | 21:20 |
| pvo | vishy: we have 4 milestones. One goal per milestone? | 21:20 |
| vishy | some of them can be worked concurrently | 21:20 |
| vishy | but I think all 4 of those require a team | 21:20 |
| vishy | i don't think one person can handle any of them | 21:21 |
| PhilDay | pvo: I'd be worried that we'd still have big changes comming through late in Essex if we do one per milestone | 21:21 |
| vishy | I'd like to push secure db / queue | 21:21 |
| vishy | #info upgrades is also large | 21:21 |
| bengrue | _0x44: the blueprint I was working on was https://blueprints.launchpad.net/nova/+spec/volume-cleanup | 21:21 |
| vishy | bengure: that is implemented and merged | 21:21 |
| vishy | * bengrue | 21:21 |
| _0x44 | I wasn't sure if it was merged | 21:22 |
| bengrue | Yeah, Vlad I think drove it home? | 21:22 |
| PhilDay | Upgrades is a v important now there are systems deployed | 21:22 |
| _0x44 | Ok, sorry for the confusion. | 21:22 |
| bengrue | np. | 21:22 |
| vishy | Yes we need a team for all 5 of those, but if we don't hit secure dbs in essex does that kill anyone | 21:22 |
| vishy | PhilDay: can we push that one from your perspective? | 21:22 |
| anotherjesse | vishy: secure db + zones might need to coordinate | 21:23 |
| PhilDay | yep | 21:23 |
| vishy | PhilDay: That one in particular requires massive changes | 21:23 |
| vishy | anotherjesse: I'd like to tackle db cleanup + zones first, i think it makes secure db easier | 21:23 |
| vishy | working on it concurrently will be a huge issue | 21:24 |
| anotherjesse | vishy: also we might want to think of using a smaller component like the volume component for testing out the secure db | 21:24 |
| pvo | vishy: ++ | 21:24 |
| PhilDay | Agreed, and the session in Boston showed there are more questions than answers - but if we don't hit it soon it'll just get worse | 21:24 |
| vishy | #idea create subteams for the major work sections | 21:24 |
| anotherjesse | vishy: teams mean launchpad teams? | 21:24 |
| vishy | anotherjesse: I don't know if it needs to be that formal | 21:25 |
| pvo | I think its just working groups that Vish keeps tabs on | 21:25 |
| vishy | zone aggregation, i'd like to see anotherjesse, comstud, sandywalsh collaborate | 21:25 |
| vishy | don't know if there is anyone else who should be involved there | 21:26 |
| comstud | yeah, myself and sandy are probably a given | 21:26 |
| PhilDay | We have some views, although we're not heavy into zones - yet | 21:26 |
| anotherjesse | vishy: wiki page of major themes for essex with people on it (so people who aren't on it originally can join in) | 21:27 |
| vishy | does anyone want to tackle the db cleanup and testing stuff | 21:27 |
| vishy | anotherjesse: definitely | 21:27 |
| bcwaldon | vishy: blamar would be a good one there, I'm also interested | 21:27 |
| *** primeministerp1 has joined #openstack-meeting | 21:27 | |
| comstud | bcwaldon: funny, I was just going to nominate both of you | 21:27 |
| vishy | how about upgrades? | 21:27 |
| comstud | :) | 21:28 |
| anotherjesse | sleepsonthefloor: do you want to help on db, statemachine or ? | 21:28 |
| blamar | bcwaldon: thanks there buddy | 21:28 |
| vishy | that one is a lot of theory and prototyping | 21:28 |
| bcwaldon | blamar: there you are! | 21:28 |
| comstud | blamar: np :) | 21:28 |
| _0x44 | vishy: Am interested in db=-cleanup at piston | 21:28 |
| rjh | once again, we need to have a group to define what upgrades are all about | 21:28 |
| vishy | I'm adding this to the etherpad | 21:28 |
| rjh | We are definitely interested | 21:28 |
| vishy | feel free to add yourself to a section | 21:28 |
| vishy | rjh: who are you with again? | 21:29 |
| pvo | I'm going to throw Dietz on the upgrades. He and I have been talking about it and whiteboarding | 21:29 |
| anotherjesse | _0x44: are you guys interested in building a db backend that isn't sqlalchemy? | 21:29 |
| _0x44 | anotherjesse: Yes. | 21:29 |
| anotherjesse | _0x44: zk? | 21:29 |
| _0x44 | anotherjesse: Likely | 21:29 |
| PhilDay | rjh=Ray Hookway (HP) | 21:30 |
| *** NeilJohnston has joined #openstack-meeting | 21:30 | |
| anotherjesse | _0x44: I think it is important that whoever leads the db cleanup does in order to be able to ship an alternative backend | 21:30 |
| bcwaldon | thanks PhilDay, was wondering ;) | 21:30 |
| _0x44 | pvo: | 21:30 |
| PhilDay | At least I think its Ray :-) | 21:30 |
| rjh | It is | 21:31 |
| jk0 | if not, he was just volunteered ;) | 21:31 |
| pvo | _0x44: | 21:31 |
| _0x44 | pvo/vishy: I'd like to add novas0x2a to upgrades also | 21:31 |
| vishy | oh hai | 21:31 |
| vishy | #topic subteams for major sections | 21:31 |
| *** openstack changes topic to "subteams for major sections" | 21:31 | |
| _0x44 | Sorry, am on a terrible network right now | 21:31 |
| pvo | _0x44: something didn't convert there | 21:31 |
| comstud | 0x44: you still in boston? | 21:32 |
| salv-orlando | Citrix would be more than happy to contribute on upgrades as well. I think the name is johngarbutt but I'm not totally sure | 21:32 |
| comstud | :) | 21:32 |
| _0x44 | pvo: novas0x2a is mike lundy | 21:32 |
| vishy | #info breaking out subteams for particular sections of the code | 21:32 |
| pvo | gotcha | 21:32 |
| _0x44 | pvo: The nordic bearded guy at Pisotn | 21:32 |
| vishy | ok we have one more subteam | 21:32 |
| vishy | feature parity | 21:32 |
| anotherjesse | vishy - you mean hypervisors? | 21:32 |
| _0x44 | I have to run now | 21:32 |
| anotherjesse | or apis? | 21:32 |
| vishy | anotherjesse: hypervisors | 21:32 |
| pvo | all hypervisors? | 21:33 |
| pvo | we focused just on KVM and XenServer at the summit | 21:33 |
| pvo | is that still the majority focus? | 21:33 |
| anotherjesse | pvo: probably some things will result in documenting "not supported" - for things that don't make sense | 21:33 |
| vishy | no just the main two | 21:33 |
| pvo | ok | 21:33 |
| vishy | i don't want to get crazy | 21:33 |
| pvo | just wanted to make sure | 21:33 |
| vishy | so quick once over from the interested parties | 21:33 |
| anotherjesse | vishy: does this include the fact that xenserver at rax vs. kvm openstack is very different from user perspective (image formats, userdata/metdata, how to auth to servers, ...) | 21:34 |
| vishy | anotherjesse: it doesn't | 21:34 |
| rjh | How about a security team to deal with message signing and db access? | 21:34 |
| vishy | anotherjesse: we have no blueprints for those things, but they sound important | 21:34 |
| vishy | rjh: yes security team is good. I'm concerned about them being able to make much progress | 21:35 |
| anotherjesse | #info jesse write up a blueprint on ux for openstack | 21:35 |
| *** Gordonz has quit IRC | 21:35 | |
| vishy | but they can at least start planning | 21:35 |
| vishy | pvo, is there someone on your team who is more focused on feature parity? | 21:35 |
| anotherjesse | vishy: I volunteer pvo and sleepsonthefloor | 21:36 |
| vishy | :) | 21:36 |
| pvo | more focused? | 21:36 |
| anotherjesse | it would be nice if someone from ubuntu (kvm/lxc) & citrix (xs) could help | 21:36 |
| vishy | #info db and rabbit security should be planned but the aren't targeted to be complete by essex | 21:37 |
| sleepsonthefloor | yeah, I'm definitely interested in parity | 21:37 |
| salv-orlando | more or less the whole Citrix team is focused on parity | 21:37 |
| vishy | anotherjesse: agreed, I wonder if we could add salv-orlando | 21:37 |
| *** NeilJohnston has quit IRC | 21:37 | |
| *** bcwaldon has quit IRC | 21:37 | |
| salv-orlando | I'd say ewanmellor would be happy to be on this team as well | 21:37 |
| sleepsonthefloor | it would be nice if someone else who has thought about nova-network and security groups with xen could be on it | 21:38 |
| vishy | so does anything else seem to dangerous to be in scope for essex? | 21:38 |
| anotherjesse | api 2.0 - but before zones is done … that seems scary to talk about | 21:39 |
| pvo | anotherjesse: agree | 21:39 |
| comstud | yeah | 21:39 |
| comstud | #agree | 21:39 |
| vishy | bcwaldon disappeared | 21:39 |
| vishy | I don't think we need 2.0 for essex | 21:39 |
| pvo | #info wait on zones to be completed before nova api 2.0 | 21:39 |
| anotherjesse | vishy: rbac is medium sized - mostly busy work | 21:39 |
| vishy | anotherjesse: good point we need to give special attention to that one | 21:40 |
| anotherjesse | (arguing over what the proper verbs are) | 21:40 |
| vishy | anotherjesse: do you think we should have a team for that. Should rcb take lead on it? | 21:40 |
| anotherjesse | maybe todd? | 21:40 |
| anotherjesse | xtoddx: | 21:40 |
| anotherjesse | he needs that for nasa | 21:40 |
| vishy | i don't mind heading that one up | 21:40 |
| anotherjesse | vishy: having you on volumes would probably be better | 21:41 |
| pvo | vishy: re: the top5, are there BPs for each of those? | 21:41 |
| anotherjesse | since you have done a lot of that work already | 21:41 |
| vishy | anotherjesse: I'm trying to offload volumes onto third parties | 21:41 |
| vishy | anotherjesse: so hopefully i can move into more of a supporting role there | 21:41 |
| rjh | There is a blueprint for upgrades, but it needs to be made more specific | 21:42 |
| vishy | rjh: i think that one needs to be broken out into specific blueprints | 21:43 |
| rjh | Secure databases is mentioned in the nova-security-updates blueprint | 21:43 |
| *** jakedahn has quit IRC | 21:43 | |
| vishy | #action upgrades team to meet and come up with specific action items and blueprints | 21:43 |
| rjh | I agree - that goes for both of them | 21:43 |
| vishy | #info volumes team met today and started discussing the needed pieces | 21:44 |
| vishy | #info we don't have specific blueprints for the parts yet | 21:44 |
| vishy | blamar: do you want to lead the db cleanup team? | 21:45 |
| *** mikeyp-3 has quit IRC | 21:45 | |
| anotherjesse | vishy: nothing against blamar but I really think having the lead caring about an alternative backend is important | 21:45 |
| anotherjesse | caring = require | 21:45 |
| vishy | blamar: there is one blueprint so far, which is to make the db layer return dictionaries | 21:45 |
| vishy | anotherjesse: so you think 0x44 should head it up? | 21:45 |
| blamar | vishy: apologies, was on the phone..however not currently interested in leading a team; busy life | 21:46 |
| vishy | does anyone here care about zookeeper? | 21:46 |
| anotherjesse | vishy: supposedly _0x44 does | 21:46 |
| anotherjesse | can we pencil it in - with a note that we need to verify | 21:46 |
| vishy | #action vishy to verify with _0x44 that he can lead the db cleanup efforts | 21:46 |
| blamar | vishy, anotherjesse: I'm an advocate for getting a couchdb backend (as per my email to the mailing list a while back on this subject) and I've used ZK in the past | 21:47 |
| vishy | anotherjesse: are you heading up the zone scaling coordination? | 21:47 |
| blamar | so I'd love to assist whomever leads | 21:47 |
| vishy | blamar, so you're volunteering again :) | 21:47 |
| blamar | negatory, I'll be a fine assistant | 21:47 |
| anotherjesse | vishy: i am from our team - if sandywalsh or comstud is a better lead overall, I have no objections | 21:47 |
| pvo | vishy: comstud/sandy can as well. | 21:48 |
| *** mikeyp-3 has joined #openstack-meeting | 21:48 | |
| vishy | comstud: ? | 21:48 |
| pvo | Both have a pretty firm grasp of the issue | 21:48 |
| comstud | hmm | 21:48 |
| comstud | not sure i'm the best person | 21:48 |
| vishy | we also have that big nasty Recovery/Workflow section | 21:48 |
| comstud | esp. if i'll be tied up with zones | 21:48 |
| vishy | which sandy seems to be very excited about | 21:48 |
| anotherjesse | comstud: how about you - since you guys have to have zones to ship? | 21:48 |
| sandywalsh | I'm up for zones or orchestration ... two hot topics for me | 21:48 |
| comstud | oh | 21:48 |
| comstud | are we talking about zones? | 21:48 |
| pvo | comstud: we're talking about zones. : ) | 21:49 |
| vishy | comstud: zone scaling is what we're talking about | 21:49 |
| comstud | lol | 21:49 |
| comstud | i was chatting with sandy and not paying attention | 21:49 |
| comstud | :) | 21:49 |
| comstud | sure | 21:49 |
| vishy | #info comstud to lead zones with help from sandy and anotherjesse | 21:49 |
| comstud | I can take that | 21:49 |
| vishy | #info sandy to lead orchestration with help from ... | 21:49 |
| pvo | vishy: where is donabe in relation to orchestration? | 21:49 |
| sandywalsh | I assumed donabe more operations oriented, not nova internal? no? | 21:50 |
| salv-orlando | dendrobates? | 21:50 |
| vishy | pvo, sandywalsh: It is more related to creating groups of resources i think | 21:50 |
| pvo | I would think there would be some of the same retrying/requeueing in tehre as well | 21:50 |
| vishy | where as this is more concerned with the state of individual resources | 21:50 |
| *** creiht has left #openstack-meeting | 21:51 | |
| vishy | does anyone here care particularly about Operational Support | 21:51 |
| sandywalsh | resources and the workflows around them | 21:51 |
| vishy | including admin apis, cli tools, etc? | 21:51 |
| pvo | vishy: we do... I'm repping for our ops guys today | 21:52 |
| anotherjesse | vishy: we should volunteer chmouel or others from deployment team | 21:52 |
| vishy | sleepsonthefloor: are you able to lead the feature parity section? | 21:52 |
| *** NeilJohnston has joined #openstack-meeting | 21:52 | |
| sleepsonthefloor | vishy - for sure | 21:52 |
| sleepsonthefloor | salv-orlando - you interested in helping then? | 21:53 |
| vishy | ok, so i need someone to take the lead on Upgrades, Operations, Security | 21:53 |
| salv-orlando | sleepsonthefloor: on feature parity? Yes. | 21:53 |
| pvo | vishy: let me get back to you on the ops part. | 21:53 |
| vishy | pvo: ok | 21:54 |
| pvo | I'm recruiting some of our ops guys to take a more active role in the open. | 21:54 |
| vishy | pvo: are you leading upgrades? | 21:54 |
| pvo | me or Dietz. | 21:54 |
| vishy | rjh: shall I put you on the lead for security planning? | 21:54 |
| anotherjesse | vishy: I'm not sure if pvo is a good fit - as they will run an internal version - upgrades is more about shipped software? | 21:54 |
| rjh | ok | 21:55 |
| vishy | anotherjesse: good point | 21:55 |
| anotherjesse | vishy: someone in canonical or citrix or others who ship software based on milestones / releases | 21:55 |
| anotherjesse | crowbar? | 21:55 |
| pvo | its more how to do upgrades is what were thinking. procedures and best practices. | 21:55 |
| vishy | anotherjesse: perhaps someone from canonical will step in here | 21:55 |
| pvo | you're meaning make sure upgrades work from Diablo to pre-Essex? | 21:55 |
| anotherjesse | diablo to essex | 21:55 |
| vishy | pvo: it is diablo to essex | 21:55 |
| pvo | essex-pre release... sure. Yes, probably not the right guy there | 21:56 |
| salv-orlando | vishy: we at Citrix have definitely interest in upgrades. Unfortunately our 'upgrade' men are not here tonight | 21:56 |
| pvo | we won't be doing massive upgrades every 6 months | 21:56 |
| vishy | ok | 21:56 |
| anotherjesse | pvo: right - not that you won't be able to contribute and have lots of good feedback - but when you run a service you can do 100 upgrades between diablo and essex in stages (gradual db migrations, ...) | 21:56 |
| vishy | guys, I need some suggestions for how these groups should keep in touch | 21:56 |
| *** rnirmal has quit IRC | 21:56 | |
| pvo | anotherjesse: yep. Totally valid point | 21:56 |
| pvo | walkie talkies | 21:57 |
| anotherjesse | pvo: you should definitely have folks on the team | 21:57 |
| vishy | should we start little mailing lists for all of them like we did for the volume group? | 21:57 |
| pvo | anotherjesse: absolutely will | 21:57 |
| anotherjesse | vishy: does lp teams give you a mailing list? | 21:57 |
| pvo | anotherjesse: I believe it does | 21:57 |
| vishy | anotherjesse: yeah | 21:57 |
| vishy | that is how we did it for voluems | 21:57 |
| anotherjesse | teams with open enrollment (or somethign else?) seems valuable | 21:58 |
| vishy | anotherjesse: ok | 21:58 |
| vishy | #action vishy to create subteams for mailing list communication | 21:58 |
| anotherjesse | vishy: melange integration into nova - ? is that an essex thing? | 21:58 |
| vishy | #info subteams will be open enrollment | 21:59 |
| vishy | #info each team will have a poc so that vishy has someone to bug | 21:59 |
| vishy | #info subteams are responsible for creating blueprints for needed work and helping vishy target them to specific milestones | 22:00 |
| vishy | #action vishy to go through the registered blueprints and accept them and assign them to the subteam. | 22:01 |
| *** medberry is now known as med_out | 22:01 | |
| vishy | #info subteam leader can reassign the blueprints to specific individuals or real teams to do the actual work | 22:01 |
| vishy | Ok guys, I don't want to make this too heavyweight | 22:01 |
| vishy | But there are way too many people working on the code for me to keep tabs on all of this at once, so I appreciate the help | 22:02 |
| vishy | I will create open launchpad groups for all of these teams so that they can communicate | 22:03 |
| vishy | i think there is already an operations team, so I might just use that one. Although I specifically want dev help for tool and admin api createion | 22:03 |
| vishy | Any other subteam that we're missing? | 22:03 |
| anotherjesse | melange? | 22:04 |
| anotherjesse | (integration) | 22:04 |
| salv-orlando | I think there is alread a melange team | 22:04 |
| salv-orlando | ah ok | 22:04 |
| vishy | #topic What do we do with melange | 22:05 |
| *** openstack changes topic to "What do we do with melange" | 22:05 | |
| vishy | lets take a minute and plan that | 22:05 |
| vishy | any input on melange? | 22:06 |
| anotherjesse | right now nova-network doesn't use it - if we integrate it then we should update nova-network? | 22:06 |
| anotherjesse | (melange=ipam) | 22:06 |
| vishy | anotherjesse: perhaps | 22:06 |
| jk0 | I think it has a long ways to go before it can merge into trunk | 22:07 |
| vishy | anotherjesse: why not just keep it separate | 22:07 |
| salv-orlando | in QuantumManager we allow users to either use traditional nova IPAM or Melange | 22:07 |
| vishy | anotherjesse: if the merge was an easy refactor inside was better | 22:07 |
| salv-orlando | we could do the same in Flat & VlanManager | 22:07 |
| jk0 | +1 on keeping it seprate | 22:07 |
| vishy | anotherjesse: just let melange support quantum | 22:07 |
| *** martine_ has quit IRC | 22:07 | |
| anotherjesse | has anyone investigated the level of effort to make nova-net use melange? | 22:07 |
| bhall_ | vishy: +1 | 22:07 |
| vishy | anotherjesse: no, but I'm worried about the two integration points | 22:08 |
| vishy | quantum is already integrating, so we save work by just using that integration | 22:08 |
| salv-orlando | vishy: +1 | 22:09 |
| anotherjesse | salv-orlando: my goal would be to kill the nova-ipam to make things simplier - instead of making both quantum and nova-net use both | 22:09 |
| anotherjesse | but I'm good with waiting - just want to make sure | 22:09 |
| vishy | are any of the key melange devs here? | 22:09 |
| vishy | anotherjesse: does quantum use both? | 22:10 |
| jk0 | they're mostly/all in India | 22:10 |
| salv-orlando | I know only Troy and Rajaram | 22:10 |
| bhall_ | vishy: it can, currently | 22:10 |
| bhall_ | (by quantum I'm asuming you mean quantummanager) | 22:10 |
| salv-orlando | just to be precise, quantummanager is nova-net manager for quantum | 22:11 |
| vishy | salv-orlando: so there is no integration in quantum itself? | 22:11 |
| *** HowardRoark has quit IRC | 22:11 | |
| bhall_ | vishy: that's correct | 22:11 |
| salv-orlando | vishy: no, we actually do it in nova-network! | 22:12 |
| vishy | anotherjesse: in that case it sounds like the integration is fairly easy | 22:12 |
| salv-orlando | I don't see it as a major hurdle. bhall_ might have more details | 22:12 |
| bhall_ | yeah, I don't think the integration would be that bad | 22:12 |
| vishy | bhall_: but you think it should be separate? | 22:13 |
| anotherjesse | vishy: it is a 10k line diff - just worry about it living in the edge too long and not getting attention | 22:13 |
| vishy | anotherjesse: does it need attention? | 22:13 |
| salv-orlando | (integrating, or replacing nova's IPAM as anotherjesse suggested) | 22:13 |
| anotherjesse | vishy: given that we haven't looked at it outside of the quantum use case … maybe? | 22:13 |
| vishy | anotherjesse: someone is going to have to spike this it sounds like | 22:14 |
| anotherjesse | i'm suggesting a spike - ya | 22:14 |
| *** zykes- has quit IRC | 22:14 | |
| pvo | we were just talking about this today | 22:14 |
| pvo | I think they're going to try to figureo ut how to break it apart | 22:14 |
| pvo | unknown if it can | 22:14 |
| vishy | ok who can spike it? | 22:15 |
| pvo | I think this is Trey or Koelker | 22:15 |
| vishy | tr3buchet might be a good choice | 22:15 |
| pvo | someone on my team | 22:15 |
| vishy | pvo can you have the two of them look at it and come up with a plan | 22:15 |
| vishy | considering a) our existing ip management sucks, what is the best path forward | 22:15 |
| pvo | #action will coordinate a plan to get the network diff broken up | 22:16 |
| vishy | pvo thx | 22:16 |
| vishy | ok anything else | 22:16 |
| anotherjesse | pvo: I feel that if we don't move to melange we will end up implementing most of the api in an os-extension | 22:16 |
| vishy | #topic open discussion | 22:16 |
| *** openstack changes topic to "open discussion" | 22:16 | |
| *** mattray has quit IRC | 22:16 | |
| comstud | so | 22:17 |
| comstud | reviews | 22:18 |
| comstud | I've been cracking down on HACKING violations when reviewing | 22:18 |
| anotherjesse | ++ | 22:18 |
| comstud | I dunno if this is the case or not... but it seems maybe there hasn't been a lot of attention paid to them | 22:18 |
| vishy | hopefully these teams will help with the reviews | 22:18 |
| comstud | Some of the stuff that annoys me in the code is general inconsistency | 22:18 |
| anotherjesse | comstud: be strict but helpful? | 22:19 |
| comstud | so I'm feeling like we could crack down a little more on that | 22:19 |
| comstud | haha | 22:19 |
| comstud | yeah | 22:19 |
| anotherjesse | I kinda want a termie bot again - for the simple stuff | 22:19 |
| vishy | there are a lot of cleanup related tasks needed that don't have blueprints | 22:19 |
| tr3buchet | true | 22:19 |
| jk0 | there's a lot of stuff that isn't covered in HACKING | 22:19 |
| salv-orlando | termie bot? | 22:19 |
| vishy | #idea jesse suggested dedicated a couple of milestones to stabilization and cleanup | 22:20 |
| salv-orlando | So it wasn't the real termie putting needs fixing for a missing linefeed on a docstring in my branch? | 22:20 |
| tr3buchet | we could probably dedicate a release to it | 22:20 |
| comstud | I hate making people fix little stuff like this.. for fear I'll come off like an asshole. :) But.. | 22:22 |
| comstud | That's the main complaint I hear when someone new goes to look at the code | 22:22 |
| comstud | A number of style differences... and then people not being sure which way they should do something | 22:22 |
| pvo | comstud: +++ | 22:22 |
| comstud | HACKING is pretty simple to follow.. there's clear instructions there. | 22:22 |
| vishy | maybe we need to add a link to hacking to how to contribute | 22:23 |
| vishy | and the gerrit instructions | 22:23 |
| sandywalsh | HACKING is good to enforce, sadly "pythonic" is much harder | 22:23 |
| jk0 | we can't really enforce something that isn't in HACKING. should we consider adding more to it? | 22:23 |
| comstud | sandywalsh: Yeah, that's the thing. | 22:23 |
| vishy | before typing git review: check HACKING, run tests, etc. | 22:23 |
| salv-orlando | or enforce something like the termiebot as we enforce pep8 | 22:24 |
| anotherjesse | anyone not think it is reasonable to mark a patch "plz don't merge - needs fixing" if it has consistency issues? | 22:24 |
| vishy | that is the point of code review, right? | 22:24 |
| comstud | one point of it | 22:24 |
| pvo | I think the question is which consistency | 22:24 |
| pvo | whose consistency | 22:24 |
| comstud | but 'consistency' right now doesn't mean a lot | 22:24 |
| comstud | yeah | 22:24 |
| tr3buchet | what else could be the point | 22:24 |
| jk0 | that's why I propose adding more things to HACKING | 22:25 |
| comstud | tr3buchet: obvious bugs that tests don't catch | 22:25 |
| anotherjesse | salv-orlando: termie bot was something justin-sb created to catch issues termie consistantly flagged | 22:25 |
| tr3buchet | right right | 22:25 |
| vishy | can someone add a set of instructions on running unit tests and code guidelines to the wiki | 22:25 |
| jk0 | indentations, single vs double quote usage, etc | 22:25 |
| tr3buchet | consistency can always come in the form of refactoring | 22:25 |
| bhall_ | vishy: in quantum we have a "TESTING" file that talks about that.. might be good to have one in nova, too | 22:25 |
| vishy | I'd like to see a nova contribution guidelines page | 22:26 |
| sandywalsh | well that brings up the issue of unit tests vs. integration tests in the core test suite (nearly everything is integration currently) | 22:26 |
| vishy | that we can link to from the gerrit instructions | 22:26 |
| tr3buchet | it would be lovely to pare that down to unittests only | 22:26 |
| vishy | sandywalsh: we need major unit test cleanup. That is one of the large sections that doesn't ahve blueprints | 22:26 |
| comstud | #agree | 22:26 |
| vishy | do we need a team for unit test cleanup? | 22:27 |
| jk0 | gotta admit, it was pretty nice back in the day when tests took less than a minute to run | 22:27 |
| vishy | jk0: ikr | 22:27 |
| tr3buchet | the good old days | 22:27 |
| vishy | does anyone care about testing cleanup enough to spearhead an effort on it? | 22:27 |
| sandywalsh | vishy, even if we could break it into smoke tests (pure unit tests) and "other" ... would be a great start | 22:27 |
| vishy | I know ntt is adding more and more tests | 22:28 |
| jk0 | I think that would eventually help coverage too | 22:28 |
| jk0 | I'm afraid these complex "unit" tests scare people away from writing new ones | 22:28 |
| comstud | vishy: Sooner rather than later would be good. | 22:28 |
| sandywalsh | don't we need to unify our integration test efforts? | 22:28 |
| comstud | vishy: I feel like I lose a lot of dev time with how long the tests take | 22:28 |
| vishy | sandywalsh: yes but there is a team focusing on that | 22:29 |
| sandywalsh | comstud, and people trying to understand the tests when something breaks | 22:29 |
| vishy | comstud: I've been trying to parallelize | 22:29 |
| comstud | vishy: yea | 22:29 |
| tr3buchet | comstud, jk0: you can run individual modules | 22:29 |
| comstud | tr3buchet: And I do | 22:29 |
| jk0 | well yeah | 22:29 |
| tr3buchet | oh even then | 22:29 |
| vishy | this seems like a big discussion | 22:29 |
| sandywalsh | devstack to parallelize running the tests :D | 22:29 |
| jk0 | but you still have to run the entire suite before proposing merge | 22:29 |
| comstud | tr3buchet: I run individual test cases sometimes as well.. | 22:29 |
| vishy | does anyone have a way forward on this? | 22:29 |
| tr3buchet | i usually only end up running the "big test" after i'm finished and the module tests pass | 22:30 |
| vishy | I'm pretty full with the blueprint and subteam stuff right now | 22:30 |
| tr3buchet | i think sandywalsh had a good point | 22:30 |
| comstud | right now.. i have something i'm working on.. | 22:30 |
| comstud | i'm not sure which tests will break exactly | 22:30 |
| comstud | i have a rough idea | 22:30 |
| vishy | so I don't have the brain power to come up with a plan here | 22:30 |
| tr3buchet | breaking the tests into unittests and other | 22:30 |
| comstud | so I run them all | 22:30 |
| comstud | wait fora breakage.. fix it by re-running the broken module | 22:30 |
| comstud | then re-run the whole test suite again | 22:30 |
| vishy | tr3buchet: do you want to lead that effort? | 22:30 |
| comstud | wait for the next breakage | 22:30 |
| comstud | repeat. | 22:30 |
| vishy | I'm happy for a test cleanup team to be formed | 22:31 |
| tr3buchet | vishy: if it comes down to it | 22:31 |
| vishy | ok i will create the team and add tr3buchet , comstud , sandywalsh to it | 22:31 |
| tr3buchet | vishy: sounds like i've got a good bit of work to do in the melange area | 22:31 |
| comstud | i nominate dprince.. because he seems to not be here | 22:31 |
| comstud | :) | 22:31 |
| tr3buchet | +1 | 22:31 |
| jk0 | I'd like to see bcwaldon on it too | 22:32 |
| vishy | perhaps titan can take the lead on that | 22:32 |
| jk0 | he seems to know his way around the tests | 22:32 |
| vishy | #action vishy to try to find a lead for testing cleanup team | 22:32 |
| comstud | i'm mostly serious about dprince, because he seems to have use passion for tests | 22:32 |
| comstud | use/huge | 22:32 |
| vishy | s1rp_: seems to care a lot too | 22:32 |
| tr3buchet | don't forget jaypipes | 22:33 |
| jk0 | agreed, s1rp_ and waldon come to mind when I think 'tests' | 22:33 |
| * comstud queues 'we care a lot' | 22:33 | |
| sandywalsh | I'm busier than a two-headed woodpecker ... don't know how valuable my contributions will be (from here) | 22:33 |
| vishy | there is already a qa team | 22:33 |
| tr3buchet | yea that's my thought too sandywalsh | 22:33 |
| vishy | sandywalsh: I'm going to be on all of these teams, so yay me | 22:33 |
| sandywalsh | heh | 22:33 |
| sandywalsh | vishy, that's your lot in life though | 22:33 |
| tr3buchet | hey you let them talk you into being the king of openstack | 22:33 |
| vishy | tr3buchet: :( | 22:34 |
| vishy | sigh | 22:34 |
| vishy | ok i will create these teams | 22:34 |
| vishy | and we will see how things shake out over the next week | 22:34 |
| tr3buchet | are we going to have blueprints? | 22:34 |
| vishy | time to finish this meeting | 22:34 |
| vishy | #endmeeting | 22:34 |
| *** openstack changes topic to "Openstack Meetings: http://wiki.openstack.org/Meetings | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/" | 22:34 | |
| openstack | Meeting ended Thu Oct 13 22:34:44 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 22:34 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-13-21.00.html | 22:34 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-13-21.00.txt | 22:34 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/openstack-meeting/2011/openstack-meeting.2011-10-13-21.00.log.html | 22:34 |
| vishy | tr3buchet what do you mean? | 22:34 |
| tr3buchet | for the test changes | 22:35 |
| pvo | thanks Vish. | 22:35 |
| comstud | thanks Vish | 22:35 |
| PhilDay | Thanks Vish | 22:35 |
| tr3buchet | what's happening right now | 22:35 |
| vishy | yw guys | 22:35 |
| sandywalsh | thanks vishy ! | 22:35 |
| vishy | i will summarize on mailing list | 22:36 |
| vishy | I will assign all the blueprints i can to teams | 22:36 |
| vishy | any that don't fit i will manage | 22:36 |
| *** PhilDay has quit IRC | 22:36 | |
| vishy | subteams add blueprints that don't exist yet | 22:36 |
| vishy | (for upgrades for example) | 22:36 |
| comstud | s/manage/make tr3buchet do/ | 22:36 |
| tr3buchet | oh yes, by all means | 22:37 |
| comstud | i know your boss | 22:37 |
| comstud | i can make it happen. | 22:37 |
| tr3buchet | i'm bigger than him | 22:38 |
| jk0 | lol | 22:38 |
| comstud | taller, anyway | 22:38 |
| tr3buchet | actually.. we're both bigger than you | 22:38 |
| comstud | but that's not difficult | 22:38 |
| *** jdg has quit IRC | 22:39 | |
| *** jdg has joined #openstack-meeting | 22:39 | |
| *** NeilJohnston has quit IRC | 22:39 | |
| *** masumotok has quit IRC | 22:39 | |
| *** rjh has quit IRC | 22:39 | |
| *** jk0 has left #openstack-meeting | 22:40 | |
| *** mikeyp-3 has quit IRC | 22:42 | |
| *** primeministerp1 has quit IRC | 23:12 | |
| *** dragondm has quit IRC | 23:16 | |
| *** joonwon has joined #openstack-meeting | 23:29 | |
| *** joonwon has quit IRC | 23:51 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!