Re: [openstack-dev] [oslo][devstack][all] ZooKeeper vs etcd for Tooz/DLM

2017-03-15 Thread Louis Taylor
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

2017-02-17 Thread Louis Taylor
On Fri, Feb 17, 2017 at 4:19 PM, Brian Rosmaita
<rosmaita.foss...@gmail.com> 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?

2016-03-09 Thread Louis Taylor
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

2015-12-23 Thread Louis Taylor
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

2015-12-13 Thread Louis Taylor
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

2015-12-07 Thread Louis Taylor
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

2015-11-06 Thread Louis Taylor
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

2015-11-04 Thread Louis Taylor
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

2015-07-29 Thread Louis Taylor
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

2015-07-27 Thread Louis Taylor
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)

2015-07-18 Thread Louis Taylor
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

2015-07-16 Thread Louis Taylor
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?

2015-06-30 Thread Louis Taylor
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

2015-05-19 Thread Louis Taylor
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

2015-04-30 Thread Louis Taylor
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!

2015-04-16 Thread Louis Taylor
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.

2015-03-11 Thread Louis Taylor
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.

2015-03-08 Thread Louis Taylor
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.

2015-03-04 Thread Louis Taylor
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

2015-02-13 Thread Louis Taylor
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?

2015-01-23 Thread Louis Taylor
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

2015-01-13 Thread Louis Taylor
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

2015-01-05 Thread Louis Taylor
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

2014-12-19 Thread Louis Taylor
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?

2014-12-03 Thread Louis Taylor
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


[openstack-dev] [glance] Deprecating osprofiler option 'enabled' in favour of 'profiler_enabled'

2014-12-01 Thread Louis Taylor
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

2014-11-26 Thread Louis Taylor
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: large_dict
  actual: large_dict
 
 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

2014-11-18 Thread Louis Taylor
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

2014-11-17 Thread Louis Taylor
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

2014-11-11 Thread Louis Taylor
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.

2014-10-31 Thread Louis Taylor
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

2014-10-17 Thread Louis Taylor
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

2014-09-30 Thread Louis Taylor
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

2014-09-23 Thread Louis Taylor
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?)

2014-09-03 Thread Louis Taylor
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