Re: [openstack-dev] [all] [tc] [api] Paste Maintenance
On Mon, 2018-10-22 at 07:50 -0700, Morgan Fainberg wrote: > Also, doesn't bitbucket have a git interface now too (optionally)? > It does :) But I think it requires a new repo, so it means that could as well move to somewhere else like github or openstack infra :p __ 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] [goals][upgrade-checkers] Week R-25 Update
On Tue, 2018-10-23 at 16:40 -0500, Matt Riedemann wrote: > On 10/23/2018 1:41 PM, Sean McGinnis wrote: > > > Yeah, but part of the reason for placeholders was consistency > > > across all of > > > the services. I guess if there are never going to be upgrade > > > checks in > > > adjutant then I could see skipping it, but otherwise I would > > > prefer to at > > > least get the framework in place. > > > > > +1 > > > > Even if there is nothing to check at this point, I think having the > > facility > > there is a benefit for projects and scripts that are going to be > > consuming > > these checks. Having nothing to check, but having the status check > > there, is > > going to be better than everything needing to keep a list of which > > projects to > > run the checks on and which not. > > > > Sure, that works for me as well. I'm not against adding > placeholder/noop > checks knowing that nothing is immediately obvious to replace those > in > Stein, but could be done later when the opportunity arises. If it's > debatable on a per-project basis, then I'd defer to the core team > for > the project. > +1 on what Ben, Matt, and Sean said there. __ 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] [goals][upgrade-checkers] Week R-26 Update
ain multi-upgrade (jumps) scenarios. After a while, we could think of feeding those back to upgrade checkers. 3) I like the approach of having oslo-config-validator. However, I must admit it's not part of our process to always validate a config file before trying to start a service in OSA. I am not sure where other deployment projects are in terms of that usage. I am not familiar with upgrade checker code, but I would love to see it re-using oslo-config- validator, as it would be the unique source of truth for upgrades before the upgrade happens (vs having to do multiple steps). If I am completely out of my league here, tell me. Just my 2 cents. Jean-Philippe Evrard (evrardjp) __ 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] [tc][all] Discussing goals (upgrades) with community @ office hours
On Sat, 2018-10-13 at 15:04 +0200, Mohammed Naser wrote: > I wanted to propose one of the upcoming office hours to perhaps > invite > some of the community members (PTL, developers, anyone!) as well as > the TC with goal champions to perhaps discuss some of these goals to > help everyone get a clear view on what's going on. > > Does this seem like it would be of interest to the community? I am > currently trying to transform our office hours to be more of a space > where we have more of the community and less of discussion between > us. > Great idea, mnaser. I think it's good if we discuss all together during office hours! I believe the office hours should not only be used for discussing progress by subject-matter experts (SME), but also a place for the community to discuss cross-team issues, and victories. I like to have goal champions talking about progress in the next office hours. +1! JP __ 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] [tc] assigning new liaisons to projects
On Mon, 2018-10-08 at 10:27 -0400, Doug Hellmann wrote: > TC members, > > Since we are starting a new term, and have several new members, we > need > to decide how we want to rotate the liaisons attached to each our > project teams, SIGs, and working groups [1]. > > Last term we went through a period of volunteer sign-up and then I > randomly assigned folks to slots to fill out the roster evenly. > During > the retrospective we talked a bit about how to ensure we had an > objective perspective for each team by not having PTLs sign up for > their > own teams, but I don't think we settled on that as a hard rule. > > I think the easiest and fairest (to new members) way to manage the > list > will be to wipe it and follow the same process we did last time. If > you > agree, I will update the page this week and we can start collecting > volunteers over the next week or so. > > Doug > > [1] https://wiki.openstack.org/wiki/OpenStack_health_tracker > > _ > _ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs > cribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev +1 __ 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] [openstack-ansible] dropping xenial jobs
On Wed, 2018-10-10 at 06:50 +0200, Mohammed Naser wrote: > Hi everyone! > > So I’ve been thinking of dropping the Xenial jobs to reduce our > overall impact in terms of gate usage in master because we don’t > support it. > > However, I was a bit torn on this because i realize that it’s > possible for us to write things and backport them only to find out > that they’d break under xenial which can be deployed with Rocky. > > Thoughts? Ideas? I was thinking maybe Lee an experimental job.. not > really sure on specifics but I’d like to bring in more feedback. > > Thanks, > Mohammed > _ > _ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs > cribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hello, In the past we removed the jobs (ocata didn't have trusty jobs, IIRC), and made sure backports were still passing the gates of newton with trusty jobs voting. It may force a re-implementation in lower branches, but it is fine for me, as ansible versions also differ and might require re-implementation anyway. That said, we didn't have the flexibility we have now with Zuul v3, and making the jobs voting/nv/experimental. The middle ground would be to have a non-voting check job. It is fine, but it consumes resources for patches that aren't supposed to be backported, and therefore I think it's not the greatest solution. I like the "check experimental" part. It has an inconvenient: it relies on our good behaviour: When a bug is raised (so first element, we should not forget the bug link!) for backport, we should all keep in mind to check experimental before attempting the merge on the higher branch. That said, I still prefer the "check experimental" that nothing. You have my vote! Best regards, JP __ 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] [tc] bringing back formal TC meetings
On Fri, 2018-10-05 at 07:40 -0400, Doug Hellmann wrote: > Chris Dent writes: > > > On Thu, 4 Oct 2018, Doug Hellmann wrote: > > > > > TC members, please reply to this thread and indicate if you would > > > find > > > meeting at 1300 UTC on the first Thursday of every month > > > acceptable, and > > > of course include any other comments you might have (including > > > alternate > > > times). > > > > +1 > > > > Also, if we're going to set aside a time for a semi-formal meeting, > > I > > hope we will have some form of agenda and minutes, with a fairly > > clear process for setting that agenda as well as a process for > > I had in mind "email the chair your topic suggestion" and then "the > chair emails the agenda to openstack-dev tagged [tc] a bit in advance > of > the meeting". There would also probably be some standing topics, like > updates for ongoing projects. > > Does that work for everyone? > > Fine for me __ 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] [Openstack-sigs] [all][tc] We're combining the lists!
Agreed with the merge. null__ 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] ?==?utf-8?q? ?==?utf-8?q? [infra] Gerrit User Summit, November 2018
On Tuesday, October 02, 2018 14:59 CEST, Adam Spiers wrote: > Hi all, > > The next forthcoming Gerrit User Summit 2018 will be Nov 15th-16th in > Palo Alto, hosted by Cloudera. > > See the Gerrit User Summit page at: > > https://gerrit.googlesource.com/summit/2018/+/master/index.md > > and the event registration at: > > https://gus2018.eventbrite.com > > Hopefully some members of the OpenStack community can attend the > event, not just so we can keep up to date with Gerrit but also so that > our interests can be represented! > > Regards, > Adam > > __ > 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 Good catch! When I read your email, I assume you won't be going? Palo Alto is indeed not very close to Europe and it's indeed a long trip for a two day effort. Maybe there is someone closer that can help there and attend this? Regards, Jean-Philippe Evrard (evrardjp) __ 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] ?==?utf-8?q? ?==?utf-8?q? [helm] multiple nova compute nodes
> > The nova-compute pods are part of a daemonset which will automatically > create a nova-compute pod on each node that has the > "openstack-compute-node=enabled" label. > Hello, Should we add this in the documentation, maybe with an architecture diagram? Regards, Jean-Philippe Evrard (evrardjp) __ 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] ?==?utf-8?q? ?==?utf-8?q? [docs] Nominating Ian Y. Choi for openstack-doc-core
> > > > Based on our PTG discussion, I'd like to nominate Ian Y. Choi for > > membership in the openstack-doc-core team. I think Ian doesn't need an > > introduction, he's been around for a while, recently being deeply involved > > in infra work to get us robust support for project team docs translation and > > PDF builds. > > > > Having Ian on the core team will also strengthen our integration with > > the i18n community. > > > > Please let the ML know should you have any objections. > Petr, > > Not a doc Core but wanted to add my support. Agree he would be a great > addition. Appreciate all he does for i18n, docs and OpenStack! > > Jay Likewise. Great addition! __ 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] [election][tc]Question for candidates about global reachout
[...] I respect that tool choices can make a difference in enabling or improving our outreach to specific cultures. I agree there. I'll commit to personally rejecting presence on proprietary social media services so as to demonstrate that public work can be done within our community while relying exclusively on free/libre open source software. It is nice to be in a position to do so. Please don't change! : ) I recognize the existence of the free software movement as a distinct culture with whom we could do a better job of connecting. If as a community we promote and embrace non-free tools we will only continue to alienate them, [...] I agree again with Jeremy here. As this was a direct question for the candidates, here is my answer... There is two layers in this conversation: a personal level, and an official stance on the subject (as discussed in the TC room). At a personal level,I guess I wouldn't mind myself joining to Wechat, with the hope of being helpful there. As I don't speak this language particularily, I am not sure how I can be more of help there than I can be with speaking an ambassador in a mutually common language (I am also not native english). At the same time, I would be very sad to not use an open tool, because I am not sure what the privacy implications would be. But, pragmatically, I understand the biggest picture here: We want to be more reachable, as increasing community size over time is a must for sustainable software, and if I can be a little help personally, I'd do it. Before giving my opinion for an official stance as a TC candidate (the other layer), I'd like to ask you a few questions ... - What is the problem joining Wechat will solve (keeping in mind the language barrier)? - Isn't this problem already solved for other languages with existing initiatives like local ambassadors and i18n team? Why aren't these relevant? - Should we widen this 'Wechat' initiative to all system based on location> systems? - Pardon my ignorance here, what is the problem with email? (I understand some chat systems might be blocked, I thought emails would be fine, and the lowest common denominator). I also have technical questions about 'wechat' (like how do you use it without a smartphone?) and the relevance of tools we currently use, but this will open Pandora's box, and I'd rather not spend my energy on closing that box right now :D Best regards, Jean-Philippe Evrard (evrardjp) __ 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-dev] [election][tc] Opinion about 'PTL' tooling
Hello everyone, In my candidacy [1], I mentioned that the TC should provide more tools to help the PTLs at their duties, for example to track community health. I have questions for the TC candidates: - What is your opinion about said toolkit? Do you see a purpose for it? - Do you think said toolkit should fall under the TC umbrella? After my discussion with Rico Lin (PTL of the Heat project, and TC candidate) yesterday, I am personally convinced that it would be a good idea, and that we should have those tools: As a PTL (but also any person interested to see health of projects) I wanted it and I am not alone. PTLs are focusing on their duties and, as a day is only composed of so few hours, it is possible they won't have the focus to work on said tools to track, in the longer term, the community. For me, tracking community health (and therefore a toolkit for the PTLs/community) is something TC should cover for good governance, and I am not aware of any tooling extracting metrics that can be easily visible and used by anyone. If each project started to have their own implementation of tools, it would be opposite to one of my other goals, which is the simplification of OpenStack. Thanks for reading me, and do not hesitate to ask me questions on the mailing lists, or in real life during the PTG! Regards, Jean-Philippe Evrard (evrardjp) [1]: https://git.openstack.org/cgit/openstack/election/plain/candidates/stein/TC/jean-phili...@evrard.me __ 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-dev] [election][tc] TC Candidacy
Hello everyone, I am hereby announcing my candidacy for a position on the OpenStack Technical Committee (TC). I believe that Open Source software is not only about code, but also a way to bring people together in order to find a solution to business problems. Many people find me an easy person to talk with, due to my open mindset and my "facilitator" spirit. Those qualities helped me build solutions in the past. I hope they will be helpful to the TC: While OpenStack is becoming more mature everyday, it is facing (and will face) new challenges in terms of community, or identity. I have been following the OpenStack ecosystem since Kilo. I went through multiple companies and multiple hats (A cloud end-user, an OpenStack advocate in meetups and at FOSDEM, a product owner of the cloud strategy, architect of a community cloud, a deployer, a developer, a team lead), which gives me a unique view on OpenStack and other adjacent communities. I am now working full time on OpenStack for SUSE, focusing on deployment tooling. That growing involvement inspires me to be a TC candidate. I would like to help shape what the future of OpenStack could be. Even if my experience spans quite a few cycles, I consider myself as an OpenStack newcomer. I like to see things with fresh eyes, and I do not hesitate to question the status quo. It usually gives me a different perspective to explore new conversations or find new solutions. I also think this freshness makes me very approachable to new community members, new users, or external communities. Listening to those inputs is very important to me: good software can only exist with proper requirements! I would like to focus my time at the TC with a general simplification of OpenStack. Simplification would first *reduce the barrier of entry for new contributors*, make community goals more easily reachable, and help connecting adjacent communities. In this matter, I consider the technical 'python3-first' project will open the door to many positive improvements and simplifications, but setting up a good knowledge transfer platform and best practices/recommendations for projects could be a positive improvement. Talking about best practices and simplification, I would like to help PTLs at their duties, as I consider TC members should be more supportive of the day to day work of the PTL and projects. I would love to see the TC as provider of toolkits helping maintain and grow the community of each of the official projects. These could be the tools that projects do not have time to develop and grow. The code would be common to OpenStack, and therefore reducing the overall complexity of projects which were carrying those tools, the same way as the Release or OpenStack-Infra team are providing tools for the community. I have a few other ideas for simplifications but instead of carrying on, I would prefer hearing from you, and hearing from your ideas. So, please, contact me! Long story short: I would like to be there to help shaping the community together, with your help. Thank you for your consideration, Jean-Philippe Evrard (evrardjp) __ 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] ?==?utf-8?q? [openstack-ansible] Stepping down from OpenStack-Ansible core
On Thursday, August 30, 2018 19:40 CEST, Andy McCrae wrote: > Now that Rocky is all but ready it seems like a good time! Since changing > roles I've not been able to keep up enough focus on reviews and other > obligations - so I think it's time to step aside as a core reviewer. > > I want to say thanks to everybody in the community, I'm really proud to see > the work we've done and how the OSA team has grown. I've learned a tonne > from all of you - it's definitely been a great experience. Andy, You've been there for the reshaping of OSA (splitting of repos, change of testing!), and always there when we needed you. I'd like to thank you for your work. I wish you all the best for your new role, and hope our paths will cross again soon! Best regards, Jean-Philippe Evrard (evrardjp) __ 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] ?==?utf-8?q? [kolla][project?==?utf-8?q? navigator] kolla missing in project navigator
On Monday, August 20, 2018 15:57 CEST, Jimmy McArthur wrote: > Eduardo, > > Thanks for the heads up. We're in the process of updating the Project > Navigator to match the OpenStack Map [1]. It looks like Kolla got lost > in the shuffle. I've added it back to the Project [2Navigator under the > Deployment Tools section [2]. > > Please let me know if I can assist further. > > Thanks, > Jimmy > > > [1] https://www.openstack.org/assets/software/projectmap/openstack-map.pdf > [2] https://www.openstack.org/software/project-navigator/deployment-tools That second link is very confusing, on the openstack-ansible case. Yes we ship recipes (roles, playbooks) for deployment using Ansible (any other ansible project could use them, maybe we need to adapt there if it's not the case...), but we also deal with the installation and upgrade of the openstack cloud. Therefore, shouldn't OSA also be listed in the "Deployment / Lifecycle Tools"? Best regards, Jean-Philippe Evrard (evrardjp) __ 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-dev] [openstack-ansible][ptg] PTG etherpad planning.
Dear community, We are approaching the PTG in Denver, and I want to remind everybody to make sure you are ready for it! I've created the etherpad [1] where you can add any topic you want to discuss, if you haven't done so already. If you are not able to attend the PTG, please mention it on the etherpad, and we'll run the session remotely if we can. Note: There will be the now traditional team photos and dinner too :) Regards, Jean-Philippe Evrard (evrardjp) [1]: https://etherpad.openstack.org/p/osa-stein-ptg __ 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] ?==?utf-8?q? PTG Denver Horns
On Wednesday, August 08, 2018 16:12 CEST, Jeremy Stanley wrote: > On 2018-08-08 06:51:27 -0500 (-0500), David Medberry wrote: > > So basically, we have added "sl" to osc. Duly noted. > > > > (FWIW, I frequently use "sl" as a demo of how "live" a VM is during live > > migration. The train "stutters" a bit during the cutover.) > > > > Now I can base it on PTG design work in a backronym fashion. > [...] > > Speaking of which, is it too soon to put in bids to name the Denver > summit and associated release in 2019 "OpenStack Train"? I feel like > we're all honorary railroad engineers by now. > -- > Jeremy Stanley +1 __ 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-dev] [openstack-ansible] Change in our IRC channel
Hello everyone, Due to a continuously increasing spam [0] on our IRC channels, I have decided to make our channel (#openstack-ansible on freenode) only joinable by Freenode's nickserv registered users. I am sorry for the inconvenience, as it will now be harder to reach us (but it's not that hard to register! [1]). The conversations will be easier to follow though. You can still contact us on the mailing lists too. Regards, Jean-Philippe Evrard (evrardjp) [0]: https://freenode.net/news/spambot-attack [1]: https://freenode.net/kb/answer/registration __ 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-dev] [openstack-ansible] Proposing Jonathan Rosser as core reviewer
Hello everyone, I'd like to propose Jonathan Rosser (jrosser) as core reviewer for OpenStack-Ansible. The BBC team [1] has been very active recently across the board, but worked heavily in our ops repo, making sure the experience is complete for operators. I value Jonathan's opinion (I remember the storage backend conversations for lxc/systemd-nspawn!), and I'd like this positive trend to continue. On top of it Jonathan has been recently reviewing quite a series of patches, and is involved into some of our important work: bringing the Bionic support. Best regards, Jean-Philippe Evrard (evrardjp) [1]: http://stackalytics.com/?project_type=openstack=rocky=commits=BBC __ 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-dev] [openstack-ansible] Using jmespath more
Hello, According to the readability test here [1], contributors prefer reading a task like the following: - name: Fail if service was deployed using a different installation method fail: msg: "Switching installation methods for OpenStack services is not supported" when: - ansible_local is defined - ansible_local.openstack_ansible is defined - ansible_local.openstack_ansible.aodh is defined - ansible_local.openstack_ansible.aodh.install_method is defined - ansible_local.openstack_ansible.aodh.install_method != aodh_install_method as: - name: Fail if service was deployed using a different installation method fail: msg: "Switching installation methods for OpenStack services is not supported" when: - (ansible_local | json_query("openstack_ansible.aodh.install_method")) is not "" - ansible_local.openstack_ansible.aodh.install_method != aodh_install_method (Short explanation, json_query returns an empty string if path is not found, instead of having an ansible failure, which is very welcomed. In the case above, if everything is defined, there will be no empty string, and we can compare the string contents with the second when condition). Another example avoiding the "is defined" dance: Checking if install_method IS equal to "source" in the local facts could be simplified to: when: - (ansible_local | json_query("openstack_ansible.aodh.install_method")) == 'source' I hope this will inspire people to refactor some tedious to read tasks into more readable ones. Thanks for your contributions! Best regards, Jean-Philippe Evrard (evrardjp) [1]: https://etherpad.openstack.org/p/osa-readability-test __ 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] [charms] PTL non-candidacy for Stein cycle
On July 27, 2018 4:09:04 PM UTC, James Page wrote: >Hi All > >I won't be standing for PTL of OpenStack Charms for this upcoming >cycle. > >Its been my pleasure to have been PTL since the project was accepted >into >OpenStack, but its time to let someone else take the helm. I'm not >going >anywhere but expect to have a bit of a different focus for this cycle >(at >least). > >Cheers > >James Thanks for the work done on a cross project level and your communication! JP (evrardjp)__ 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] ?==?utf-8?q? Lots of slow tests timing out jobs
On Wednesday, July 25, 2018 08:46 CEST, Ghanshyam Mann wrote: > On Wed, 25 Jul 2018 05:15:53 +0900 Matt Riedemann > wrote > > While going through our uncategorized gate failures [1] I found that we > > have a lot of jobs failing (161 in 7 days) due to the tempest run timing > > out [2]. I originally thought it was just the networking scenario tests, > > but I was able to identify a handful of API tests that are also taking > > nearly 3 minutes each, which seems like they should be moved to scenario > > tests and/or marked slow so they can be run in a dedicated tempest-slow > job. > > > > I'm not sure how to get the history on the longest-running tests on > > average to determine where to start drilling down on the worst > > offenders, but it seems like an audit is in order. > > yeah, there are many tests taking too long time. I do not know the reason > this time but last time we did audit for slow tests was mainly due to ssh > failure. > I have created the similar ethercalc [3] to collect time taking tests and > then round figure of their avg time taken since last 14 days from health > dashboard. Yes, there is no calculated avg time on o-h so I did not take > exact avg time its round figure. > > May be 14 days is too less to take decision to mark them slow but i think > their avg time since 3 months will be same. should we consider 3 month time > period for those ? > > As per avg time, I have voted (currently based on 14 days avg) on ethercalc > which all test to mark as slow. I taken the criteria of >120 sec avg time. > Once we have more and more people votes there we can mark them slow. > > [3] https://ethercalc.openstack.org/dorupfz6s9qt > > -gmann > We have a similar observation in openstack-ansible. It is painful. Recently something that passed gates without rechecks (but close to timeout) took 14 (timeouts) rechecks to get in. In OSA, we will be starting a project to refactor our testing for being faster, but I'd like to have news of your research :) Thanks, Jean-Philippe (evrardjp) > > > > [1] http://status.openstack.org/elastic-recheck/data/integrated_gate.html > > [2] https://bugs.launchpad.net/tempest/+bug/1783405 > > > > -- > > > > Thanks, > > > > Matt > > > > __ > > 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 __ 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-dev] [openstack-ansible] PTL non-candidacy
Hello everyone, If you were not at the previous OpenStack-Ansible meeting*, I'd like to inform you I will not be running for PTL of OSA. It's been a pleasure being the PTL of OSA for the last 2 cycles. We have improved in many ways: testing, stability, speed, features, documentation, user friendliness... I am glad of the work we achieved, and I think it's time for a fresh view with a new PTL. Thanks for being an awesome community. Jean-Philippe Evrard (evrardjp) *Please join! 4PM UTC in #openstack-ansible! __ 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] [sig][upgrades][ansible][charms][tripleo][kolla][airship] reboot or poweroff?
Sorry about the lack of participation too. Monthly sounds good. Regards, JP On July 24, 2018 9:34:56 AM UTC, Paul Bourke wrote: >Hi James, > >Sorry to hear about the lack of participation. I for one am guilty of >not taking part, there just seems to be never enough time in the day to > >cram in all the moving parts that a project like OpenStack requires. > >That being said, this effort is definitely one of the most important to > >the project imo, so I'm keen to step up. > >Moving to a monthly meeting sounds a good idea, at least till things >get >back on foot. Could you share what the current times / location for the > >meeting is? > >Cheers, >-Paul > >On 23/07/18 17:01, James Page wrote: >> Hi All >> >> tl;dr we (the original founders) have not managed to invest the time >to >> get the Upgrades SIG booted - time to hit reboot or time to poweroff? >> >> Since Vancouver, two of the original SIG chairs have stepped down >> leaving me in the hot seat with minimal participation from either >> deployment projects or operators in the IRC meetings. In addition >I've >> only been able to make every 3rd IRC meeting, so they have generally >not >> being happening. >> >> I think the current timing is not good for a lot of folk so finding a > >> better slot is probably a must-have if the SIG is going to continue - > >> and maybe moving to a monthly or bi-weekly schedule rather than the >> weekly slot we have now. >> >> In addition I need some willing folk to help with leadership in the >> SIG. If you have an interest and would like to help please let me >know! >> >> I'd also like to better engage with all deployment projects - >upgrades >> is something that deployment tools should be looking to encapsulate >as >> features, so it would be good to get deployment projects engaged in >the >> SIG with nominated representatives. >> >> Based on the attendance in upgrades sessions in Vancouver and >> developer/operator appetite to discuss all things upgrade at said >> sessions I'm assuming that there is still interest in having a SIG >for >> Upgrades but I may be wrong! >> >> Thoughts? >> >> James >> >> >> >> >> >> >> >__ >> 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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.__ 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] [docs][all] Front page template for project team documentation
Is there a lint tool that can catch incoherent markup at a global project level (vs at a page gen level)? Any tool to catch these issues would help. JP. On July 19, 2018 3:55:29 PM UTC, Petr Kovar wrote: >Hi all, > >A spin-off discussion in https://review.openstack.org/#/c/579177/ >resulted >in an idea to update our RST conventions for headings level 2 and 3 so >that >our guidelines follow recommendations from >http://docutils.sourceforge.net/docs/user/rst/quickstart.html#sections. > >The updated conventions also better reflect what most projects have >been >using already, regardless of what was previously in our conventions. > >To sum up, for headings level 2, use dashes: > >Heading 2 >- > >For headings level 3, use tildes: > >Heading 3 >~ > >For details on the change, see: > >https://review.openstack.org/#/c/583239/1/doc/doc-contrib-guide/source/rst-conv/titles.rst > >Thanks, >pk > > >On Fri, 29 Jun 2018 16:45:53 +0200 >Petr Kovar wrote: > >> Hi all, >> >> Feedback from the Queens PTG included requests for the Documentation >> Project to provide guidance and recommendations on how to structure >common >> content typically found on the front page for project team docs, >located at >> doc/source/index.rst in the project team repository. >> >> I've created a new docs spec, proposing a template to be used by >project >> teams, and would like to ask the OpenStack community and, >specifically, the >> project teams, to take a look, submit feedback on the spec, share >> comments, ideas, or concerns: >> >> https://review.openstack.org/#/c/579177/ >> >> The main goal of providing and using this template is to make it >easier for >> users to find, navigate, and consume project team documentation, and >for >> contributors to set up and maintain the project team docs. >> >> The template would also serve as the basis for one of the future >governance >> docs tags, which is a long-term plan for the docs team. >> >> Thank you, >> pk >> >> >__ >> 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 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.__ 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] [openstack-ansible] dropping selinux support
This title seems very scary. It was to be read as "... for source installs" : ) To be honest, I feel very sad about the lack of involvement in CentOS in OSA over the years. We didn't get many contributors over time for it. This has always been a labour of love, and the honeymoon seems over for many. So... Please help us if you want to keep your sourced based installs + CentOS + selinux. Else, you can still use packages! :D Thanks mnaser for starting this hard topic and community decision process. JP (evrardjp) __ 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] [tc] [all] TC Report 18-26
My two cents: > I think if OpenStack wants to gain back some of the steam it had before, it > needs to adjust to the new world it is living in. This means: > * Consider abolishing the project walls. They are driving bad architecture > (not intentionally but as a side affect of structure) As long as there is no walled garden, everything should be done in a modular way. I don't think having separated nova from cinder prevented some contributions, quite the contrary. (Optionally, watch [1]). I am not familiar with the modularity and ease of contribution in k8s, so the modularity could be there in a different form. [1]: https://www.youtube.com/watch?v=xYkh1sAu0UM > * focus on the commons first. Good point. > * simplify the architecture for ops: Good point, but I don't see how code, org structure, or project classification changes things here. > * come up with an architecture team for the whole, not the subsystem. The > whole thing needs to work well. Couldn't that be done with a group TC sponsored? > * encourage current OpenStack devs to test/deploy Kubernetes. It has some > very good ideas that OpenStack could benefit from. If you don't know what > they are, you can't adopt them. Good idea. > > And I know its hard to talk about, but consider just adopting k8s as the > commons and build on top of it. OpenStack's api's are good. The > implementations right now are very very heavy for ops. You could tie in K8s's > pod scheduler with vm stuff running in containers and get a vastly simpler > architecture for operators to deal with. Yes, this would be a major > disruptive change to OpenStack. But long term, I think it would make for a > much healthier OpenStack. Well, I know operators that wouldn't like k8s and openstack components on top. If you're talking about just a shim between k8s concepts and openstack apis, that sounds like a good project : p >> I've also argued in the past that all distro- or vendor-specific >> deployment tools (Fuel, Triple-O, etc [3]) should live outside of >> OpenStack because these projects are more products and the relentless >> drive of vendor product management (rightfully) pushes the scope of >> these applications to gobble up more and more feature space that may or >> may not have anything to do with the core OpenStack mission (and have >> more to do with those companies' product roadmap). > > I'm still sad that we've never managed to come up with a single way to > install OpenStack. The amount of duplicated effort expended on that > problem is mind-boggling. At least we tried though. Excluding those > projects from the community would have just meant giving up from the > beginning. Well, I think it's a blessing and a curse. Sometimes, I'd rather have only one tool, so that we all work on it, and not dilute the community into small groups. But when I started deploying OpenStack years ago, I was glad I could find a community way to deploy it using , and not . So for me, I am glad (what became) OpenStack-Ansible existed and I am glad it still exists. The effort your are talking about is not purely duplicated: - Example: whether openstack-ansible existed or not, people used to Ansible would still prefer deploying openstack with Ansible than with puppet or chef (because of their experience) if not relying on a vendor. In that case, they would probably create their own series of playbooks. (I've seen some). That's the real waste, IMO. - Deployments projects talk to each other. Talking about living outside OpenStack, where would, for you, OpenStack-Ansible, the puppet modules, or OpenStack-Chef be? For OSA, I consider our community now as NOT vendor specific, as many actors are now playing with it. We've spent a considerable effort in outreaching and ensuring everyone can get involved. So we should be in openstack/ right? But what about 4 years ago? Every project starts with a sponsor. I am not sure a classification (is it outside, is it inside openstack/?) matters in this case. > > I think Thierry's new map, that collects installer services in a > separate bucket (that may eventually come with a separate git namespace) > is a helpful way of communicating to users what's happening without > forcing those projects outside of the community. Side note: I'd be super happy if OpenStack-Ansible could be on that bucket! Cheers, JP (evrardjp) __ 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] [tc] [ptl] PTL E-mail addresses on rendered team pages
> Not sure it'd help but one option we do is to create aliases based on > the title. Though since the PTLs don't have addresses on the openstack > domain an alias may not make as much sense, it'd have to be a full > account forward. It's useful for centralized spam filtering. I foresee this: 1) We create an alias to PTL email 2) PTL think that kind of emails are worth sharing with a team to balance work 3) We now have a project mailing list 4) People stop using openstack-dev lists. But that's maybe me... __ 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] [tc] [summary] Organizational diversity tag
I think PTLs would naturally like to have those updated, and for me a TC +w would make sense. But we need to have guidelines, so that's it's more tangible, and the subtlety stays impartial. __ 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-dev] [openstack-ansible] Restarting our very own "SIG" teams
Hello, TL:DR; If you have spare cycles, join one of our interest groups! In the Queens cycle, I have formalised the "liaisons" work, making them an integral part of the Thursday's meeting agenda. Sadly, that initiative didn't work, as almost no liaison worked/reported on those meetings, and I stopped the initiative. Upon common agreement that we now need to change how we scale the team, we will now start our "liaison 2.0" work. So, I have started an etherpad [1], where you could see all the "groups" of people that OSA need, and where you could help. Please don't hesitate to edit this etherpad, adding your new special interest group, or simply joining an existing one if you have spare cycles! Thank you! Jean-Philippe Evrard (evrardjp) [1]: https://etherpad.openstack.org/p/osa-liaisons __ 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] [tc] [summary] Organizational diversity tag
> - Drop tags, write a regular report instead that can account for the > subtlety of each situation (ttx). One issue here is that it's obviously a > lot more work than the current situation. That's what I'd prefer personally. We have a website with a nice project navigator now [1]. This is somewhat a reference IMO, and should always be up to date for the published releases. The information is generated, but it could now as well be a static file/source of truth that we update and peer review manually after a cycle. It could allow more flexible and case by case data. This also make the information easy to find: that's naturally where I'd go (if I was an end-user) to see information about a project, not the governance repo. Although now I have learnt, and I am not sure this is worth spending much effort. [1]: https://www.openstack.org/software/project-navigator/ __ 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] [all] [release] How to handle "stable" deliverables releases
Option 2 for me. And the option switch to independant is IMO just fine. __ 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] [Openstack-operators] [openstack-ansible][releases][governance] Change in OSA roles tagging
> Right, you can set the stable-branch-type field to 'tagless' (see > http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n462) and > then set the branch location field to the SHA you want to use. Exactly what I thought. > If you would be ready to branch all of the roles at one time, you could > put all of them into 1 deliverable file. Otherwise, you will want to > split them up into their own files. Same. > > And since you have so many, I will point out that we're really into > automation over here on the release team, and if you wanted to work on > making the edit-deliverable command smart enough to determine the SHA > for you I could walk you through that code to get you started. Cool. __ 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-dev] [openstack-ansible][releases][governance] Change in OSA roles tagging
Hello, *TL:DR;* If you are an openstack-ansible user, consuming our roles directly, with tags, without using openstack-ansible plays or integrated repo, then things will change for you. Start using git shas instead of tags. All other openstack-ansible users should not see a difference, even if they use openstack-ansible tags. During the summit, I had a discussion with dhellman (and smcginnis) to change how openstack-ansible does its releases. Currently, we tag openstack-ansible + many roles under our umbrella every two weeks. As far as I know, nobody requested to have roles tagged every two weeks. Only OpenStack-Ansible need to be tagged for consumption. Even people using our roles directly outside openstack-ansible generally use sha for roles. We don't rely on ansible galaxy. Because there is no need to tag the roles, there is no need to make them part of the "openstack-ansible" deliverable [1][2]. I will therefore clarify the governance repo for that, separating the roles, each of them with their own deliverable, instead of grouping some roles within openstack-ansible, and some others outside it. With this done, a release of openstack-ansible becomes straightforward using the standard release tooling. The releases of openstack-ansible becomes far simpler to request, review, and will not have timeouts anymore :p There are a few issues I see from the change. Still according to the discussion, it seems we can overcome those. 1. As this will be applied on all the branches, we may reach some issues with releasing in the next days. While the validate tooling of releases has shown me that it wouldn't be a problem (just warning) to not have all the repos in the deliverable, I would expect a governance change could be impactful. However, that is only impacting openstack-ansible, releases, and governance team: Keep in mind, openstack-ansible will not change for its users, and will still be tagged as you know it. 2. We will keep branching our roles the same way we do now. What we liked for roles being part of this deliverable, is the ability of having them automatically branched and their files adapted. To what I heard, it is still possible to do so, by having a devstack-like behavior, which branches on a sha, instead of branching on tag. So I guess it means all our roles will now be part of release files like this one [3], or even on a single release file, similar to it. What I would like to have, from this email, is: 1. Raise awareness to all the involved parties; 2. Confirmation we can go ahead, from a governance standpoint; 3. Confirmation we can still benefit from this automatic branch tooling. Thank you in advance. Jean-Philippe Evrard (evrardjp) [1]: https://github.com/openstack/governance/blob/8215c5fd9b464b332b310bbb767812fefc5d9174/reference/projects.yaml#L2493-L2540 [2]: https://github.com/openstack/releases/blob/9db5991707458bbf26a4dd9f55c2a01fee96a45d/deliverables/queens/openstack-ansible.yaml#L768-L851 [3]: https://github.com/openstack/releases/blob/9db5991707458bbf26a4dd9f55c2a01fee96a45d/deliverables/queens/devstack.yaml __ 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] [tc] Organizational diversity tag
Sorry if I missed/repeat something already said in this thread... When I am looking at diversity, I generally like to know: 1) what's going on "right now", and 2) what happened in the cycle x. I think these 2 are different problems to solve. And tags are, IMO, best applied to the second case. So if I focus on the second: What if we are only tagging once per cycle, after the release? (I am pushing the idea further than the quarter basically). It would avoid flappiness (if that's a proper term?). For me, a cycle has a clear meaning. And involvements can balance out in a cycle. This would be, IMO, good enough to promote/declare diversity after the facts (and is an answer to the "what happened during the cycle"). Jean-Philippe Evrard (evrardjp) __ 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] [docs][openstack-ansible]
Can't. use. words. Much sadness! But happiness for you and your future, at the same time :) It was a pleasure to work on your side. https://media.giphy.com/media/IcGkqdUmYLFGE/giphy.gif __ 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] [all][tc][ptls] final stages of python 3 transition
We've been juggling with python3, ansible and multiple distros for a while now. That dance hasn't been fruitful: many hidden issues, either due to ansible modules, or our own modules, or upgrade issues. I've recently decided to simplify the python2/3 story. Queens and all the stable branches will be python2 only (python3 will not be used anymore, to simplify the code) For Rocky, we plan to use as much as possible the distribution packages for the python stack, if it's recent enough for our source installs. Ubuntu 16.04 will have python2, SUSE has python2, CentOS has no appropriate package, so we are pip installing things (and using python2). So... If people work on Ubuntu 18.04 support, we could try a python3 only system. Nobody worked on it right now. Same for CentOS, because there is no usage of packages, we could use Software Collections and have centos as a python3 only system. Sadly, nobody has the cycles to do it now. I am expecting we'll be using/seeing a lot more python3 in the future with S, and wish for a python3 only "S" release. But this solely depends on the work done in R to make sure 18.04 is ready, as this would be our example, and "stepping stone" towards both python2 and python3. I am not sure this answers your question, as this is more gray than a black or white answer. But I am hoping we'll stabilize python3 this cycle, for ubuntu 18.04 at least, and other distros as a stretch goal. Best regards, Jean-Philippe Evrard (evrardjp) __ 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] [openstack-ansible] Implement rotations for meetings handling
I think Jesse sumarized things elegantly. Here is an analogy for you, to complement the answer with more background. Let me compare our state with a new company, as this is a a notion people many people can relate to. Initially we were a startup. Only a few people were working on OSA on its creation. And they were busy doing everything. But then we grew, and we continue to grow. At some point, those few people doing everything didn't (or don't) have the time to do everything anymore (because of the growing nature). So OSA, like any business, needs to learn how to grow bigger. One of the way is to distribute work as much as we can into the more appropriate persons. We started doing that by distributing core duties for roles. We are now adding the meeting organisation. I have a few other ideas where shared ownership will help the project mature and allow more growth in the future, but one step at a time :) Best regards, Jean-Philippe Evrard (evrardjp) __ 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-dev] [openstack-ansible] Implement rotations for meetings handling
Hello everyone, Now that we are all part-time, I'd like to toy with a new idea, proposed in the past by Jesse, to rotate the duties with people who are involved in OSA, or want to get involved more (it's not restricted to core developers!). One of the first duties to be handled this way could be the weekly meeting. Handling the meeting is not that hard, it just takes time to prepare, and to facilitate. I think everyone should step into this, not only core developers, but core developers are now expected to run the meetings when their turn comes. What are the actions to take: - Prepare the triage. Generate the list of the bugs for the week. - Ping people with the triage links around 1h before the weekly meeting. It would give them time to get prepared for meeting, eventually updating the agenda, and read the current bugs - Ping people at the beginning of the meeting - Chair the meeting: The structure of the meeting is now always the same, a recap of the week, and handling the bug triage. - After the meeting we would ask who is volunteer to run next meeting, and if none, a meeting char will be selected amongst core contributors at random. Thank you for your understanding. Jean-Philippe Evrard (evrardjp) __ 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] [OpenStackAnsible] Tag repos as newton-eol
Hello, > I'd like to phase out openstack/openstack-ansible-tests and > openstack/openstack-ansible later. Now that we had the time to bump the roles in openstack-ansible, and adapt the tests, we can now EOL the rest of newton, i.e.: openstack/openstack-ansible and openstack/openstack-ansible-tests. Thanks for the help again Tony! JP __ 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-dev] [openstack-ansible] Proposing Mohammed Naser as core reviewer
Hi everyone, I’d like to propose Mohammed Naser [1] as a core reviewer for OpenStack-Ansible. He has been working actively on fixing the telemetry stack, and is now willing to step up to improve the CentOS platform which is now in a very degraded state. I feel that it’s important that he’s able to safeguard the existing and future work about CentOS and help grow the maintenance community for it. [1] http://stackalytics.com/?module=openstackansible-group_id=mnaser=rocky=person-day Best regards, Jean-Philippe Evrard IRC: evrardjp __ 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] [all][infra] ubuntu-bionic and legacy nodesets
That's very cool. Any idea of the repartition of nodes xenial vs bionic? Is that a very restricted amount of nodes? On 20 April 2018 at 00:37, Paul Belangerwrote: > Greetings, > > With ubuntu-bionic release around the corner we'll be starting discussions > about > migrating jobs from ubuntu-xenial to ubuntu-bionic. > > On topic I'd like to raise, is round job migrations from legacy to native > zuulv3. Specifically, I'd like to propose we do not add legacy-ubuntu-bionic > nodesets into openstack-zuul-jobs. Projects should be working towards moving > away from the legacy format, as they were just copypasta from our previous JJB > templates. > > Projects would still be free to move them intree, but I would highly encourage > projects do not do this, as it only delays the issue. > > The good news is the majority of jobs have already been moved to native zuulv3 > jobs, but there are still some projects still depending on the legacy > nodesets. > For example, tox bases jobs would not be affected. It mostly would be dsvm > based jobs that haven't been switch to use the new devstack jobs for zuulv3. > > -Paul > > __ > 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] [openstack-ansible] Problems with Openstack services while migrating VMs
Maybe worth posting on operators, but it looks like the scheduling of the action fails, which let me think that nova is not running fine somewhere. Why is the restart in a random order? That can cause issues, and that's the whole reason why we are orchestrating the deploys/upgrade with ansible. Also, why don't you follow our operations guide for recovering for a failure? Is there something wrong there? Regards, JP On 17 April 2018 at 14:07, Periyasamy Palanisamywrote: > Hi, > > > > I’m trying to migrate controller and compute VMs installed with > Openstack-Ansible across systems with following approach. > > This is mainly to minimize the deployment time in the Jenkins CI > environment. > > > > Export steps: > > Power off the VMs gracefully. > virsh dumpxml ${node} > $EXPORT_PATH/${node}.xml > cp /var/lib/libvirt/images/${node}.qcow2 $EXPORT_PATH/$node.qcow2 > create a tar ball for the xml’s and qcow2 images. > > > > Import steps: > > cp ${node}.qcow2 /var/lib/libvirt/images/ > virsh define ${node}.xml > virsh start ${node} > > > > After the import of the VMs, The openstack services (neutron-server, DHCP > agent, Metering agent, Metadata agent, L3 agent, Open vSwitch agent, > nova-conductor and nova-comute) are started in random order. > > This causes neutron and nova is not able to find DHCP agent and compute > accordingly to bring up the tenant VM and throws the error [1]. > > > > I have also tried to boot compute VM followed by controller VM. It also > doesn’t help. > > Could you please let me know what is going wrong here ? > > > > [1] https://paste.ubuntu.com/p/YNg2NnjvpS/ (fault section) > > > > Thanks, > > Periyasamy > > > __ > 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
[openstack-dev] [openstack-ansible] We need to change!
Dear community, Starting at the end of this month, I won't be able to work full time on OpenStack-Ansible anymore. I want to highlight the following: Our current way of working is not sustainable in the long run, as a lot of work (and therefore pressure) is concentrated on a few individuals. I managed to get more people working on some parts of our code (becoming cores on specific areas of knowledge, like mbuil on networking, mnaser and gokhan on telemetry, johnsom on octavia, mugsie on designate), but at the same time we have lost a core reviewer on all our code base (mhayden). I like the fact we are still innovating with our own deployment tooling, bringing more features in, changing the deployment models to be always more stable, more user-friendly. But new features aren't all. We need people actively looking at the quality of existing deliverables. We need to stretch those responsibilities to more people. I would be very happy if some people using OpenStack-Ansible would help on: * Bugs. We are reaching an all-time high amount of bugs pending. We need people actively cleaning those. We need someone to organize a bug smash. We need people willing to lead the bug triage process too. * Releases. Our current release process is manual. People interested by how releases are handled should step in there (for example, what does in, and at what time). We also need to coordinate with the releases team, and improve our way to release. * Jobs/state monitoring. I have spent an insane amount of time cleaning up after other people. That cannot be done any longer. If you're breaking a job, whether it's part of the openstack-ansible gates or not, you should be fixing it. Even if it's a non-voting job, or a periodic job. I'd like everyone to monitor our zuul dashboard, and take action based on that. When queens was close to release, everything job was green on the zuul dashboard. I did an experiment of 1 month without me fixing the upgrade jobs, and guess what: ALL (or almost ALL) the upgrade jobs are now broken. Please monitor [1] and actively help fixing the jobs. Remember, if everyone works on this, it would give a great feedback to new users, and it becomes a virtuous cycle. * Reduce technical debt. We have so many variables, so many remnants of the past. This cycle is planned to be a cleanup. Let's simplify all of this, making sure the deployment of openstack with openstack-ansible ends up with a system KISS. * Increasing voting test coverage. We need more code paths tested and we need those code path preventing bad patches to merge. It makes the reduction of technical debt easier. Really thank you for your understanding. Best regards, Jean-Philippe (evrardjp) [1]: http://zuul.openstack.org/builds.html?pipeline=periodic=openstack%2Fopenstack-ansible __ 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] [openstack-ansible] Stepping down from OpenStack-Ansible core
Hello, Ahah, gate job breakages? You were the first to break them, but also willing to step in to fix them as soon as you knew. And that's the part I will remember the most. You will be missed, Major. Your next team is lucky to have you! It was a pleasure working with you. And the gifs, omagad! :) JP On 27 March 2018 at 12:11, Jesse Pretoriuswrote: > Ah Major, we shall definitely miss your readiness to help, positive attitude > and deep care for setenforce 1. Oh, and then there're the gifs... so many > gifs... > > While I am inclined to [1], I shall instead wish you well while you [2]. ( > > [1] https://media.giphy.com/media/1BXa2alBjrCXC/giphy.gif > [2] https://media.giphy.com/media/G6if3AWViiNdC/giphy.gif > > > On 3/26/18, 2:07 PM, "Major Hayden" wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hey there, > > As promised, I am stepping down from being an OpenStack-Ansible core > reviewer since I am unable to meet the obligations of the role with my new > job. :( > > Thanks to everyone who has mentored me along the way and put up with my > gate job breakages. I have learned an incredible amount about OpenStack, > Ansible, complex software deployments, and open source communities. I > appreciate everyone's support as I worked through the creation of the > ansible-hardening role as well as adding CentOS support for OpenStack-Ansible. > > - -- > Major Hayden > -BEGIN PGP SIGNATURE- > > iQIzBAEBCAAdFiEEG/mSZJWWADNpjCUrc3BR4MEBH7EFAlq4774ACgkQc3BR4MEB > H7E+gA/9HJEDibsQhdy191NbxbhF75wUup3gRDHhGPI6eFqHo/Iz8Q5Kv9Z9CXbo > rkBGMebbGzoKwiLnKbFWr448azMJkj5/bTRLHb1eDQg2S2xaywP2L4e0CU+Gouto > DucmGT6uLg+LKdQByYTB8VAHelub4DoxV2LhwsH+uYgWp6rZ2tB2nEIDTYQihhGx > /WukfG+3zA99RZQjWRHmfnb6djB8sONzGIM8qY4qDUw9Xjp5xguHOU4+lzn4Fq6B > cEpsJnztuEYnEpeTjynu4Dc8g+PX8y8fcObhcj+1D0NkZ1qW7sdX6CA64wuYOqec > S552ej/fR5FPRKLHF3y8rbtNIlK5qfpNPE4UFKuVLjGSTSBz4Kp9cGn2jNCzyw5c > aDQs/wQHIiUECzY+oqU1RHZJf9/Yq1VVw3vio+Dye1IMgkoaNpmX9lTcNw9wb1i7 > lac+fm0e438D+c+YZAttmHBCCaVWgKdGxH7BY84FoQaXRcaJ9y3ZoDEx6Rr8poBQ > pK4YjUzVP9La2f/7S1QemX2ficisCbX+MVmAX9G4Yr9U2n98aXVWFMaF4As1H+OS > zm9r9saoAZr6Z8BxjROjoClrg97RN1zkPseUDwMQwlJwF3V33ye3ib1dYWRr7BSm > zAht+Jih/JE6Xtp+5UEF+6TBCYFVtXO8OHzCcac14w9dy1ur900= > =fx64 > -END PGP SIGNATURE- > > __ > 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 > > > > > Rackspace Limited is a company registered in England & Wales (company > registered number 03897010) whose registered office is at 5 Millington Road, > Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be > viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may > contain confidential or privileged information intended for the recipient. > Any dissemination, distribution or copying of the enclosed material is > prohibited. If you receive this transmission in error, please notify us > immediately by e-mail at ab...@rackspace.com and delete the original message. > Your cooperation is appreciated. > __ > 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] [stable][release] Remove complex ACL changes around releases
LGTM __ 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-dev] [OpenStack-Ansible] Vancouver forum etherpad
Dear OpenStack-Ansiblers, We've got an etherpad here [1], to track all the things we want to discuss at the forum. if you're an OpenStack-Ansible user, don't hesitate to add your session ideas, list what you liked or disliked in the last release, and share your experience! Thank you in advance. [1]: https://etherpad.openstack.org/p/YVR-openstack-ansible-brainstorming Best regards, Jean-Philippe. __ 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] [charms] [tripleo] [puppet] [fuel] [kolla] [openstack-ansible] [cloudcafe] [magnum] [mogan] [sahara] [shovel] [watcher] [helm] [rally] Heads up: ironic classic drivers deprecation
Hello, Thanks for the notice! JP On 16 March 2018 at 12:09, Dmitry Tantsurwrote: > Hi all, > > If you see your project name in the subject that is because a global search > revived usage of "pxe_ipmitool", "agent_ipmitool" or "pxe_ssh" drivers in > the non-unit-test context in one or more of your repositories. > > The classic drivers, such as pxe_ipmitool, were deprecated in Queens, and > we're on track with removing them in Rocky. Please read [1] about > differences between classic drivers and newer hardware types. Please refer > to [2] on how to update your code. > > Finally, the pxe_ssh driver was removed some time ago. Please use the > standard IPMI driver with the virtualbmc project [3] instead. > > Please reach out to the ironic team (here or on #openstack-ironic) if you > have any questions or need help with the transition. > > Dmitry > > [1] https://docs.openstack.org/ironic/latest/install/enabling-drivers.html > [2] > https://docs.openstack.org/ironic/latest/admin/upgrade-to-hardware-types.html > [3] https://github.com/openstack/virtualbmc > > __ > 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] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime
Thanks! On 16 March 2018 at 16:56, Doug Hellmann <d...@doughellmann.com> wrote: > Excerpts from Jeremy Stanley's message of 2018-03-16 13:43:00 +: >> On 2018-03-16 08:34:28 -0500 (-0500), Sean McGinnis wrote: >> > On Mar 16, 2018, at 04:02, Jean-Philippe Evrard <jean-phili...@evrard.me> >> > wrote: >> > >> > > For OpenStack-Ansible, we don't need to do anything for that >> > > community goal. I am not sure how we can remove our name from >> > > the storyboard, so I just inform you here. >> > >> > I believe you can just mark the task as done if there is no >> > additional work required. >> >> Yeah, either "merged" or "invalid" states should work. I'd lean >> toward suggesting "invalid" in this case since the task did not >> require any changes merged to your source code. > > Yes, we've been using "invalid" to indicate that no work was needed. > > Doug > > __ > 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] [ALL][PTLs] Community Goals for Rocky: Toggle the debug option at runtime
Hello, For OpenStack-Ansible, we don't need to do anything for that community goal. I am not sure how we can remove our name from the storyboard, so I just inform you here. Jean-Philippe Evrard (evrardjp) On 28 February 2018 at 05:27, ChangBo Guo <glongw...@gmail.com> wrote: > Hi ALL, > > TC approved the goal [0] a week ago , so it's time to finish the work. we > also have a short discussion in oslo meeting at PTG, find more details in > [1] , > we use storyboard to check the goal in > https://storyboard.openstack.org/#!/story/2001545. It's appreciated PTL set > the owner in time . > Feel free to reach me( gcb) in IRC if you have any questions. > > > [0] https://review.openstack.org/#/c/534605/ > [1] https://etherpad.openstack.org/p/oslo-ptg-rocky From line 175 > > -- > ChangBo Guo(gcb) > Community Director @EasyStack > > __ > 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] [infra][all] Anyone using our ubuntu-mariadb mirror?
Hello, We were using it until a couple of weeks ago, when 10.1.31 got out. 10.1.31 got issues with clustering and we moved to use a mirror of 10.1. (here 10.1.30), instead of 10.1. We haven't decided if we'll move back to 10.1 when 10.1.32 will be out. You can remove it for now, I think we can discuss this again when 10.1.32 will be out. Best regards, JP On 14 March 2018 at 22:50, Ian Wienandwrote: > Hello, > > We discovered an issue with our mariadb package mirroring that > suggests it hasn't been updating for some time. > > This would be packages from > > http://mirror.X.Y.openstack.org/ubuntu-mariadb/10.<1|2> > > This was originally added in [1]. AFAICT from codesearch, it is > currently unused. We export the top-level directory in the mirror > config scripts as NODEPOOL_MARIADB_MIRROR, which is not referenced in > any jobs [2], and I couldn't find anything setting up apt repos > pointing to it. > > Thus since it's not updating and nothing seems to reference it, I am > going to assume it is unused and remove it next week. If not, please > respond and we can organise a fix. > > -i > > [1] https://review.openstack.org/#/c/307831/ > [2] > http://codesearch.openstack.org/?q=NODEPOOL_MARIADB_MIRROR=nope== > > __ > 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] OpenStack Ansible Disk requirements [docs] [osa]
Hello, That's what it always was, but it was hidden in the pages. Now that I refactored the pages to be more visible, you spotted it :) Congratulations! More seriously, I'd like to remove that requirement, showing people can do whatever they like. It all depends on how/where they store images, ephemeral storage... Will commit a patch today. Best regards, Jean-Philippe Evrard On 15 March 2018 at 18:31, Gordon, Kent S <kent.gor...@verizonwireless.com> wrote: > Compute host disk requirements for Openstack Ansible seem high in the > documentation. > > I think I have used smaller compute hosts in the past. > Did something change in Queens? > > https://docs.openstack.org/project-deploy-guide/openstack-ansible/latest/overview-requirements.html > > > Compute hosts > > Disk space requirements depend on the total number of instances running on > each host and the amount of disk space allocated to each instance. > > Compute hosts must have a minimum of 1 TB of disk space available. > > > > > -- > Kent S. Gordon > kent.gor...@verizonwireless.com Work:682-831-3601 Mobile: 817-905-6518 > > __ > 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] [OpenStackAnsible] Tag repos as newton-eol
Looks good to me. On 15 March 2018 at 01:11, Tony Breeds <t...@bakeyournoodle.com> wrote: > On Wed, Mar 14, 2018 at 09:40:33PM +0000, Jean-Philippe Evrard wrote: >> Hello folks, >> >> The list is almost perfect: you can do all of those except >> openstack/openstack-ansible-tests. >> I'd like to phase out openstack/openstack-ansible-tests and >> openstack/openstack-ansible later. > > Okay excluding the 2 repos above and filtering out projects that don't > have newton branches we came down to: > > # EOL repos belonging to OpenStackAnsible > eol_branch.sh -- stable/newton newton-eol \ > openstack/ansible-hardening \ > openstack/openstack-ansible-apt_package_pinning \ > openstack/openstack-ansible-ceph_client \ > openstack/openstack-ansible-galera_client \ > openstack/openstack-ansible-galera_server \ > openstack/openstack-ansible-haproxy_server \ > openstack/openstack-ansible-lxc_container_create \ > openstack/openstack-ansible-lxc_hosts \ > openstack/openstack-ansible-memcached_server \ > openstack/openstack-ansible-openstack_hosts \ > openstack/openstack-ansible-openstack_openrc \ > openstack/openstack-ansible-ops \ > openstack/openstack-ansible-os_aodh \ > openstack/openstack-ansible-os_ceilometer \ > openstack/openstack-ansible-os_cinder \ > openstack/openstack-ansible-os_glance \ > openstack/openstack-ansible-os_gnocchi \ > openstack/openstack-ansible-os_heat \ > openstack/openstack-ansible-os_horizon \ > openstack/openstack-ansible-os_ironic \ > openstack/openstack-ansible-os_keystone \ > openstack/openstack-ansible-os_magnum \ > openstack/openstack-ansible-os_neutron \ > openstack/openstack-ansible-os_nova \ > openstack/openstack-ansible-os_rally \ > openstack/openstack-ansible-os_sahara \ > openstack/openstack-ansible-os_swift \ > openstack/openstack-ansible-os_tempest \ > openstack/openstack-ansible-pip_install \ > openstack/openstack-ansible-plugins \ > openstack/openstack-ansible-rabbitmq_server \ > openstack/openstack-ansible-repo_build \ > openstack/openstack-ansible-repo_server \ > openstack/openstack-ansible-rsyslog_client \ > openstack/openstack-ansible-rsyslog_server \ > openstack/openstack-ansible-security > > If you confirm I have the list right this time I'll work on this tomorrow > > Yours Tony. > > __ > 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] [OpenStackAnsible] Tag repos as newton-eol
Hello folks, The list is almost perfect: you can do all of those except openstack/openstack-ansible-tests. I'd like to phase out openstack/openstack-ansible-tests and openstack/openstack-ansible later. JP On 14 March 2018 at 21:20, Tony Breedswrote: > Hi all, > JP has asked me to to work with infra to tag the newton branches of > the following repos as EOL: > > > openstack/ansible-hardening > openstack/openstack-ansible-apt_package_pinning > openstack/openstack-ansible-ceph_client > openstack/openstack-ansible-galera_client > openstack/openstack-ansible-galera_server > openstack/openstack-ansible-haproxy_server > openstack/openstack-ansible-lxc_container_create > openstack/openstack-ansible-lxc_hosts > openstack/openstack-ansible-memcached_server > openstack/openstack-ansible-nspawn_container_create > openstack/openstack-ansible-nspawn_hosts > openstack/openstack-ansible-openstack_hosts > openstack/openstack-ansible-openstack_openrc > openstack/openstack-ansible-os_aodh > openstack/openstack-ansible-os_barbican > openstack/openstack-ansible-os_ceilometer > openstack/openstack-ansible-os_cinder > openstack/openstack-ansible-os_designate > openstack/openstack-ansible-os_glance > openstack/openstack-ansible-os_gnocchi > openstack/openstack-ansible-os_heat > openstack/openstack-ansible-os_horizon > openstack/openstack-ansible-os_ironic > openstack/openstack-ansible-os_keystone > openstack/openstack-ansible-os_magnum > openstack/openstack-ansible-os_molteniron > openstack/openstack-ansible-os_neutron > openstack/openstack-ansible-os_nova > openstack/openstack-ansible-os_octavia > openstack/openstack-ansible-os_panko > openstack/openstack-ansible-os_rally > openstack/openstack-ansible-os_sahara > openstack/openstack-ansible-os_swift > openstack/openstack-ansible-os_tacker > openstack/openstack-ansible-os_tempest > openstack/openstack-ansible-os_trove > openstack/openstack-ansible-pip_install > openstack/openstack-ansible-pip_lock_down > openstack/openstack-ansible-plugins > openstack/openstack-ansible-rabbitmq_server > openstack/openstack-ansible-repo_build > openstack/openstack-ansible-repo_server > openstack/openstack-ansible-rsyslog_client > openstack/openstack-ansible-rsyslog_server > openstack/openstack-ansible-security > openstack/openstack-ansible-ops > openstack/openstack-ansible-os_almanach > openstack/openstack-ansible-os_cloudkitty > openstack/openstack-ansible-os_congress > openstack/openstack-ansible-os_freezer > openstack/openstack-ansible-os_karbor > openstack/openstack-ansible-os_monasca > openstack/openstack-ansible-os_monasca-agent > openstack/openstack-ansible-os_monasca-ui > openstack/openstack-ansible-os_searchlight > openstack/openstack-ansible-os_watcher > openstack/openstack-ansible-os_zaqar > openstack/openstack-ansible-specs > openstack/openstack-ansible-tests > > I'll process that this week after getting an ACK from JP > > > Yours Tony. > > __ > 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] [openstack-ansible] Meetings change (PTG discussion follow-up)
Hello, We discussed the problem of the miscommunication at the PTG, and we agreed the focus of the week solved many things for clarity. I am not sure we need to send a ML summary, if all is recorded in the meeting each week: people can just browse meetings for this info. I have no strong opinion about office hours: - it is more formal than our ad-hoc dicussions (more than necessary?).; - it helps for timezones: We can have different office hours (US based/Europe based) for discussing things; - it can be reported during Tuesday's meeting. Let's discuss this on the chan and validate next Tuesday I guess :) Because there were no strong against the meeting time change/format we should go ahead on the change of the community meetings. So from now on, until daylight saving applies to Europe, we should have the meetings on Tuesday at 5PM UTC. Thanks everyone! On 6 March 2018 at 16:08, Amy Marrich <a...@demarco.com> wrote: > JP, > > When the Community meeting was moved to once a month there was a lot of > resulting miscommunication as a result. If a weekly review is going to be > sent to the mailing list with channel discussions is going to be sent out, I > think that's a good alternative but the conversations still need to take > place and as many people involved as possible. What about having office > hours? > > Amy (spotz) > > On Tue, Mar 6, 2018 at 9:51 AM, Jean-Philippe Evrard > <jean-phili...@evrard.me> wrote: >> >> Hello, >> >> During the PTG, we've discussed about changing our meetings. >> I'd like to have a written evidence in our mailing lists, showing what >> we discussed, and what we proposed to change. I propose we validate >> those changes if they get no opposition in the next 7 days (deadline: >> 13 March). >> >> What we discussed was: >> - Should the meetings be rescheduled, and at what time; >> - Should the meetings be happening in alternance for US/Europe >> friendly timezones; >> - What is the purpose/expected outcome of those meetings; >> - What is the reason the attendance is low. >> >> The summary is the following: >> - The expected outcome of bug triage is currently (drumroll) >> actively triaging bugs which produces better deliverables (what a >> surprise!). >> - The expected outcome of the community meeting is to discuss about >> what we actively need to work on together, but we are doing these kind >> of conversations, ad-hoc, in the channel. So if we summarize things on >> a regular basis to make sure everyone is aware of the conversations, >> we should be good. >> - The timezone friendly things won't impact the attendance positively. >> - Right now, the Europe meetings can be postponed of one hour, but >> decision should be re-discussed with daylight saving. >> - A lot of ppl have meetings at 4PM UTC right now. >> >> As such, here is the PTG proposed change: >> - Moving the bug triage meeting to 5PM UTC until next daylight saving >> change. >> - Keep the "Focus of the week" section of the bug triage, to list what >> we discussed in the week (if more conversations have to happen, they >> can happen just after the bug triage) >> - Removing the community meeting. >> >> Any opposition there? If we are all okay, I will update our procedures >> next week. >> >> Best regards, >> JP >> >> __ >> 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 > __ 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-dev] [openstack-ansible] Meetings change (PTG discussion follow-up)
Hello, During the PTG, we've discussed about changing our meetings. I'd like to have a written evidence in our mailing lists, showing what we discussed, and what we proposed to change. I propose we validate those changes if they get no opposition in the next 7 days (deadline: 13 March). What we discussed was: - Should the meetings be rescheduled, and at what time; - Should the meetings be happening in alternance for US/Europe friendly timezones; - What is the purpose/expected outcome of those meetings; - What is the reason the attendance is low. The summary is the following: - The expected outcome of bug triage is currently (drumroll) actively triaging bugs which produces better deliverables (what a surprise!). - The expected outcome of the community meeting is to discuss about what we actively need to work on together, but we are doing these kind of conversations, ad-hoc, in the channel. So if we summarize things on a regular basis to make sure everyone is aware of the conversations, we should be good. - The timezone friendly things won't impact the attendance positively. - Right now, the Europe meetings can be postponed of one hour, but decision should be re-discussed with daylight saving. - A lot of ppl have meetings at 4PM UTC right now. As such, here is the PTG proposed change: - Moving the bug triage meeting to 5PM UTC until next daylight saving change. - Keep the "Focus of the week" section of the bug triage, to list what we discussed in the week (if more conversations have to happen, they can happen just after the bug triage) - Removing the community meeting. Any opposition there? If we are all okay, I will update our procedures next week. Best regards, JP __ 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-dev] [openstack-ansible] Roles not passing functional tests
Dear community, We are everyday closer to the end of the cycle, and the following roles seem not ready for integration into the next release, because they are failing their own gates's functional testing for more than two weeks: - os_ceilometer - os_aodh - os_trove - os_magnum Following the guidelines of the role maturity downgrade procedure [1], I am sending you a list of bugs that needs fixing: - magnum [2] - trove [3] - aodh [4] - ceilometer [5] According to the same guidelines, if nobody fixes those bugs until the next community meeting, those roles's maturity index will be moved to unmaintained, and will eventually be removed from release. Thank you for your understanding, Jean-Philippe Evrard (evrardjp) [1]: https://docs.openstack.org/openstack-ansible/latest/contributor/additional-roles.html#maturity-downgrade-procedure [2]: https://bugs.launchpad.net/openstack-ansible/+bug/1747607 [3]: https://bugs.launchpad.net/openstack-ansible/+bug/1747608 [4]: https://bugs.launchpad.net/openstack-ansible/+bug/1747610 [5]: https://bugs.launchpad.net/openstack-ansible/+bug/1747612 __ 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-dev] [openstack-ansible][ptl] PTL candidacy for Rocky
Hello everyone, I would like to announce my candidacy for PTL of the OpenStack-Ansible project for the Rocky cycle. I will focus on a single theme this cycle, simplification. After all the features introduced in Queens cycle, it's time to simplify our work: * Reduce the amount of variables in each role, and/or rename them to a more guessable name. * Make possible to use a source of truth to reduce the amount of glue variables we need. A candidate for source of truth could be etcd, due to its presence in the OpenStack reference architecture. * Simplifying further our "repo build". * Simplifying our tasks, by using convention over configuration (Reducing the group configurability for example). * Reducing the need of our dynamic inventory: everyone should be able to use openstack-ansible with a simple static inventory. * Clarify each role maturity/contributions status. This would make easier for deployers to understand the status of each role, and take the appropriate decisions to whether or not deploy project x or y. If we make it simple to contribute to new roles and playbooks, it would also open us to more contributions and contributors. On top of those simplification topics, I'd like to add the following features in the next cycle, depending on their release timing: * Upgrade to Ansible 2.5 * Support Ubuntu 18.04 I look forward to keep working with you all, and it would be my honor to serve as PTL for the next cycle. Thanks for taking the time to read this and I hope to see you in Dublin, Jean-Philippe Evrard (evrardjp) __ 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] [openstack-ansible] Limiting pip wheel builds for OpenStack clients
I added my comment/opinion on the bug. Thanks for reporting this, Major! __ 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] [all] Switching to longer development cycles
On 13 December 2017 at 16:52, Matt Riedemannwrote: > On 12/13/2017 10:17 AM, Thierry Carrez wrote: >> >> Hi everyone, >> >> Over the past year, it has become pretty obvious to me that our >> self-imposed rhythm no longer matches our natural pace. It feels like we >> are always running elections, feature freeze is always just around the >> corner, we lose too much time to events, and generally the impression >> that there is less time to get things done. Milestones in the >> development cycles are mostly useless now as they fly past us too fast. >> A lot of other people reported that same feeling. > > > On the other hand, without community-wide imposed deadlines and milestones, > we lose some motivation for getting things done by a specific time, which > could mean the bigger and more complicated things drag on longer because > there isn't a deadline. One could say that we just need to be more > disciplined, but in an open source project where there is no boss at the top > setting that deadline and holding people to it, it's hard to be that > disciplined. The PTL can only ask people to work on priorities so much. We could still have community-wide milestones and deadlines. I don't understand the point of "no boss at the top", I don't see how it impacts. You're right on the idea, but I don't see how the cycle length changes that. Do you think milestones have less value/criticality than final release? > >> >> As our various components mature, we have less quick-paced feature >> development going on. As more and more people adopt OpenStack, we are >> more careful about not breaking them, which takes additional time. The >> end result is that getting anything done in OpenStack takes more time >> than it used to, but we have kept our cycle rhythm mostly the same. >> >> Our development pace was also designed for fast development in a time >> where most contributors were full time on OpenStack. But fewer and fewer >> people have 100% of their time to dedicate to OpenStack upstream >> development: a lot of us now have composite jobs or have to participate >> in multiple communities. This is a good thing, and it will only >> accelerate as more and more OpenStack development becomes fueled >> directly by OpenStack operators and users. >> >> In another thread, John Dickinson suggested that we move to one-year >> development cycles, and I've been thinking a lot about it. I now think >> it is actually the right way to reconcile our self-imposed rhythm with >> the current pace of development, and I would like us to consider >> switching to year-long development cycles for coordinated releases as >> soon as possible. >> >> What it means: >> >> - We'd only do one *coordinated* release of the OpenStack components per >> year, and maintain one stable branch per year >> - We'd elect PTLs for one year instead of every 6 months > > > If we're running elections too often, we can do this without a change to a > 1-year dev cycle. I think it's appropriate to sync elections with cycles. > >> - We'd only have one set of community goals per year >> - We'd have only one PTG with all teams each year > > > This is arguably going to impact productivity, not improve it - because > without the face time to hash out the complicated things, they drag on > longer. > >> >> What it does _not_ mean: >> >> - It doesn't mean we'd release components less early or less often. Any >> project that is in feature development or wants to ship changes more >> often is encouraged to use the cycle-with-intermediary release model and >> release very early and very often. It just means that the minimum we'd >> impose for mature components is one release per year instead of one >> release every 6 months. > > > I personally don't expect anyone to pick up these intermediate releases. I > expect most consumers are going to pick up a coordinated release (several > months or years after it's released), especially if that's what the distro > vendors are going to be doing. So Nova could release once per quarter but I > wouldn't expect anyone to pick it up except maybe hosting companies, but not > even sure about that. Our deployment project could/would rely more on upstream intermediate release, so all our consumers would get that at the same time. > >> >> - It doesn't mean that we encourage slowing down and procrastination. >> Each project would be able to set its own pace. We'd actually encourage >> teams to set objectives for the various (now longer) milestones in the >> cycle, and organize virtual sprints to get specific objectives done as a >> group. Slowing down the time will likely let us do a better job at >> organizing the work that is happening within a cycle. > > > As I said above, encouraging teams to do this and teams actually being > disciplined enough to do it are different things. Maybe if we actually did > the runways / slots idea from years past but as I've been reminded by people > many times over the years, you can't
Re: [openstack-dev] [all] Switching to longer development cycles
On 13 December 2017 at 16:49, Jeremy Stanleywrote: > On 2017-12-13 16:45:14 + (+), Chris Jones wrote: > [...] >> For me the first thing that comes to mind with this proposal, is >> how would the milestones/FF/etc be arranged within that year? > [...] > > Excellent point. If it's not too much work for the Release team, it > would be very helpful to have a straw man release schedule for a > year-long Rocky so we can see what that might look like. > -- > Jeremy Stanley > > __ > 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 > Hello, 100% agreed on all of the above. I'd think it would be nice to move to 1 year, starting from Rocky. Thierry, with your position it seems logical that you started this conversation and ask for a TC vote. I guess there will always be happy/unhappy people anyway, so a TC vote seems good. Best regards, JP __ 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] [E] [openstack-ansible] Cannot connect to proxy server from infra1-repo-container
On 7 December 2017 at 14:02, Gordon, Kent S <kent.gor...@verizonwireless.com> wrote: > On Thu, Dec 7, 2017 at 3:24 AM, Goutham Pratapa > <pratapagout...@gmail.com> wrote: >> Hi, >> >> We are trying test environment deployment with OpenStack-ansible pike >> release. After executing setup-hosts.yaml, the lxc-containers were created. >> We have an issue while doing >> apt-get update in infra-repo-container as it couldn't connect to the proxy >> server. >> The strange thing is that the infra-repo-container is not showing ip on any >> interface when checked with ip r. >> >> Could you please help us with this issue. Below are some logs on the >> container and on the host. >> >> E: Failed to fetch >> http://security.ubuntu.com/ubuntu/dists/xenial-security/main/binary-amd64/Packages >> Something wicked happened resolving 'xx.xx.xx.xx:8080' (-9 - Address family >> for hostname not supported) >> >> root@infra1-repo-container-a7a137c4:/# ping xx.xx.xx.xx (proxy server) >> connect: Network is unreachable >> >> On Container: >> >> root@infra1-repo-container-a7a137c4:/# cat /etc/network/interfaces >> # The loopback network interface >> auto lo >> iface lo inet loopback >> # LXC interface, this is ALWAYS assumed to be DHCP. >> auto eth0 >> iface eth0 inet dhcp >> # Load any additional configs >> source /etc/network/interfaces.d/*.cfg >> >> root@infra1-repo-container-a7a137c4:/# cat >> /etc/network/interfaces.d/eth1.cfg >> # Ansible managed >> >> ### start generated network for [ eth1 ] ### >> auto eth1 >> iface eth1 inet static >> address 192.168.124.126 >> netmask 255.255.255.0 >> mtu 1500 >> post-up sysctl -w net.ipv4.conf.$IFACE.arp_notify=1 >> post-up ip link set $IFACE address $(cat /sys/class/net/$IFACE/address) >> ### end generated network for [ eth1 ] ### >> root@infra1-repo-container-a7a137c4:/# route -n >> Kernel IP routing table >> Destination Gateway Genmask Flags Metric RefUse >> Iface >> >> On host: >> >> root@ubuntu:/home/ansible# ifconfig lxcbr0 >> lxcbr0Link encap:Ethernet HWaddr fe:02:f2:ff:bd:86 >> inet addr:10.0.3.1 Bcast:10.0.3.255 Mask:255.255.255.0 >> inet6 addr: fe80::a085:76ff:febb:401d/64 Scope:Link >> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 >> RX packets:691 errors:0 dropped:0 overruns:0 frame:0 >> TX packets:10 errors:0 dropped:0 overruns:0 carrier:0 >> collisions:0 txqueuelen:1000 >> RX bytes:181224 (181.2 KB) TX bytes:828 (828.0 B) >> root@ubuntu:/home/ansible# ip r >> default via 192.168.124.1 dev eno1 >> 10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1 >> 192.168.124.0/24 dev eno1 proto kernel scope link src 192.168.124.28 >> 192.168.124.0/24 dev br-mgmt proto kernel scope link src 192.168.124.28 >> >> >> Thanks in advance... >> >> -- >> Thanks !!! >> Goutham Pratapa >> >> __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev=DwIGaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=Xkn6r0Olgrmyl97VKakpX0o-JiB_old4u22bFbcLdRo=WEmA5tlLT-4nxWR8GoeTS7dM7n6BX52-5ELlKu5-o4c=RjnZBhACZLdykt8ETppf88EEKeePLRoCWZYV060iJw8= >> > > Is a AIO or multi host setup? > > I have found places in openstack ansible that bypass the proxy server > variables. > My memory was is that it was using systemd to fetch files in certain > cases and that systemd did not honor proxy variables. > I have ended up using a secondary proxy on the deployment host along > with a NAT setup > on the deployment host that made sure to send external requests to the proxy. > > > > -- > Kent S. Gordon > kent.gor...@verizonwireless.com Work:682-831-3601 Mobile: 817-905-6518 > > __ > 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 Could you show your bridges on the host too? And your openstack_user_config.yml? When the repo-server gets installed, it installs a reverse proxy. All the nodes are then configured to use the repo server(s).
Re: [openstack-dev] [all] Dublin PTG format
On 29 November 2017 at 03:20, Masayuki Igawawrote: > On 11/28, Ghanshyam Mann wrote: >> Mon-Tue/Wed-Fri works as most suitable format. There are always >> conflict for many of us but that can be adjusted by working with team >> planning. >> >> Another thing can help is to give flexibility to team to have team >> topic even on Mon-Tue, which mean team need dedicated room on Mon-Tue >> also. For example, if QA want to discuss few of the topic on Mon-Tue >> and have Code sprint/Help room etc on rest of week. This can help me >> or other QA members to join other team discussion on Wed-Fri. But that >> is based on special request and team requirement of number of topics >> to discuss. >> >> morning/afternoon format will be little hectic and less productive due >> to changing rooms and topic etc, at least for me :) > > Yeah, I totally agree with that. Regarding to the QA team members, > most of members are not dedicated to the upstream work. So, if we can > concentrate on it during the rest of 3 days, the days could be really > productive. And I felt it in the past PTG. > > -- Masayuki > > >> >> -gmann >> >> >> On Mon, Nov 27, 2017 at 7:58 PM, Thierry Carrez >> wrote: >> > Hi everyone, >> > >> > We are in the final step in the process of signing the contract with the >> > PTG venue. We should be able to announce the location this week ! >> > >> > So it's time to start preparing. We'll have 5 days, like in Denver. One >> > thing we'd like to change for this round is to give a bit more >> > flexibility in the topics being discussed, especially in the first two >> > days. >> > >> > In Denver, we selected a number of general "themes" and gave them all a >> > room for 2 days on Monday-Tuesday. Then all the "teams" that wanted a >> > project team meeting could get a room for 2 or 3 days on >> > Wednesday-Friday. That resulted in a bit of flux during the first two >> > days, with a lot of empty rooms as most of the themes did not really >> > need 2 days, and a lot of conflicts were present. >> > >> > For Dublin, the idea would be to still predetermine topics (themes and >> > teams) and assign them rooms in advance. But we would be able to assign >> > smaller amounts of time (per half-day) based on the expressed needs. >> > Beyond those pre-assigned themes/teams we'd add flexibility for other >> > groups to book the remaining available rooms in 90-min slots on-demand. >> > A bit like how we did reservable rooms in the past, but more integrated >> > with the rest of the event. It would all be driven by the PTGbot, which >> > would show which topic is being discussed in which room, in addition to >> > the current discussion subject within each topic. >> > >> > We have two options in how we do the split for predetermined topics. We >> > used to split the week between Mon-Tue (themes) and Wed-Fri (teams). The >> > general idea there was to allow some people only interested in a team >> > meeting to only attend the second part of the week. However most people >> > attend all 5 days, and during event feedback some people suggested that >> > "themes" should be in the mornings and "teams" in the afternoons (and >> > all Friday). >> > >> > What would be your preference ? The Mon-Tue/Wed-Fri split means less >> > room changes, which make it easier on the events team. So all else being >> > equal we'd rather keep it the way it is, but I'm open to changing it if >> > attendees think it's a good idea. >> > >> > If you have any other suggestion (that we could implement in the 3 >> > months we have between now and the event) please let me know :) >> > >> > -- >> > Thierry Carrez (ttx) >> > >> > __ >> > 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 > > -- > > __ > 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 > I like the 2+3 days format. I'd prefer that to fragmenting. If people want to roam around they are free. On top of that PTG bot is a helper to find what's going to happen next. I heard once (ok, maybe more than once): "If it ain't broke, don't fix it"! Best regards, JP __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [all] Community managed tech/dev blog: Call for opinions and ideas
On 29 November 2017 at 11:30, Thierry Carrezwrote: > Jimmy McArthur wrote: >> Thierry Carrez wrote: >>> Historically blog.o.o used to be our only blog outlet, so almost >>> anything would go in: >>> >>> "OpenStack Events Sponsorship Webinar" >>> "New Foundation Gold Members & Corporate Sponsors" >>> "HP Announces Private Beta Program for OpenStack Cloud" >>> "2016 OpenStack T-Shirt Design Contest" >>> >>> What Josh wants is a curated technical blog, so if we reused blog.o.o >>> for this (and I think it's a good idea), we'd likely want to have a bit >>> more rules on what's appropriate. >> >> Agreed. It's almost solely used for developer digest now and isn't >> frequently updated. Most of the promotion of sponsors and news goes into >> o.o/News, SuperUser, or one of our other marketing channels. It's a good >> time for the community to repurpose it :) > > Perfect, we have a plan. > > Before we make it tech-only and boring, let us all take a minute to > remember the OpenStack jingle: > > https://www.openstack.org/blog/2011/07/openstack-the-best-sounding-cloud/ I haven't moved. Then I laughed. Thanks for that share Thierry! > > -- > Thierry Carrez (ttx) > > __ > 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
[openstack-dev] [openstack-ansible] Sydney summit -- We'll be there!
Hello everyone, A small delegation of our openstack-ansible team will be in Sydney, and we are looking forward to meeting all of you! We'll have an ops feedback session during the forum happening on Monday 6th, 1:30 pm - 2:10 pm. If you're willing to get started with openstack-ansible, contribute, or get to know us, please join us on Tuesday 7th, 9:50 - 10:30 AM. Last, but not least, if you want to know what happened in openstack-ansible in the last cycle(s) or if you're interested by our future strategy, that would be on Tuesday 7th, 5:50 pm - 6:10 pm during our traditional "Project Update" session. I am looking forward meeting all of you! Best regards, Jean-Philippe Evrard (evrardjp) PS: We have an etherpad listing all these activities and more details about the ops session here: https://etherpad.openstack.org/p/osa-sydney-summit-planning __ 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] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
t;>>>> considering doing first, because I realized it could bring confusion >>>>>> in which projects actually follow the real stable policy and the ones >>>>>> who have exceptions. >>>>>> That's why I thought having a dedicated tag would help to separate >>>>>> them. >>>>>> >>>>>> Proposal 3: no change anywhere, projects like installer can't claim >>>>>> stability etiquette (not my best option in my opinion). >>>>>> >>>>>> Anyway, feedback is welcome, I'm now listening. If you work on Kolla, >>>>>> TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has >>>>>> this need), please get involved in the review process. >>>>> >>>>> >>>>> My preference goes to proposal 1, however rather than call it "relaxed" >>>>> I would make it specific to deployment/lifecycle or cycle-trailing >>>>> projects. >>>>> >>>>> Ideally this policy could get adopted by any such project. The >>>>> discussion started on the review and it's going well, so let's see >>>>> where >>>>> it goes :) >>>> >>>> >>>> Thierry, when I read your comment on Gerrit I understand you prefer to >>>> amend the existing policy and just make a note for installers (which >>>> is I think the option #2 that I proposed). Can you please confirm >>>> that? >>>> So far I see option #1 has large consensus here, I'll wait for >>>> Thierry's answer to continue to work on it. >>>> >>>> Thanks for the feedback so far! >>>> -- >>>> Emilien Macchi >>>> >>>> >>>> ______ >>>> 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 >>> >>> >>> __ >>> 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 >> >> >> >> >> -- >> Emilien Macchi >> >> __ >> 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 > > > -- > @flaper87 > Flavio Percoco > > __ > 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 > I'll be there too. @evrardjp Jean-Philippe Evrard __ 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] [stable] Preping for the stable/newton EOL
On 25 October 2017 at 03:57, Tony Breeds <t...@bakeyournoodle.com> wrote: > On Tue, Oct 24, 2017 at 05:11:15PM +1100, Tony Breeds wrote: >> On Fri, Oct 06, 2017 at 10:15:56AM +1100, Tony Breeds wrote: >> > On Wed, Oct 04, 2017 at 02:51:06PM +1100, Tony Breeds wrote: >> > > I'll prep the list of repos that will be tagged EOL real soon now for >> > > review. >> > >> > As promised here's the list. The fomat is new, It's grouped by project >> > team so it should be easy for teams to find repos they care about. >> > >> > The only wart may be repos I couldn't find an owning team for, so check >> > the '-' as the owning team. >> > >> > I'm proposing to EOL all projects that meet one or more of the following >> > criteria: >> > >> > - The project is openstack-dev/devstack, openstack-dev/grenade or >> > openstack/requirements (although these wil be done last) >> > - The project has the 'check-requirements' job listed as a template in >> > project-config:zuul/layout.yaml >> > - The project gates with either devstack or grenade jobs >> > - The project is listed in governance:reference/projects.yaml and is tagged >> > with 'stable:follows-policy'. >> > >> > >> > Based on previous cycles I have opted out: >> > - 'openstack/group-based-policy' >> > - 'openstack/openstack-ansible' # So they can add EOL tags >> > >> > Also based on recent email's with tripleo I have opted out: >> > - 'openstack/instack' >> > - 'openstack/instack-undercloud' >> > - 'openstack/os-apply-config' >> > - 'openstack/os-collect-config' >> > - 'openstack/os-net-config' >> > - 'openstack/os-refresh-config' >> > - 'openstack/puppet-tripleo' >> > - 'openstack/python-tripleoclient' >> > - 'openstack/tripleo-common' >> > - 'openstack/tripleo-heat-templates' >> > - 'openstack/tripleo-puppet-elements' >> > - 'openstack/tripleo-validations' >> > - 'openstack/tripleo-image-elements' >> > - 'openstack/tripleo-ui' >> >> I've also removed the following repos as the have open release requests >> for stable/newton >> - openstack/nova >> - openstack/ironic >> - openstack/openstack-ansible* >> >> And at the request of the docs team I've omitted: >> - openstack/openstack-manuals >> >> to facilitate 'badging' of the newton docs. > > The repos listed in > http://lists.openstack.org/pipermail/openstack-dev/2017-October/123910.html > have been retired. > > There were a couple of issues > - openstack/deb-python-os-cloud-config > - openstack/bareon > My clones of both had stale gerrit remotes that has been corrected > manually. > > The timing of the next phase is uncertain right now but I'd like to take > care of: > > - openstack/nova > - openstack/ironic > - openstack/openstack-ansible* > - openstack/openstack-manuals > > before the summit if possible. > > Thanks to the infra team for enabling this to happen today. > > Tony. > > __ > 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 > Hello Tony, We'd like to continue doing as before: updating all our upstream projects to their EOL tag, then creating an EOL release based on our roles that would successfully deploy those EOL upstream projects. If any role need a change, due to latest upstream changes, we need to be ready. TL:DR; I'll submit a patch soon to bump our upstream roles to EOL, when nova/ironic will have their EOL tag :p Best regards, Jean-Philippe Evrard (evrardjp) PS: The existing newton release to review was the last bump before EOL, and was submitted during EOL week IIRC. It's good to keep it, this way we are still following our release train, while some EOL tags are not yet issued. __ 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] [All][Elections] Vote Vote Vote in the TC election!
On 20 October 2017 at 22:25, Kendall Nelson <kennelso...@gmail.com> wrote: > > Hello! > > We are coming down to the last hours for voting in the TC election. Voting > ends 23:45 October 20th, 2017. > > Search your gerrit preferred email address[0] for the following subject: > Poll: Queens TC Election > > That is your ballot and links you to the voting application. Please vote. If > you have voted, please encourage your colleagues to vote. > > Candidate statements are linked to the names of all confirmed candidates: > http://governance.openstack.org/election/#pike-tc-candidates > > What to do if you don't see the email and have a commit in at least one of > the official programs projects[1]: > * check the trash of your gerrit Preferred Email address[0], in case it > went into trash or spam > * wait a bit and check again, in case your email server is a bit slow > * find the sha of at least one commit from the program project repos[1] > and email the election officials[2]. If we can confirm that you are entitled > to vote, we will add you to the voters list and you will be emailed a > ballot. > > Please vote! > > Thank you, > > Kendall Nelson (diablo_rojo) > > [0] Sign into review.openstack.org: Go to Settings > Contact > Information. Look at the email listed as your Preferred Email. > That is where the ballot has been sent. > [1]:https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml?id=oct-2017-elections > [2] http://governance.openstack.org/election/#election-officials > > > __ > 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 > Hello, Thanks Kendall and the elections team. It looks the reminders have paid off :) Best regards, Jean-Philippe Evrard (evrardjp) __ 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] [all] [elections] Technical Committee Election Results
On 21 October 2017 at 01:20, Tony Breeds <t...@bakeyournoodle.com> wrote: > > Hi All, > With the election behind us it's somewhat traditional to look at > some simple stats from the elections: > > +--+---+---+---+ > | Election | Electorate (delta %) | Voted (delta %) | Turnout % (delta > %) | > +--+---+---+---+ > | 10/2013 | 1106 (nan) | 342 (nan) | 30.92 ( > nan) | > | 04/2014 | 1510 ( 36.53) | 448 ( 30.99) | 29.67 ( > -4.05) | > | 10/2014 | 1893 ( 25.36) | 506 ( 12.95) | 26.73 ( > -9.91) | > | 04/2015 | 2169 ( 14.58) | 548 ( 8.30) | 25.27 ( > -5.48) | > | 10/2015 | 2759 ( 27.20) | 619 ( 12.96) | 22.44 ( > -11.20) | > | 04/2016 | 3284 ( 19.03) | 652 ( 5.33) | 19.85 ( > -11.51) | > | 10/2016 | 3517 ( 7.10) | 801 ( 22.85) | 22.78 ( > 14.71) | > | 04/2017 | 3191 ( -9.27) | 427 ( -46.69) | 13.38 ( > -41.25) | > | 10/2017 | 2430 ( -23.85) | 420 ( -1.64) | 17.28 ( > 29.16) | > +--+---+---+---+ > > Election CIVS links > 10/2014: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_c105db929e6c11f4 > 04/2015: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ef1379fee7b94688 > 10/2015: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_4ef58718618691a0 > 04/2016: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_fef5cc22eb3dc27a > 10/2016: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_356e6c1b16904010 > 04/2017: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_072c4cd7ff0673b5 > 10/2017: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_ce86063991ef8aae > > I don't have a feel for with the Pike electorate decreased but my gut > feel is that it was organic drop-off possibly in part to the shorter > Ocata development cycle. The Queens drop-off was due to a new[1] > membership API being available that meant we could validate Foundation > membership instead of using gerrit permission as a proxy. > > I'd like to call out that with Pike we had a very dramatic decrease in > voter turnout both in absolute and relative terms. As a community it's > worth trying to understand whether this is a problem and/or a trend that > needs to change. > > Yours Tony. > > [1] It wasn't that new it was also used during the PTL election[2] > [2] See: > http://lists.openstack.org/pipermail/openstack-dev/2017-July/119786.html > ; and > http://lists.openstack.org/pipermail/openstack-dev/2017-August/120544.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 > Very interesting analysis. I agree, we should care about not repeating this Pike trend. It looks like Queens is better in terms of turnout (see the amazing positive delta!). However, I can't help but noticing that the trend for turnouts is slowly reducing (excluding some outliers) since the beginning of these stats. Any idea on how to improve that? On top of that, thanks to all the candidates, and congratulations! Best regards, Jean-Philippe Evrard (evrardjp) __ 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] [ptls] Sydney Forum Project Onboarding Rooms
To be as cool as nova, we'll find nicknames until then. We can probably start with Kevin "Destroy of Clouds" Carter. On 17 October 2017 at 15:28, Jean-Philippe Evrard <jean-phili...@evrard.me> wrote: > Hello, > > I'd be happy to have a room for OpenStack-Ansible. > > I'll be there, and probably more ppl, like Kevin Carter(cloudnull) and > Amy Marrich(spotz). > > Thanks! > > On 17 October 2017 at 03:39, Jeffrey Zhang <zhang.lei@gmail.com> wrote: >> I am the speaker. Michal couldn't be Sydney this summit. >> >> On Tue, Oct 17, 2017 at 1:05 AM, Kendall Nelson <kennelso...@gmail.com> >> wrote: >>> >>> Added Kolla to my list. Would the speakers be you and Michal? >>> >>> -Kendall (diablo_rojo) >>> >>> >>> On Thu, Oct 12, 2017 at 5:51 PM Jeffrey Zhang <zhang.lei@gmail.com> >>> wrote: >>>> >>>> Hi Kendall, >>>> >>>> Kolla project would like to have a on-boarding session too. >>>> >>>> thanks. >>>> >>>> On Fri, Oct 13, 2017 at 5:58 AM, Kendall Nelson <kennelso...@gmail.com> >>>> wrote: >>>>> >>>>> Added Nova to my list with Dan, Melanie, and Ed as speakers. >>>>> >>>>> Thanks Matt, >>>>> -Kendall (diablo_rojo) >>>>> >>>>> On Thu, Oct 12, 2017 at 2:43 PM Matt Riedemann <mriede...@gmail.com> >>>>> wrote: >>>>>> >>>>>> On 10/9/2017 4:24 PM, Kendall Nelson wrote: >>>>>> > Wanted to keep this thread towards the top of inboxes for those I >>>>>> > haven't heard from yet. >>>>>> > >>>>>> > About a 1/4 of the way booked, so there are still slots available! >>>>>> > >>>>>> > -Kendall (diablo_rojo) >>>>>> >>>>>> I've tricked the following people into running a Nova on-boarding room: >>>>>> >>>>>> - "Super" Dan Smith <dansm...@redhat.com> >>>>>> - Melanie "Structured Settlement" Witt <melwi...@gmail.com> >>>>>> - Ed "Alternate Hosts" Leafe <e...@leafe.com> >>>>>> >>>>>> -- >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Matt >>>>>> >>>>>> >>>>>> __ >>>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Jeffrey Zhang >>>> Blog: http://xcodest.me >>>> >>>> __ >>>> 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 >>> >> >> >> >> -- >> Regards, >> Jeffrey Zhang >> Blog: http://xcodest.me >> >> __ >> 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] [ptls] Sydney Forum Project Onboarding Rooms
Hello, I'd be happy to have a room for OpenStack-Ansible. I'll be there, and probably more ppl, like Kevin Carter(cloudnull) and Amy Marrich(spotz). Thanks! On 17 October 2017 at 03:39, Jeffrey Zhangwrote: > I am the speaker. Michal couldn't be Sydney this summit. > > On Tue, Oct 17, 2017 at 1:05 AM, Kendall Nelson > wrote: >> >> Added Kolla to my list. Would the speakers be you and Michal? >> >> -Kendall (diablo_rojo) >> >> >> On Thu, Oct 12, 2017 at 5:51 PM Jeffrey Zhang >> wrote: >>> >>> Hi Kendall, >>> >>> Kolla project would like to have a on-boarding session too. >>> >>> thanks. >>> >>> On Fri, Oct 13, 2017 at 5:58 AM, Kendall Nelson >>> wrote: Added Nova to my list with Dan, Melanie, and Ed as speakers. Thanks Matt, -Kendall (diablo_rojo) On Thu, Oct 12, 2017 at 2:43 PM Matt Riedemann wrote: > > On 10/9/2017 4:24 PM, Kendall Nelson wrote: > > Wanted to keep this thread towards the top of inboxes for those I > > haven't heard from yet. > > > > About a 1/4 of the way booked, so there are still slots available! > > > > -Kendall (diablo_rojo) > > I've tricked the following people into running a Nova on-boarding room: > > - "Super" Dan Smith > - Melanie "Structured Settlement" Witt > - Ed "Alternate Hosts" Leafe > > -- > > Thanks, > > Matt > > > __ > 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 >>> >>> >>> >>> -- >>> Regards, >>> Jeffrey Zhang >>> Blog: http://xcodest.me >>> >>> __ >>> 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 >> > > > > -- > Regards, > Jeffrey Zhang > Blog: http://xcodest.me > > __ > 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] [tc] [stable] [tripleo] [kolla] [ansible] [puppet] Proposing changes in stable policy for installers
On 16 October 2017 at 12:27, Thierry Carrezwrote: > Emilien Macchi wrote: >> [...] >> ## Proposal >> >> Proposal 1: create a new policy that fits for projects like installers. >> I kicked-off something here: https://review.openstack.org/#/c/511968/ >> (open for feedback). >> Content can be read here: >> http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases >> Tag created here: https://review.openstack.org/#/c/511969/ (same, >> please review). >> >> The idea is really to not touch the current stable policy and create a >> new one, more "relax" that suits well for projects like installers. >> >> Proposal 2: change the current policy and be more relax for projects >> like installers. >> I haven't worked on this proposal while it was something I was >> considering doing first, because I realized it could bring confusion >> in which projects actually follow the real stable policy and the ones >> who have exceptions. >> That's why I thought having a dedicated tag would help to separate them. >> >> Proposal 3: no change anywhere, projects like installer can't claim >> stability etiquette (not my best option in my opinion). >> >> Anyway, feedback is welcome, I'm now listening. If you work on Kolla, >> TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has >> this need), please get involved in the review process. > > My preference goes to proposal 1, however rather than call it "relaxed" > I would make it specific to deployment/lifecycle or cycle-trailing > projects. > > Ideally this policy could get adopted by any such project. The > discussion started on the review and it's going well, so let's see where > it goes :) > > -- > Thierry Carrez (ttx) > > __ > 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 Thanks for the work there Emilien! __ 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-dev] [openstack-ansible] Role maturity downgrades: Looking for contributions/maintainers
Hello everyone, With our role maturity guidelines now in place [1], we can now start the maturity downgrade procedure [2] for the following roles: - monasca [3] - monasca-agent [4] - octavia [5] - searchlight [6] On top of that, the os_freezer role need more love [7], while still in incubated status. What does this mean? It means we are calling out contributors to be maintainers of those roles. Their goal is to improve the current testing for the role on which they would be maintainer on. (Making the role pass functional tests is a first step!) If you want to be a contributor, please answer on this email or talk to us on our irc channel #openstack-ansible. If no contributor step forward for those roles, we'll have no choice than to downgrade their maturity status during the next community meeting. Thank you for your understanding. Best regards, Jean-Philippe Evrard (evrardjp) [1]: https://review.openstack.org/#/c/504279/ [2]: https://docs.openstack.org/openstack-ansible/latest/contributor/additional-roles.html#maturity-downgrade-procedure [3]: https://review.openstack.org/#/c/510497/ [4]: https://review.openstack.org/#/c/510498/ [5]: https://review.openstack.org/#/c/510502/ [6]: https://review.openstack.org/#/c/510505/ [7]: https://review.openstack.org/#/c/510486/ __ 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-dev] [openstack-ansible] Looking for help: bug triage meeting organiser
Hello everyone, I'd be very happy if someone can take over the bug triage czar duty, and report it in our community meeting end of each month. It doesn't take too much time in itself (preparing a list of bugs before the meeting, having an opinion on them, and attend the bug triage meeting). IMO, it's greatly rewarding (be ahead of bugs). If you are interested, please contact me on IRC or answer this email. Thank you. Best regards, Jean-Philippe Evrard (evrardjp) __ 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-dev] [openstack-ansible] Changes in meetings now in application!
Hello everyone, From this week on, openstack-ansible will meet in the #openstack-ansible channel, every Tuesday, 16:00 UTC. No meeting will happen on Thursdays anymore. The community meeting would happen the last Tuesday of the month, the bug triages are kept the rest of the time. Keep also in mind that daylight saving might apply to you this month, for example in mainline Europe will be in "winter time" (that's how we call it in french, please translate to whatever word applies to you!), starting from the last weekend of October. See you next week, Best regards, Jean-Philippe Evrard (evrardjp) __ 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] Thanks for all the fish
On Wed, Oct 11, 2017 at 1:34 AM, Lana Brindley <openst...@lanabrindley.com> wrote: > Hi everyone, > > As most of you know, I was caught up in the Rackspace layoffs that happened > earlier this year, and have been looking for work (in between knee surgery) > since then. Well, in good news for my bank account, I have now secured a new > job with a startup based here in Brisbane. The bad news is that, while it's > working on cool stuff and is likely to be at least partially open sourced at > some point, there's currently no scope for me to continue working on > OpenStack. Sadly, an OpenStack related position just did not come my way, > despite my best efforts. > > So, this is goodbye for now. I'm going to unsubscribe from the OpenStack > mailing lists, and resign my core positions, but you can still email me at > this address if you want to. Feel free to hit me up on LinkedIn or Twitter, > if that's your thing. > > I'm going to miss being part of the community we built here, and all the > fabulous people I've met over my OpenStack years. Keep being awesome, I'll be > cheering from the sidelines. > > Keep on Doc'ing :) > > Lana > > -- > Lana Brindley > Technical Writer > http://lanabrindley.com > > > __ > 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 > Congratulations on the new job. You'll be missed, for sure! Thanks for the work done. Best regards, Jean-Philippe Evrard (evrardjp) __ 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] [packaging][all] Sample Config Files in setup.cfg
On Sat, Oct 7, 2017 at 11:30 AM, Thomas Goirand <z...@debian.org> wrote: > On 10/03/2017 03:07 PM, Luigi Toscano wrote: >>> Why not? Simply because installing config files in /usr/etc is silly. >>> The question would rather be: why not accepting the PBR patch... >> >> It is silly, but again, people consuming from deb or RPM won't notice it. > > Though people doing the packaging will suffer. Please don't throw the > baby over the wall, and let's fix the issue. > >> Sure, having the python tools install the files in the right directory is the >> ideal final solution. > > Let's get there then. In the mean while, don't break stuff. > >> My point is that the proposed solution is not worse than >> the previous one and fixes at least one use case that was not previously >> covered (the one that can be easily fixed). > > You are proposing to induce pain to everyone doing packaging, just > because it solves your developer pip use case. That's not what OpenStack > used to do, and that's not fair. Let's fix things properly *first* > please, maybe by discussing the PBR fix I linked to. Can we agree that > this is the pragmatic easy (but maybe temporarily) way to fix the issue, > even if it's not perfect and a setuptools fix would be better? > > Cheers, > > Thomas Goirand (zigo) > > __ > 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 Hello Thomas, Yes, some people suffer from changes. But other people already suffer on a regular basis to NOT change too. There is no easy win here. IMO, this is fixing things properly. First we make things uniform, then we improve them. By making things uniform and agreed upon, we are progressing. If you want to include the fix for PBR, or refresh it, don't hesitate to propose a follow-up patch. In any case, I don't think it's a good idea to wait for things to happen, and expect that uniformity will happen naturally. This is a step in the right direction. On top of that we are still early in the Queens cycle, so it leaves a chance to the packagers to react. I think it's good timing. Best regards, Jean-Philippe Evrard (evrardjp) __ 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] [ptl][tc] Accessible upgrade support
On Tue, Oct 3, 2017 at 7:52 PM, Sean McGinniswrote: > I'm hoping this will get a little more attention. > > We recently started discussing removing governance tags that did not have any > projects asserting them. I think this makes a lot of sense. Some tags were > defined apparently in the hope that it would get projects thinking about them > and wanting to either apply for the tag, or do the work to be able to meet the > requirements for that tag. > > While this may have worked in some cases, we do have a few that are a little > unclear and not really getting much attention. We will likely clean up that > tag list a little, but there was some push back on at least one tag. > > The supports-accessible-upgrade tag basically states that a service can be > upgraded without affecting access to the resources that the service manages > [1]. This actually fits with how at least Nova and Cinder work, so a patch is > now out there to assert this for those two projects [2]. > > I would bet there are several other projects out there that work in this same > way. Since we are looking between removing tags or using them (use it or lose > it), I would actually love to see more projects asserting this tag. If your > project manages a set of resources that are available even when your service > is down and/or being upgraded, please consider submitting a patch like [2] to > add your project to the list. > > And just a general call out to raise awareness - please take a look through > the other defined tags and see if there are any others that are applicable to > your projects [3]. > > Thanks! > > Sean (smcginnis) > > > [1] > https://governance.openstack.org/tc/reference/tags/assert_supports-accessible-upgrade.html > [2] https://review.openstack.org/#/c/509170/ > [3] https://governance.openstack.org/tc/reference/tags/index.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 Hello, I like the idea. A few comments, I don't know if it's too late for that, but I shoot anyway: - I don't see any mention of documentation in the required steps to get this governance tag. I think it can serve the community better if we enforce the inclusion of the documentation on 'HOW to trigger this "accessible" upgrade'. What do you think? - As part of a deployment project team, I like the fact it's easy for us (and for our users) to see which service is behaving "accessibly". It sets expectations, both for us and for the deployers. I have questions on that "expectations" part: Would you like the deployment projects apply for those tags? How do you see that going? What are the requirements we have to match for a deployment project to be considered "upgrade accessible" ? In my opinion it should be something along the lines of: "if an upstream "accessible" project is deployed, it should be upgraded in an "accessible" way, while non "accessible" projects would fallback to a standard 'supporting upgrade' pattern?" Or alternatively, we don't apply this tag to deployment projects. Opinion? __ 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] [all] Zuul v3 Status - and Rollback Information
On Tue, Oct 3, 2017 at 5:40 PM, Monty Taylor <mord...@inaugust.com> wrote: > Hey everybody! > > Thank you all for your patience over the last week as we've worked through > the v3 rollout. While we anticipated some problems, we've run into a number > of unexpected issues, some of which will take some time to resolve. It has > become unreasonable to continue in our current state while they are being > worked. > > With that in mind, we are going to perform a partial rollback to Zuul v2 > while we work on it so that teams can get work done. The details of that are > as follows: > > The project-config repo remains frozen. Generally we don't want to make > changes to v2 jobs. If a change must be made, it will need to be made to > both v2 and v3 versions. We will not run the migration script again. > > Zuul v3 will continue to run check and periodic jobs on all repos. It will > leave review messages, including +1/-1 votes. > > Our nodepool quota will be allocated 80% to Zuul v2, and 20% to ZUul v3. > This will slow v2 down slightly, but allow us to continue to exercise v3 > enough to find problems. > > Zuul v2 and v3 can not both gate a project or set of projects. In general, > Zuul v2 will be gating all projects, except the few projects that are > specifically v3-only: zuul-jobs, openstack-zuul-jobs, project-config, and > zuul itself. > > We appreciate that some projects would prefer to use v3 exclusively, even > while we continue to work to stabilize it. However, in order to complete > our work as quickly as possible, we may need to restart frequently or take > extended v3 downtimes. Because of this, and the reduced capacity that v3 > will be running with, we will keep the set of projects gating under v3 > limited to only those necessary. But keep in mind, v3 will still be running > check jobs on all projects, so you can continue to iterate on v3 job content > in check. > > If you modified a script in your repo that is called from a job to work in > v3, you may need to modify it to be compatible with both. If you need to > determine whether you are running under Zuul v2 or under v3 with legacy > compatibility shims, check for the LOG_PATH environment variable. It will > only be present when running under Zuul v2 (and it is the variable that we > are least likely to add to the v3 compatibility shim). > > Again - thank you all for your patience, and for all of the great work > people have done working through the issues we've uncovered. As soon as > we've got a handle on the most critical issues, we'll plan another > roll-forward ... hopefully in a week or two, but we'll send out status > updates as we have them. > > Thanks! > Monty > > __ > 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 Hello, I'd like to first thank everyone involved, doing this hard work. As an extra comment, please remember that Newton EOL is next week, so it's maybe worth waiting after that for the next full rollout/roll-forward (whatever the term is!) to avoid the overlap of critical events in the same timeframe. Best regards, Jean-Philippe Evrard (evrardjp) __ 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] [packaging][all] Sample Config Files in setup.cfg
On Tue, Oct 3, 2017 at 2:07 PM, Luigi Toscanowrote: > On Tuesday, 3 October 2017 14:31:05 CEST Thomas Goirand wrote: >> On 10/02/2017 02:04 PM, Luigi Toscano wrote: >> > Why not? Even if it does not fix the issue for proper installations, >> > - it does not provent people from copying the files somewhere else (it >> > happened in sahara for how long I can remember, we have been using >> > data_files) - it fixes the deployment when the package is installed in a >> > virtualenv; - it introduces consistency: the day data_files starts to do >> > the right thing, everything will work; if it's not possible to fix it >> > with data_files, it's easy to spot which files should be fixed because >> > all handled by data_files. >> > >> > So definitely go for it. >> > >> > Ciao >> >> Why not? Simply because installing config files in /usr/etc is silly. >> The question would rather be: why not accepting the PBR patch... > > It is silly, but again, people consuming from deb or RPM won't notice it. > People using pip and virtualenv will get those files; the others will get them > (compared to the previous "no available"). > > Sure, having the python tools install the files in the right directory is the > ideal final solution. My point is that the proposed solution is not worse than > the previous one and fixes at least one use case that was not previously > covered (the one that can be easily fixed). > > > -- > Luigi > > > __ > 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 Agreed, let's continue and go ahead. __ 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-dev] [openstack-ansible] Meetings change
Hello everyone, Some people on this planet are more aware of others of this fact: we have too many meetings in our life. I don't think OpenStack-Ansible should be so greedy to take 8 hours of your life a month for meetings. I therefore propose the reduction to 4 meetings/month: 3 bug triages and 1 community meeting. On top of that, attendance in meetings is low, so I'd rather we find, all together, a timeslot that matches the majority of us. I started this etherpad [1], to list timeslots. I'd like you to: 1) (Optionally) Add timeslot that would suit you best 2) Vote for a timeslot in which you can regularily attend OpenStack-Ansible meetings Please give your irc nick too, that would help. Thank you in advance. Best regards, Jean-Philippe Evrard (evrardjp) [1] https://etherpad.openstack.org/p/osa-meetings-planification __ 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] OpenStack-Ansible testing with OpenVSwitch
Well, there are ppl already running OpenVSwitch on openstack-ansible, so I guess it's just a question of a few bug fixes and adding a scenario to make sure this is working forever :p On Fri, Sep 29, 2017 at 8:22 AM, Gyorgy Szombathelyiwrote: > >> >> Hello JP, >> >> Ok, I will do some more testing against the blog post and then hit up the >> #openstack-ansible channel. >> >> I need to finish a presentation on SFC first which is why I am looking into >> OpenVSwitch. > > Hi Michael, > > If your goal is not openstack-ansible, here's an AIO installer for Pike with > OpenVSwitch: > https://github.com/DoclerLabs/openstack > (needs vagrant and VirtualBox) > > Br, > György > >> >> Thanks >> Michael >> > > __ > 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] [release][ptl] Improving the process for release marketing
On Fri, Sep 29, 2017 at 11:16 PM, Mike Perezwrote: > On 14:33 Sep 26, Anne Bertucio wrote: >> Release marketing is a critical part of sharing what’s new in each release, >> and we want to rework how the marketing community and projects work together >> to make the release communications happen. >> >> Having multiple, repetetive demands to summarize "top features" during >> release time can be pestering and having to recollect the information each >> time isn't an effective use of time. Being asked to make polished, >> "press-friendly" messages out of release notes can feel too far outside of >> the PTL's focus areas or skills. At the same time, for technical content >> marketers, attempting to find the key features from release notes, ML posts, >> specs, Roadmap, etc., means interesting features are sometimes overlooked. >> Marketing teams don't have the latest on what features landed and with what >> caveats. >> >> To address this gap, the Release team and Foundation marketing team propose >> collecting information as part of the release tagging process. Similar to the >> existing (unused) "highlights" field for an individual tag, we will collect >> some text in the deliverable file to provide highlights for the series (about >> 3 items). That text will then be used to build a landing page on >> release.openstack.org that shows the "key features" flagged by PTLs that >> marketing teams should be looking at during release communication times. The >> page will link to the release notes, so marketers can start there to gather >> additional information, eliminating repetitive asks of PTLs. The "pre >> selection" of features means marketers can spend more time diving into >> release note details and less sifting through them. >> >> To supplement the written information, the marketing community is also going >> to work together to consolidate follow up questions and deliver them in >> "press corps" style (i.e. a single phone call to be asked questions from >> multiple parties vs. multiple phone calls from individuals). >> >> We will provide more details about the implementation for the highlights page >> when that is ready, but want to gather feedback about both aspects of the >> plan early. > > As being someone who participates in building out that page, I welcome this > to > represent highlights from the community itself better. > > -- > Mike Perez > > __ > 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 > It's a good thing. Thanks for the feature! __ 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] OpenStack-Ansible and Trove support
Hello Michael, On top of that, we intend to have a "role maturity" that will include when the role was proposed and it's current maturity phase, for more clarity, not unlike openstack project navigator. Our os_trove role has not received many commits recently, and the "maintenance mode" of Trove will probably impact you in the future. Do you intend to keep a trove installation in production, or do you want to do a PoC? Best regards, JP On Wed, Sep 27, 2017 at 12:24 AM, Amy Marrichwrote: > Michael, > > There are release notes for each release that will go over what's new, > what's on it's way out or even gone as well as bug fixes and other > information. Here's a link to the Ocata release notes for OpenStack-Ansible > which includes the announcement of the Trove role. > > https://docs.openstack.org/releasenotes/openstack-ansible/ocata.html > > Thanks, > > Amy (spotz) > > On Tue, Sep 26, 2017 at 6:04 PM, Michael Gale > wrote: >> >> Hello, >> >>Based on github and >> https://docs.openstack.org/openstack-ansible-os_trove/latest/ it looks like >> OpenStack-Ansible will support Trove under the Ocata release. >> >> Is that assumption correct? is there a better method to determine when a >> software component will likely be included in a release? >> >> Michael >> >> __ >> 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 > __ 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] OpenStack-Ansible testing with OpenVSwitch
Hello, We currently don't have a full scenario for openvswitch for an easy "one line" install. It still deserves more love. You could come on our channel in #openstack-ansible to discuss about it if you want. But the general idea should be close to the same explained in the blog post. Best regards, JP On Wed, Sep 27, 2017 at 12:13 AM, Michael Galewrote: > Hello, > > I am trying to build a Pike All-in-One instance for OpenStack Ansible > testing, currently I have a few OpenStack versions being deployed using the > default Linux Bridge implementation. > > However I need a test environment to validate OpenVSwitch implementation, is > there a simple method to get an AIO installed? > > I tried following > https://medium.com/@travistruman/configuring-openstack-ansible-for-open-vswitch-b7e70e26009d > however Neutron is blowing up because it can't determine the name for the > Neutron Server. I am not sure if that is my issue or not, a reference > implementation of OpenStack AIO with OpenVSwitch would help me a lot. > > Thanks > Michael > > __ > 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
[openstack-dev] [openstack-ansible] PTG Team dinner
Hello guys, I propose we have a team dinner at casey's this Thursday, at the PTG. Could you please vote on the following poll, this way I can book? https://framadate.org/zQPEvPGPOH1u2EU8 Thank you in advance. Best regards, JP __ 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-dev] [ptg] [openstack-ansible] [kolla-ansible] [tripleo] Ansible feedback sharing session
Hello, The OpenStack-Ansible team will have a session to share feedbacks about ansible 2.4 or ansible+python3. Anyone welcomed to share their experience and give insights. It will be on Wednesday 3:30 to 5pm. See you there! Best regards, Jean-Philippe Evrard (evrardjp) __ 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] [kolla] [tripleo] [openstack-ansible] [deployment] Collaboration at PTG
Hello Emilien, The Discussion room is a good idea. I like it. Most of the OpenStack-Ansible crew will be available the whole week, so we can even think of doing a conversation outside the Wed-Friday timeframe. If you/we all have enough time, maybe we could organise two sessions, probably with different formats? For example, a brainstorming session about how we collaborated on previous cycles and how we could collaborate in the future, and another session with the real action points based on the first conversation? On top of that, I have extra points I'd like to discuss with you: - Architecture of LB + web server + uwsgi - Possibility of sharing infrastructure (mariadb/rabbitmq/...) experience/code between projects. Thank you in advance. Best regards, JP On Fri, Aug 25, 2017 at 8:16 PM, Emilien Macchiwrote: > Cool, sounds like some people are interested (I haven't hear from > Kolla yet but I'm sure they are as well). > > I was wondering if we should take benefit of Discussion Rooms, useful > for inter-projects topics: > https://ethercalc.openstack.org/Queens-PTG-Discussion-Rooms > > There is still some place, let me know what you think and we can block > a slot (maybe 2h?) > I want to hear from Kolla and OpenStack Ansible at least and know if > you have schedule constraints otherwise I'll go ahead and block a > slot. > > Thanks, > > On Fri, Aug 18, 2017 at 4:37 AM, Flavio Percoco wrote: > > On 17/08/17 10:24 -0500, Major Hayden wrote: > >> > >> On 08/17/2017 09:30 AM, Emilien Macchi wrote: > >>> > >>> If you're working on Kolla / OpenStack-Ansible - please let us know if > >>> you have specific constraints on the schedule, so we can maybe block a > >>> timeslot in the agenda from now. > >>> We'll have a "Packaging" room which is reserved for all topics related > >>> to OpenStack deployments, so we can use this one. > >> > >> > >> I don't have any constraints (that I'm aware of), but I'd be interested > in > >> participating! Performance in the gate jobs has been one of my tasks > lately > >> and I'd like to see if we can collaborate there to make improvements > without > >> ruining infra's day. ;) > >> > >> As long as you can put up with a few Dad jokes, I'll be there. > > > > > > ++ I'm interested in this topic too! > > > > Flavio > > > > -- > > @flaper87 > > Flavio Percoco > > > > > __ > > 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 > > > > > > -- > Emilien Macchi > > __ > 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] [openstack-ansible] group/host specific config file overrides: how-to?
Hello, The variables documented in each of the roles defaults/ are generally what you can consider a user level interface (i.e.: what you can modify), while the variables from vars/ are generally what's best to avoid overriding. We've been slowly phasing out variables insides templates, to exclusively rely on config_template overrides (See also: [1] and [2]) Please note that if a variable is deprecated, we are issuing a release note. [1]: https://github.com/openstack/openstack-ansible-os_nova/blob/ 4b9100a612ba0e9449d792b2783b9ec50a8fb28e/tasks/nova_post_install.yml#L40 [2]: https://docs.openstack.org/project-deploy-guide/ openstack-ansible/ocata/app-advanced-config-override.html Best regards, JP On Tue, Aug 22, 2017 at 1:24 PM, Markus Zoellerwrote: > On 22.08.2017 09:46, Flávio Ramalho wrote: > > Hi Markus, > > > > I think you can achieve what you want by simple overriding the host > > variables, for example: > > > > In /etc/openstack_deploy/openstack_user_config.yml: > > compute_hosts: > >compute1: > > ip: 192.168.100.12 > > host_vars: > >nova_reserved_host_memory_mb: 256 > >compute2: > > ip: 192.168.100.10 > > > > In this case you would have compute1 with reserved_host_memory_mb = 256 > and > > compute2 with the default value set for nova_reserved_host_memory_mb. > > > > > > Flávio > > Oh, I didn't see those variables, good hint! I'll give it a try, maybe > that's good enough for me. Thanks a lot Flavio! > > http://git.openstack.org/cgit/openstack/openstack-ansible-os > _nova/tree/templates/nova.conf.j2 > > Despite that this will probably work, is that an "interface" I'm allowed > to touch or is it considered an "internal/private" part of > OpenStack-Ansible (and/or its roles)? > > -- > Regards, Markus Zoeller (markus_z) > > > > On Mon, Aug 21, 2017 at 6:09 PM Markus Zoeller < > mzoel...@linux.vnet.ibm.com> > > wrote: > > > >> On 21.08.2017 16:40, Andy McCrae wrote: > >>> Hey Markus, > >>> > >>> > I'm wondering which possibilities I have to do group/host specific > config file overrides. After reading [1], I'm still a little clueless. > To be specific, I have this setup (expressed as Ansible inventory > file): > > [z_compute_nodes] > compute1 > # more nodes > [x_compute_nodes] > compute2 > # more nodes > [computes:children] > z_compute_nodes > x_compute_nodes > > As an example, I want to set Nova's config option > `reserved_host_memory_mb` of the `DEFAULT` config file section: > > ### nova.conf > [DEFAULT] > reserved_host_memory_mb=$VALUE > > My goal is this: > > | reserved_host_memory_mb > -- > compute1 | 256 > compute2 | 512 > > I know there are overrides like `nova_nova_conf_overrides`. > So I tried to set a default override in `user_variables.yml`: > > ### /etc/openstack_deploy/user_variables.yml > > nova_nova_conf_overrides: > DEFAULT: > reserved_host_memory_mb: 512 > > But I wanted to override this depending on the host in > `openstack_user_config.yml`: > > ### /etc/openstack_deploy/openstack_user_config.yml > # [...] > # nova hypervisors > compute_hosts: > compute1: > ip: 192.168.100.12 > host_vars: > nova_nova_conf_overrides: > DEFAULT: > reserved_host_memory_mb: 256 > compute2: > ip: 192.168.100.10 > > >>> > >>> Try change "host_vars" to "container_vars". > >>> If that doesn't work let me know, I'll spin up a test to recreate the > >>> actual problem, but at a glance that looks correct otherwise. > >>> > >> > >> > >> Replacing `host_vars` with `container_vars` didn't have an effect: > >> > >> ### controller1: /etc/openstack_deploy/openstack_user_config.yml > >> # nova hypervisors > >> compute_hosts: > >> compute1: > >> ip: 192.168.100.12 > >> container_vars: > >> nova_nova_conf_overrides: > >> DEFAULT: > >> reserved_host_memory_mb: 256 > >> compute2: > >> ip: 192.168.100.10 > >> > >> Both compute nodes still have the same $VALUE, although `compute1` > >> should have 256: > >> > >> ### compute1: /etc/nova/nova.conf > >> root@compute1:~# grep reserved_host_memory_mb /etc/nova/nova.conf > >> reserved_host_memory_mb = 512 > >> > >> > >> ### compute2: /etc/nova/nova.conf > >> root@compute2:~# grep reserved_host_memory_mb /etc/nova/nova.conf > >> reserved_host_memory_mb = 512 > >> > >> I'd like to avoid to introduce some "clever" dict merging algorithm I > >> won't understand anymore after a few weeks. :/ > >>
Re: [openstack-dev] [kolla] [tripleo] [openstack-ansible] [deployment] Collaboration at PTG
I'd be happy to join. I don't think we have constraints on the schedule yet, and we can indeed book slot(s). Best regards, JP. On Thu, Aug 17, 2017 at 3:30 PM, Emilien Macchiwrote: > Hey folks, > > As usual, we'll meet in Denver and I hope we can spend some time > together (in a meeting room first) to have face to face discussions on > the recent topics that we had. > Right now, TripleO sessions are not scheduled in our agenda, so we're > pretty flexible: https://etherpad.openstack.org/p/tripleo-ptg-queens > > I would like to propose one topic (happy to coordinate the discussion) > on some efforts regarding doing configuration management with Ansible, > and k8s integration as well. > Flavio made some progress [1] - I really hope we can make progress here. > > [1] http://lists.openstack.org/pipermail/openstack-dev/2017- > July/119696.html > > If you're working on Kolla / OpenStack-Ansible - please let us know if > you have specific constraints on the schedule, so we can maybe block a > timeslot in the agenda from now. > We'll have a "Packaging" room which is reserved for all topics related > to OpenStack deployments, so we can use this one. > > Looking forward to meeting you at PTG! > Thanks, > -- > Emilien Macchi > > __ > 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
[openstack-dev] [openstack-ansible] Queens PTL candidacy
Hello everyone, I would like to announce my candidacy for PTL of the OpenStack-Ansible project for the Queens cycle. I will focus on the following themes: 1) Improve the usability It can be difficult for a newcomer to fully grasp the way OpenStack-Ansible works, and the first experience can be daunting. The deploy and operator's guides are a step in the right direction, and we must continue that documentation effort to show that our solution can scale up to any operator's size. OpenStack-Ansible has largely grown since its creation, and we support much more roles now. That is a positive improvement. We now have more features that people want to use. As a consequence, we also carry less used roles that are less maintained. My objective is to reduce our technical debt if possible, standardize more, and make sure the less maintained roles don't have a negative impact on our image. For that, I'd like to formalize our role maturity index as a way to show role adoption, and to easily spot if the role is meeting our latest testing/coding standards. 2) Redesign for the future, while still improving operator's experience We've always taken the decision to go for proven technology/low risks/ low maintenance solutions. I intend to keep this mindset, but also introduce newer architecture: * Re-design the placement of web servers/reverse proxy, thanks to the recent work done for UWSGI support. * Introduce systemd-nspawn, next to LXC. * Change our default deployments to be more converged, to reduce the amount of containers to manage. * Separate the installation and configuration steps of a deploy, and test it in our gates. This would allow larger operators to build their own "artifacts" separately of their consumption in a standard way, and share experience in the larger community. * Upgrade to Ansible 2.4. I look forward to working with you all, and it would be my honor to serve as PTL for the next cycle. Best regards, Jean-Philippe Evrard (evrardjp) __ 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] [openstack-ansible][security] To firewalld, or not to firewalld
Hello, A few additions for/against firewalld, linked to ansible's firewalld module: http://docs.ansible.com/ansible/latest/firewalld_module.html +: The module is built-in, so no need to ship it. It provides idempotency, and is easy to use. -: The module is: "Not tested on any Debian based system. Requires the python2 bindings of firewalld, which may not be installed by default if the distribution switched to python 3". My take: For ppl who aren't iptables experts, firewalld module brings a lot of readability. If we are doing the tasks equivalent with iptables, the readability will be brought in by variables (I mean variables to list ports_to_open are fairly easy to understand). I am myself preferring to always use modules, and so, use the firewalld module (because it's already upstream, less tasks and therefore less error prone). However, that would mean that we improve the module itself to grant what we need: Real ubuntu and python3 support. Maybe it's a crusade that nobody wants to partake in, and using iptables would mean a path to least resistance, therefore easier to ship. On top of it, if it's more a hassle to use the module due to complex rules (do we even need that?), I'd understand the move to iptables management. Is there already a role to handle this? Best regards, JP On Wed, Jul 26, 2017 at 3:59 PM, Major Haydenwrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hey there, > > I'm working through some drafts of a spec[0] (rendered[1]) that aims to > deploy software firewalls within an OpenStack-Ansible deployment. The goal > is to increase security by restricting lateral movement. > > One of the questions that was raised was the method for managing firewall > rules. The spec lays out a plan for firewalld since it is available in the > supported operating systems (Ubuntu 16.04, CentOS 7, OpenSUSE 42.x) and it > allows us to control IPv4/IPv6 rules in the same place. > > However, Logan makes a good point about using a jinja template to write > firewall rules to a file and load that via normal iptables service > mechanisms. I definitely see merit to that approach, too. > > I'd really like feedback from developers/operators of OpenStack-Ansible to > determine the best method to proceed. Here's what I've come up with so far: > > firewalld advantages > - > 1) Available in all distributions we support > 2) Provides simple commands to interface with firewall rules > 3) Manages IPv4/IPv6 iptables rules at the same time > > firewalld disadvantages > - --- > 1) Different distributions have different base rule sets > 2) Medium/High complexity rules require --direct, which is like using > iptables anyway > 3) It's another daemon to manage/monitor > 4) We wouldn't be able to use firewalld's "zones" very heavily > 5) Saving/restoring iptables rules is battle-tested already > > > [0] https://review.openstack.org/#/c/479415/ > [1] http://docs-draft.openstack.org/15/479415/5/check/gate- > openstack-ansible-specs-docs-ubuntu-xenial/6a50e01//doc/ > build/html/specs/pike/software-firewall.html > > - -- > Major Hayden > -BEGIN PGP SIGNATURE- > > iQIzBAEBCAAdFiEEG/mSZJWWADNpjCUrc3BR4MEBH7EFAll4rkwACgkQc3BR4MEB > H7G3ThAAkYfAGPThoaLK+a+xSZjQrrDYo3T2Q8h/nCVdSbXU1npfv0wnIUcpezH7 > a2bq4tSOX53tupUtvtMXK1VzSh5zQbohewfndmAOpwH8yNJ6UdnBjTfNXbs1WU05 > ke6X/RIvkNEKO4q5RvO3hbgKFKtLFdDVWRa7m6ORM2UaN2QXRrr85Cs0GrS0wWJq > XDLVf5277VPXiobntUkdSdVAHfPX0QULMUBxSbnhAjGhLWfZnGiyInntHAu0rGqj > xhkZNT3wuEMmorbIfUkY1NhjWJyy5LyjCar+hpJKRz/pNlFiOiF36Ps4PLNBW06P > IwL3IbTkOwI6KPffFBqmMYb2AHsbqpnwxjBjoUQv1YvW55IZn3EliUY0t05JBFZ0 > N4EDNplyX9UhEQdFQrKHkOjCzADuuI/nnngfsZiCziiU068mRYIp4S3phj6QiOZP > bHdjQDUx3X7rk1s6i7SdLPxPYNPxEs6wipXzofjB4STwDYqFKmpSNOTecLVN64PE > H1bmt/lOfSpl05jjwhk8Jaxd0RgMAM2a7pA7nsTpFqRG4v7VaucewGaCRypCvAUD > JiuQ+RYCNifEBb8nX6lx8TnJLCzaFK4xZuEdpBqGCwKaXRYUqdS+W2bRPqRY6EmF > 5jYN1d2U0rxyYmQ1cH921VQPhA8K142FoUgq+oqiaH/8cqeWr9o= > =lwtm > -END PGP SIGNATURE- > > __ > 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
[openstack-dev] [openstack-ansible] Bug smash
Hello team, We've talked about a few times in our channels about a bug smash. I think it's time to do it: - We have 9 bugs triaged as highly important - We have 21 bugs of medium importance - We have 30 bugs classified as low. That's 60 bugs we've agreed to fix, ranging from "when convenient" to "hey, we should do it very much... now", which is probably enough for having bug smash session(s). So, I'll freeze two of my afternoons to fix what I can, and I'd be happy if you could join me in the effort. Here are two weeks that would fit best for the bug smash, IMO (see also pike schedule, [2]): - Aug 14 - Aug 18 (after RC and after our feature freeze) - Sep 04 - Sep 08 (just after our RC and after our other projects releases, just before the PTG/our release deadline) I'd be happy if you could vote on the doodle here [1] to show your availability. If we have extra time on the Sep 04-Sep 08, we could also talk about our 54 wishlist bugs, because we'll have these in mind when bringing ideas at the PTG. For the technical details, I think we should gather at least online. I have a meeting room (zoom, a skype-like thing) we could all join, which makes it more friendly. Alternatively, if there is an organisation willing to host the bug smash in their offices, please come forward. I think the only requirement would be to have a meeting room system where the participants can join remotely if they can't join physically. Sorry for the long mail and thank you in advance. Best regards, JP (evrardjp) [1]: https://framadate.org/osa-pike-bug-smash [2]: https://releases.openstack.org/pike/schedule.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
Re: [openstack-dev] [OpenStack-Ansible] Proposing Markos Chandras for osa-core
+1 Thanks for all the work! On Tue, Jul 18, 2017 at 10:33 AM, Nicolas Bock < nicolasbock.openst...@gmail.com> wrote: > On Tue, Jul 18, 2017 at 10:23:46AM +0100, Andy McCrae wrote: > >> Following on from last week's meeting I'd like to propose Markos >> (hwoarang) >> for OSA core. >> > > +1 !! > > Markos has done a lot of good reviews and commits over an extended period >> of time, and has shown interest in the project as a whole. (Not to mention >> the addition of SUSE support) >> >> We already have quite a few +1's from the meeting itself, but opening up >> to >> everybody who wasn't available at the meeting! >> >> Thanks, >> Andy >> > > __ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> 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 > __ 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-dev] [openstack-ansible] Next bug triages
Hello everyone, I won't be able to hold the bug triage meeting for OpenStack-Ansible, this week and next week. I'd be super happy if someone could replace me. On top of that, I suggest to cancel the bug triage for the 4th of July. Thank you for your help/understanding! Best regards, Jean-Philippe Evrard -- @evrardjp __ 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] [openstack-ansible] mount ceph block from an instance
Hello, That was indeed my suggestion. The alternative would be to make sure your ceph can be routed through your public network. But it’s not my infrastructure, I don’t know what you store as data, etc… In either case, you’re making possible for your tenants to access a part of your infra (the ceph cluster that’s used for openstack too), so you should think of the implications twice (bad neighbours, security intrusions…). Best regards, JP On 29/05/2017, 10:27, "fabrice grelaud" <fabrice.grel...@u-bordeaux.fr> wrote: Thanks for the answer. My use case is for a file-hosting software system like « Seafile » which can use a ceph backend (swift too but we don’t deploy swift on our infra). Our network configuration of our infra is identical as your OSA documentation. So, on our compute node we have two bonding interface (bond0 and bond1). The ceph vlan is actually propagate on bond0 (where is attach br-storage) to have ceph backend for our openstack. And on bond1, among other, we have br-vlan for ours vlans providers. If i understood correctly, the solution is to propagate too on our switch the ceph vlan on bond1, and create by neutron the provider network to be reachable in the tenant by our file-hosting software. For security issues, using neutron rbac tool to share only this provider network to the tenant in question, could be sufficient ? I’m all ears ;-) if you have another alternative. Regards, Fabrice > Le 25 mai 2017 à 14:01, Jean-Philippe Evrard <jean-philippe.evr...@rackspace.co.uk> a écrit : > > I doubt many people have tried this, because 1) cinder/nova/glance probably do the job well in a multi-tenant fashion 2) you’re poking holes into your ceph cluster security. > > Anyway, if you still want it, you would need (I guess) have to create a provider network that will be allowed to access your ceph network. > > You can either route it from your current public network, or create another network. It’s 100% up to you, and not osa specific. > > Best regards, > JP > > On 24/05/2017, 15:02, "fabrice grelaud" <fabrice.grel...@u-bordeaux.fr> wrote: > >Hi osa team, > >i have a multimode openstack-ansible deployed, ocata 15.1.3, with ceph as backend for cinder (with our own ceph infra). > >After create an instance with root volume, i would like to mount a ceph block or cephfs directly to the vm (not a cinder volume). So i want to attach a new interface to the vm that is in the ceph vlan. >How can i do that ? > >We have our ceph vlan propagated on bond0 interface (bond0.xxx and br-storage configured as documented) for openstack infrastructure. > >Should i have to propagate this vlan on the bond1 interface where my br-vlan is attach ? >Should i have to use the existing br-storage where the ceph vlan is already propagated (bond0.xxx) ? And how i create the ceph vlan network in neutron (by neutron directly or by horizon) ? > >Has anyone ever experienced this ? > > __ >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 > > > > > Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com and delete the original message. Your cooperation is appreciated. > __ > 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] [openstack-ansible] mount ceph block from an instance
I doubt many people have tried this, because 1) cinder/nova/glance probably do the job well in a multi-tenant fashion 2) you’re poking holes into your ceph cluster security. Anyway, if you still want it, you would need (I guess) have to create a provider network that will be allowed to access your ceph network. You can either route it from your current public network, or create another network. It’s 100% up to you, and not osa specific. Best regards, JP On 24/05/2017, 15:02, "fabrice grelaud"wrote: Hi osa team, i have a multimode openstack-ansible deployed, ocata 15.1.3, with ceph as backend for cinder (with our own ceph infra). After create an instance with root volume, i would like to mount a ceph block or cephfs directly to the vm (not a cinder volume). So i want to attach a new interface to the vm that is in the ceph vlan. How can i do that ? We have our ceph vlan propagated on bond0 interface (bond0.xxx and br-storage configured as documented) for openstack infrastructure. Should i have to propagate this vlan on the bond1 interface where my br-vlan is attach ? Should i have to use the existing br-storage where the ceph vlan is already propagated (bond0.xxx) ? And how i create the ceph vlan network in neutron (by neutron directly or by horizon) ? Has anyone ever experienced this ? __ 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 Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com and delete the original message. Your cooperation is appreciated. __ 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-dev] [openstack-ansible] Bug triage cancelled this week
Hello everyone, We’ll not have an openstack-ansible bug triage this week, as many of our contributors are on the summit! See you next week! Best regards, Jean-Philippe Evrard (@)evrardjp Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com and delete the original message. Your cooperation is appreciated. __ 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] [openstack-ansible] Adding a scenario for shade's functional tests
Hey, My two cents. JP On 04/04/2017, 13:39, "Monty Taylor"wrote: Hey all! I woke up early this morning and found myself thinking "I clearly don't have enough work on my plate, why don't I add some more?" I'd love to make a gate job that: - Deploys a cloud with openstack-ansible - Runs shade's functional tests against that cloud How do you run these functional tests? Do you expect this as a simple tox run, a tempest scenario, or anything else? Which makes me think it just needs to be an additional scenario perhaps? I think a scenario is good, but we could consider this test as part of a basic end-to-end testing. If the tests aren’t too long, we could include them at the end of an AIO run to make sure everything “works as expected” for both tempest and shade. Sadly, our jobs are already long and hitting timeouts on some distros. As I started to poke, I need to figure out the best way to accomplish something. Namely, shade's functional tests expect a clouds.yaml that defines two entires - one admin and one non-admin. OSA already creates a clouds.yaml with admin creds, so that's done. And there is already tempest setup that creates a demo user, so that's done too. Here's where I could use some advice: - What's the best way to plumb through an option to also write an entry to clouds.yaml for the demo user? I'm thinking a boolean in openstack-ansible-openstack_openrc like "openrc_clouds_yml_add_demo_user" that can be wrapped around a second entry in clouds.yaml.j2? I’d agree with Jesse definition there: have vars defined in utility_all group vars (or like jesse said, something in the AIO prep). These vars would: - override the openstack_openrc default vars (we need to adapt the tasks in openstack_openrc “Create openrc” to include a loop + “Create clouds.yaml” to generate a more complete clouds.yaml according to the users defined in the dict) - override the tempest user creation (we need to adapt the tasks in tempest to be a var + at the same time we could maybe move to ansible os_ modules there, that would also be a win for shade) - Can we create the demo user and not run tempest? It's in the os_tempest role at the moment. Should I split out the user creation bits into a "test_setup" role that tempest depends on - and then also make a shade_test role that also depends on the test_setup role? I like this approach. If you want a shorter path, you can still define in the user variables ``tempest_run: False`` for the scenario, and we could have an include shade_run. I guess it all depends on shade_run content and if that deserves the burden of a role to maintain. If you think shade_test deserves a role, we could transfer the maintenance burden to you by including it in the ansible-role-requirements, but not under the openstack-ansible umbrella, like we do for some external roles. We could then adapt the plays, or use an include_role inside tempest role for laziness. - If we do a test_setup role, should that maybe just write a whole additional clouds.yaml out that has the admin and the demo user so that we don't have to put conditionals in places that also get used for prod deploys? We used to need the openrc role to happen before the tempest role IIRC. We couldn’t have one role fits all. However, I see in that model that tempest or shade roles could both have a meta dep on openrc, and openrc being the source of truth for generating openrc like files (openrc + clouds.yaml). Openrc could then be used for production deploys to have a more complete clouds.yaml file. Maybe it’s worth splitting the clouds.yaml with a secure.yaml in that case too. But that’s another topic. I think that's about all the questions I have for now ... Thanks! Monty __ 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 Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com and delete the original message. Your cooperation is appreciated. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: