20:00:06 <robcresswell> #startmeeting horizondrivers
20:00:08 <openstack> Meeting started Wed Jan  6 20:00:06 2016 UTC and is due to finish in 60 minutes.  The chair is robcresswell. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:11 <openstack> The meeting name has been set to 'horizondrivers'
20:00:23 <robcresswell> o/
20:01:01 <r1chardj0n3s> o/
20:01:07 <r1chardj0n3s> my first one as a Driver
20:01:56 <robcresswell> I'll give it a minute see if more people drift in
20:02:21 <mrunge> o/
20:02:34 <piet> o/
20:03:03 <robcresswell> #link https://wiki.openstack.org/wiki/Meetings/HorizonDrivers#Agenda_for_2015-01-06_2000_UTC Agenda for today
20:04:21 <robcresswell> I won't repeat the notices from earlier (saves more time for blueprints)
20:04:31 <r1chardj0n3s> oic, there's homework for these meetings :-)
20:04:35 <robcresswell> But if you haven't checked the logs, here you go http://eavesdrop.openstack.org/meetings/horizon/2016/
20:04:49 <robcresswell> There's a few things, like the midcycle, that were spoken about.
20:04:57 <robcresswell> Now down to work!
20:05:00 <mrunge> robcresswell, you forgot the note on checking tests
20:05:02 <tsufiev> o/
20:05:24 <mrunge> since tests seem to be broken somehow, at least some failures are tolerated
20:05:37 <robcresswell> Sure
20:05:39 <mrunge> reviewers, please be careful and run tests yourself
20:05:49 <robcresswell> I was going to just let people read the logs to save time :p
20:06:14 <robcresswell> In short, tests don't always fail due to errors, so its worth looking at test logs or running them yourselves even if Jenkins says they pass.
20:06:29 <mrunge> robcresswell, we didn't had that in earlier meeting
20:06:32 <mrunge> iirc
20:06:36 <r1chardj0n3s> we did
20:06:44 <r1chardj0n3s> robcresswell did bring it up
20:06:47 <robcresswell> I think I mentioned it before you joined perhaps
20:06:50 <mrunge> oh :-O
20:06:59 <mrunge> maybe yes.
20:07:07 <mrunge> just prved I did not read the logs
20:07:08 <robcresswell> Is your minion around? itxaka?
20:07:18 <robcresswell> seems not
20:07:32 <robcresswell> #topic Allow launching an instance with ports attached
20:07:39 <mrunge> he should, but is not :(
20:07:44 <robcresswell> #link https://blueprints.launchpad.net/horizon/+spec/allow-launching-ports
20:08:54 <robcresswell> I rather like this change. Seems straightforward.
20:09:09 <r1chardj0n3s> that spec could use a link to supporting documentation :/
20:09:12 <mrunge> there is this reature named SR-IOV
20:09:20 <mrunge> and this is a prerequisite
20:09:31 <robcresswell> Ah
20:09:40 <mrunge> some network guys really like this feature, but we don't support it yet
20:10:35 <r1chardj0n3s> we ran into issues with the SR-IOV patch IIRC because we can't query for whether it's supported
20:10:47 <r1chardj0n3s> but that's a distraction from this bp
20:10:50 <robcresswell> r1chardj0n3s: Agreed on needing more info
20:11:11 <robcresswell> But I think not worth blocking over. Approve, and leave comment asking for links to docs?
20:11:21 <r1chardj0n3s> sounds good to me
20:11:29 <tsufiev> +1
20:11:35 <mrunge> I'm obviously biased here...
20:11:41 <mrunge> not voting
20:11:52 <tsufiev> if it cannot be done, we could just change it to Needs Infrastructure, couldn�t we?
20:11:56 <mrunge> but yes, +1 for requesting more docs
20:12:16 <r1chardj0n3s> +1
20:12:19 <r1chardj0n3s> just to be clear
20:13:23 <robcresswell> #info https://blueprints.launchpad.net/horizon/+spec/allow-launching-ports Approved (but needs a little extra detail on blueprint)
20:13:56 <robcresswell> #topic Allow add/delete networks ports as a tenant
20:14:06 <robcresswell> #link https://blueprints.launchpad.net/horizon/+spec/network-ports-tenant
20:14:51 <tsufiev> I was intially against the idea because I saw no real value - but perhaps I was wrong
20:14:57 <ducttape_> robcresswell - so default neutron policy file allows this then ?
20:15:51 <tsufiev> ducttape_, https://github.com/openstack/horizon/blob/master/openstack_dashboard/conf/neutron_policy.json#L43
20:16:02 <mrunge> why don't we allow this, if policy allows this?
20:16:03 <tsufiev> seems that �create_port� is allowed
20:16:10 <robcresswell> Wait, am I supposed to have memorised neutrons policy files?
20:16:12 <tsufiev> but many other operations are not
20:16:21 <tsufiev> robcresswell, ^^^
20:16:54 <ducttape_> yeah, I think this was not done just because this is not a likely thing most _member_ users would utilize
20:17:07 <tsufiev> I�d like to hear feedback from neutron-oriented people
20:17:26 <robcresswell> If default policy allows it, it seems we should follow that. At least, there is no reason to block it if the change is written for us to use.
20:17:42 <ducttape_> what is the use case for creating a port without the other side (like a vm) ?
20:17:57 * mrunge got the impression, this is another part required for SR-IOV
20:18:27 <tsufiev> iirc, itxaka initial proposal was to enable port creation for regular users - to later use during vm launch
20:18:38 <robcresswell> Ideally I'd ask the blueprint owner, but they aren't here.
20:18:46 <tsufiev> instead I suggested to specify a port right during vm launc
20:18:53 <tsufiev> to provide better UX
20:19:07 <tsufiev> (since the primary use case for port creation is to use for vm)
20:19:09 <robcresswell> I think, leave a comment asking for more info, and leave to next meeting?
20:19:15 <ducttape_> deal
20:19:18 <tsufiev> +1
20:19:21 <mrunge> yepp, +1
20:19:57 <r1chardj0n3s> sounds good +1
20:20:03 <mrunge> and even if it's denied by default policy, we don't even have the action for a normal user
20:20:16 <mrunge> if it's being enabled in policy
20:20:41 <mrunge> we should take policy into account. if it's allowed: fine.
20:20:42 <robcresswell> #info https://blueprints.launchpad.net/horizon/+spec/network-ports-tenant Left comment asking for more info, put to side for now
20:21:10 <robcresswell> #topic Configurable Instance Boot Source list for launch instance
20:21:18 <robcresswell> #link https://blueprints.launchpad.net/horizon/+spec/configurable-boot-sources
20:22:15 <mrunge> this is a end user request: be able to restrict boot sources to a limited selection
20:22:34 <mrunge> like preventing to boot from an image, or from volumes
20:22:48 <ducttape_> or a set of images / volumes ?
20:22:49 <itxaka> o/
20:22:57 <itxaka> sorry Im a bit late :(
20:23:00 <robcresswell> Ah
20:23:03 <robcresswell> No problem
20:23:06 <mrunge> itxaka, good to have you here
20:23:13 <robcresswell> we'll circle back to the previous BP if there is time at the end
20:23:26 <robcresswell> Currently on the third agenda item
20:23:26 <itxaka> Good :)
20:23:28 <mrunge> that's my question robcresswell ....
20:23:38 <mrunge> https://blueprints.launchpad.net/horizon/+spec/configurable-boot-sources  <- that is
20:23:50 <ducttape_> so mrunge - would this be a list of images or volumes, like a subset ?
20:24:12 <itxaka> This would actually be the source for boot, it being images or volumes or snapshots
20:24:18 <tsufiev> ducttape_, should we encourage hardcoding :/?
20:24:19 <mrunge> ducttape_, not in this implementation
20:24:21 <robcresswell> I think its just the options, not as deep as specific choices
20:24:37 <ducttape_> ah ok, thanks for clarification
20:24:41 <itxaka> yeah, only the source as a generic option rather than going deeper than that
20:24:42 <mrunge> we shouldn't list image ids (or so) to prevent booting from them
20:25:13 <mrunge> and for images, there is the bootable flag
20:25:30 <ducttape_> that bp sounds simple / reasonable
20:25:31 <mrunge> but that is not useful to prevent booting from images in general
20:25:59 <robcresswell> This seems sensible. I'm unaware if there are any conflicting options already available.
20:26:31 <robcresswell> +1 from me, anyway
20:26:40 <r1chardj0n3s> I just had a look to see whether nova already had a facility for configuring boot types, and couldn't see anything
20:26:45 <r1chardj0n3s> so +1
20:27:03 <r1chardj0n3s> (it seems a shame we're coding this into our side)
20:27:05 <robcresswell> r1chardj0n3s: two steps ahead of me
20:27:15 <robcresswell> Yeah, I agree, but its a useful option
20:27:24 <tsufiev> +1
20:27:45 <ducttape_> deployers should realize that this does not prevent the cli from working around this
20:27:50 <tsufiev> r1chardj0n3s, that�s not the first instance of doing things on our side :)
20:27:58 <robcresswell> btw I'd prefer something like INSTANCE_SOURCE_OPTIONS than openstack source boot, that sounds too vague
20:28:06 <robcresswell> If its specific to launching instances.
20:28:21 <r1chardj0n3s> tsufiev: yep, but I also know what some people default to configuring on Horizon side when the service has a setting we should be using
20:28:38 <r1chardj0n3s> s/what/that
20:28:43 <mrunge> robcresswell, sounds sensible
20:29:06 <robcresswell> #info https://blueprints.launchpad.net/horizon/+spec/configurable-boot-sources Approved
20:29:20 <robcresswell> #topic Performance & convenience improvements to integration tests, part1
20:29:29 <robcresswell> #link https://blueprints.launchpad.net/horizon/+spec/integration-tests-improvements-part1
20:29:29 <tsufiev> r1chardj0n3s, that�s a shame. Shame for documentation team, of course :)
20:29:51 <tsufiev> so, it�s as simple as it is
20:30:20 <tsufiev> make integration tests faster (will be more important as number of tests raises), make the internals saner
20:30:42 <hurgleburgler> that'd be nice :)
20:30:46 <tsufiev> I chose �part1� suffix because there possibly will be other parts to
20:30:50 <tsufiev> *to it
20:31:10 <robcresswell> something something premature optimisation :p
20:31:19 <r1chardj0n3s> ^^ ;-)
20:31:20 <mrunge> tsufiev, any chance to stretch that over several releases?
20:31:27 <tsufiev> I think current list of patches https://review.openstack.org/#/q/topic:bp/integration-tests-improvements-part1 is now final, there won�t be more for part1
20:31:40 <mrunge> it might be the case we're not done with mitaka release
20:31:56 <robcresswell> I don't disagree with the effort, but in the opening paragraph you mention that most of the time is spent on devstack, not the tests
20:32:08 <robcresswell> But hey, good patterns are useful.
20:32:34 <robcresswell> I just wouldn't recommend chasing performance too much over more tests :)
20:32:46 <tsufiev> robcresswell, the reason I did it so early is because refactoring becomes more expensive at time passes
20:32:54 <robcresswell> tsufiev: Yep, understood
20:33:00 <tsufiev> especially with horizon plugins building integration tests on it
20:33:19 <mrunge> any chance to make integrations tests being run in parallel?
20:33:41 <tsufiev> mrunge, haven�t investigated yet it on my own
20:33:56 <robcresswell> I'm fine with the blueprint itself.
20:34:05 <tsufiev> but that I would call premature optimization :)
20:34:09 <mrunge> not sure if that's really feasible
20:34:19 <tsufiev> mrunge, I�m afraid it could them less reliable
20:34:24 <mrunge> yes, +1 from my side
20:34:25 <tsufiev> could do*
20:34:39 <robcresswell> r1chardj0n3s, itxaka, hurgleburgler ?
20:34:51 <r1chardj0n3s> +1
20:34:52 <itxaka> +1 from me, any test improvements are always welcome
20:35:06 <mrunge> tsufiev, yes. I thought about relying on earlier states during test execution.
20:35:13 <robcresswell> #info https://blueprints.launchpad.net/horizon/+spec/integration-tests-improvements-part1 Approved
20:35:24 <robcresswell> #topic Enhance the use of tox
20:35:31 <robcresswell> #link https://blueprints.launchpad.net/horizon/+spec/enhance-tox
20:35:36 <itxaka> yay
20:35:48 <itxaka> basically, lets use tox as its supposed to be used
20:35:57 <itxaka> and try to deprecate run_tests.sh
20:36:07 <itxaka> like any other openstack project :D
20:36:14 <tsufiev> \o/
20:36:21 <hurgleburgler> +1
20:36:25 <mrunge> iirc, horizon is the only (larger) openstack project, which uses something else other than tox
20:36:33 <robcresswell> Yup
20:36:33 <tsufiev> sounds very nice, I wonder what was the reason to use it in the first time
20:36:37 <mrunge> I mean, we have our own script
20:36:43 <robcresswell> I even recommend the plugins to use it
20:37:02 <ducttape_> so we would eliminate run_tests.sh altogether, or just it's support for running tests / pep8 / etc ?
20:37:05 <itxaka> robcresswell, you recomend tox or run_tests?
20:37:12 <robcresswell> itxaka: tox
20:37:27 <mrunge> ducttape_, at the end, we should be removing run_tests
20:37:29 <itxaka> ducttape_, for the moment it replaces run_tests
20:37:43 <itxaka> but I didnt remove run_tests
20:37:53 <robcresswell> There's more external work involved in removing run tests
20:37:59 <robcresswell> translations depends on it, for a start
20:38:00 <itxaka> as it requires updating docs, maybe some infra changes?
20:38:18 <itxaka> robcresswell, yep, thats my point
20:38:23 <mrunge> sure
20:38:30 <mrunge> but we could add a warning
20:38:31 <itxaka> unfortunately I still dont have enough visibility on what could be affected :S
20:38:39 <mrunge> just to see, where the warning will show up
20:38:46 <ducttape_> how do you run a django dev server with tox?  /me looks into our tox options
20:38:54 <mrunge> like: run_tests is being deprecated
20:39:21 <tsufiev> ducttape_, btw, why do we need tox or run_tests to run dev server?
20:39:22 <mrunge> ducttape_, line 169 in the review
20:39:26 <itxaka> tox -e runserver
20:39:27 <itxaka> :D
20:39:44 <robcresswell> Or just whatever the actual command is... manage.py runserver?
20:39:48 <tsufiev> ducttape_, is �tools/with_venv.sh ./manage.py runserver� not enough?
20:39:57 <tsufiev> yep)
20:39:59 <itxaka> yeah but you need a .venv for runniing that directly
20:40:12 <itxaka> why not use tox as it sets everything for you :D
20:40:20 <ducttape_> yeah thats all fine / good.  thanks for the points.  (I'm stuck in my ways)
20:40:21 <robcresswell> I'm always in a venv :D
20:40:24 * mrunge is running the server without venv
20:40:29 <tsufiev> itxaka, because with tox you cannot alter dependenices easily
20:40:30 <mrunge> I mean devserver
20:40:35 <tsufiev> for example, django_openstack_auth
20:40:54 <robcresswell> tsufiev: ?
20:41:23 <itxaka> oh, but you can, exactly like with venv tsufiev
20:41:29 <tsufiev> robcresswell, ah, nevermind, on a second thought tox and install_venv are equally bad )
20:41:30 <mrunge> tsufiev, do you mean, you want to use a git checkout of doa and another one of horizon?
20:41:32 <woodm19791> It would be trivially easy and somewhat nice to add a tiny "run_sev_server.sh" script.  I think people would likely appreciate that.  Even it it's effectively an alias to ./manage.py runserver
20:42:03 <woodm19791> run_dev_server.sh *
20:42:46 <tsufiev> mrunge, sorry, I was mixed my own experience with install_venv specifics. I personally run both in pycharm and need to uninstall DOA each time I add it to PyCharm env
20:43:01 <tsufiev> so tox doesn�t make it any worse
20:43:16 <mrunge> tsufiev, ah, got you.
20:43:32 <robcresswell> So, vote time.
20:43:40 <robcresswell> +1
20:43:41 <ducttape_> tox is fine / wfm
20:43:43 <tsufiev> +1
20:43:45 <mrunge> +1
20:43:45 <hurgleburgler> +1
20:43:53 <r1chardj0n3s> +1
20:44:14 <mrunge> btw, it's only a single patch to play with: https://review.openstack.org/#/c/259013/
20:44:32 <tsufiev> and don�t forget to read all the logs ;)
20:45:01 <mrunge> while playing with tox, you'll immediately see the logs
20:45:22 <robcresswell> #info https://blueprints.launchpad.net/horizon/+spec/enhance-tox Approved
20:45:29 <mrunge> robcresswell, time to get back to https://blueprints.launchpad.net/horizon/+spec/network-ports-tenant ?
20:45:37 <robcresswell> Lets loop back round to itxaka other patch
20:45:38 <robcresswell> yes
20:45:40 <tsufiev> mrunge, unless you go away to fetch some coffee while it�s warming up :)
20:45:42 <robcresswell> give me a moment :p
20:45:50 <ducttape_> ./run_test.sh   ->  echo "you really want to use tox -e foo"   ;)
20:46:12 <robcresswell> #topic Back to "Allow add/delete networks ports as a tenant"
20:46:21 <robcresswell> #link https://blueprints.launchpad.net/horizon/+spec/network-ports-tenant
20:46:27 <mrunge> tsufiev, lol
20:46:49 <itxaka> yay o/
20:46:54 <robcresswell> itxaka: So, policy allows this. The question earlier was what's the use case
20:47:13 <itxaka> the reasoning for that is we are virtually not allowing users to create their own ports while they can do it trougth the cli
20:47:16 <robcresswell> and what effort is this building toward; mrunge mentioned sriov
20:47:29 <itxaka> plus it links with https://blueprints.launchpad.net/horizon/+spec/allow-launching-ports
20:47:37 <ducttape_> why is this more useful than just having the port automatically created ?
20:47:57 <itxaka> yeah basically if as an user I want to launch an instance with a port attached, I need an admin to add ports to a network that I created
20:48:11 <ducttape_> or to use the cli, yes
20:48:18 <itxaka> why not allow users to set up their own ports as with the cli
20:48:29 <itxaka> so they can add ports and then launch an instance attached to those ports
20:48:30 <itxaka> :)
20:48:31 <ducttape_> I'm just not sure what the use case where a user cares about the port is
20:48:57 <robcresswell> I don't see much of an issue with Horizon adding the option and letting it be controlled by policy
20:49:02 <ducttape_> would it be something related to getting the same ip reused?
20:49:46 <itxaka> ducttape_, no idea about that tbh
20:50:24 <itxaka> but I know that adding the port options to be created by the user is not a really big change (99% of the code is the admin one)
20:50:54 <itxaka> but it allows for advanced configuration to be used afterwards on instance launch
20:51:06 <ducttape_> It's ok, I don't object to this.... but it's like adding lower level network buttons and actions just because we can.   Not sure if this is more useful or confusing
20:51:29 <itxaka> and by advanced configuration, I mean selecting ports which could be using SR-IOV for example
20:51:39 <ducttape_> the few people that will create ports ahead of time, are probably not spending much time in horizon ;)
20:51:40 <itxaka> not sure if its just because we can
20:51:58 <itxaka> shouldnt we respect that if a user expects to do x in the cli he can do the same trougth GUI?
20:52:17 <itxaka> hopefully, more easily than trougth cli?
20:52:18 <robcresswell> I think in this case it's not really Horizons job to decide that though. The action can be blocked just as easily with a rule change.
20:52:36 <ducttape_> perhaps, but there is a usability concern in not confusing or overwhelming the users too
20:52:48 <tsufiev> ducttape_, +1
20:52:58 <mrunge> but you could change the policy
20:53:10 <mrunge> and policy should block that one then
20:53:14 <robcresswell> True, but I don;t think one table action is really overwhelming users, and if the company has a concern, they can just block it with policy
20:53:34 <robcresswell> I mean, its not like we just sat them down in front of transfer tables for the first time
20:53:36 <ducttape_> but I might have lots of cli low level options I want technically possible, but I don't want 100% of them in the UI
20:53:37 * robcresswell ducks
20:54:19 <robcresswell> Anyone else for/against?
20:54:46 <r1chardj0n3s> it seems like there's a need, even though there's potential UI complexity issues, so I'm happy to +1
20:54:48 <ducttape_> I'm not against btw.  Not really for either.  Is "meh" an option ?
20:54:59 <mrunge> itxaka, is that required for any of the other blueprints?
20:55:02 <r1chardj0n3s> ducttape_: +0 I believe :-)
20:55:03 * tsufiev abstains
20:55:04 <itxaka> I do thinks ports are an important part of openstack, after reading more and more about them :)
20:55:04 <r1chardj0n3s> or -0
20:55:12 <mrunge> if that's a blocker....
20:55:17 <robcresswell> ha
20:55:22 <robcresswell> I think approve it
20:55:28 <ducttape_> itxaka - would delete port be an option then too ?
20:55:40 <itxaka> yeah, same options that are on the admin side I believe
20:55:47 <ducttape_> that becomes a problem then
20:55:52 <itxaka> just transferred to run under tenant if the policy allows it
20:56:11 <tsufiev> ducttape_, according to policy delete_port is for admin or owner
20:56:14 <itxaka> why is that a problem ducttape_
20:56:19 <ducttape_> if you allow delete ports, it is not easy to re-create the same port - and your instance then becomes 100% dead
20:56:34 <tsufiev> hm...
20:56:40 <ducttape_> this is why it is in the cli, but not in the UI
20:56:57 <ducttape_> if you are deleting ports, you better know what you are doing
20:56:58 <robcresswell> Perhaps Add/ Del should be different proposals, itxaka
20:57:04 <tsufiev> ducttape_, is it possible to delete a port used by running VM?
20:57:08 <mrunge> so: create for the user, but delete for admin? that's fine
20:57:28 <itxaka> but user created port == owner
20:57:34 <robcresswell> This is making me think a lot about where Horizon should intervene with default policy...
20:57:37 <itxaka> tif the policy allows for it...?
20:57:45 <ducttape_> tsufiev - yes, you can delete a port for a running vm.  at that point, the vm has 0 networking
20:58:02 <tsufiev> ducttape_, I think we should restrict that in Horizon
20:58:14 <mrunge> yepp, agree tsufiev
20:58:28 <robcresswell> We're almost at time.
20:58:45 <robcresswell> I think for now the bp needs to be split to at least add/delete as separate proposals
20:58:51 <robcresswell> And then we can revisit it
20:58:56 <itxaka> nice, will do
20:59:01 <robcresswell> We may get more opinions in a couple weeks too. It that okay?
20:59:21 <robcresswell> s/It/Is
20:59:30 <itxaka> thanks for all the comments, Im not that good with the networking stuff :)
20:59:41 <itxaka> so its always nice to get good info
20:59:57 <robcresswell> #info https://blueprints.launchpad.net/horizon/+spec/network-ports-tenant Needs to be split, so that add/delete are separate proposals, and then we will revisit
21:00:13 <robcresswell> Time! Thanks all
21:00:18 <itxaka> o/
21:00:20 <robcresswell> #endmeeting