16:02:30 <schwicke> #startmeeting hierarchical_multitenancy\
16:02:31 <openstack> Meeting started Fri Sep 19 16:02:30 2014 UTC and is due to finish in 60 minutes.  The chair is schwicke. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:32 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:34 <openstack> The meeting name has been set to 'hierarchical_multitenancy_'
16:02:52 <schwicke> welcome everybody!
16:03:13 <schwicke> Thiago dropped me a mail that he can't make it today
16:03:34 <schwicke> I have a few items on the radar for today
16:03:38 <Nirbhay> Hi
16:03:44 <sajeesh> hi nirbhay
16:03:46 <schwicke> Hi, Nribhay
16:03:48 <Nirbhay> hi sajeesh
16:03:58 <Nirbhay> hi schwicke
16:04:10 <schwicke> #topic hierarchial projects quota code testing
16:04:35 <schwicke> first thing I'd like to clarify: there was some discussion about unit tests.
16:04:48 <schwicke> what is the status of them ?
16:05:11 <sajeesh> you mean horizon ?
16:05:18 <sajeesh> thiago's code
16:05:47 <schwicke> do we have all unit tests for the quota code ?
16:06:09 <sajeesh> schwicke,I am testing it and have corrected some bugs
16:06:40 <schwicke> sajeesh: testing the quota code in the VM ?
16:06:44 <sajeesh> will upload the patches tomorrow
16:06:49 <schwicke> great!
16:06:50 <sajeesh> yes
16:06:55 <schwicke> what needs to be changed ?
16:06:55 <sajeesh> yes in the VM
16:07:16 <sajeesh> no some bug correction only
16:07:21 <schwicke> ok
16:07:36 <schwicke> so that should be fine then ?
16:07:48 <sajeesh> Now I will add raildo's code and will do the complete testing
16:08:34 <schwicke> ok
16:09:27 <sajeesh> it should be over by this week
16:09:35 <schwicke> #info few bugs identifed in the quote code identfied
16:09:58 <schwicke> #action: Sajeesh will push the required patches
16:10:21 <sajeesh> regarding horizon,I have asked Thiago for the VM
16:10:29 <schwicke> yes, me too :)
16:10:49 <schwicke> I'd like to continue for a minute with the nova stuff though
16:10:54 <sajeesh> sure
16:11:02 <schwicke> last meeting we had a question about the client code
16:11:07 <sajeesh> yes
16:11:16 <schwicke> #topic nova client code : any required updates ?
16:11:38 <schwicke> so my understanding is that it should work without change for the API but there are some worries about keystone V3
16:11:54 <sajeesh> exactly
16:12:02 <schwicke> I had a chat today with Tim Bell on this
16:12:06 <sajeesh> ok
16:12:22 <schwicke> he pointed out that it might be actually better not to focus on python-novaclient
16:12:39 <schwicke> but rather to go for the unified interface (python-openstack I think)
16:13:00 <sajeesh> python-openstack ?
16:13:26 <schwicke> He told me that they plan to deploy that here at CERN. It comes with a plugin already to support stuff like kerberos etc etc
16:13:33 <sajeesh> ok
16:13:33 <schwicke> and has keystone v3 support.
16:13:37 <sajeesh> ok
16:13:40 <Nirbhay> python-nova-client
16:13:50 <schwicke> raildo: do you know it ?
16:14:55 <sajeesh> I think raildo is not available now
16:15:29 <schwicke> #link https://github.com/openstack/python-openstackclient
16:16:14 <sajeesh> ok
16:16:33 <schwicke> The cern patched version is actually here:
16:16:38 <schwicke> #link https://github.com/cernops/python-openstackclient
16:16:41 <sajeesh> ok
16:17:36 <schwicke> certainly worth testing I think
16:17:38 <schwicke> comments ?
16:18:00 <sajeesh> schwicke..I will check it
16:18:03 <Nirbhay> yes we need to provide keystone v3
16:20:33 <schwicke> #action sajeesh will check nova-openstackclient after finishing the current testing and bug fixes
16:21:30 <schwicke> sajeesh: if you need help we should discuss how we can distribute the load internally
16:21:56 <schwicke> let's switch topic
16:21:56 <sajeesh> schwicke....thanks ..we can discuss
16:22:41 <schwicke> #topic horizon
16:23:14 <schwicke> Thiago offered to make a VM available for testing
16:23:29 <schwicke> I think I can best contribute by giving feedback on the look and feel
16:23:41 <schwicke> It would be great to have such a thing
16:24:00 <sajeesh> true
16:24:56 <schwicke> not sure how to get secure access to the gui though.
16:25:29 <sajeesh> we have to see that
16:26:00 <sajeesh> in cern we access via socks proxy ..right ?
16:26:27 <schwicke> hmm ...
16:26:47 <schwicke> maybe ssh with X11 forwarding + a browser on the VM would work as well ?
16:27:10 <schwicke> then open the interface to localhost only - up to Thiago really
16:27:39 <schwicke> #action it would be nice if Thiago could create a VM with the horizon patches installed
16:28:39 <schwicke> I think we need to follow up by e-mail with Thiago (and Raildo)
16:28:44 <sajeesh> ok
16:29:31 <schwicke> Raildo: are you available ? Do you want to comment ?
16:29:32 <sajeesh> Hi Vinod...I think Nirupma too  had joined
16:30:21 <schwicke> Vinod: hi
16:30:23 <Nirbhay> hi vinod
16:30:36 <schwicke> niru-pma: hi!
16:30:46 <niru-pma> hi
16:30:47 <sajeesh> hi nirupma
16:31:17 <schwicke> I think Raildo is busy
16:31:20 <VINOD_> schwicke, Nirbhay, sajeesh: hi
16:31:25 <VINOD_> sorry for late joinging
16:31:31 <schwicke> no problem
16:31:35 <sajeesh> yes
16:32:09 <schwicke> Sajeesh: can you coordiate a bit with Nirupma to share the load ?
16:32:21 <sajeesh> ok...I will do
16:32:51 <schwicke> #action Sajeesh to coordinate with Nirpma to share the load
16:32:57 <niru-pma> iokies
16:32:59 <sajeesh> schwicke..in what area you are expecting nirupma to work ..horizon ?
16:33:37 <schwicke> code review and testing on horizon would be useful I think
16:33:55 <sajeesh> yes
16:33:56 <schwicke> so that you can focus on finalizing the quota stuff
16:34:10 <sajeesh> yes
16:34:36 <schwicke> I'm not sure how useful I am in reviewing the code itself.
16:35:48 <schwicke> There was quite a bit of traffic and work done by Thiago so I think it is a good time to start the review
16:36:00 <sajeesh> yes
16:36:23 <VINOD_> I am waiting for the sajeesh to give a VM with quota code integrated with raildo's keystone code. As soon as he gives me access, i will also test all the quota APIs
16:36:46 <schwicke> Vinod: excellent!
16:36:53 <sajeesh> Vinod,I will give you soon
16:37:11 <VINOD_> Sajeesh: Thanks
16:37:21 <schwicke> #action Vinod will help testing the quota code as soon as raildos keystone patches are integrated
16:37:33 <schwicke> I think we have a plan
16:37:38 <sajeesh> yes
16:37:53 <schwicke> I have one more item on the agenda to be discussed
16:38:03 <schwicke> unless there is anything else on the previous topic
16:38:22 <sajeesh> schwicke,plz proceed
16:38:26 <schwicke> Raildo posted the etherpad link last week
16:38:31 <sajeesh> ok
16:38:52 <schwicke> #topic eitherpad on cross project topics
16:39:02 <schwicke> #link https://etherpad.openstack.org/p/kilo-crossproject-summit-topics
16:39:23 <schwicke> quite a bit of updates since Wednesday when we have added the two points on hierarchical projects
16:40:43 <schwicke> for the hierarchal projects I think it looks good so far
16:41:06 <sajeesh> ok
16:41:48 <schwicke> nothing else from my side
16:42:02 <sajeesh> schwicke....what about nova v3 complete migration ...or is it v3 or v2.1..do we need to discuss
16:42:08 <sajeesh> that in the summit
16:42:16 <VINOD_> The one thing that needs to adopted in quota code, when the feature of recursive deletion and change of parent in hierarchical projects is availabile in keystone
16:42:33 <schwicke> yes, there is an item on the etherpad on this already
16:42:38 <sajeesh> yes
16:43:40 <schwicke> maybe that should be added
16:43:42 <sajeesh> vinod,I think recurisive deletion doesn't have any effect on the quota code
16:44:29 <schwicke> with the exception of possible race conditions.
16:44:31 <VINOD_> Sajeesh: It will have an effect..The nova should be able to catch the notification sent by keystone and clear the quota data stored for the projects that have been deleted
16:44:35 <sajeesh> sure
16:45:00 <VINOD_> any way, i think we can wait till the notification feature gets evolved...
16:45:05 <sajeesh> vinod,notification is a different thing
16:46:24 <sajeesh> what I mean is that the nested quota driver will not be bother if it is recursive or non recursive
16:46:34 <schwicke> I've added a sub-bullet: impact for h
16:46:47 <sajeesh> anyway ,I will cross check it
16:46:51 <VINOD_> Sajeesh: Its same. The nova can come to know (Infact any other service) the changes in the project hierarchy through notification from Keystone
16:47:00 <schwicke> I think that is really a topic for the summit
16:47:34 <VINOD_> sajeesh: I mean when the notification comes to nova, in the nova notification procedure the quota cleaning also has to be there (but as i said, we can wait till this concept evolves)
16:47:40 <schwicke> the important bit is that this is discussed at the summit
16:48:10 <sajeesh> vinod,we can wait for the notification
16:48:32 <schwicke> I'm a bit worried about the other point: change the hierarchy
16:48:33 <sajeesh> that is really important
16:48:40 <schwicke> the question is what that means
16:48:43 <sajeesh> means ..parent ?
16:49:06 <VINOD_> schwicke: I think it means that a subset of hierarchy is moved from one parent to another parent
16:49:28 <schwicke> Vinod: that is my understanding as well
16:49:30 <sajeesh> yes
16:49:49 <sajeesh> schwicke, any issue with that ?
16:49:53 <schwicke> IMO if quota don't match then there should be a way to veto such a change
16:50:30 <schwicke> sajeesh: yes, it could be that the quota of the new parent is not sufficient in which case a move would have a funny impact
16:50:31 <sajeesh> schwicke,these all things should be taken care well in the notification  part
16:50:39 <VINOD_> schwicke: I think the notifications may not be synchronous as it may cause so much delay
16:50:58 <sajeesh> ++1,there should be veto if quota doesn't match
16:51:16 <schwicke> will add a sub-bullet
16:51:22 <sajeesh> good
16:52:12 <schwicke> done
16:52:25 <sajeesh> schwicke....do we need to add about complete migration of nova v2
16:52:58 <schwicke> you mean nova api version 2?
16:53:06 <VINOD_> I think the notifications subject is not a small one. I guess first the notifications have to be divided into different types and each service may be notified and then the service does some thing with that particular notification..
16:53:40 <sajeesh> schwicke ...according to Belmiro will be v2 ro v2.1 or v3
16:53:44 <schwicke> vinod: I agree
16:54:13 <schwicke> sajeesh: do we need this really ? I don't think it is terribly important, is it ?
16:54:30 <VINOD_> and i guess these notifications may be asynchronous (to avoid the delay notifying all the services and waiting for their reply) and all the services apply a fail safe method..
16:54:35 <sajeesh> don't know ?
16:55:34 <schwicke> vinod: yes, certainly.
16:55:43 <sajeesh> vinod,what do you think about nova api call migration?
16:56:35 <VINOD_> sajeesh: I think its still long way to go to migrate to v3 for nova...and i don't find any conversation happening in doing this.
16:56:40 <sajeesh> it is not urgent...right ?
16:56:46 <VINOD_> its just adopting keystone v3 in all the services
16:57:04 <sajeesh> ok
16:57:07 <schwicke> there is one bullet already on consistent API microversioning
16:57:29 <schwicke> I think this should cover this question.
16:57:37 <sajeesh> I think so
16:57:46 <schwicke> time is over :(
16:57:51 <sajeesh> ok
16:58:11 <schwicke> let's follow up via e-mail on the action items
16:58:19 <sajeesh> ok
16:58:21 <VINOD_> schwicke: ok
16:58:23 <schwicke> and re-meet next week on Friday again
16:58:27 <sajeesh> ok
16:58:29 <Nirbhay> ok
16:58:47 <schwicke> #endmeeting