Re: [openstack-dev] [oslo][devstack][all] ZooKeeper vs etcd for Tooz/DLM
On Wed, Mar 15, 2017 at 1:44 PM, Julien Danjou wrote: > On Wed, Mar 15 2017, Davanum Srinivas wrote: > >> Yep, jd__ and i confirmed that things work with 3.x > > Though to be clear, what's used in tooz is the v2 HTTP API, not the new > v3 gRPC API. And just to be double clear: although etcd 3.x comes with a v2 api, the etcd3 api also has a different data model, so the data stored using it is not accessible to the v2 api, and vice versa. __ 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] [glance] revising the core list
On Fri, Feb 17, 2017 at 4:19 PM, Brian Rosmaita wrote: > Finally, the following people are dropped from the Glance core list due > to inactivity during Ocata. On behalf of the entire Glance team, I > thank each of you for your past service to Glance, and hope to see you > again as Glance contributors: > - Kairat Kushaev > - Mike Fedosin > - Louis Taylor So long, and thanks for all the images! __ 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] The #openstack-packaging channel requires an invite?
On Wed, Mar 9, 2016 at 5:48 PM, Matt Riedemann wrote: > Someone showed up in the -stable channel this morning asking for help with > packaging. I gather they were there because the IRC wiki [1] says the > #openstack-stable channel is also for packaging discussions, given -stable > originated from distro people. > > I redirected them to https://wiki.openstack.org/wiki/Packaging which points > to https://wiki.openstack.org/wiki/PackagerResources which says: > > "The #openstack-packaging channel on Freenode is available for packaging > collaboration and discussion." > > Great! > > However, you have to apparently be invited to join the elite > #openstack-packaging channel. > > What gives? Is that channel dead? Is there something else? Is there a secret > handshake I can learn to palms to grease to get in? >From ChanServ: 17:55:03 -ChanServ(ChanServ@services.)- Information on #openstack-packaging: 17:55:03 -ChanServ(ChanServ@services.)- Registered : Nov 11 18:59:55 2011 (4y 17w 0d ago) 17:55:03 -ChanServ(ChanServ@services.)- Last used : (about 75 weeks ago) 17:55:03 -ChanServ(ChanServ@services.)- Mode lock : +imnstf #openstack-stable 17:55:03 -ChanServ(ChanServ@services.)- Flags : KEEPTOPIC TOPICLOCK GUARD PRIVATE 17:55:03 -ChanServ(ChanServ@services.)- *** End of Info *** It doesn't look like it's been used in a long time (75 weeks). Louis __ 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][release][all] Automatic .ics generation for OpenStack's and project's deadlines
On Wed, Dec 23, 2015 at 2:26 PM, Doug Hellmann wrote: > What you have is a really good start. Thanks for working on this! > How do you feel about importing the repository into gerrit? > > A couple of things I'd like to see added: > > 1. Separate sections for cross-project and project-specific events. > >This would let us completely generate the RST content, as it >appears on http://docs.openstack.org/releases/schedules/mitaka.html, >as well as generate project-specific ICS files (some folks may want >to only subscribe to cross-project events and their own project's >schedule). > > 2. Durations for individual events. > >This would let us have single-day events, such as the final >release date, as well as include things like mid-cycle meetings, >sprints, etc. that may not all last 4 days. > > 3. The "generator" python package directory will probably need to >be renamed to something more descriptive to let this be installed >with other projects, which we'll need in order to integrate it with >Sphinx. > > 4. That Sphinx integration will be easier if the function to construct >the data structure representing the schedule data is separated from >the function to format the data in different ways. That's just >refactoring some of what's already there, so it's not a big deal. > > Doug Hi Doug, thanks for the feedback! I'll import this into gerrit and have a look at working on your suggestions. Cheers, Louis __ 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][release][all] Automatic .ics generation for OpenStack's and project's deadlines
On Thu, Dec 10, 2015 at 06:20:44PM +, Flavio Percoco wrote: > Greetings, > > I'd like to explore the possibility of having .ics generated - pretty > much the same way we generate it for irc-meetings - for the OpenStack > release schedule and project's deadlines. I believe just 1 calendar > would be enough but I'd be ok w/ a per-project .ics too. > > With the new home for the release schedule, and it being a good place > for projects to add their own deadlines as well, I believe it would be > good for people that use calendars to have these .ics being generated > and linked there as well. > > Has this been attempted? Any objections? Is there something I'm not > considering? I had a bit of time and started hacking up a simple version of this: https://github.com/kragniz/release-schedule-generator The output of this may or may not be standards-compliant, but google calendar appears to accept it. You can see example output here: https://kragniz.eu/pub/schedule.ics There's currently no support for project-specific events or RST output, but these can be added later if people think this current implementation isn't too bad. Feel free to send feedback or (even better) pull requests in my direction if this seems okay. Cheers, Louis signature.asc Description: 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
Re: [openstack-dev] [glance] Add Ian Cordasco back into glance-core
On Mon, Dec 07, 2015 at 12:06:03PM -0430, Flavio Percoco wrote: > Greetings, > > Not long ago, Ian Cordasco, sent an email out stepping down from his > core roles as he didn't have the time to dedicate to the project > team's he was part of. > > Ian has contacted me mentioning that he's gotten clearance, and > therefore, time to dedicate to Glance and other activities around our > community (I'll let him expand on this and answer questions if there > are). > > As it was mentioned in the "goodbye thread" - and because Ian knows > Glance quite well already, including the processes we follow - I'd > like to propose a fast-track addition for him to join the team again. > > Please, just like for every other folk volunteering for this role, do > provide your feedback on this. If no rejections are made, I'll proceed > to adding Ian back to our core team in a week from now. +1! It would be great to have Ian back. Louis signature.asc Description: 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
Re: [openstack-dev] [All][Glance Mitaka Priorities
On Fri, Nov 06, 2015 at 06:31:23PM +, Bhandaru, Malini K wrote: > Hello Glance Team/Flavio > > Would you please provide link to Glance priorities at > https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads#Glance > > [ Malini] Regards > Malini I don't belive there was an etherpad for this session. We were discussing the list of priorities for Mitaka located here: https://specs.openstack.org/openstack/glance-specs/priorities/mitaka-priorities.html I've updated the wiki page with a link to the spec. Cheers, Louis signature.asc Description: 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
Re: [openstack-dev] [release] new change management tools and processes for stable/liberty and mitaka
On Wed, Nov 04, 2015 at 03:03:29PM +1300, Fei Long Wang wrote: > Hi Doug, > > Thanks for posting this. I'm working on this for Zaqar now and there is a > question. As for the stable/liberty patch, where does the "60fdcaba00e30d02" > in [1] come from? Thanks. > > [1] > https://review.openstack.org/#/c/241322/1/releasenotes/notes/60fdcaba00e30d02-start-using-reno.yaml This is from running the reno command to create a uniquely named release note file. See http://docs.openstack.org/developer/reno/usage.html Cheers, Louis signature.asc Description: 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
Re: [openstack-dev] [glance] Removing python-swiftclient from requirements.txt
On Tue, Jul 28, 2015 at 07:55:54PM -0400, Doug Hellmann wrote: > I replied on both patches, but I'll repeat it here for a broader > audience: > > Please set up an "extras" entry for each backend instead of just > removing the dependencies. That will signal to users that you know > what dependencies there are for a backend, but that they are optional, > and still allow someone to do the equivalent of "pip install > glance[vmware]" or "pip install glance[swift]" to get those > dependencies. Nova and oslo.versionedobjects have examples in their > setup.cfg if you need a template. > > I didn't mention in the reviews, but this will also make integration > tests in our gate easier, since you can put ".[vmware]" or ".[swift]" in > the tox.ini to pull in those dependencies. This sounds like the best option. What happens if you want to enable multiple backends? Can you do something like "pip install glance[swift, vmware]", or would you need to run a separate pip command to install each? Cheers, Louis signature.asc Description: Digital 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-dev] [glance] Removal of Catalog Index Service from Glance
On Fri, Jul 17, 2015 at 07:50:55PM +0100, Louis Taylor wrote: > Hi operators, > > In Kilo, we added the Catalog Index Service as an experimental API in Glance. > It soon became apparent this would be better suited as a separate project, so > it was split into the Searchlight project: > > https://wiki.openstack.org/wiki/Searchlight > > We've now started the process of removing the service from Glance for the > Liberty release. Since the service was originally had the status of being > experimental, we felt it would be okay to remove it without a cycle of > deprecation. > > Is this something that would cause issues for any existing deployments? If you > have any feelings about this one way or the other, feel free to share your > thoughts on this mailing list or in the review to remove the code: > > https://review.openstack.org/#/c/197043/ Some time has passed and no one has complained about this, so I propose we go ahead and remove it in liberty. Cheers, Louis signature.asc Description: Digital 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
Re: [openstack-dev] 7/17 state of the gate (you know, fires)
On Fri, Jul 17, 2015 at 07:51:35PM -0500, Matt Riedemann wrote: > We started the day with a mock 1.1.4 release breaking unit tests for a few > projects (nova, cinder, ironic at least). > > The nova blocker was tracked with bug 1475661. > > We got a g-r change up to block mock!=1.1.4 but that didn't fix the issue > because oslo.versionedobjects pulls mock in before pip processes the !=. > Luckily lifeless reverted the regression and released mock 1.2 so we should > be OK on that front for now. > > However, cinder/glance/nova, which gate on the ceph job, are blocked by bug > 1475811 which is a regression with the rbd driver in glance_store 0.7.0, > which was put into upper-constraints.txt today. > > I have a patch up for glance_store here: > > https://review.openstack.org/#/c/203294/ > > And an exclusion of 0.7.0 in g-r here: > > https://review.openstack.org/#/c/203295/ > > If the glance core team could get around to approving that fix and releasing > 0.7.1 it would unblock the gate for glance/cinder/nova and make me happy. Hi Matt, thanks for working on this. I've approved the glance_store fix and have submitted a request for a new release: https://review.openstack.org/#/c/203362/ Cheers, Louis signature.asc Description: Digital 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
Re: [openstack-dev] [glance] Progress of the Python 3 port
On Wed, Jul 15, 2015 at 10:39:11AM +0200, Victor Stinner wrote: > Hi, > Any update on this release? This has now been released in glance_store 0.7.0 Cheers, Louis signature.asc Description: Digital 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
Re: [openstack-dev] Why doesn't Gerrit email me?
On Tue, Jun 30, 2015 at 02:08:45PM +0100, Neil Jerram wrote: > Apologies if this is an FAQ - I tried a quick search, but that didn't find > anything that looked both up to date and authoritative. > > I keep going back to Gerrit jobs that I've reviewed or commented on, and > finding that there have been other comments since mine, but that Gerrit > didn't email me about. > > Does anyone know why that happens? It's really important to my workflow, > and to continuing review conversations effectively, that Gerrit emails new > comments reliably and in good time. Could I be doing something wrong that > is causing this not to happen? This is probably a silly question, but have you enabled email notifications for all comments in your watched projects? You can create a watch item for a particular project with 'owner:me' in the 'Only If' field to prevent a deluge of comment notifications. Cheers, Louis signature.asc Description: Digital 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
Re: [openstack-dev] [Security][Glance] Design session for image signing/encryption
On Tue, May 19, 2015 at 03:01:39PM +, Clark, Robert Graham wrote: > Is there a session to discuss the image security proposal? > https://review.openstack.org/#/c/177948/2/specs/liberty/encrypted-and-authenticated-image-support.rst Yes, it's at 4:30 - 5:10pm on Wednesday. Cheers, Louis https://libertydesignsummit.sched.org/event/fc81bd8fb60d71ba4fe1c0cfa0637b2b https://etherpad.openstack.org/p/liberty-glance-image-signing-and-encryption signature.asc Description: Digital 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
Re: [openstack-dev] [QA][Glance][Heat][Cinder] Removing the CLI tests from Tempest
On Thu, Apr 30, 2015 at 12:28:15PM -0400, Matthew Treinish wrote: > We're now at the end of the cycle and there are 3 clients that still have CLI > tests in tempest. I have pushed the patch up to remove all these tests here: > > https://review.openstack.org/#/c/178757/ Hi Matt, This is being worked on in glance (infra patch adding test job: https://review.openstack.org/#/c/178285/). It will likely be finished before you remove the tests from tempest, so your current plan for removal sounds okay for us. Cheers, Louis signature.asc Description: Digital 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
Re: [openstack-dev] [Nova][Glance] Last day to elect your PTL!
On Thu, Apr 16, 2015 at 02:55:20PM -0400, Tristan Cacqueray wrote: > Just a quick reminder that elections are closing soon, if you haven't > already you should use your right to vote and pick your favourite candidate! Also remember to make sure you voted using the second vote link you were sent (at least for glance, I'm not sure about nova), since the votes for the first are discounted. Cheers, Louis signature.asc Description: Digital 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
Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.
On Wed, Mar 11, 2015 at 02:25:26PM +, Ian Cordasco wrote: > I have no opinions on the matter. Either 1400 or 1500 work for me. I think > there are a lot of people asking for it to be at 1500 instead though. > Would anyone object to changing it to 1500 instead (as long as it is one > consistent time for the meeting)? I have no problem with that. I'm +1 on a consistent time, but don't mind when it is. signature.asc Description: Digital 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
Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.
On Sun, Mar 08, 2015 at 08:07:33PM +, Nikhil Komawar wrote: > So, the new proposal is: > > Glance meetings [1] to be conducted weekly on Thursdays at 1400UTC [2] on > #openstack-meeting-4 +1 It was nice to try out the alternating meeting times. However, I don't think it brought many benefits, and made scheduling harder. Louis signature.asc Description: Digital 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
Re: [openstack-dev] [Glance] Core nominations.
On Wed, Mar 04, 2015 at 07:38:42AM -0430, Flavio Percoco wrote: > I'm sorry but no. I don't think there's anything that requires extra > patience than 2 (or even more) cycles without provaiding reviews or > even any kind of active contribution. > > I personally don't think adding new cores without cleaning up that > list is something healthy for our community, which is what we're > trying to improve here. Therefore I'm still -2-W on adding new folks > without removing non-active core members. > > >The questions I poised are still unanswered: > > > >There are a few members who have been relatively inactive this cycle in terms > >of reviews and have been missed in Flavio's list (That list is not > >comprehensive). On what basis have some of them been missed out and if we do > >not have strong reason, are we being fair? Again, I would like to emphasize > >that, cleaning of the list in such proportions at this point of time does NOT > >look OK strategy to me. > > The list contains the names of ppl that have not provided *any* kind > of review in the last 2 cycles. If there are folks in that list that > you think shouldn't be there, please, bring them up now. If there are > folks you think *should* be in that list, please, bring them on now. > > There's nothing unpolite in what's being discussed here. The proposal > is based on the facts that these folks seem to be focused in different > things now and that's perfectly fine. > > As I mentioned in my first email, we're not questioning their > knowledge but their focus and they are more than welcome to join > again. > > I do not think *counting* the stats of everyone makes sense here, > we're not competing on who reviews more patches. That's nonsense. > We're just trying to keep the list of folks that will have the power > to approve patches short. > > >To answer your concerns: (Why was this not proposed earlier in the cycle?) > > [snip] ? > > >The essence of the matter is: > > > >We need to change the dynamics slowly and with patience for maintaining a > >good > >balance. > > As I mentioned above, I don't think we're being impatient. As a matter > of fact, some of this folks haven't been around in *years* so, pardon > my stubborness but I believe we have been way to patient and I'd have > loved this folks to step down themselves. > > I infinitely thank these folks past work and efforts (and hopefully > future works too) but I think it's time for us to have a clearer view > of who's working in the project. > > As a last note, it's really important to have the list of members > updated, some folks rely on that to know who are the contacts for some > projects. As one of the people in the proposed group of cores, I agree with Flavio. This is something routinely done in other projects, and I don't see why we should be any different. Louis signature.asc Description: Digital 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
Re: [openstack-dev] [glance] Cleanout of inactive change proposals from review
Erno Kuvaja wrote: > We have almost year old (from last update) reviews still in the queue > for glance. The discussion was initiated on yesterday's meeting for > adopting abandon policy for stale changes. I'm okay with abandoning old some old reviews which are obviously going nowhere, such as ones superseded by other fixes or not deemed necessary by anyone (and should probably have been abandoned by the author). I'm not convinced about this being a commonplace action for reviews which are currently inactive. James E. Blair wrote: > Abandoning changes submitted by other people is not a good experience > for people who are contributing to OpenStack, but fortunately, it is not > necessary. > > Our current version of Gerrit supports a rich syntax for searching, > which you can use to create personal or project dashboards. It is quite > easy to filter out changes that appear old or inactive, without the > negative experience of having them abandoned. > > Many projects, including all of the infra projects (which see a > substantial number of changes) are able to function without > automatically abandoning changes. > > If you could identify why you feel the need to abandon other peoples > changes, I'm sure we can find a resolution. I agree with this. I made (actually hacked up Ironic's. Thanks Ironic!) a dashboard for glance [1], which is what I use during reviewing. This hides a lot of the reviews which look stale, and is fairly good at getting an overview of the reviews which require attention. Using or editing a dashboard for your own daily use removes the need to abandon the majority of the changes this proposal suggests. Louis [1] http://goo.gl/eS05pD signature.asc Description: Digital 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
Re: [openstack-dev] [oslo] Why are we continuing to add new namespaced oslo libs?
On Sat, Jan 24, 2015 at 01:48:32AM +0100, Thomas Goirand wrote: > I've just noticed that oslo.log made it to global-requirements.txt 9 > days ago. How come are we still adding some name.spaced oslo libs? > Wasn't the outcome of the discussion in Paris that we shouldn't do that > anymore, and that we should be using oslo-log instead of oslo.log? > > Is three something that I am missing here? The decision at paris was to maintain the same naming convention so the oslo packages are consistent, since dhellman didn't want to rename a lot of packages. [1] http://lists.openstack.org/pipermail/openstack-dev/2014-November/050313.html signature.asc Description: Digital 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
Re: [openstack-dev] [Glance] IRC logging
On Tue, Jan 13, 2015 at 10:54:13AM -0700, John Griffith wrote: > I'd echo all the points made regarding "logging" shouldn't be a > problem; we're an Open Source project so the idea of our communication > being public making anybody nervous and not wanting to participate > seems really off to me. Yes many of us setup our IRC clients to log, > some of us record everything anyway; most of all some of us like to go > back through logs to recap discussions that we had with others > regarding features, bug fixes etc. It's a valuable thing to have IMO. Yes, and transparency in the development is only a good thing in my opinion. > While I'm at it, do meeting channels make sense for project meetings? Seems > like if every project has an IRC channel they could/should probably just have > their meetings there (just make sure there's a meetbot setup). This would be great, since it avoids the scheduling and "which channel have we moved to" questions when a different slot is required. Louis signature.asc Description: Digital 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
Re: [openstack-dev] [Glance] IRC logging
On Mon, Jan 05, 2015 at 05:42:02AM -0600, Cindy Pallares wrote: > I would like to re-open the discussion on IRC logging for the glance > channel. It was discussed on a meeting back in November[1], but it didn't > seem to have a lot of input from the community and it was not discussed in > the mailing list. A lot of information is exchanged through the channel and > it isn't accessible for people who occasionally come into our channel from > other projects, new contributors, and people who don't want to be reached > off-hours or don't have bouncers. Logging our channel would increase our > community's transparency and make our development discussions publicly > accessible to contributors in all time-zones and from other projects. It is > very useful to look back on the logs for previous discussions or as well as > to refer people to discussions or questions previously answered. As the person who brought this up previously, +1 on this. Last time it was brought up there was no strong consensus. Louis signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Git client vulnerability
On Fri, Dec 19, 2014 at 01:19:48PM +, Jeremy Stanley wrote: > Please re-read that advisory[1]. GitHub's _servers_ were not > affected as this is a client-side vulnerability. What GitHub did was > release fixed versions of their "GitHub for Windows" and "GitHub for > Mac" _client_ tools. Github's servers were patched such that is is now not possible to host a malicious repository on github servers, and attempts to push one will be rejected. This is mentioned in the advisory. signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] How to get openstack bugs data for research?
On Wed, Dec 03, 2014 at 08:20:45PM +0800, zfx0...@gmail.com wrote: > Hi, all > > I am a graduate student in Peking University, our lab do some research on > open source projects. > This is our introduction: https://passion-lab.org/ > > Now we need openstack issues data for research, I found the issues list: > https://bugs.launchpad.net/openstack/ > I want to download the openstack issues data, Could anyone tell me how to > download the data? Or is there some link or API for download the data? > > And I found 9464 bugs in https://bugs.launchpad.net/openstack/ ??is this > all? why so few? That is the number of currently open bugs. There are 47733 bugs including closed ones. Launchpad has an API [1], which can probably list the bugs filed against a project. [1] https://help.launchpad.net/API signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [glance] Deprecating osprofiler option 'enabled' in favour of 'profiler_enabled'
On Tue, Dec 02, 2014 at 12:16:44PM +0800, Zhi Yan Liu wrote: > Why not change other services instead of glance? I see one reason is > "glance is the only one service use this option name", but to me one > reason to keep it as-it in glance is that original name makes more > sense due to the option already under "profiler" group, adding > "profiler" prefix to it is really redundant, imo, and in other > existing config group there's no one go this naming way. Then in the > code we can just use a clear way: > > CONF.profiler.enabled > > instead of: > > CONF.profiler.profiler_enabled > > thanks, > zhiyan I agree this looks nicer in the code. However, the primary consumer of this option is someone editing it in the configuration files. In this case, I believe having something more verbose and consistent is better than the Glance code being slightly more elegant. One name or the other doesn't make all that much difference, but consistency in how we turn osprofiler on and off across projects would be best. - Louis signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [glance] Deprecating osprofiler option 'enabled' in favour of 'profiler_enabled'
Hi all, In order to enable or disable osprofiler in Glance, we currently have an option: [profiler] # If False fully disable profiling feature. enabled = False However, all other services with osprofiler integration use a similar option named profiler_enabled. For consistency, I'm proposing we deprecate this option's name in favour of profiler_enabled. This should make it easier for someone to configure osprofiler across projects with less confusion. Does anyone have any thoughts or concerns about this? Thanks, Louis signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Proposal new hacking rules
On Wed, Nov 26, 2014 at 08:54:35AM -0500, Jay Pipes wrote: > It's not about an equality condition. > > It's about the message that is produced by testtools.TestCase.assertEqual(), > and the helpfulness of that message when the order of the arguments is > reversed. > > This is especially true with large dict comparisons. If you get a message > like: > > reference: > actual: > > And the arguments are reversed, then you end up wasting time looking in the > test code instead of the real code for the thing that is different. > > Anyway, like I said, it's not something that we can write a simple hacking > check for, and therefore, it's not something that should have much time > spent on. But I do recommend that reviewers bring it up, especially if the > patch author has been inconsistent in their usage of (expected, actual) in > multiple assertEqual() calls in their patch. I think Nicolas's question was what made testtools choose this ordering. As far as I know, the python docs for unittest uses the opposite ordering. I think most people can see that the error messages involving 'reference' and 'actual' are useful, but maybe not the fact that in order to achieve them using testtools, you need to go against the norm for other testing frameworks. (fwiw, I'm an advocate for using the ordering with the best error messages) signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] fix latency on requirements breakage
On Mon, Nov 17, 2014 at 09:32:21PM -0600, Matt Riedemann wrote: > I think this idea has come up before, the problem is knowing how to > distinguish the sky is falling type bugs from other race bugs we know about. > Thinking out loud it could be severity of the bug in launchpad but we have a > lot of high/critical race bugs that have been around for a long time and they > are obviously not breaking the world. We could tag bugs (I'm assuming I could > get bug tags from the launchpad API) but we'd have to be pretty strict about > not abusing the tag just to get attention on a bug. > > Other ideas? I think just having something like a 'blocks-gate' tag would be fine. I'm not sure it could be badly abused. I'm envisioning elastic recheck giving a message along the lines of: This failure has been tagged as a gate blocking bug, please avoid rechecking until it has been addressed. This should inform people that they shouldn't blindly recheck that patchset and it has limited scope for abuse. signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] fix latency on requirements breakage
On Tue, Nov 18, 2014 at 10:46:38AM +1030, Christopher Yeoh wrote: > Maybe a MOTD at the top of http://review.openstack.org could help here? Have > a button that the QA/infra people can hit when everything is broken that puts > up a message there asking people to stop rechecking/submitting patches. How about elastic recheck showing a message? If a bug is identified as breaking the world, it shouldn't give a helpful "feel free to leave a 'recheck' comment to run the tests again" comment when tests fail. That just encourages people to keep rechecking. signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] Translation technical debt
On Tue, Nov 11, 2014 at 01:46:34PM +, Gary Kotton wrote: > In order to enforce our translation policies - > http://docs.openstack.org/developer/oslo.i18n/guidelines.html - we have added > a hacking rule in Neutron. If you wish to jump aboard this effort then please > let me know. There are patches for all directories except the plugins and > services. I'm interested in adding similar rules to glance sometime in the future. Do you have links to the hacking patches? Louis signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Poll for change in weekly meeting time.
Thanks for bringing this up, Nikhil. On Fri, Oct 31, 2014, Nikhil Komawar wrote: > Here's a poll [0] to find what time-slots work best for everyone as well as > for the interest to remove the alternating time-slot aspect in the schedule. Could this poll be expanded with a wider range of times? I'm sure people will be happy with some time after 17:00 UTC, but not midnight, for example. Are all these timeslots available in #openstack-meeting*? > Please be empathetic in your votes, try to suggest all possible options that > would work for you and note the changes in your timezone due to day-light > savings ending. Please let me know if you've any more questions. I'm personally okay with the later time slot if it means some people can attend who otherwise would not, but other commitments make that availability somewhat sporadic. signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance][QA] python-glanceclient untestable in Python 3.4
On Fri, Oct 17, 2014 at 03:01:22PM +, Jeremy Stanley wrote: > Gah! You'd think *I* would know better at this point--sorry about > that... I've now opened https://launchpad.net/bugs/1382582 to track > this. Thanks for any assistance you're able to provide! This looks like a continuation of the old PYTHONHASHSEED bug: https://launchpad.net/bugs/1348818 signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] 2 Minute tokens
On Tue, Sep 30, 2014 at 10:44:51AM -0400, Adam Young wrote: > What are the uses that require long lived tokens? Glance has operations which can take a long time, such as uploading and downloading large images. signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Some ideas for micro-version implementation
On Tue, Sep 23, 2014 at 01:32:50PM -0400, Andrew Laski wrote: > I've been thinking along very similar lines, but I don't think each current > API needs to be replaced. I would very much like to see a unified API > project that could be responsible for managing requests to "boot an instance > with this network and that volume" which would make requests to > Nova/Neutron/Cinder on the users behalf. Isn't this what openstacksdk [0] is? [0] https://wiki.openstack.org/wiki/SDK-Development/PythonOpenStackSDK signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] znc as a service (was Re: [nova] Is the BP approval process broken?)
Thierry Carrez wrote: > Note that ZNC is not the only IRC proxy out there. Bip is also working > quite well. Note also that an IRC proxy is not the only solution. Using a console IRC client on a server works well for me. Irssi or weechat are both simple to set up. signature.asc Description: Digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
