Meetings/Horizon/March4Log

david-lyle: #startmeeting Horizon david-lyle: hmm is the meeting bot sleeping? doug-fish: seems that way  :-) david-lyle: ok, we'll just do without david-lyle: Let's start with dates reminder david-lyle: March 9 is Feature Proposal Freeze (FPF), all proposed changes for Kilo should have the initial patch set posted by then david-lyle: March 19 is Feature Freeze (FF), all code needs to be merged by this date. david-lyle: there is the possibility of exceptions, but it is always preferable not to use them david-lyle: https://launchpad.net/horizon/+milestone/kilo-3 david-lyle: with that in mind, I've started removing items from kilo-3 david-lyle: will remove more as time goes on david-lyle: removed a fair number of cinder patches blocked by no python-cinderclient release david-lyle: that being release on the last couple of days of Kilo is too late to handle effectively doug-fish: are the python client updates scheduled? david-lyle: for us doug-fish: (I may know of another item in trouble without an update) david-lyle: doug-fish: not generally, just when ready doug-fish: ok david-lyle: most don't release very often, which is unfortunate david-lyle: for us doug-fish: agreed david-lyle: for high priority items in Kilo we only have 4 of 9 implemented david-lyle: I did see mrunge posted a patch for the unowned one, thanks, will try to look at today mrunge: david-lyle, yeah. mrunge: unfortunately, we're a bit blocked here mrunge: django-1.8 needs an update of django-nose david-lyle: which is not released? mrunge: right mrunge: the issue has a patcj mrunge: patch, and I cherry-picked that patch for fedora. david-lyle: well 1.7 support is the higher priority mrunge: nevertheless, there's still work to do david-lyle: 1.8 would be great too, but 1.7 is essential mrunge: yepp david-lyle: mrunge: is you opinion that with your patch, 1.7 support is complete? david-lyle: or is that a step? mrunge: david-lyle, nope. it's not mrunge: david-lyle, and I was just looking for 1.8, because of LTS mrunge: 1.7 should be doable more easily mrunge: needs 2 tests to be fixed, afaik david-lyle: ok, will take a closer look later doug-fish: is it time to update gate-horizon-python27-django14? mrunge: those tests need to be fixed anyways. mrunge: doug-fish, django-1.4 will be supported until october, or so david-lyle: I think next release doug-fish: k, sounds good mrunge: my way would be, to add another job to gate on django-1.7 david-lyle: mrunge: or move default to 1.7 and add 1.6 job mrunge: sure! mrunge: makes even more sense david-lyle: easier to do with the higher cap anyway mrunge: david-lyle, I've seen an infra issue with django-1.7. not sure, what this is. mrunge: we'll need to figure that out, once we're ready mrunge: it was "django-nose not found" david-lyle: mrunge: just an openstack/requirements problem, or something more david-lyle: oh, I see mrunge: I'll link the review to the blueprint david-lyle: ok, thanks david-lyle: For other high priority items in flight, progress is being made on the table paging/sorting blueprint david-lyle: I believe that there is a new release of magic-search pending that will require a new rev of the xstatic package david-lyle: and that will require the requirements dance david-lyle: fortunately the xstatic package has already been added to requirements and will just need a version rev david-lyle: and the launch instance redesign is progressing, but has a bit to go still david-lyle: most of tools/widgets are in place, including a base wizard, and now work is concentrating on the steps themselves david-lyle: a sub-group is still regularly meeting to push that work, but I have not been able to attend david-lyle: the etherpad, which I don't have handy has the up to date status david-lyle: ping me later if you are interested and can't find the link neillc: https://etherpad.openstack.org/p/horizon-kilo-virtual-sprint david-lyle: thanks neillc david-lyle: that's about it for status, any questions? david-lyle: The agenda today only consists of a request to review SSO (single sign on) patches david-lyle: there is one in django_openstack_auth and one in Horizon david-lyle: I've looked at the django_openstack_auth review, but I'm concerned about it and the domain scoped token work and other efforts to get auth to work with Kerberos all stomping on each other doug-fish: I think that's a reasonable concern david-lyle: so I've been reluctant to bless any of them david-lyle: without getting that worked out mrunge: yeah. django_openstack_auth seems to be in a not so good shape david-lyle: doug-fish: also is trying to allow for Keystone2Keystone federation in the same area as well doug-fish: yeah, I wasn't going to mention it because the patch looks so bad right now, but I'm hopeful to make progress over the next day or two after I get a python-keystoneclient patch outdoug-fish: how do we resolve the conflict? these are all things people care about enough to provide the code doug-fish: arm wrestling? david-lyle: my short assessment is we're trying to handle too many keystone changes at once without coordinated efforts david-lyle: I've dropped consideration of HMT for that reason david-lyle: also lack of support in other projects in Kilo david-lyle: doug-fish: I think I need we need to pull in all parties pushing the patches and try to unify on an approach, or at least better coordinate david-lyle: I'll work on arranging that doug-fish: sounds good david-lyle: #topic Open Discussion absubram: david-lyle: agree with the trimming of the k-3 list to just important items.. having said that I am here to request a couple additions of low priority items into kilo-3 haha.. it isn’t obviously going to hold up k-3 without them.. but the owners are targeting k-3 absubram: the owners aren’t here at the meeting given they’re in CA.. but both already have reviews out for their BPs.. it’s just that their BP’s need approval and targets for K-3 please.. they will also make sandboxes available for each of their reviews so people can test out their changes.. david-lyle: absubram: what is the content of the blueprints? mrunge: absubram, at least I have some need for discussion here absubram: one is a Cisco FWaaS addition - https://review.openstack.org/#/c/161049/ .. and the other is another addition to the N1K - https://review.openstack.org/#/c/143582/ absubram: mrunge: sure thing! I do believe I saw an email with some comments you posted on the FW BP mrunge: exactly mrunge: https://blueprints.launchpad.net/horizon/+spec/bp-cisco-fwaas-horizon david-lyle: glancing at the patch, I'll reiterate that I'm not looking to add driver specific code into Horizon mrunge: my question was: where to put this, how to put this mrunge: david-lyle, can you explain that a bit more? mrunge: so, no spice support? absubram: do you mean vendor specific code? :) david-lyle: consoles are a bit different and most nebulus david-lyle: (sp) mrunge: or does that mean, there won't be ceph-radosgw specific code in horizon? mrunge: (as requested 2 days before on the mailing list) david-lyle: so that one I think is us misusing headers in Horizon david-lyle: requiring non-required headers mrunge: yupp mrunge: although first direction was a bit different mrunge: about non standard API support mrunge: - whatever that means david-lyle: it's more along the lines of building on top of cinder and neutron or swift, where backend drivers code can be swapped out david-lyle: I think once we're beyond the abstraction level built into the API, we're getting into plugin territory david-lyle: plugin to horizon absubram: haha true mrunge: david-lyle, can we write that somewhere down? I foresee the demand to do plugins more and more absubram: yeah.. agree with mrunge mrunge: or support plugins into e.g cinder absubram: david-lyle: I do have a BP I created.. though it is definitely going to be an L target.. https://blueprints.launchpad.net/horizon/+spec/horizon-vendor-split david-lyle: mrunge: yes, I also think the stigma around this will go down in L after everyone gets over the shock of the release working differently mrunge: maybe worth a topic for the summit david-lyle: For L, I think we as horizon need to look to splitting out some of the code already integrated into plugins absubram: it is to try and see if we can maybe do somehting like what neutron did recently.. move the vendor specific plugins to their own stackforge repo.. I think that’ll be best for all the “cisco” specific code we’re trying to add.. as far as I know we have four platforms that all what platform specific code in Horizon mrunge: david-lyle, +1 that would solve some of the problems david-lyle: I think there will be several plugins and we can using tagging to identity interoperability mrunge: oh, reading https://etherpad.openstack.org/p/horizon-liberty-summit again, I already added that :D absubram: ok.. I’ll let the owners of these two BPs know.. but for now their code will be just left in review? david-lyle: it would also reduce the load on the core horizon project and allow those projects to move more quickly david-lyle: absubram: yes, I'll look more closely at them, and comment absubram: lol mrunge absubram: ty absubram: I do believe the firewall community had an idea for one more BP.. that is not vendor specific :p mrunge: david-lyle, any info about string freeze? david-lyle: oh yes david-lyle: talked to amotoki about that david-lyle: I believe we arrived at approx a week before RC-1 david-lyle: and use RC-2 for translated strings primarily, as we have done in the past mrunge: ok, great david-lyle: RC-1 date is not set in stone, but we'll know when we're close david-lyle: as long as we allow approx 2 weeks, we should be ok david-lyle: anything other topics? david-lyle: *any david-lyle: ok, well I'm UTC-8 today, so I'm going back to sleep for a bit. absubram: :) absubram: thanks all.. later! david-lyle: Thanks, everyone. Have a great week! And get your features up by March 9. neillc: night all mrunge: thanks david-lyle and good night david-lyle: #endmeeting