Re: [openstack-dev] [ironic] UFCG OneView CI comments missing recheck command
Hi Jay, Sorry about that. The comment should be "recheck oneview" to test again. I'll patch the failure message with instructions, thanks for the warning. About being broken, we experience some transient failures due to concurrency on our physical resources and/or timeouts. We'll be fine tuning this as soon as we get Ironic Tempest passing, but could you point me to the specific case you're seeing so I can double check the failure? Thanks. Regards, Thiago Paiva Brito Lead Software Engineer OneView Drivers for Openstack Ironic - Mensagem original - De: "Jay Faulkner" <j...@jvf.cc> Para: openstack-dev@lists.openstack.org Cc: ufcg-oneview...@lsd.ufcg.edu.br Enviadas: Terça-feira, 28 de junho de 2016 20:53:25 Assunto: [openstack-dev] [ironic] UFCG OneView CI comments missing recheck command Hi all, The new UFCG OneView CI is posting on changes now, and doesn't have any information about how to perform rechecks. It also appears to be broken, but given it's new that's not surprising. Can someone get the message updated with a recheck command? Thanks, Jay Faulkner OSIC __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic] ironic 5.0.0, the rest of mitaka, and beyond
Hi all, Our team at UFCG is working on polishing this spec[0] and the code implementation for that[1] for some time now. It's not a priority to the community since it is vendor specific, but since we are the only ones working on that and we consider it mature enough, we would like you to consider landing this still on Mitaka, if you would be so kind as to spare some review slots on that. :) Thanks in advance, [0]https://review.openstack.org/#/c/275726 [1]https://review.openstack.org/#/c/286192 Thiago Paiva Brito Lead Software Engineer OneView Drivers for Openstack Ironic - Mensagem original - De: "Jim Rollenhagen" <j...@jimrollenhagen.com> Para: openstack-dev@lists.openstack.org Enviadas: Sexta-feira, 11 de março de 2016 21:51:31 Assunto: [openstack-dev] [ironic] ironic 5.0.0, the rest of mitaka, and beyond Hi all, (grab some coffee, this is a bit long) Today we released ironic 5.0.0. Congrats to the team, and thank you for your hard work so far this cycle! You've all done an amazing job getting things done. The release notes[0] show how many awesome things we've shipped this cycle. Even Doug complimented us on making our notes awesome :D jroll : I have to say, now that I've seen the announcement email: nice job with reno release notes there! :-) Now, that said, there's still some things I'd like to get done this cycle; some are action items from the midcycle, and some are patches we'd like to land in ironic 5.1.0, which will be the basis of stable/mitaka. We'll need everyone to pitch in to get this stuff done. First though, I'm really sad to say we need to bump the networking work to Newton. We got a lot of the underpinnings in, which is great, but moving forward from here is a pretty large change in our core driver code, and API changes. I'd rather not rush those through, especially when the Mitaka versions of our client, and Nova, won't have them done. Let's keep working on those and land them first thing in Newton. To be clear, this was the main item I wanted to get done in Mitaka. I failed to sufficiently herd all of the cats needed to finish this. We got a late start, and made an even later decision that the pluggability of it was the wrong direction and needed to be rewritten. That's totally on me, and I feel pretty bad about it. Sorry, community. :( That said, things we need to do. Follow-up items from the midcycle, that we should do soon. Most of these are "before summit" rather than "before end of Mitaka". * jroll is going to work on a priorities dashboard that we can use during Newton to help focus on the right thing. * Deva is going to lead the work on setting up a timebox in our meeting to triage a few specs, as far as if it's worth looking at in the short term. We should also be sure to triage all RFEs, and make sure we continue to keep them triaged each week. * Let's get a few specs cores in an audio (and video?) conference for a couple hours next week to push through all of the existing RFEs, and make a plan to keep them up to date. * Keep working on our gate. * Julia is going to write a spec for the reference implementation of boot-from-volume. * We also should be reviewing the spec for the data model for all the data that needs to be passed to ironic. * jroll to separate specs for the filter API from the claims API. * Review the "VLAN aware baremetal" spec * tl;dr unbinds user-facing neutron networking from physical infra * https://review.openstack.org/#/c/277853/ * Plan summit sessions! Please put your ideas here: https://etherpad.openstack.org/p/ironic-newton-summit And code that we should land for the 5.1.0 release: * Anything fixing critical/high bugs * Partition image support for agent drivers * https://review.openstack.org/#/c/160224/ * https://review.openstack.org/#/c/162008/ * Others? I haven't done a full sweep of everything out there. I'd love suggestions on what else should land in Mitaka. :) * (this has been made harder by not keeping up to date on approving RFEs) Last, (again), we need to keep hacking on the neutron integration code and get that all ready to land ASAP in Newton. As a reminder, April 1 is the last day to cut the 5.1.0 release: http://releases.openstack.org/mitaka/schedule.html If you got this far, thanks for reading. I'm confident we can get this stuff done in a timely fashion. Thanks in advance for helping. :) // jim [0] http://docs.openstack.org/releasenotes/ironic/mitaka.html __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscr
[openstack-dev] [Ironic] Clarifications about ThirdParty CI deadlines
Hello folks, My project is in need of some clarifications about the deadlines for the CI deployment on [1]. If you can kindly answer these questions to help us consider changes on our sprint planning to address the community requirements, would be very very helpful: 1) In the point 2, what do we mean by "receive events"? Is is about reading from the event stream of Gerrit and take the appropriate actions? Act upon "check experimental" or "check " comments are considered valid to fulfill this requirement? 2) We are a little confused with the phrase "post comments in the sandbox". By that we mean commenting on the "openstack-infra/ci-sandbox" project? Do we need to keep commenting on sandbox even when we have already set-up the job to read events and comment results for the "openstack/ironic" project? Thank you, [1] https://wiki.openstack.org/wiki/Ironic/Testing#Third_Party_CI_Requirements Thiago Paiva Brito Lead Software Engineer OneView Drivers for Openstack Ironic __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] [Devstack]
Hello everyone, I have bumped into an article from one of the memcached creators where he discuss the use of memcached to store session data: http://dormando.livejournal.com/495593.html Maybe we need to take it into consideration. Maybe it'll bring more problems than solutions for a future, scallable HA environment. Best regards, On 24-10-2014 17:10, Gabriel Hurley wrote: SQLite doesn't introduce any additional dependencies, memcached requires installation of memcached (admittedly it's not hard on most distros, but it *is* yet another step) and in most cases the installation of another python module to interface with it. Memcached might be a good choice for devstack, but it may or may not be the right thing to recommend for Horizon by default. - Gabriel -Original Message- From: Yves-Gwenaël Bourhis [mailto:yves-gwenael.bour...@cloudwatt.com] Sent: Friday, October 24, 2014 7:06 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Horizon] [Devstack] Le 24/10/2014 13:30, Chmouel Boudjnah a écrit : On Fri, Oct 24, 2014 at 12:27 PM, Yves-Gwenaël Bourhis yves-gwenael.bour...@cloudwatt.com mailto:yves-gwenael.bour...@cloudwatt.com wrote: memcache can be distributed (so usable in HA) and has far better performances then db sessions. Why not use memcache by default? I guess for the simple reason that if you restart your memcache you loose all the sessions? Indeed, and for devstack that's an easy way do do a cleanup of old sessions :-) We are well talking about devstack in this thread, where loosing sessions after a memcache restart is not an issue and looks more like a very handy feature. For production it's another mater, and operators have the choice. -- Yves-Gwenaël Bourhis ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Thiago Paiva Brito Software Engineer Advanced OpenStack Brazil Team ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Horizon][RBAC] Approach to eliminate hard-coded checks based on roles
Hello everyone, Today, Horizon protect its resources (views, Dashboards or Panels) using a hard-coded approach, restricting on code the access to users having determined roles (like Admin). This problem was already addressed in this bug: https://bugs.launchpad.net/horizon/+bug/1226627 In an attempt to flexibilize the RBAC control over Horizon resources, I designed an approach that involves the creation of a (temporary) Horizon's policy file. This file receives rules to protect every resource, controlling the access on Horizon and has the flexibility for cloud-providers to edit these rules and add the checks over the roles that best meet their needs. A POC of this approach was sent to Gerrit as WIP, so you may evaluate the viability of the approach. It's avaliable on the review link below. I'd like you to take a look and send some feedback. If it seems viable to you guys, I'll write a blueprint (or spec) to address this change. https://review.openstack.org/#/c/99446/ Thanks, -- Thiago Paiva Brito Software Engineer Advanced OpenStack Brazil Team ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
