[openstack-dev] [Infra] [All] Long test queue relieve

[Kuvaja, Erno]

Hi All,

Looking the queue lengths from Zuul, one thing came to my mind. There is quite 
a few heavy non-voting test jobs running specifically on the check lines. Would 
it be possible to disable these non-voting jobs, lets say, week before freeze 
and re-enable them after the rush has calmed down? This would potentially free 
up some resources to get the pre-freeze merges in.

It's quite unlikely that the non-voting jobs will trigger any actions anyways 
at this point of the cycle.

Erno (jokke_) Kuvaja
kuv...@hp.com
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Glance][Nova][All] requests 2.4.0 breaks glanceclient

[Kuvaja, Erno]

Hi All,

While investigating glanceclient gating issues we narrowed it down to requests 
2.4.0 which was released 2014-08-29. Urllib3 seems to be raising new 
ProtocolError which does not get catched and breaks at least glanceclient.
Following error can be seen on console "ProtocolError: ('Connection aborted.', 
gaierror(-2, 'Name or service not known'))".

Unfortunately we hit on such issue just under the freeze. Apparently this 
breaks novaclient as well and there is change 
(https://review.openstack.org/#/c/118332/ )proposed to requirements to limit 
the version <2.4.0.

Is there any other projects using requirements and seeing issues with the 
latest version?


-  Erno (jokke_) Kuvaja

kuv...@hp.com
___
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?)

[Kuvaja, Erno]

Another well working option that can be easily used:
1) get a Linux system with internet connection (local box, VM in a cloud, 
whatever floats your boat)
2) install irssi and screen
3) run irssi in a screen

Now you can login (local console, ssh, telnet, mosh  again pick your 
preferred) into that linux system attach to the screen and you have your IRC 
client online all the time even you're not.

- Erno (jokke_) Kuvaja

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: 03 September 2014 13:24
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] znc as a service (was Re: [nova] Is the BP
> approval process broken?)
> 
> Stefano Maffulli wrote:
> > On 08/29/2014 11:17 AM, John Garbutt wrote:
> >> After moving to use ZNC, I find IRC works much better for me now, but
> >> I am still learning really.
> >
> > There! this sentence has two very important points worth highlighting:
> >
> > 1- when people say IRC they mean IRC + a hack to overcome its
> > limitation
> > 2- IRC+znc is complex, not many people are used to it
> 
> Note that ZNC is not the only IRC proxy out there. Bip is also working quite
> well.
> 
> > I never used znc, refused to install, secure and maintain yet another
> > public facing service. For me IRC is: be there when it happens or read
> > the logs on eavesdrop, if needed.
> >
> > Recently I found out that there are znc services out there that could
> > make things simpler but they're not easy to join (at least the couple
> > I looked at).
> >
> > Would it make sense to offer znc as a service within the openstack project?
> 
> We could at least document the steps required to set up a proxy. Or propose
> pre-configured images/containers for individuals to run "in the cloud". I
> agree with Ryan that running an IRC proxy for someone else creates...
> interesting privacy issues that may just hinder adoption of said solution.
> 
> --
> Thierry Carrez (ttx)
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][feature freeze exception] Proposal for using Launcher/ProcessLauncher for launching services

[Kuvaja, Erno]

In principle I like the idea and concept, a lot. In practice I don't think 
glance code is ready in a state that we could say SIGHUP reloads our configs. 
Even more my concern is that based on the behavior seen some config options 
gets picked up and some does not.

As long as we do not have definite list documented what options gets updated on 
the fly and what is the actual behavior at the point when new config is picked 
up (lets say we have some locks in place and locking folder gets updated, what 
happens?) I don't think we should be taking this functionality in. Even the 
current behavior is fundamentally broken, at least it's broken in a way that it 
is consistent and the behavior is known.


-  Erno (jokke_) Kuvaja

kuv...@hp.com

From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
Sent: 03 September 2014 14:39
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance][feature freeze exception] Proposal for 
using Launcher/ProcessLauncher for launching services

Hi All,

Please give your support me for applying the  freeze exception for using 
oslo-incubator service framework in glance, based on the following blueprint:

https://blueprints.launchpad.net/glance/+spec/use-common-service-framework

I have ensured that after making these changes everything is working smoothly.

I have done the functional testing for following three scenarios:

1.   Enabled SSL and checked requests are processed by the Api service 
before and after SIGHUP signal

2.   Disabled SSL and  checked requests are processed by the Api service 
before and after SIGHUP signal

3.   I have also ensured reloading of the parameters like 
ilesystem_store_datadir, filesystem_store_datadirs are  working effectively 
after sending the SIGHUP signal.

To test 1st and 2nd I have created a python script which will send multiple 
requests to glance at a time and added a chron job to send a SIGHUP signal to 
the parent process.
I have tested above script for 1 hour and confirmed every request has been 
processed successfully.

Please consider this feature to be a part of Juno release.



Thanks & Regards,

Abhishek Kekane


From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
Sent: 02 September 2014 19:11
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org)
Subject: [openstack-dev] [glance][feature freeze exception] Proposal for using 
Launcher/ProcessLauncher for launching services

Hi All,

I'd like to ask for a feature freeze exception for using oslo-incubator service 
framework in glance, based on the following blueprint:

https://blueprints.launchpad.net/glance/+spec/use-common-service-framework


The code to implement this feature is under review at present.

1. Sync oslo-incubator service module in glance: 
https://review.openstack.org/#/c/117135/2
2. Use Launcher/ProcessLauncher in glance: 
https://review.openstack.org/#/c/117988/


If we have this feature in glance then we can able to use features like reload 
glance configuration file without restart, graceful shutdown etc.
Also it will use common code like other OpenStack projects nova, keystone, 
cinder does.


We are ready to address all the concerns of the community if they have any.


Thanks & Regards,

Abhishek Kekane

__
Disclaimer:This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged, confidential, 
and proprietary data. If you are not the intended recipient, please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding

__
Disclaimer:This email and any attachments are sent in strictest confidence for 
the sole use of the addressee and may contain legally privileged, confidential, 
and proprietary data. If you are not the intended recipient, please advise the 
sender by replying promptly to this email and then delete and destroy this 
email and any attachments without any further use, copying or forwarding
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [glance] do NOT ever sort requirements.txt

[Kuvaja, Erno]

> -Original Message-
> From: Sean Dague [mailto:s...@dague.net]
> Sent: 03 September 2014 13:37
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [all] [glance] do NOT ever sort requirements.txt
> 
> I'm not sure why people keep showing up with "sort requirements" patches
> like - https://review.openstack.org/#/c/76817/6, however, they do.
> 
> All of these need to be -2ed with predjudice.
> 
> requirements.txt is not a declarative interface. The order is important as pip
> processes it in the order it is. Changing the order has impacts on the overall
> integration which can cause wedges later.
> 
> So please stop.
> 
>   -Sean
> 
> --
> Sean Dague
> http://dague.net
>

Hi Sean & all,

Could you please open this up a little bit? What are we afraid breaking 
regarding the order of these requirements? I tried to go through pip 
documentation but I could not find reason of specific order of the lines, 
references to keep the order there was 'though.

I'm now assuming one thing here as I do not know if that's the case. None of 
the packages enables/disables functionality depending of what has been 
installed on the system before, but they have their own dependencies to provide 
those. Based on this assumption I can think of only one scenario causing us 
issues. That is us abusing the example in point 2 of 
https://pip.pypa.io/en/latest/user_guide.html#requirements-files meaning; we 
install package X depending on package Y>=1.0,<2.0 before installing package Z 
depending on Y>=1.0 to ensure that package Y<2.0 without pinning package Y in 
our requirements.txt. I certainly hope that this is not the case as depending 
3rd party vendor providing us specific version of dependency package would be 
extremely stupid.

Other than that I really don't know how the order could cause us issues, but I 
would be really happy to learn something new today if that is the case or if my 
assumption went wrong.

Best Regards,
Erno (jokke_) Kuvaja
 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [glance] do NOT ever sort requirements.txt

[Kuvaja, Erno]

> -Original Message-
> From: Clark Boylan [mailto:cboy...@sapwetik.org]
> Sent: 03 September 2014 20:10
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all] [glance] do NOT ever sort requirements.txt
> 
> 
> 
> On Wed, Sep 3, 2014, at 11:51 AM, Kuvaja, Erno wrote:
> > > -Original Message-
> > > From: Sean Dague [mailto:s...@dague.net]
> > > Sent: 03 September 2014 13:37
> > > To: OpenStack Development Mailing List (not for usage questions)
> > > Subject: [openstack-dev] [all] [glance] do NOT ever sort
> > > requirements.txt
> > >
> > > I'm not sure why people keep showing up with "sort requirements"
> > > patches like - https://review.openstack.org/#/c/76817/6, however, they
> do.
> > >
> > > All of these need to be -2ed with predjudice.
> > >
> > > requirements.txt is not a declarative interface. The order is
> > > important as pip processes it in the order it is. Changing the order
> > > has impacts on the overall integration which can cause wedges later.
> > >
> > > So please stop.
> > >
> > >   -Sean
> > >
> > > --
> > > Sean Dague
> > > http://dague.net
> > >
> >
> > Hi Sean & all,
> >
> > Could you please open this up a little bit? What are we afraid
> > breaking regarding the order of these requirements? I tried to go
> > through pip documentation but I could not find reason of specific
> > order of the lines, references to keep the order there was 'though.
> >
> > I'm now assuming one thing here as I do not know if that's the case.
> > None of the packages enables/disables functionality depending of what
> > has been installed on the system before, but they have their own
> > dependencies to provide those. Based on this assumption I can think of
> > only one scenario causing us issues. That is us abusing the example in
> > point 2 of
> > https://pip.pypa.io/en/latest/user_guide.html#requirements-files
> > meaning; we install package X depending on package Y>=1.0,<2.0 before
> > installing package Z depending on Y>=1.0 to ensure that package Y<2.0
> > without pinning package Y in our requirements.txt. I certainly hope
> > that this is not the case as depending 3rd party vendor providing us 
> > specific
> version of dependency package would be extremely stupid.
> >
> > Other than that I really don't know how the order could cause us
> > issues, but I would be really happy to learn something new today if
> > that is the case or if my assumption went wrong.
> >
> > Best Regards,
> > Erno (jokke_) Kuvaja
> >
> > > ___
> > > OpenStack-dev mailing list
> > > OpenStack-dev@lists.openstack.org
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> The issue is described in the bug that Josh linked
> (https://github.com/pypa/pip/issues/988). Basically pip doesn't do
> dependency resolution in a way that lets you treat requirements as order
> independent. For that to be the case pip would have to evaluate all
> dependencies together then install the intersection of those dependencies.
> Instead it iterates over the list(s) in order and evaluates each dependency as
> it is found.
> 
> Your example basically describes where this breaks. You can both depend on
> the same dependency at different versions and pip will install a version that
> satisfies only one of the dependencies and not the other leading to a failed
> install. However I think a more common case is that openstack will pin a
> dependency and say Y>=1.0,<2.0 and the X dependency will say Y>=1.0. If
> the X dependency comes first you get version 2.5 which is not valid for your
> specification of Y>=1.0,<2.0 and pip fails.
> You fix this by listing Y before X dependency that installs Y with less 
> restrictive
> boundaries.
> 
> Another example of a slightly different failure would be hacking, flake8,
> pep8, and pyflakes. Hacking installs a specific version of flake8, pep8, and
> pyflakes so that we do static lint checking with consistent checks each
> release. If you sort this list alphabetically instead of allowing hacking to 
> install
> its deps flake8 will come first and you can get a different version of pep8.
> Different v

Re: [openstack-dev] [all] [glance] do NOT ever sort requirements.txt

[Kuvaja, Erno]

> -Original Message-
> From: Clark Boylan [mailto:cboy...@sapwetik.org]
> Sent: 03 September 2014 21:57
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all] [glance] do NOT ever sort requirements.txt
> 
> 
> 
> On Wed, Sep 3, 2014, at 01:06 PM, Kuvaja, Erno wrote:
> > > -Original Message-
> > > From: Clark Boylan [mailto:cboy...@sapwetik.org]
> > > Sent: 03 September 2014 20:10
> > > To: openstack-dev@lists.openstack.org
> > > Subject: Re: [openstack-dev] [all] [glance] do NOT ever sort
> > > requirements.txt
> > >
> > >
> > >
> > > On Wed, Sep 3, 2014, at 11:51 AM, Kuvaja, Erno wrote:
> > > > > -Original Message-
> > > > > From: Sean Dague [mailto:s...@dague.net]
> > > > > Sent: 03 September 2014 13:37
> > > > > To: OpenStack Development Mailing List (not for usage questions)
> > > > > Subject: [openstack-dev] [all] [glance] do NOT ever sort
> > > > > requirements.txt
> > > > >
> > > > > I'm not sure why people keep showing up with "sort requirements"
> > > > > patches like - https://review.openstack.org/#/c/76817/6,
> > > > > however, they
> > > do.
> > > > >
> > > > > All of these need to be -2ed with predjudice.
> > > > >
> > > > > requirements.txt is not a declarative interface. The order is
> > > > > important as pip processes it in the order it is. Changing the
> > > > > order has impacts on the overall integration which can cause wedges
> later.
> > > > >
> > > > > So please stop.
> > > > >
> > > > >   -Sean
> > > > >
> > > > > --
> > > > > Sean Dague
> > > > > http://dague.net
> > > > >
> > > >
> > > > Hi Sean & all,
> > > >
> > > > Could you please open this up a little bit? What are we afraid
> > > > breaking regarding the order of these requirements? I tried to go
> > > > through pip documentation but I could not find reason of specific
> > > > order of the lines, references to keep the order there was 'though.
> > > >
> > > > I'm now assuming one thing here as I do not know if that's the case.
> > > > None of the packages enables/disables functionality depending of
> > > > what has been installed on the system before, but they have their
> > > > own dependencies to provide those. Based on this assumption I can
> > > > think of only one scenario causing us issues. That is us abusing
> > > > the example in point 2 of
> > > > https://pip.pypa.io/en/latest/user_guide.html#requirements-files
> > > > meaning; we install package X depending on package Y>=1.0,<2.0
> > > > before installing package Z depending on Y>=1.0 to ensure that
> > > > package Y<2.0 without pinning package Y in our requirements.txt. I
> > > > certainly hope that this is not the case as depending 3rd party
> > > > vendor providing us specific
> > > version of dependency package would be extremely stupid.
> > > >
> > > > Other than that I really don't know how the order could cause us
> > > > issues, but I would be really happy to learn something new today
> > > > if that is the case or if my assumption went wrong.
> > > >
> > > > Best Regards,
> > > > Erno (jokke_) Kuvaja
> > > >
> > > > > ___
> > > > > OpenStack-dev mailing list
> > > > > OpenStack-dev@lists.openstack.org
> > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-de
> > > > > v
> > > >
> > > > ___
> > > > OpenStack-dev mailing list
> > > > OpenStack-dev@lists.openstack.org
> > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > > The issue is described in the bug that Josh linked
> > > (https://github.com/pypa/pip/issues/988). Basically pip doesn't do
> > > dependency resolution in a way that lets you treat requirements as
> > > order independent. For that to be the case pip would have to
> > > evaluate all dependencies together then install the intersection of those
> dependencies.
> > > Instead it

[openstack-dev] [Glance][FFE] Refactoring Glance Logging

[Kuvaja, Erno]

All,

There is two changes still not landed from 
https://blueprints.launchpad.net/glance/+spec/refactoring-glance-logging

https://review.openstack.org/116626

and

https://review.openstack.org/#/c/117204/

Merge of the changes was delayed over J3 to avoid any potential merge 
conflicts. There was minor change made (couple of LOG.exceptions changed to 
LOG.error based on the review feedback) when rebased.

I would like to request Feature Freeze Exception if needed to finish the Juno 
Logging refactoring and getting these two changes merged in.

BR,
Erno (jokke_) Kuvaja
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

[Kuvaja, Erno]

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: 16 September 2014 10:08
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
> level
> guidelines
> 
> On 09/16/2014 01:10 AM, Clint Byrum wrote:
> > Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
> >> On 09/15/2014 07:00 PM, Mark Washenberger wrote:
> >>> Hi there logging experts,
> >>>
> >>> We've recently had a little disagreement in the glance team about
> >>> the appropriate log levels for http requests that end up failing due
> >>> to user errors. An example would be a request to get an image that
> >>> does not exist, which results in a 404 Not Found request.
> >>>
> >>> On one hand, this event is an error, so DEBUG or INFO seem a little
> >>> too low. On the other hand, this error doesn't generally require any
> >>> kind of operator investigation or indicate any actual failure of the
> >>> service, so perhaps it is excessive to log it at WARN or ERROR.
> >>>
> >>> Please provide feedback to help us resolve this dispute if you feel you
> can!
> >>
> >> My feeling is this is an INFO level. There is really nothing the
> >> admin should care about here.
> >
> > Agree with Sean. INFO are useful for investigations. WARN and ERROR
> > are cause for alarm.
> 
> +1 this is what we do in Zaqar as well.
> 
> 
> --
> @flaper87
> Flavio Percoco
> 

I think the debate here does not only limit to 404s. By the logging guidelines 
INFO level messages should not contain any error related messages but rather 
stuff like certain components starting/stopping, config info, etc. WARN should 
not be anything that gets the ops pulled out of bed and so on. 

Also all information that would be in interest of ops should be logged INFO+.

Now if we are logging user errors as WARN that makes the environment 
supportable even if the logging has been set as high as WARN cleaning the 
output a lot (as INFO shouldn't contain anything out of order anyways). Current 
situation is that logging at DEBUG level is the only option to get the needed 
information to actually run the services and get the data needed to support it 
as well. If we log user errors on INFO we get one step higher but we still have 
all that clutter like every single request in the logs and if that's the 
direction we want to go, we should revisit our logging guidelines as well.

Thus my two euro cents goes towards WARN rather than debug and definitely not 
INFO.

- Erno (jokke) Kuvaja

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

[Kuvaja, Erno]

> -Original Message-
> From: Sean Dague [mailto:s...@dague.net]
> Sent: 16 September 2014 12:40
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
> level
> guidelines
> 
> On 09/16/2014 06:44 AM, Kuvaja, Erno wrote:
> >> -Original Message-
> >> From: Flavio Percoco [mailto:fla...@redhat.com]
> >> Sent: 16 September 2014 10:08
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [glance][all] Help with interpreting the
> >> log level guidelines
> >>
> >> On 09/16/2014 01:10 AM, Clint Byrum wrote:
> >>> Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
> >>>> On 09/15/2014 07:00 PM, Mark Washenberger wrote:
> >>>>> Hi there logging experts,
> >>>>>
> >>>>> We've recently had a little disagreement in the glance team about
> >>>>> the appropriate log levels for http requests that end up failing
> >>>>> due to user errors. An example would be a request to get an image
> >>>>> that does not exist, which results in a 404 Not Found request.
> >>>>>
> >>>>> On one hand, this event is an error, so DEBUG or INFO seem a
> >>>>> little too low. On the other hand, this error doesn't generally
> >>>>> require any kind of operator investigation or indicate any actual
> >>>>> failure of the service, so perhaps it is excessive to log it at WARN or
> ERROR.
> >>>>>
> >>>>> Please provide feedback to help us resolve this dispute if you
> >>>>> feel you
> >> can!
> >>>>
> >>>> My feeling is this is an INFO level. There is really nothing the
> >>>> admin should care about here.
> >>>
> >>> Agree with Sean. INFO are useful for investigations. WARN and ERROR
> >>> are cause for alarm.
> >>
> >> +1 this is what we do in Zaqar as well.
> >>
> >>
> >> --
> >> @flaper87
> >> Flavio Percoco
> >>
> >
> > I think the debate here does not only limit to 404s. By the logging 
> > guidelines
> INFO level messages should not contain any error related messages but
> rather stuff like certain components starting/stopping, config info, etc.
> WARN should not be anything that gets the ops pulled out of bed and so on.
> >
> > Also all information that would be in interest of ops should be logged
> INFO+.
> >
> > Now if we are logging user errors as WARN that makes the environment
> supportable even if the logging has been set as high as WARN cleaning the
> output a lot (as INFO shouldn't contain anything out of order anyways).
> Current situation is that logging at DEBUG level is the only option to get the
> needed information to actually run the services and get the data needed to
> support it as well. If we log user errors on INFO we get one step higher but
> we still have all that clutter like every single request in the logs and if 
> that's
> the direction we want to go, we should revisit our logging guidelines as well.
> >
> > Thus my two euro cents goes towards WARN rather than debug and
> definitely not INFO.
> 
> Part of it is how often you expect things to happen as well. Remember
> glanceclient opperates in the context of "other" processes. When it hits a 404
> in Glance, it's not running in the glance context, it's running in the Nova
> context. Which means it needs to think of itself in that context.
> 
> In that context we got the exception back from Glance, we know the image
> wasn't there. And we know whether or not that's a problem (glanceclient
> actually has no idea if it's a problem or not, we might be checking to make
> sure a thing isn't there, and success for us is the 404).
> 
> So actually, I'm back to Jay on this, it should be DEBUG. Nova (or whoever the
> caller is) can decide if the issue warents something larger than that.
> 
> This is really the biggest issue with logging in the clients, people don't 
> think
> about the context that they are running in.
> 
>   -Sean
> 
> --
> Sean Dague
> http://dague.net
> 

Sean,

I'm not sure if we were specific enough here. Not talking about client but the 
server logging. So how we should log events like client trying to change 
protected properties, access non existing image, create duplicate image IDs, 
etc.

So for example if Nova is trying to access image that does not exist should we 
ignore it on Glance side or when the user tries to do something that does not 
succeed. In my point of view it makes life much easier if we have information 
where the request failed rather than just a wsgi return code or having to run 
the system on DEBUG logging to get that information.

- Erno

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

[Kuvaja, Erno]

> -Original Message-
> From: Sean Dague [mailto:s...@dague.net]
> Sent: 16 September 2014 15:56
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
> level
> guidelines
> 
> On 09/16/2014 10:16 AM, Kuvaja, Erno wrote:
> >> -Original Message-
> >> From: Sean Dague [mailto:s...@dague.net]
> >> Sent: 16 September 2014 12:40
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [glance][all] Help with interpreting the
> >> log level guidelines
> >>
> >> On 09/16/2014 06:44 AM, Kuvaja, Erno wrote:
> >>>> -Original Message-
> >>>> From: Flavio Percoco [mailto:fla...@redhat.com]
> >>>> Sent: 16 September 2014 10:08
> >>>> To: openstack-dev@lists.openstack.org
> >>>> Subject: Re: [openstack-dev] [glance][all] Help with interpreting
> >>>> the log level guidelines
> >>>>
> >>>> On 09/16/2014 01:10 AM, Clint Byrum wrote:
> >>>>> Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
> >>>>>> On 09/15/2014 07:00 PM, Mark Washenberger wrote:
> >>>>>>> Hi there logging experts,
> >>>>>>>
> >>>>>>> We've recently had a little disagreement in the glance team
> >>>>>>> about the appropriate log levels for http requests that end up
> >>>>>>> failing due to user errors. An example would be a request to get
> >>>>>>> an image that does not exist, which results in a 404 Not Found
> request.
> >>>>>>>
> >>>>>>> On one hand, this event is an error, so DEBUG or INFO seem a
> >>>>>>> little too low. On the other hand, this error doesn't generally
> >>>>>>> require any kind of operator investigation or indicate any
> >>>>>>> actual failure of the service, so perhaps it is excessive to log
> >>>>>>> it at WARN or
> >> ERROR.
> >>>>>>>
> >>>>>>> Please provide feedback to help us resolve this dispute if you
> >>>>>>> feel you
> >>>> can!
> >>>>>>
> >>>>>> My feeling is this is an INFO level. There is really nothing the
> >>>>>> admin should care about here.
> >>>>>
> >>>>> Agree with Sean. INFO are useful for investigations. WARN and
> >>>>> ERROR are cause for alarm.
> >>>>
> >>>> +1 this is what we do in Zaqar as well.
> >>>>
> >>>>
> >>>> --
> >>>> @flaper87
> >>>> Flavio Percoco
> >>>>
> >>>
> >>> I think the debate here does not only limit to 404s. By the logging
> >>> guidelines
> >> INFO level messages should not contain any error related messages but
> >> rather stuff like certain components starting/stopping, config info, etc.
> >> WARN should not be anything that gets the ops pulled out of bed and so
> on.
> >>>
> >>> Also all information that would be in interest of ops should be
> >>> logged
> >> INFO+.
> >>>
> >>> Now if we are logging user errors as WARN that makes the environment
> >> supportable even if the logging has been set as high as WARN cleaning
> >> the output a lot (as INFO shouldn't contain anything out of order
> anyways).
> >> Current situation is that logging at DEBUG level is the only option
> >> to get the needed information to actually run the services and get
> >> the data needed to support it as well. If we log user errors on INFO
> >> we get one step higher but we still have all that clutter like every
> >> single request in the logs and if that's the direction we want to go, we
> should revisit our logging guidelines as well.
> >>>
> >>> Thus my two euro cents goes towards WARN rather than debug and
> >> definitely not INFO.
> >>
> >> Part of it is how often you expect things to happen as well. Remember
> >> glanceclient opperates in the context of "other" processes. When it
> >> hits a 404 in Glance, it's not running in the glance context, it's
> >> running in the Nova context. Which means it needs to think of itself in
> that context.
> >>
> >> In that context we got 

Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

[Kuvaja, Erno]

> -Original Message-
> From: Sean Dague [mailto:s...@dague.net]
> Sent: 16 September 2014 17:31
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
> level
> guidelines
> 
> On 09/16/2014 12:07 PM, Kuvaja, Erno wrote:
> >> -Original Message-
> >> From: Sean Dague [mailto:s...@dague.net]
> >> Sent: 16 September 2014 15:56
> >> To: openstack-dev@lists.openstack.org
> >> Subject: Re: [openstack-dev] [glance][all] Help with interpreting the
> >> log level guidelines
> >>
> >> On 09/16/2014 10:16 AM, Kuvaja, Erno wrote:
> >>>> -Original Message-
> >>>> From: Sean Dague [mailto:s...@dague.net]
> >>>> Sent: 16 September 2014 12:40
> >>>> To: openstack-dev@lists.openstack.org
> >>>> Subject: Re: [openstack-dev] [glance][all] Help with interpreting
> >>>> the log level guidelines
> >>>>
> >>>> On 09/16/2014 06:44 AM, Kuvaja, Erno wrote:
> >>>>>> -Original Message-
> >>>>>> From: Flavio Percoco [mailto:fla...@redhat.com]
> >>>>>> Sent: 16 September 2014 10:08
> >>>>>> To: openstack-dev@lists.openstack.org
> >>>>>> Subject: Re: [openstack-dev] [glance][all] Help with interpreting
> >>>>>> the log level guidelines
> >>>>>>
> >>>>>> On 09/16/2014 01:10 AM, Clint Byrum wrote:
> >>>>>>> Excerpts from Sean Dague's message of 2014-09-15 16:02:04 -0700:
> >>>>>>>> On 09/15/2014 07:00 PM, Mark Washenberger wrote:
> >>>>>>>>> Hi there logging experts,
> >>>>>>>>>
> >>>>>>>>> We've recently had a little disagreement in the glance team
> >>>>>>>>> about the appropriate log levels for http requests that end up
> >>>>>>>>> failing due to user errors. An example would be a request to
> >>>>>>>>> get an image that does not exist, which results in a 404 Not
> >>>>>>>>> Found
> >> request.
> >>>>>>>>>
> >>>>>>>>> On one hand, this event is an error, so DEBUG or INFO seem a
> >>>>>>>>> little too low. On the other hand, this error doesn't
> >>>>>>>>> generally require any kind of operator investigation or
> >>>>>>>>> indicate any actual failure of the service, so perhaps it is
> >>>>>>>>> excessive to log it at WARN or
> >>>> ERROR.
> >>>>>>>>>
> >>>>>>>>> Please provide feedback to help us resolve this dispute if you
> >>>>>>>>> feel you
> >>>>>> can!
> >>>>>>>>
> >>>>>>>> My feeling is this is an INFO level. There is really nothing
> >>>>>>>> the admin should care about here.
> >>>>>>>
> >>>>>>> Agree with Sean. INFO are useful for investigations. WARN and
> >>>>>>> ERROR are cause for alarm.
> >>>>>>
> >>>>>> +1 this is what we do in Zaqar as well.
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> @flaper87
> >>>>>> Flavio Percoco
> >>>>>>
> >>>>>
> >>>>> I think the debate here does not only limit to 404s. By the
> >>>>> logging guidelines
> >>>> INFO level messages should not contain any error related messages
> >>>> but rather stuff like certain components starting/stopping, config info,
> etc.
> >>>> WARN should not be anything that gets the ops pulled out of bed and
> >>>> so
> >> on.
> >>>>>
> >>>>> Also all information that would be in interest of ops should be
> >>>>> logged
> >>>> INFO+.
> >>>>>
> >>>>> Now if we are logging user errors as WARN that makes the
> >>>>> environment
> >>>> supportable even if the logging has been set as high as WARN
> >>>> cleaning the output a lot (as INFO shouldn't contain anything out
> >>>> of order
> >> anyways).
&g

Re: [openstack-dev] [glance][all] Help with interpreting the log level guidelines

[Kuvaja, Erno]

> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: 16 September 2014 18:10
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [glance][all] Help with interpreting the log 
> level
> guidelines
> 
> On 09/16/2014 10:16 AM, Kuvaja, Erno wrote:
>  > In my point of view it makes life
> > much easier if we have information where the request failed
> 
> The request did not fail. The HTTP request succeeded and Glance returned a
> 404 Not Found. If the caller was expecting an image to be there, but it 
> wasn't,
> then it can log the 404 in whatever log level is most appropriate.
> 
> The point is that DEBUG log level is appropriate for the glanceclient logs, 
> since
> the glanceclient doesn't know if a 404 is something to be concerned about or
> not. To glanceclient, the call succeeded.
> Communication with the Glance API server worked, authentication worked,
> and the server returned successfully stating that the image does not exist.
> 
> -jay
> 

Still this is not about glanceclient logging. On that discussion I fully agree 
that less is more what comes to logging.

When we try to update an image in the glance code and that fails because the 
image is not there, I do not care where that gets stated to the end user. What 
I care about is that when the user starts asking what happened, I don't get 
called up from the bed because the ops responsible for the service have no 
idea. I also care that the ops does not need to run through million lines of 
debugging logs just because they would not get the info without. The reality is 
after all that even in developer point of view the request did not fail, user 
point of view it did.

We must keep in mind that somewhere out there is bunch of people using these 
services outside of devstack who does not know the code and how it behaves 
internally. They see the log messages if any and need to try to get the answers 
for the people who knows even less about the internals.

- Erno

___
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'

[Kuvaja, Erno]

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: 02 December 2014 09:45
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [glance] Deprecating osprofiler option 'enabled'
> in favour of 'profiler_enabled'
> 
> On 02/12/14 12:16 +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
> 
> I'm with Zhi Yan on this one. Adding profiler sounds redundant.

+1, The reasoning makes sense to keep it as it is.

- Erno

> 
> Cheers,
> Flavio
> 
> >
> >thanks,
> >zhiyan
> >
> >On Mon, Dec 1, 2014 at 11:43 PM, Ian Cordasco
> > wrote:
> >> On 12/1/14, 08:37, "Louis Taylor"  wrote:
> >>
> >>>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
> >>
> >> We *just* introduced this if I remember the IRC discussion from last
> >> month. I’m not sure how many people will be immediately making use of
> it.
> >> I’m in favor of consistency where possible and while this would
> >> require a deprecation, I think it’s a worthwhile change.
> >>
> >> +1 from me
> >>
> >> —
> >>
> >> Ian
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >___
> >OpenStack-dev mailing list
> >OpenStack-dev@lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> --
> @flaper87
> Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] Option to skip deleting images in use?

[Kuvaja, Erno]

I think that's horrible idea. How do we do that store independent with the 
linking dependencies?

We should not depend universal use case like this on limited subset of 
backends, specially non-OpenStack ones. Glance (nor Nova) should never depend 
having direct access to the actual medium where the images are stored. I think 
this is school book example for something called database. Well arguable if 
this should be tracked at Glance or Nova, but definitely not a dirty hack 
expecting specific backend characteristics.

As mentioned before the protected image property is to ensure that the image 
does not get deleted, that is also easy to track when the images are queried. 
Perhaps the record needs to track the original state of protected flag, image 
id and use count. 3 column table and couple of API calls. Lets not at least 
make it any more complicated than it needs to be if such functionality is 
desired.


-  Erno

From: Nikhil Komawar [mailto:nikhil.koma...@rackspace.com]
Sent: 17 December 2014 20:34
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] Option to skip deleting images in use?

Guess that's a implementation detail. Depends on the way you go about using 
what's available now, I suppose.

Thanks,
-Nikhil

From: Chris St. Pierre [chris.a.st.pie...@gmail.com]
Sent: Wednesday, December 17, 2014 2:07 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] Option to skip deleting images in use?
I was assuming atomic increment/decrement operations, in which case I'm not 
sure I see the race conditions. Or is atomism assuming too much?

On Wed, Dec 17, 2014 at 11:59 AM, Nikhil Komawar 
mailto:nikhil.koma...@rackspace.com>> wrote:
That looks like a decent alternative if it works. However, it would be too racy 
unless we we implement a test-and-set for such properties or there is a 
different job which queues up these requests and perform sequentially for each 
tenant.

Thanks,
-Nikhil

From: Chris St. Pierre 
[chris.a.st.pie...@gmail.com]
Sent: Wednesday, December 17, 2014 10:23 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] Option to skip deleting images in use?
That's unfortunately too simple. You run into one of two cases:

1. If the job automatically removes the protected attribute when an image is no 
longer in use, then you lose the ability to use "protected" on images that are 
not in use. I.e., there's no way to say, "nothing is currently using this 
image, but please keep it around." (This seems particularly useful for 
snapshots, for instance.)

2. If the job does not automatically remove the protected attribute, then an 
image would be protected if it had ever been in use; to delete an image, you'd 
have to manually un-protect it, which is a workflow that quite explicitly 
defeats the whole purpose of flagging images as protected when they're in use.

It seems like flagging an image as *not* in use is actually a fairly difficult 
problem, since it requires consensus among all components that might be using 
images.

The only solution that readily occurs to me would be to add something like a 
filesystem link count to images in Glance. Then when Nova spawns an instance, 
it increments the usage count; when the instance is destroyed, the usage count 
is decremented. And similarly with other components that use images. An image 
could only be deleted when its usage count was zero.

There are ample opportunities to get out of sync there, but it's at least a 
sketch of something that might work, and isn't *too* horribly hackish. Thoughts?

On Tue, Dec 16, 2014 at 6:11 PM, Vishvananda Ishaya 
mailto:vishvana...@gmail.com>> wrote:
A simple solution that wouldn't require modification of glance would be a cron 
job
that lists images and snapshots and marks them protected while they are in use.

Vish

On Dec 16, 2014, at 3:19 PM, Collins, Sean 
mailto:sean_colli...@cable.comcast.com>> wrote:

> On Tue, Dec 16, 2014 at 05:12:31PM EST, Chris St. Pierre wrote:
>> No, I'm looking to prevent images that are in use from being deleted. "In
>> use" and "protected" are disjoint sets.
>
> I have seen multiple cases of images (and snapshots) being deleted while
> still in use in Nova, which leads to some very, shall we say,
> interesting bugs and support problems.
>
> I do think that we should try and determine a way forward on this, they
> are indeed disjoint sets. Setting an image as protected is a proactive
> measure, we should try and figure out a way to keep tenants from
> shooting themselves in the foot if possible.
>
> --
> Sean M. Collins
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailma

Re: [openstack-dev] [Glance] IRC logging

[Kuvaja, Erno]

I'm heavily against the public logging to the level that I will just leave the 
channel if that will be enabled. My point is not foul language and I do 
understand that there could be some benefits out of it. Personally I think we 
have enough tracked public communication means like ask.openstack.org and the 
mailing lists. IRC is and has always been real time communications with defined 
audience. 

I think the major benefits of this defined audience are:
1) One does not need to express themselves in a way that is for public. ( 
Misunderstandings can be corrected on the fly if needed. ) There is no need to 
explain to anyone reading the logs what you actually meant during the 
conversation month ago.
2) there is level of confidentiality within that defined audience. ( For 
example someone not familiar with the processes thinks they have found security 
vulnerability and comes to the IRC-channel to ask second opinion. Those details 
are not public and that bug can still be raised and dealt properly. Once the 
discussion is logged and the logs are publicly available the details are 
publicly available as well. )
3) That defined audience does not usually limit content. I have no problem to 
throw my e-mail address, phone number etc. into the channel, I would not yell 
them out publicly.

For me personally the last point is the biggest problem, professionally the 
second is major concern. I have been using IRC for so long time that I'm not 
willing to take the risk I can't filter myself on my regular channels. Meetings 
are different story as there it is defined time and at least I'm on meeting 
mode that time knowing it will be publicly logged.

The channels are not locked so anyone can keep a client online and log it for 
themselves if they feel need for it and lots of people do so. There is just 
that big barrier having it within the defined group you can see on the channel 
versus public to anyone. 

As opposed to Cindy's original statement of not wanting to be available 
off-hours, that's solved already: you can set your client to away or not 
respond. It's really common on any IRC network that nick is online while user 
is not or is ignoring that real time outreach by personal preference. No-one 
will/should take that personally or offensive. Not having bouncer/shell to run 
your client is as well personal preference, I doubt anyone can claim they could 
not do it with the options available nowadays.

 - Erno (jokke_) Kuvaja

> -Original Message-
> From: Nikhil Komawar [mailto:nikhil.koma...@rackspace.com]
> Sent: 05 January 2015 19:11
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Glance] IRC logging
> 
> Thanks Cindy!
> 
> Glance cores, can you all please pitch in?
> 
> -Nikhil
> 
> 
> From: Cindy Pallares [cpalla...@redhat.com]
> Sent: Monday, January 05, 2015 12:28 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Glance] IRC logging
> 
> I've made a patch, we can vote on it there.
> 
> https://review.openstack.org/#/c/145025/
> 
> 
> On 01/05/2015 11:15 AM, Amrith Kumar wrote:
> > I think logging the channel is a benefit even if, as Nikhil points out, it 
> > is not
> an official meeting. Trove logs both the #openstack-trove channel and the
> meetings when they occur. I have also had some conversations with other
> ATC's on #openstack-oslo and #openstack-security and have found that the
> eavesdrop logs at http://eavesdrop.openstack.org/irclogs/ to be invaluable
> in either bug comments or code review comments.
> >
> > The IRC channel is an integral part of communicating within the OpenStack
> community. The use of foul language and other inappropriate behavior
> should be monitored not by admins but by other members of the community
> and called out just as one would call out similar behavior in a non-virtual 
> work
> environment. I submit to you that profanity and inappropriate conduct in an
> IRC channel constitutes a hostile work environment just as much as it does in
> a non-virtual environment.
> >
> > Therefore I submit to you that there is no place for such behavior on an IRC
> channel irrespective of whether it is logged or not.
> >
> > Thanks,
> >
> > -amrith
> >
> > | -Original Message-
> > | From: Morgan Fainberg [mailto:morgan.fainb...@gmail.com]
> > | Sent: Monday, January 05, 2015 11:58 AM
> > | To: OpenStack Development Mailing List (not for usage questions)
> > | Subject: Re: [openstack-dev] [Glance] IRC logging
> > |
> > |
> > |
> > | > On Jan 5, 2015, at 08:07, Nikhil Komawar
> > | > 
> > | wrote:
> > | >
> > | > Based on the feedback received, we would like to avoid logging on
> > | > the
> > | project channel. My take from the discussion was that it gives many
> > | a folks a feeling of informal platform to express their ideas freely
> > | in contrast to the meeting channels.
> > | >
> > | > However, at the same time I would like to point out tha

Re: [openstack-dev] [Glance] IRC logging

[Kuvaja, Erno]

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: 13 January 2015 13:02
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Glance] IRC logging
> 
> Kuvaja, Erno wrote:
> > [...]
> > 1) One does not need to express themselves in a way that is for public. (
> Misunderstandings can be corrected on the fly if needed. ) There is no need
> to explain to anyone reading the logs what you actually meant during the
> conversation month ago.
> > 2) there is level of confidentiality within that defined audience. (
> > For example someone not familiar with the processes thinks they have
> > found security vulnerability and comes to the IRC-channel to ask
> > second opinion. Those details are not public and that bug can still be
> > raised and dealt properly. Once the discussion is logged and the logs
> > are publicly available the details are publicly available as well. )
> > 3) That defined audience does not usually limit content. I have no problem
> to throw my e-mail address, phone number etc. into the channel, I would not
> yell them out publicly.
> > [...]
> 
> All 3 arguments point to issues you have with *public* channels, not
> *logged* channels.
> 
> Our IRC channels are, in effect, already public. Anyone can join them, anyone
> can log them. An embargoed vulnerability discussed on an IRC channel
> (logged or not) should be considered leaked. I agree that logging makes it
> easier for random people to access that already-public information, but you
> can't consider an IRC channel private (and change your communication style
> or content) because it's not logged by eavesdrop.
> 
> What you seem to be after is a private, invitation-only IRC channel.
> That's an orthogonal issue to the concept of logging.

Nope, what I'm saying is that I'm opposing public logging to the level that I 
will not be part if it will be enabled. If someone start publishing the logs 
they collect from the channel my response is the same I will ask to stop doing 
that and if it's not enough I will just leave.  I do not use tinfoil hat nor 
live in a bubble thinking that information is private but I prefer not to make 
it more obvious. And your private channel would not solve "someone logging and 
publishing the logs" anyways, any level of privacy in the communication is 
based on trust was it participants, service/venue providers or something else 
so lets not make it more difficult than it is.

- Erno
> 
> --
> 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

Re: [openstack-dev] [Glance] IRC logging

[Kuvaja, Erno]

> -Original Message-
> From: Dave Walker [mailto:em...@daviey.com]
> Sent: 13 January 2015 15:10
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Glance] IRC logging
> 
> On 13 January 2015 at 12:32, Kuvaja, Erno  wrote:
> > I'm heavily against the public logging to the level that I will just leave 
> > the
> channel if that will be enabled. My point is not foul language and I do
> understand that there could be some benefits out of it. Personally I think we
> have enough tracked public communication means like ask.openstack.org
> and the mailing lists. IRC is and has always been real time communications
> with defined audience.
> >
> > I think the major benefits of this defined audience are:
> > 1) One does not need to express themselves in a way that is for public. (
> Misunderstandings can be corrected on the fly if needed. ) There is no need
> to explain to anyone reading the logs what you actually meant during the
> conversation month ago.
> > 2) there is level of confidentiality within that defined audience. (
> > For example someone not familiar with the processes thinks they have
> > found security vulnerability and comes to the IRC-channel to ask
> > second opinion. Those details are not public and that bug can still be
> > raised and dealt properly. Once the discussion is logged and the logs
> > are publicly available the details are publicly available as well. )
> > 3) That defined audience does not usually limit content. I have no problem
> to throw my e-mail address, phone number etc. into the channel, I would not
> yell them out publicly.
> >
> > For me personally the last point is the biggest problem, professionally the
> second is major concern. I have been using IRC for so long time that I'm not
> willing to take the risk I can't filter myself on my regular channels. 
> Meetings
> are different story as there it is defined time and at least I'm on meeting
> mode that time knowing it will be publicly logged.
> >
> > The channels are not locked so anyone can keep a client online and log it
> for themselves if they feel need for it and lots of people do so. There is 
> just
> that big barrier having it within the defined group you can see on the channel
> versus public to anyone.
> >
> > As opposed to Cindy's original statement of not wanting to be available off-
> hours, that's solved already: you can set your client to away or not respond.
> It's really common on any IRC network that nick is online while user is not or
> is ignoring that real time outreach by personal preference. No-one
> will/should take that personally or offensive. Not having bouncer/shell to run
> your client is as well personal preference, I doubt anyone can claim they
> could not do it with the options available nowadays.
> >
> >  - Erno (jokke_) Kuvaja
> 
> 
> Hi,
> 
> I think these concerns are more based around fear, than any real merit.  I
> would suggest that any IRC communication should be treated as public, and
> therefore the idea of bouncing around personal contacts details is pretty
> poor personal security.  If this is required, then using private messages 
> would
> seem to be perfectly suitable.
> 
> A user can join any #openstack-* channel, and not necessarily be a friend of
> the project.  The concerns about security issues should be treated as if they
> have already become public.
> 
> It seems that Openstack currently has around 40 non-meeting channels
> logged[0] and contrasting with the Ubuntu project, there are some 350 public
> logged channels[1] - with the logs going back to 2004.  This has caused little
> issue over the years.
> 
> It would seem logical to introduce project-wide irc logging IMO.  I
> *have* found it useful to search through archives of projects, and find it
> frustrating when this data is not available.
> 
> I really struggle with the idea that contributors of a developer channel do 
> not
> consider themselves to be talking in a public forum, which to me - is the same
> as being logged.  Without this mindset, the channel (and project?) merely
> becomes a cabal developers area.
> 
> [0] http://eavesdrop.openstack.org/irclogs/
> [1] http://irclogs.ubuntu.com/2015/01/01/
> 
> --
> Kind Regards,
> Dave Walker

I do not have a problem to tell my phone number to someone at my local which is 
packed with people I do not know and they might hear it, I would have problem 
with my local if they would start recording all discussions in their premises 
and posting those publicly in the internet. I don't have even problem X people 
recording their visits there as l

Re: [openstack-dev] Add VMware dvSwitch/vSphere API support for Neutron ML2

[Kuvaja, Erno]

Hi Sami,

There was discussion around this in IRC yesterday iirc. The process seems to be 
just broken. As this week is Atlanta Summit week, expect some delays on 
responses/getting it fixed.

- Erno

-Original Message-
From: "Sami J. Mäkinen" [mailto:sjm+osde...@hard.ware.fi] 
Sent: 13 May 2014 13:43
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Add VMware dvSwitch/vSphere API support for 
Neutron ML2


Hello to all. I just created a document called 
neutron-ml2-mech-vmware-dvswitch.rst
on a git repo clone from neutron-specs
as instructed.

My problem is, I just cannot submit my Contributor Agreement. I've tried Google 
Chrome and Firefox to no avail. The error message is always:

***
Code Review - Error
Server Error
Cannot store contact information
button: Continue
***

Sigh, I even tried Opera. I get always the same error message.

I cannot proceed from here. Can anybody help me out?
My username/email is sjm  cybercom.fi and my realname contains one 
non-7bit-ascii character, if it does matter.
Other than that, I don't see anything odd here.

BR,

Sami J. Mäkinen from Cybercom Finland


On 06/05/14 20:05, Armando M. wrote:
> Hi Ilkka,
>
> As Mathieu suggested there is a blueprint submission and revision 
> process put in place since the Juno release. Also, since Icehouse, to 
> incorporate a new plugin/mechanism driver into the Neutron source 
> tree, and to be designated as compatible, such a plugin/driver must be 
> accompanied by external third party CI testing (more details in [1]).
>
> This means that, once the blueprint work has been approved, the code 
> must be submitted through the same review process adopted for the 
> blueprint, as detailed in [2], and accompanied by validation through 
> third party CI.
>
> This sounds like a lot of work, but it is aimed at ensuring all the 
> usual ilities of the software being part of the official source tree.
>
> That said, you are not alone and you can tap into the usual channels, 
> like the mailing list or IRC ([3]). If there is anything vmware 
> specific that you would like to address, we are here to help, so feel 
> free to direct your questions to #openstack-vmware.
>
> Keep up the good work!
>
> Cheers,
> Armando
>
> [1] - https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers
> [2] - https://wiki.openstack.org/wiki/Gerrit_Workflow
> [3] - https://wiki.openstack.org/wiki/IRC



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance] [TC] Program Mission Statement and the Catalog

[Kuvaja, Erno]

Hi,

+1 for the mission statement, but indeed why 2 changes?


-  Erno (jokke)

From: Mark Washenberger [mailto:mark.washenber...@markwash.net]
Sent: 05 June 2014 02:04
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Glance] [TC] Program Mission Statement and the Catalog
Importance: High

Hi folks,

I'd like to propose the Images program to adopt a mission statement [1] and 
then change it to reflect our new aspirations of acting as a Catalog that works 
with artifacts beyond just disk images [2].

Since the Glance mini summit early this year, momentum has been building 
significantly behind catalog effort and I think its time we recognize it 
officially, to ensure further growth can proceed and to clarify the 
interactions the Glance Catalog will have with other OpenStack projects.

Please see the linked openstack/governance changes, and provide your feedback 
either in this thread, on the changes themselves, or in the next TC meeting 
when we get a chance to discuss.

Thanks to Georgy Okrokvertskhov for coming up with the new mission statement.

Cheers
-markwash

[1] - https://review.openstack.org/98001
[2] - https://review.openstack.org/98002

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance] Nominating Nikhil Komawar for Core

[Kuvaja, Erno]

+1

From: Alex Meade [mailto:mr.alex.me...@gmail.com]
Sent: 12 June 2014 13:56
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Nominating Nikhil Komawar for Core

+100 it's about time!

On Thu, Jun 12, 2014 at 3:26 AM, Mark Washenberger 
mailto:mark.washenber...@markwash.net>> wrote:
Hi folks,

I'd like to nominate Nikhil Komawar to join glance-core. His code and review 
contributions over the past years have been very helpful and he's been taking 
on a very important role in advancing the glance tasks work.

If anyone has any concerns, please let me know. Otherwise I'll make the 
membership change next week (which is code for, when someone reminds me to!)

Thanks!
markwash

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] Unifying configuration file

[Kuvaja, Erno]

I do not like this idea. As now we are on 5 different config files (+ policy 
and schema). One for each (API and Registry) would still be ok, but putting all 
together would just become messy.

If the *-paste.ini will be migrated to .conf files that would bring it down, 
but please do not try to mix reg and API configs together.

- Erno (jokke) Kuvaja

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: 17 June 2014 15:19
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [glance] Unifying configuration file
> 
> On 17/06/14 15:59 +0200, Julien Danjou wrote:
> >Hi guys,
> >
> >So I've started to look at the configuration file used by Glance and I
> >want to switch to one configuration file only.
> >I stumbled upon this blueprint:
> >
> >  https://blueprints.launchpad.net/glance/+spec/use-oslo-config
> >
> 
> w.r.t using config.generator https://review.openstack.org/#/c/83327/
> 
> >which fits.
> >
> >Does not look like I can assign myself to it, but if someone can do so,
> >go ahead.
> >
> >So I've started to work on that, and I got it working. My only problem
> >right now, concerned the [paste_deploy] options that is provided by
> >Glance. I'd like to remove this section altogether, as it's not
> >possible to have it and have the same configuration file read by both
> >glance-api and glance-registry.
> >My idea is also to unify glance-api-paste.ini and
> >glance-registry-paste.ini into glance-paste.ini and then have each
> >server reads their default pipeline (pipeline:glance-api).
> >
> >Does that sounds reasonable to everyone?
> 
> +1, it sounds like a good idea. I don't think we need to maintain 2
> separate config files, especially now that the registry service is optional.
> 
> Thanks for working on this.
> Flavio
> 
> --
> @flaper87
> Flavio Percoco
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] Unifying configuration file

[Kuvaja, Erno]

> -Original Message-
> From: Mark McLoughlin [mailto:mar...@redhat.com]
> Sent: 18 June 2014 06:58
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [glance] Unifying configuration file
> 
> Hey
> 
> On Tue, 2014-06-17 at 17:43 +0200, Julien Danjou wrote:
> > On Tue, Jun 17 2014, Arnaud Legendre wrote:
> >
> > > @ZhiYan: I don't like the idea of removing the sample configuration
> > > file(s) from the git repository. Many people do not want to have to
> > > checkout the entire codebase and tox every time they have to verify
> > > a variable name in a configuration file. I know many people who were
> > > really frustrated where they realized that the sample config file was gone
> from the Nova repo.
> > > However, I agree with the fact that it would be better if the sample
> > > was 100% accurate: so the way I would love to see this working is to
> > > generate the sample file every time there is a config change (this
> > > being totally automated (maybe at the gate level...)).
> >
> > You're a bit late on this. :)
> > So what I did these last months (year?) in several project, is to
> > check at gate time the configuration file that is automatically
> > generated against what's in the patches.
> > That turned out to be a real problem because sometimes some options
> > changes from the eternal module we rely on (e.g. keystone authtoken or
> > oslo.messaging). In the end many projects (like Nova) disabled this
> > check altogether, and therefore removed the generated configuration
> > file From the git repository.

Yes and the users who relied on those config files in the github were really 
upset about that.
> 
> For those that casually want to refer to the sample config, what would help if
> there was Jenkins jobs to publish the generated sample config file
> somewhere.
> 
> For people installing the software, it would probably be nice if pbr added
> 'python setup.py sample_config' or something.
> 
> > > @Julien: I would be interested to understand the value that you see
> > > of having only one config file? At this point, I don't see why
> > > managing one file is more complicated than managing several files
> > > especially when they are organized by categories. Also, scrolling
> > > through the registry settings every time I want to modify an api setting
> seem to add some overhead.
> >
> > Because there's no way to automatically generate several configuration
> > files with each its own set of options using oslo.config.
> 
> I think that's a failing of oslo.config, though. Glance's layout of config 
> files is
> useful and intuitive.

I totally agree.
> 
> > Glance is (one of?) the last project in OpenStack to manually write
> > its sample configuration file, which are not up to date obviously.

We can learn from others, can't we? 
I think the key point here is part of the comment in the Cinder discussion to 
remove the sample config  https://review.openstack.org/#/c/96581/ (Mathieu Jun 
6 7:53 PM):
"""
Note that it's not just about Cinder, its about all the other projects. They 
[ops; Erno add] don't track changes in Gerrit, its not something they do in 
their day-to-day job. It just happened that we heard about this change on the 
openstack-operators mailinglist.
"""

We are again having this discussion on the dev list without involving the most 
important group, our ops. 
> 
> Neutron too, but not split out per-service. I don't find Neutron's config file
> layout as intuitive.
> 
> > So really this is mainly about following what every other projects did
> > the last year(s).
> 
> There's a balance here between what makes technical sense and what helps
> users. If Glance has support for generating a unified config file while also
> manually maintaining the split configs, I think that's a fine compromise.


+100
I'd add to that: until olso.config can provide us more than one config file 
generated automatically. Now lets remember that if you run glance with the 
registry on somewhere else than devstack you are most probably running registry 
and API on different servers. Making them relying on single config is about as 
smart idea as saying that we should not provide project independent configs, 
but combine all the configs to a single OpenStack config file with nice note 
"good luck trying to figure out what bits you need from this". That would 
probably make sense if you never run these out of devstack having all the 
services on same machine anyways.
> 
> Mark.
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

- Erno (jokke) Kuvaja

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] using released versions of python clients in tests

[Kuvaja, Erno]

Sean,

Please correct me if I'm wrong, but I think this needs to happen on RCs not on 
CI tests.

Couple of possible problems I personally see with this approach:
1) Extensive pressure to push new client releases (perhaps the released client 
is not as good as intended for just to provide someone tools to get through 
tests).
2) Un-necessary slowing of development. If the needed client functionality is 
merged but not released, the commits using this functionality will fail. This 
IMO fights against the point of having CI as we're still depending on internal 
releases during the development process.
3) More skipped tests "waiting" for client release and not catching the real 
issues.
4) over time LIBS_FROM_GIT just cumulates having all used clients rendering the 
effort useless anyways.

I do agree that we need to catch the scenarios driving you towards this on 
whatever we call Stable, but anything out of that should not be affected just 
because project does not release monthly, weekly or daily client versions.

I might have missed something here, but I just don't see the correlation  of 
unreleased server depending unreleased client being problem.

- Erno

> -Original Message-
> From: Sean Dague [mailto:s...@dague.net]
> Sent: 28 October 2014 12:29
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [all] using released versions of python clients in
> tests
> 
> At the beginning of the month we moved through a set of patches for oslo
> libs that decoupled them from the integrated gate by testing server projects
> with released versions of oslo libraries.
> 
> The way it works is that in the base devstack case all the oslo libraries are
> pulled from pypi instead of git. There is an override LIBS_FROM_GIT that lets
> you specify you want certain libraries from git instead.
> 
> * on a Nova change oslo.config comes from the release pypi version.
> * on an olso.config change we test a few devstack configurations with
> LIBS_FROM_GIT=oslo.config, so that we can ensure that proposed
> olso.config changes won't break everyone.
> 
> I believe we should do the same with all the python-*client libraries as well.
> That will ensure that servers don't depend on unreleased features of python
> client libraries, and will provide the forward testing to ensure the next
> version of the python client to be released won't ruin the world.
> 
> This is mostly a heads up that I'm going to start doing this implementation. 
> If
> someone wants to raise an objection, now is the time.
> However I think breaking this master/master coupling of servers and clients
> is important, and makes OpenStack function and upgrade a bit closer to what
> people expect.
> 
>   -Sean
> 
> --
> Sean Dague
> http://dague.net
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Usage of _L?() translation functions

[Kuvaja, Erno]

Hi Matt,

Is it perhaps this one you're looking for:
https://wiki.openstack.org/wiki/LoggingStandards#Guidelines

 -Erno

> -Original Message-
> From: Matthew Booth [mailto:mbo...@redhat.com]
> Sent: 20 June 2014 14:46
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [nova] Usage of _L?() translation functions
> 
> I read a doc on this the other day, but for the life of me I can't remember
> where. It's relevant to this review:
> 
> https://review.openstack.org/#/c/97612/18/nova/virt/vmwareapi/volumeo
> ps.py
> 
> If anybody knowledgeable could give this a glance I'd be grateful. I'd like to
> know I'm not giving duff advice.
> 
> Thanks,
> 
> Matt
> --
> Matthew Booth
> Red Hat Engineering, Virtualisation Team
> 
> Phone: +442070094448 (UK)
> GPG ID:  D33C3490
> GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [All] Removing translations from debug logging where exception formatted into the message

[Kuvaja, Erno]

Hi,

We hit nasty situation where _() was removed from DEBUG level logging and there 
is exception included like following:
msg = "Forbidden upload attempt: %s" % e
This caused gettextutils raising UnicodeError:
2014-06-26 18:16:24.221 |   File "glance/openstack/common/gettextutils.py", 
line 333, in __str__
2014-06-26 18:16:24.222 | raise UnicodeError(msg)
2014-06-26 18:16:24.222 | UnicodeError: Message objects do not support str() 
because they may contain non-ascii characters. Please use unicode() or 
translate() instead.
(For Example 
http://logs.openstack.org/63/102863/1/check/gate-glance-python27/6ad16a3/console.html#_2014-06-26_15_57_12_262)

As discussed with mriedm, jecarey and dhellmann on #openstack-oslo this can be 
avoided by specifying the message being unicode like:
msg = u"Forbidden upload attempt: %s" % e

For us in Glance it caused bunch of gating issues, so hopefully this helps the 
rest of the projects avoiding same, or at least tackling it bit faster.


-  Erno (jokke_) Kuvaja
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Glance] Logging ratios (part of bp/refactoring-glance-logging)

[Kuvaja, Erno]

Hi all,

As Arnaud requested on his comment to https://review.openstack.org/#/c/99622/ I 
have done quick analysis of Glance logging.

Please find the results attached to this e-mail. The output is file by file, 
but if you're interested only about the totals, please see the end of the file.

BR,
Erno (jokke) Kuvaja


pre_refactoring_logging_analysis
Description: pre_refactoring_logging_analysis
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] Bug Days - July 15/16

[Kuvaja, Erno]

Good Morning/Day,

I have just started Etherpad 
https://etherpad.openstack.org/p/glance-bugday-progress for tracking. Please 
also join to #openstack-glance @Freenode to join the chat. All hands onboard 
would be appreciated!

BR,
Erno

From: Fei Long Wang [mailto:feil...@catalyst.net.nz]
Sent: 11 July 2014 03:43
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] Bug Days - July 15/16

As for the bug tagging, I just added some tags in the wiki for Glance: 
https://wiki.openstack.org/wiki/Bug_Tags#Glance, please feel free to complete 
it.

On 11/07/14 12:07, Arnaud Legendre wrote:
Hi All,

Glance is going to have bug days next week on July Tuesday 15 and Wednesday 16. 
This is a two-days bug day to accommodate most of the Glance contributors (time 
zones, etc.). Of course, You do not need to be 100% two days…

This is a great opportunity to:
- triage bugs
- fix bugs
- tag bugs
and hopefully make Glance better…!

Please register yourself on the wiki page if you plan to participate:
https://etherpad.openstack.org/p/glance-bug-day

We will be hanging out on #openstack-glance. We seriously need help so even the 
bare minimum will be better than nothing…!

A couple of links:
- All Glance bugs: https://bugs.launchpad.net/glance
- Bugs that have gone stale: 
https://bugs.launchpad.net/glance/+bugs?orderby=date_last_updated&field.status%3Alist=INPROGRESS&assignee_option=any
- Untriaged bugs: 
https://bugs.launchpad.net/glance/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status:list=NEW&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&fie
 ld.tags_c 
ombinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on
 

- Bugs without owners: 
https://bugs.launchpad.net/glance/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&fi
 eld.statu 
s%3Alist=INPROGRESS&assignee_option=none&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.tag=&field.tags_combinator=ANY&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on


Cheers,
Arnaud




___

OpenStack-dev mailing list

OpenStack-dev@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--

Cheers & Best regards,

Fei Long Wang (王飞龙)

--

Senior Cloud Software Engineer

Tel: +64-48032246

Email: flw...@catalyst.net.nz

Catalyst IT Limited

Level 6, Catalyst House, 150 Willis Street, Wellington

--
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.

[Kuvaja, Erno]

> -Original Message-
> From: Tony Breeds [mailto:t...@bakeyournoodle.com]
> Sent: Friday, November 06, 2015 6:15 AM
> To: OpenStack Development Mailing List
> Cc: openstack-operat...@lists.openstack.org
> Subject: [openstack-dev] [stable][all] Keeping Juno "alive" for longer.
> 
> Hello all,
> 
> I'll start by acknowledging that this is a big and complex issue and I do not
> claim to be across all the view points, nor do I claim to be particularly
> persuasive ;P
> 
> Having stated that, I'd like to seek constructive feedback on the idea of
> keeping Juno around for a little longer.  During the summit I spoke to a
> number of operators, vendors and developers on this topic.  There was some
> support and some "That's crazy pants!" responses.  I clearly didn't make it
> around to everyone, hence this email.

I'm not big fan of this idea, number of reasons below.
> 
> Acknowledging my affiliation/bias:  I work for Rackspace in the private cloud
> team.  We support a number of customers currently running Juno that are,
> for a variety of reasons, challenged by the Kilo upgrade.

I'm working at HPE in the Cloud Engineering team, fwiw.
> 
> Here is a summary of the main points that have come up in my
> conversations, both for and against.
> 
> Keep Juno:
>  * According to the current user survey[1] Icehouse still has the
>biggest install base in production clouds.  Juno is second, which makes
>sense. If we EOL Juno this month that means ~75% of production clouds
>will be running an EOL'd release.  Clearly many of these operators have
>support contracts from their vendor, so those operators won't be left
>completely adrift, but I believe it's the vendors that benefit from keeping
>Juno around. By working together *in the community* we'll see the best
>results.

As you say there should some support base for these releases. Unfortunately 
that has had really small reflection to upstream. It looks like these vendors 
and operators keep backporting to their own forks, but do not propose the 
backports to upstream branches, or these installations are not really 
maintained.
> 
>  * We only recently EOL'd Icehouse[2].  Sure it was well communicated, but
> we
>still have a huge Icehouse/Juno install base.
> 
> For me this is pretty compelling but for balance 
> 
> Keep the current plan and EOL Juno Real Soon Now:
>  * There is also no ignoring the elephant in the room that with HP stepping
>back from public cloud there are questions about our CI capacity, and
>keeping Juno will have an impact on that critical resource.

I leave this point open as I do not know what our plans towards infra are. 
Perhaps someone could shed some light who does know.
> 
>  * Juno (and other stable/*) resources have a non-zero impact on *every*
>project, esp. @infra and release management.  We need to ensure this
>isn't too much of a burden.  This mostly means we need enough
> trustworthy
>volunteers.

This has been the main driver for shorter support cycles so far. The group 
maintaining stable branches is small and at least I haven't seen huge increase 
on that lately. Stable branches are getting bit more attention again and some 
great work has been done to ease up the workloads, but same time we get loads 
of new features and projects in that has affect on infra (resource wise) and 
gate stability.
> 
>  * Juno is also tied up with Python 2.6 support. When
>Juno goes, so will Python 2.6 which is a happy feeling for a number of
>people, and more importantly reduces complexity in our project
>infrastructure.

I know lots of people have been waiting this, myself included.
> 
>  * Even if we keep Juno for 6 months or 1 year, that doesn't help vendors
>that are "on the hook" for multiple years of support, so for that case
>we're really only delaying the inevitable.
> 
>  * Some number of the production clouds may never migrate from $version,
> in
>which case longer support for Juno isn't going to help them.

Both very true.
> 
> 
> I'm sure these question were well discussed at the VYR summit where we
> set the EOL date for Juno, but I was new then :) What I'm asking is:
> 
> 1) Is it even possible to keep Juno alive (is the impact on the project as
>a whole acceptable)?

Based on current status I do not think so.
> 
> Assuming a positive answer:
> 
> 2) Who's going to do the work?
> - Me, who else?

This is one of the key questions.

> 3) What do we do if people don't actually do the work but we as a community
>have made a commitment?

This was done in YVR, we decided to cut the losses and EOL early.

> 4) If we keep Juno alive for $some_time, does that imply we also bump the
>life cycle on Kilo and liberty and Mitaka etc?

That would be logical thing to do. At least I don't think Juno was anything 
that special that it would deserve different schedule than Kilo, Liberty, etc.
> 
> Yours Tony.
> 
> [1] http://www.openstack.org/assets/surve

Re: [openstack-dev] [stable] Making stable maintenance its own OpenStack project team

[Kuvaja, Erno]

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: 09 November 2015 16:42
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [stable] Making stable maintenance its own
> OpenStack project team
> 
> Hi everyone,
> 
> A few cycles ago we set up the Release Cycle Management team which was a
> bit of a frankenteam of the things I happened to be leading: release
> management, stable branch maintenance and vulnerability management.
> While you could argue that there was some overlap between those functions
> (as in, "all these things need to be released") logic was not the primary
> reason they were put together.
> 
> When the Security Team was created, the VMT was spinned out of the
> Release Cycle Management team and joined there. Now I think we should
> spin out stable branch maintenance as well:
> 
> * A good chunk of the stable team work used to be stable point release
> management, but as of stable/liberty this is now done by the release
> management team and triggered by the project-specific stable maintenance
> teams, so there is no more overlap in tooling used there
> 
> * Following the kilo reform, the stable team is now focused on defining and
> enforcing a common stable branch policy[1], rather than approving every
> patch. Being more visible and having more dedicated members can only help
> in that very specific mission
> 
> * The release team is now headed by Doug Hellmann, who is focused on
> release management and does not have the history I had with stable branch
> policy. So it might be the right moment to refocus release management
> solely on release management and get the stable team its own leadership
> 
> * Empowering that team to make its own decisions, giving it more visibility
> and recognition will hopefully lead to more resources being dedicated to it
> 
> * If the team expands, it could finally own stable branch health and gate
> fixing. If that ends up all falling under the same roof, that team could make
> decisions on support timeframes as well, since it will be the primary resource
> to make that work
> 
> So.. good idea ? bad idea ? What do current stable-maint-core[2] members
> think of that ? Who thinks they could step up to lead that team ?
> 
> [1] http://docs.openstack.org/project-team-guide/stable-branches.html
> [2] https://review.openstack.org/#/admin/groups/530,members
> 
> --
> Thierry Carrez (ttx)


Hi Thierry,

Thanks for bringing this up. The timing couldn't have been better.

I had lengthy discussion with Flavio Percoco in Tokyo. He asked me what would 
be the things I'd like to see TC taking on and fix over next cycle. After 
ranting to him over 20min how I'd like to have actual stable branches in 
OpenStack, not just tag and branch called stable and find the will and 
resources to do that, I turned to him and asked "But we really do not need TC 
for that do we?"

I'm not part of the global stable-maint-core but I have been stable branch 
liaison for Glance for year now. And I can say that our stable branches are not 
just tag and branch, they are actually maintained, by really small group of 
people (which has btw been growing over that whole time). Ihar started 
discussion to implement something similar to Neutron stable branches, which 
proves to me that there is will to work on this problem.

Based on the discussion around wishes to extend support of Juno, there is 
definitely urge to have our stable releases maintained and supported longer. I 
don't think Juno is reasonable expectation to see that happen, but perhaps we 
get there.

I think what you are proposing here is the right direction to go, not because 
it used to be part of "frankenteam" led by you, but because I think the group 
of people working on our stable branches deserves and needs the recognition for 
the work. I think that would be the first step to get the people involved. 
After moving the ownership to individual projects I'd like to see this team, 
not replacing that but being liberally inclusive cross-project (meta) team to 
unite the efforts between the projects and making the lives of those people 
easier and the efforts more justified. I'm in a lucky position as after coming 
back home I had the discussion with my management and got the commitment to 
spend significant amount of my time to work on stable across OpenStack projects.

I do realize that there is very small and dedicated group of people fixing the 
gates and doing all the magic around that issue. If we get more traction and 
interest of doing backports proactively, hopefully the health of those stable 
gates would interest more people as well and we could spread that load away 
from those so few and valuable folks.

Based on this I would like to put my name up for the task.

Will it be me or someone else leading this team if it gets formed, count me in. 
I will put my effort to make our stable branches better anyways.

Best,
Erno (jokke_) Kuvaja

> 
> 

Re: [openstack-dev] [stable] Making stable maintenance its own OpenStack project team

[Kuvaja, Erno]

> -Original Message-
> From: Matthew Treinish [mailto:mtrein...@kortar.org]
> Sent: 09 November 2015 22:40
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [stable] Making stable maintenance its own
> OpenStack project team
> 
> On Mon, Nov 09, 2015 at 05:28:45PM -0500, Doug Hellmann wrote:
> > Excerpts from Matt Riedemann's message of 2015-11-09 16:05:29 -0600:
> > >
> > > On 11/9/2015 10:41 AM, Thierry Carrez wrote:
> > > > Hi everyone,
> > > >
> > > > A few cycles ago we set up the Release Cycle Management team which
> > > > was a bit of a frankenteam of the things I happened to be leading:
> > > > release management, stable branch maintenance and vulnerability
> management.
> > > > While you could argue that there was some overlap between those
> > > > functions (as in, "all these things need to be released") logic
> > > > was not the primary reason they were put together.
> > > >
> > > > When the Security Team was created, the VMT was spinned out of the
> > > > Release Cycle Management team and joined there. Now I think we
> > > > should spin out stable branch maintenance as well:
> > > >
> > > > * A good chunk of the stable team work used to be stable point
> > > > release management, but as of stable/liberty this is now done by
> > > > the release management team and triggered by the project-specific
> > > > stable maintenance teams, so there is no more overlap in tooling
> > > > used there
> > > >
> > > > * Following the kilo reform, the stable team is now focused on
> > > > defining and enforcing a common stable branch policy[1], rather
> > > > than approving every patch. Being more visible and having more
> > > > dedicated members can only help in that very specific mission
> > > >
> > > > * The release team is now headed by Doug Hellmann, who is focused
> > > > on release management and does not have the history I had with
> > > > stable branch policy. So it might be the right moment to refocus
> > > > release management solely on release management and get the stable
> > > > team its own leadership
> > > >
> > > > * Empowering that team to make its own decisions, giving it more
> > > > visibility and recognition will hopefully lead to more resources
> > > > being dedicated to it
> > > >
> > > > * If the team expands, it could finally own stable branch health
> > > > and gate fixing. If that ends up all falling under the same roof,
> > > > that team could make decisions on support timeframes as well,
> > > > since it will be the primary resource to make that work
> > >
> > > Isn't this kind of already what the stable maint team does? Well,
> > > that and some QA people like mtreinish and sdague.
> > >
> > > >
> > > > So.. good idea ? bad idea ? What do current stable-maint-core[2]
> > > > members think of that ? Who thinks they could step up to lead that
> team ?
> > > >
> > > > [1]
> > > > http://docs.openstack.org/project-team-guide/stable-branches.html
> > > > [2] https://review.openstack.org/#/admin/groups/530,members
> > > >
> > >
> > > With the decentralizing of the stable branch stuff in Liberty [1] it
> > > seems like there would be less use for a PTL for stable branch
> > > maintenance - the cats are now herding themselves, right? Or at
> > > least that's the plan as far as I understood it. And the existing
> > > stable branch wizards are more or less around for help and answering
> questions.
> >
> > The same might be said about releasing from master and the release
> > management team. There's still some benefit to having people dedicated
> > to making sure projects all agree to sane policies and to keep up with
> > deliverables that need to be released.
> 
> Except the distinction is that relmgt is actually producing something. Relmgt
> has the releases repo which does centralize library releases, reno to do the
> release notes, etc. What does the global stable core do? Right now it's there
> almost entirely to just add people to the project specific stable core teams.
> 
> -Matt Treinish


I'd like to move the discussion from what are the roles of the current 
stable-maint-core and more towards what the benefits would be having a 
stable-maint team rather than the -core group alone.

Personally I think the stable maintenance should be quite a lot more than 
unblocking gate and approving people allowed to merge to the stable branches.

- Erno
> 
> > >
> > > [1]
> > > http://lists.openstack.org/pipermail/openstack-dev/2015-November/078
> > > 281.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] [stable] Making stable maintenance its own OpenStack project team

[Kuvaja, Erno]

> -Original Message-
> From: Matthew Treinish [mailto:mtrein...@kortar.org]
> Sent: Tuesday, November 10, 2015 3:12 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [stable] Making stable maintenance its own
> OpenStack project team
> 
> On Mon, Nov 09, 2015 at 10:54:43PM +, Kuvaja, Erno wrote:
> > > On Mon, Nov 09, 2015 at 05:28:45PM -0500, Doug Hellmann wrote:
> > > > Excerpts from Matt Riedemann's message of 2015-11-09 16:05:29 -0600:
> > > > >
> > > > > On 11/9/2015 10:41 AM, Thierry Carrez wrote:
> > > > > > Hi everyone,
> > > > > >
> > > > > > A few cycles ago we set up the Release Cycle Management team
> > > > > > which was a bit of a frankenteam of the things I happened to be
> leading:
> > > > > > release management, stable branch maintenance and
> > > > > > vulnerability
> > > management.
> > > > > > While you could argue that there was some overlap between
> > > > > > those functions (as in, "all these things need to be
> > > > > > released") logic was not the primary reason they were put together.
> > > > > >
> > > > > > When the Security Team was created, the VMT was spinned out of
> > > > > > the Release Cycle Management team and joined there. Now I
> > > > > > think we should spin out stable branch maintenance as well:
> > > > > >
> > > > > > * A good chunk of the stable team work used to be stable point
> > > > > > release management, but as of stable/liberty this is now done
> > > > > > by the release management team and triggered by the
> > > > > > project-specific stable maintenance teams, so there is no more
> > > > > > overlap in tooling used there
> > > > > >
> > > > > > * Following the kilo reform, the stable team is now focused on
> > > > > > defining and enforcing a common stable branch policy[1],
> > > > > > rather than approving every patch. Being more visible and
> > > > > > having more dedicated members can only help in that very
> > > > > > specific mission
> > > > > >
> > > > > > * The release team is now headed by Doug Hellmann, who is
> > > > > > focused on release management and does not have the history I
> > > > > > had with stable branch policy. So it might be the right moment
> > > > > > to refocus release management solely on release management and
> > > > > > get the stable team its own leadership
> > > > > >
> > > > > > * Empowering that team to make its own decisions, giving it
> > > > > > more visibility and recognition will hopefully lead to more
> > > > > > resources being dedicated to it
> > > > > >
> > > > > > * If the team expands, it could finally own stable branch
> > > > > > health and gate fixing. If that ends up all falling under the
> > > > > > same roof, that team could make decisions on support
> > > > > > timeframes as well, since it will be the primary resource to
> > > > > > make that work
> > > > >
> > > > > Isn't this kind of already what the stable maint team does?
> > > > > Well, that and some QA people like mtreinish and sdague.
> > > > >
> > > > > >
> > > > > > So.. good idea ? bad idea ? What do current
> > > > > > stable-maint-core[2] members think of that ? Who thinks they
> > > > > > could step up to lead that
> > > team ?
> > > > > >
> > > > > > [1]
> > > > > > http://docs.openstack.org/project-team-guide/stable-branches.h
> > > > > > tml [2]
> > > > > > https://review.openstack.org/#/admin/groups/530,members
> > > > > >
> > > > >
> > > > > With the decentralizing of the stable branch stuff in Liberty
> > > > > [1] it seems like there would be less use for a PTL for stable
> > > > > branch maintenance - the cats are now herding themselves, right?
> > > > > Or at least that's the plan as far as I understood it. And the
> > > > > existing stable branch wizards are more or less around for help
> > >

Re: [openstack-dev] [stable][neutron] How we handle Kilo backports

[Kuvaja, Erno]

> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> Sent: Thursday, November 19, 2015 10:43 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [stable][neutron] How we handle Kilo
> backports
> 
> Tony Breeds  wrote:
> 
> > On Wed, Nov 18, 2015 at 05:44:38PM +0100, Ihar Hrachyshka wrote:
> >> Hi all,
> >>
> >> as per [1] I imply that all projects under stable-maint-core team
> >> supervision must abide the stable policy [2] which limits the types
> >> of backports for N-2 branches (now it’s stable/kilo) to "Only
> >> critical bugfixes and security patches”. With that, I remind all
> >> stable core members about the rule.
> >>
> >> Since we are limited to ‘critical bugfixes’ only, and since there is
> >> no clear definition of what ‘critical’ means, I guess we should
> >> define it for ourselves.
> >>
> >> In Neutron world, we usually use Critical importance for those bugs
> >> that break gate. High is used for those bugs that have high impact
> >> production wise. With that in mind, I suggest we define ‘critical’
> >> bugfixes as Critical
> >> + High in LP. Comments on that?
> >
> > So I'm not a core but I check the severity of the bug and query the
> > review owner if it is < High.  My rationale is that sometimes bugs are
> > mis-classified, someone took the time to backport it so it's critical
> > to that person if not the project.
> >
> > Note that doesn't mean they'll get in but it facilitates the discussion.
> >
> > Anyway we can iterate on this: https://review.openstack.org/247229
> 
> I believe it’s fine to change bug importance later based on revealed data, or
> when initial triaging was not correct. I think making clear that discussion
> about backport applicability for a branch should be set around LP importance
> field may add more transparency to how we select backport candidates.
> 
> I also believe that we should not be afraid of other backport types, as long 
> as
> we may guarantee their safety (f.e. it’s ok to backport a fix stability fix; 
> a fix
> that adds more test coverage; a fix for a typo in a message or a config file;
> etc.; yes, those types of bugs are not high impact, but there is no real 
> reason
> not to deliver them to users).
> 
> I sent a patch to stable policy to clarify the latter:
> 
> https://review.openstack.org/247415
> 
> Ihar

Stability fixes might make sense case by case basis. And I have been looking 
all the backport more or less case by case basis anyways. Anything that throws 
500 from the api and the fix does not change other behavior is IMO critical fix.

Typo fixes are not good idea for stable branches. As it might be bit annoying 
or amusing for the English user fixing typos in kilo will mean that it breaks 
translation for all the rest and I haven't seen any translation patches being 
proposed to older stable branches. 

- Erno
__
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][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Kuvaja, Erno]

> -Original Message-
> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> Sent: Tuesday, November 17, 2015 2:57 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [stable] Preparing 2014.2.4 (Juno) WAS Re:
> [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
> 
> 
> 
> On 11/16/2015 8:49 PM, Rochelle Grober wrote:
> > I would like to make a plea that while Juno is locked down so as no changes
> can be made against it, the branch remains on the git.openstack.org site.
> Please?  One area that could be better investigated with the branch in place
> is upgrade.  Kilo will continue to get patches, as will Liberty, so an 
> occasional
> grenade run (once a week?  more often?  Less often) could help operators
> understand what is in store for them when they finally can upgrade from
> Juno.  Yes, it will require occasional resources for the run, but I think 
> this is
> one of the cheapest forms of insurance in support of the installed base of
> users, before a Stable Release team is put together.
> >
> > My $.02
> >
> > --Rocky
> >
> >> -Original Message-
> >> From: Gary Kotton [mailto:gkot...@vmware.com]
> >> Sent: Friday, November 13, 2015 6:04 AM
> >> To: Flavio Percoco; OpenStack Development Mailing List (not for usage
> >> questions)
> >> Subject: Re: [openstack-dev] [stable] Preparing 2014.2.4 (Juno) WAS Re:
> >> [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
> >>
> >>
> >>
> >> On 11/13/15, 3:23 PM, "Flavio Percoco"  wrote:
> >>
> >>> On 10/11/15 16:11 +0100, Alan Pevec wrote:
>  Hi,
> 
>  while we continue discussion about the future of stable branches in
>  general and stable/juno in particular, I'd like to execute the
> >> current
>  plan which was[1]
> 
>  2014.2.4 (eol) early November, 2015. release manager: apevec
> 
>  Iff there's enough folks interested (I'm not) in keep Juno alive
> >>
> >> +1 I do not see any reason why we should still invest time and effort
> >> here. Lets focus on stable/kilo
> >>
>  longer, they could resurrect it but until concrete plan is done
>  let's be honest and stick to the agreed plan.
> 
>  This is a call to stable-maint teams for Nova, Keystone, Glance,
>  Cinder, Neutron, Horizon, Heat, Ceilometer, Trove and Sahara to
> >> review
>  open stable/juno changes[2] and approve/abandon them as
> appropriate.
>  Proposed timeline is:
>  * Thursday Nov 12 stable/juno freeze[3]
>  * Thursday Nov 19 release 2014.2.1
> 
> >>>
> >>> General ack from a stable-maint point of view! +1 on the above
> >>>
> >>> Flavio
> >>>
>  Cheers,
>  Alan
> 
>  [1]
>  https://wiki.openstack.org/wiki/StableBranchRelease#Planned_stable.
>  2F
> >> juno
>  _releases_.2812_months.29
> 
>  [2]
> 
> https://review.openstack.org/#/q/status:open+AND+branch:stable/juno
>  +A
> >> ND+%
> 
> 28project:openstack/nova+OR+project:openstack/keystone+OR+project:o
>  pe
> >> nsta
> 
> ck/glance+OR+project:openstack/cinder+OR+project:openstack/neutron+
>  OR
> >> +pro
> 
> ject:openstack/horizon+OR+project:openstack/heat+OR+project:opensta
>  ck
> >> /cei
> 
> lometer+OR+project:openstack/trove+OR+project:openstack/sahara%29,n
>  lometer+OR+,z
> 
>  [3] documented  in
> 
> https://wiki.openstack.org/wiki/StableBranch#Stable_release_manager
>  s
>  TODO add in new location
>  http://docs.openstack.org/project-team-guide/stable-branches.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
> >>>
> >>> --
> >>> @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
> >
> >
> __
> 
> >  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'm assuming you mean grenade runs on stable/kilo. A grenade job on
> stable/kilo is installing stable/juno and then upgrading to stable/kilo (the
> change being tested is on stable/kilo). The grenade jobs for stable/juno were
> stopped when icehouse-eol happened.
> 
> Arguably we could still be testing grenade on stable/kilo by just installing
> Juno 2014.2.4 (last Juno point release before EOL

Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Kuvaja, Erno]

> -Original Message-
> From: Alan Pevec [mailto:ape...@gmail.com]
> Sent: Friday, November 20, 2015 10:46 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno)
> WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
> 
> > So we were brainstorming this with Rocky the other night. Would this be
> possible to do by following:
> > 1) we still tag juno EOL in few days time
> > 2) we do not remove the stable/juno branch
> 
> Why not?
> 
> > 3) we run periodic grenade jobs for kilo
> 
> From a quick look, grenade should work with a juno-eol tag instead of
> stable/juno, it's just a git reference.
> "Zombie" Juno->Kilo grenade job would need to set
> BASE_DEVSTACK_BRANCH=juno-eol and for devstack all
> $PROJECT_BRANCH=juno-eol (or 2014.2.4 should be the same commit).
> Maybe I'm missing some corner case in devstack where stable/* is assumed
> but if so that should be fixed anyway.
> Leaving branch around is a bad message, it implies there support for it, while
> there is not.
> 
> Cheers,
> Alan

That sounds like an easy compromise.

- Erno
> 
> __
> 
> 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][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Kuvaja, Erno]

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: Friday, November 20, 2015 10:45 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno)
> WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
> 
> Kuvaja, Erno wrote:
> > So we were brainstorming this with Rocky the other night. Would this be
> possible to do by following:
> > 1) we still tag juno EOL in few days time
> > 2) we do not remove the stable/juno branch
> > 3) we run periodic grenade jobs for kilo
> >
> > I'm not that familiar with the grenade job itself so I'm doing couple of
> assumptions, please correct me if I'm wrong.
> > 1) We could do this with py27 only
> > 2) We could do this with Ubuntu 1404 only
> >
> > If this is doable would we need anything special for these jobs in infra 
> > point
> of view or can we just schedule these jobs from the pool running our other
> jobs as well?
> > If so is there still "quiet" slots on the infra utilization so that we 
> > would not
> be needing extra resources poured in for this?
> > Is there something else we would need to consider in QA/infra point of
> view?
> >
> > Benefits for this approach:
> > 1) The upgrade to kilo would be still tested occasionally.
> > 2) Less work for setting up the jobs as we do the installs from the
> > stable branch currently (vs. installing the last from tarball)
> >
> > What we should have as requirements for doing this:
> > 1) Someone making the changes to the jobs so that the grenade job gets
> ran periodically.
> > 2) Someone looking after these jobs.
> > 3) Criteria for stop doing this, X failed runs, some set timeperiod,
> > something else. (and removing the stable/juno branch)
> >
> > Big question ref the 2), what can we do if the grenade starts failing? In
> theory we won't be merging anything to kilo that _should_ cause this and we
> definitely will not be merging anything to Juno to fix these issues anymore.
> How much maintenance those grenade jobs themselves needs?
> >
> > So all in all, is the cost doing above too much to get indicator that tells 
> > us
> when Juno --> Kilo upgrade is not doable anymore?
> 
> Let's wait a bit for this discussion for the return of the Infra PTL from
> vacation, his input is critical to any decision we can make. Jeremy should be
> back on Monday.
> 
> --
> Thierry Carrez (ttx)

Sure, didn't know that he is on holidays, but there was a reason why I added 
infra and qa tags to the subject. Like you said infra being able to facilitate 
this is crucial for any plans.

- Erno
> 
> __
> 
> 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][glance] Add Sabari Kumar Murugesan

[Kuvaja, Erno]

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: Monday, November 23, 2015 8:21 PM
> To: openstack-dev@lists.openstack.org
> Cc: Sabari Kumar Murugesan
> Subject: [openstack-dev] [all][glance] Add Sabari Kumar Murugesan
> 
> 
> Greetings,
> 
> I'd like to propose adding Sabari Kumar Murugesan to the glance-core team.
> Sabari has been contributing for quite a bit to the project with great reviews
> and he's also been providing great feedback in matters related to the design
> of the service, libraries and other areas of the team.
> 
> I believe he'd be a great addition to the glance-core team as he has
> demonstrated a good knowledge of the code, service and project's priorities.
> 
> If Sabari accepts to join and there are no objections from other members of
> the community, I'll proceed to add Sabari to the team in a week from now.
> 
> Thanks,
> Flavio
> 
> --
> @flaper87
> Flavio Percoco

+2
- Erno
__
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] Stable team PTL nominations are open

[Kuvaja, Erno]

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: Monday, November 23, 2015 5:11 PM
> To: OpenStack Development Mailing List
> Subject: [openstack-dev] [stable] Stable team PTL nominations are open
> 
> Hi everyone,
> 
> We discussed setting up a standalone stable maintenance team and as part
> of this effort we'll be organizing PTL elections over the coming weeks.
> 
> We held a preliminary meeting today to converge on team scope and
> election mechanisms. The stable team mission is to:
> 
> * Define and enforce the common stable branch policy
> * Educate and accompany projects as they use stable branches
> * Keep CI working on stable branches
> * Mentoring/growing the stable maintenance team
> * Create and improve stable tooling/automation
> 
> Anyone who successfully contributed a stable branch backport over the last
> year (on any active stable branch) is considered a stable contributor and can
> vote in the Stable PTL election.
> 
> If you're interested, please reply to this thread with your self-nomination
> (and your platform) in the coming week. Deadline for self-nomination is
> 23:59 UTC on Monday, Nov 30. Elections will then be held if needed the week
> after.
> 
> Thanks!
> 
> --
> Thierry Carrez (ttx)
> 

Hi all,

As indicated in [0] I'd like to put myself up for the task.

On my first reply [0] to the conversation to spin off Stable Maint team on it's 
own I said that I would like the team being liberally inclusive and I'm happy 
to see that happening by us counting all backporters as being part of this team.

What I think should be the first list of priorities for the PTL of this team:

* Activate people working on the stable branches. I've had few conversations 
with engineers in different companies saying that they are doing the stable 
work downstream and it would make sense for them to do it upstream instead/as 
well. We need to find way to enable and encourage these people to do the work 
in our stable branches to keep them healthy and up to date.

* With that comes gating. We have no benefit of stable branches if we cannot 
run tests on them and merge those backports. This is currently done by handful 
of people and it's not easy task to ramp up new folks on that work. We need to 
identify and encourage the people, who has the correct mindset for it, to step 
up sharing the workload of those few. Short term that will need even more 
effort from the current group doing the work and we need to ensure to not 
overload them.

* Coordination between the project stable maintenance teams. Everyone should 
not be reinventing the wheel. I don't mean that we should recentralize the 
stable maintenance out from the project specific teams, but we need to 
establish active communication to share best practices, issues seen, etc.

* Stable Branch Policy [1]. Current revision is rather discouraging to bring 
anything that is not absolutely needed to stable branches. I think we need to 
find wording that encourages to backport bug fixes while still make sure that 
the reviewers understand what is sustainable and appropriate to merge.

* Ramping up new projects to stable mindset. Via big tent we have lots of new 
projects coming in, some of them would like to have their own stable branches 
but might not have experience and/or knowledge to do it right. 

* Recognition for the people doing the stable work. We have lots of statistics 
for reviews, commits all the way to e-mails to the mailing list, but we do not 
have anything showing interested parties how they or their interest is doing on 
stable side. While in ideal world statistics wouldn't be the driving factor for 
ones contributions, in real world that is way too often the case. 

* Driving the stable related project tagging reformation.


My background and motivations to run for the position:

* Before OpenStack my near work history is in Enterprise support, consulting 
and training. I have firsthand experience of what the enterprise expectations 
and challenges are. And that's our audience for the stable branches.

* Member of HPE Public Cloud engineering. We do run old code.

* Member of HPE Helion OpenStack engineering. We package and distribute stable 
releases.

* Glance Stable Liaison for past year[2]. Freezer Stable Liaison, bringing new 
team up to speed with stable branching in OpenStack.

* Part of the Glance Release team for past cycle driving python-glanceclient 
and glance_store releases.

* I do have the time commitment from my management to work on improving 
upstream stable branches and processes.

I'm not part of stable-maint-core nor I belong to the group of gate fixers 
mentioned earlier. I do believe that I can enable that group to work at their 
best, and limit the overhead of the other areas on that priority list towards 
them; I do believe that I can improve the communication between the project 
teams and activate people to care more about their stable branches; and I do 
know that 

Re: [openstack-dev] [all] [glance] Proposal to add Abhishek to Glance core team

[Kuvaja, Erno]

> -Original Message-
> From: Nikhil Komawar [mailto:nik.koma...@gmail.com]
> Sent: Tuesday, December 01, 2015 6:21 AM
> To: OpenStack Development Mailing List (not for usage questions); Kekane,
> Abhishek
> Subject: [openstack-dev] [all] [glance] Proposal to add Abhishek to Glance
> core team
> 
> Hi,
> 
> As the requested (re-voting) on [1] seemed to conflict with the thread title, 
> I
> am __init__ing a new thread for the sake of clarity, closure and ease of vote.
> 
> Please do provide feedback on the proposal by me on this thread [1].
> Other reference links are [2] and [3].
> 
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-
> November/thread.html#80279
> [2]
> http://eavesdrop.openstack.org/meetings/glance/2015/glance.2015-10-01-
> 14.01.log.html#l-70
> 
> [3] https://launchpad.net/~abhishek-kekane
> 
> --
> 
> Thanks,
> Nikhil
> 
> 

Knowing that Abhishek has the potential and he is great guy I have to vote -1 
on this with really heavy heart.

While his statistics (apart from disagreement rate) are looking good I do not 
see Abhishek as that active member what community would expect from the core. I 
don't see him participating on the mailing list, irc, design sessions, commits 
nor our meetings.

I specially find it hard to justify as we have had few names raising up who are 
really active from design, through implementation to reviews and while they are 
still growing to the role, they demonstrate so much higher cohesion to the 
community.

- Erno

__
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][infra][qa] Preparing 2014.2.4 (Juno) WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.

[Kuvaja, Erno]

> -Original Message-
> From: Jeremy Stanley [mailto:fu...@yuggoth.org]
> Sent: Wednesday, December 02, 2015 8:34 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [stable][infra][qa] Preparing 2014.2.4 (Juno)
> WAS Re: [Openstack-operators] [stable][all] Keeping Juno "alive" for longer.
> 
> [Apologies for the delayed reply, after more than a week without Internet
> access it's taking me more than a week to catch up with everything on the
> mailing lists.]
> 
> On 2015-11-20 10:21:47 + (+), Kuvaja, Erno wrote:
> [...]
> > So we were brainstorming this with Rocky the other night. Would this
> > be possible to do by following:
> >
> > 1) we still tag juno EOL in few days time
> 
> Hopefully by the end of this week, once I finish making sure I'm up to speed
> on everything that's been said while I was out (anything less would be
> irresponsible of me).
> 
> > 2) we do not remove the stable/juno branch
> 
> As pointed out later in this thread by Alan, it's technically possible to use 
> a tag
> instead of a branch name (after all, both are just Git refs in the end), and
> deleting the branch sends a clearer message that there are no new commits
> coming for stable/juno ever again.
> 
> > 3) we run periodic grenade jobs for kilo
> >
> > I'm not that familiar with the grenade job itself so I'm doing couple
> > of assumptions, please correct me if I'm wrong.
> >
> > 1) We could do this with py27 only
> 
> Our Grenade jobs are only using Python 2.7 anyway.
> 
> > 2) We could do this with Ubuntu 1404 only
> 
> That's the only place we run Grenade now that stable/icehouse is EOL (it was
> the last branch for which we supported Ubuntu 12.04).
> 
> > If this is doable would we need anything special for these jobs in
> > infra point of view or can we just schedule these jobs from the pool
> > running our other jobs as well?
> >
> > If so is there still "quiet" slots on the infra utilization so that we
> > would not be needing extra resources poured in for this?
> >
> > Is there something else we would need to consider in QA/infra point of
> > view?
> [...]
> 
> There are no technical Infra-side blockers to changing how we've done this in
> the past and instead continuing to run stable/kilo Grenade jobs for some
> indeterminate period after stable/juno is dead, but it's also not (entirely) 
> up
> to Infra to decide this. I defer to the Grenade maintainers and QA team to
> make this determination, and they seem to be pretty heavily against the
> idea.
> 
> > Big question ref the 2), what can we do if the grenade starts failing?
> > In theory we won't be merging anything to kilo that _should_ cause
> > this and we definitely will not be merging anything to Juno to fix
> > these issues anymore. How much maintenance those grenade jobs
> > themselves needs?
> 
> That's the kicker. As I explained earlier in the thread from which this one
> split, keeping Juno-era DevStack and Tempest and all the bits on which they
> rely working in our CI without being able to make any modifications to them
> is intractable (mainly because of the potential for behavior changes in
> transitive dependencies not under our control):
> 
> http://lists.openstack.org/pipermail/openstack-dev/2015-
> December/081109.html
> 
> > So all in all, is the cost doing above too much to get indicator that
> > tells us when Juno --> Kilo upgrade is not doable anymore?
> 
> Yes. This is how we arrived at the EOL timeline for stable/juno in the first
> place: gauging our ability to keep running things like DevStack and Tempest
> on it. Now is not the time to discuss how we can keep Juno on some
> semblance of life support (that discussion concluded more than a year ago),
> it's time for discussing what we can implement in Mitaka so we have more
> reasonable options for keeping the stable/mitaka branch healthy a year from
> now.
> --
> Jeremy Stanley

Thanks for two detailed reply Jeremy!

I think this (and the one you replied to Rocky) gives enough background in 
compact package for interested parties to start focusing their efforts to the 
direction they seem appropriate. Let's see where we are in a year's time.

- Erno

__
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

[Kuvaja, Erno]

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: Monday, December 07, 2015 4:36 PM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [glance] Add Ian Cordasco back into glance-core
> 
> 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.
> 
> Cheers,
> Flavio
> 
> --
> @flaper87
> Flavio Percoco

+2A

Ian, good to have you back!

- Erno
__
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] Stable team PTL nominations are open

[Kuvaja, Erno]

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: 09 December 2015 08:57
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [stable] Stable team PTL nominations are open
> 
> Thierry Carrez wrote:
> > Thierry Carrez wrote:
> >> The nomination deadline is passed, we have two candidates!
> >>
> >> I'll be setting up the election shortly (with Jeremy's help to
> >> generate election rolls).
> >
> > OK, the election just started. Recent contributors to a stable branch
> > (over the past year) should have received an email with a link to vote.
> > If you haven't and think you should have, please contact me privately.
> >
> > The poll closes on Tuesday, December 8th at 23:59 UTC.
> > Happy voting!
> 
> Election is over[1], let me congratulate Matt Riedemann for his election !
> Thanks to everyone who participated to the vote.
> 
> Now I'll submit the request for spinning off as a separate project team to the
> governance ASAP, and we should be up and running very soon.
> 
> Cheers,
> 
> [1] http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_2f5fd6c3837eae2a
> 
> --
> Thierry Carrez (ttx)
> 

Congratulations Matt,

Almost 200 voters, sounds like great start for the new team. 

- Erno

__
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] [python-glanceclient] Return request-id to caller

[Kuvaja, Erno]

> -Original Message-
> From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
> Sent: 11 December 2015 09:19
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [python-glanceclient] Return request-id to
> caller
> 
> 
> 
> -Original Message-
> From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
> Sent: 10 December 2015 12:56
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [python-glanceclient] Return request-id to
> caller
> 
> 
> 
> -Original Message-
> From: stuart.mcla...@hp.com [mailto:stuart.mcla...@hp.com]
> Sent: 09 December 2015 23:54
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [python-glanceclient] Return request-id to
> caller
> 
> > Excerpts from Flavio Percoco's message of 2015-12-09 09:09:10 -0430:
> >> On 09/12/15 11:33 +, Kekane, Abhishek wrote:
> >>> Hi Devs,
> >>>
> >>>
> >>>
> >>> We are adding support for returning ?x-openstack-request-id?  to the
> >>> caller as per the design proposed in cross-project specs:
> >>>
> >>> http://specs.openstack.org/openstack/openstack-specs/specs/
> >>> return-request-id.html
> >>>
> >>>
> >>>
> >>> Problem Description:
> >>>
> >>> Cannot add a new property of list type to the warlock.model object.
> >>>
> >>>
> >>>
> >>> How is a model object created:
> >>>
> >>> Let?s take an example of glanceclient.api.v2.images.get() call [1]:
> >>>
> >>>
> >>>
> >>> Here after getting the response we call model() method. This model()
> >>> does the job of creating a warlock.model object(essentially a dict)
> >>> based on the schema given as argument (image schema retrieved from
> >>> glance in this case). Inside
> >>> model() the raw() method simply return the image schema as JSON
> >>> object. The advantage of this warlock.model object over a simple
> >>> dict is that it validates any changes to object based on the rules 
> >>> specified
> in the reference schema.
> >>> The keys of this  model object are available as object properties to
> >>> the caller.
> >>>
> >>>
> >>>
> >>> Underlying reason:
> >>>
> >>> The schema for different sub APIs is returned a bit differently. For
> >>> images, metadef APIs glance.schema.Schema.raw() is used which
> >>> returns a schema containing ?additionalProperties?: {?type?:
> >>> ?string?}. Whereas for members and tasks APIs
> >>> glance.schema.Schema.minimal() is used to return schema object which
> does not contain ?additionalProperties?.
> >>>
> >>>
> >>>
> >>> So we can add extra properties of any type to the model object
> >>> returned from members or tasks API but for images and metadef APIs
> >>> we can only add properties which can be of type string. Also for the
> >>> latter case we depend on the glance configuration to allow additional
> properties.
> >>>
> >>>
> >>>
> >>> As per our analysis we have come up with two approaches for
> >>> resolving this
> >>> issue:
> >>>
> >>>
> >>>
> >>> Approach #1:  Inject request_ids property in the warlock model
> >>> object in glance client
> >>>
> >>> Here we do the following:
> >>>
> >>> 1. Inject the ?request_ids? as additional property into the model
> >>> object (returned from model())
> >>>
> >>> 2. Return the model object which now contains request_ids property
> >>>
> >>>
> >>>
> >>> Limitations:
> >>>
> >>> 1. Because the glance schemas for images and metadef only allows
> >>> additional properties of type string, so even though natural type of
> >>> request_ids should be list we have to make it as a comma separated
> >>> ?string? of request ids as a compromise.
> >>>
> >>> 2. Lot of extra code is needed to wrap objects returned from the
> >>> client API so that the caller can get request ids. For example we
> >>> need to write wrapper classes for dict, list, str, tuple, generator.
> >>>
> >>> 3. Not a good design as we are adding a property which should
> >>> actually be a base property but added as additional property as a
> compromise.
> >>>
> >>> 4. There is a dependency on glance whether to allow
> >>> custom/additional properties or not. [2]
> >>>
> >>>
> >>>
> >>> Approach #2:  Add ?request_ids? property to all schema definitions
> >>> in glance
> >>>
> >>>
> >>>
> >>> Here we add  ?request_ids? property as follows to the various APIs
> (schema):
> >>>
> >>>
> >>>
> >>> ?request_ids?: {
> >>>
> >>>  "type": "array",
> >>>
> >>>  "items": {
> >>>
> >>>"type": "string"
> >>>
> >>>  }
> >>>
> >>> }
> >>>
> >>>
> >>>
> >>> Doing this will make changes in glance client very simple as
> >>> compared to approach#1.
> >>>
> >>> This also looks a better design as it will be consistent.
> >>>
> >>> We simply need to modify the request_ids property in  various API
> >>> calls for example glanceclient.v2.images.get().
> >>>
> >>
> >> Hey Abhishek,
> >>
> >> thanks for working on this.
> >>
> >> To be honest, I'm a bit confused on why the request_id needs to be an
> >> attribute of the image. Isn't it passed as 

Re: [openstack-dev] [glance][keystone][artifacts] Service Catalog name for Glance Artifact Repository API

[Kuvaja, Erno]

> -Original Message-
> From: Ian Cordasco [mailto:ian.corda...@rackspace.com]
> Sent: Friday, December 11, 2015 8:13 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [glance][keystone][artifacts] Service Catalog
> name for Glance Artifact Repository API
> 
> 
> 
> On 12/11/15, 12:25, "Alexander Tivelkov"  wrote:
> 
> >Hi folks!
> >
> >
> >As it was decided during the Mitaka design summit, we are separating
> >the experimental Artifact Repository API from the main Glance API. This
> >API will have a versioning sequence independent from the main Glance
> >API and will be run as a standalone optional  service, listening on the
> >port different from the standard glance-api port (currently the
> >proposed default is 9393). Meanwhile, it will remain an integral part
> >of the larger Glance project, sharing the database, implementation
> >roadmap, development and review  teams etc.
> 
> +1 to 9494 for DevStack so developers can run Arti and Searchlight along
> side each other.
> 
> >Since this API will be consumed by both end-users and other Openstack
> >services, its endpoint should be discoverable via regular service
> >catalog API. This rises the question: what should be the service name
> >and service type for the appropriate entree in  the service catalog?
> >
> >
> >We've came out with the idea to call the service "glare" (this is our
> >internal codename for the artifacts initiative, being an acronym for
> >"GLance Artifact REpository") and set its type to "artifacts". Other
> >alternatives for the name may be "arti" or "glance_artifacts"
> > and for the type - "assets" or "objects" (the latter may be confusing
> >since swift's type is object-store, so I personally don't like it).
> 
> For the type, I would think either "asset" or "artifact" (along the lines of 
> how
> glance is "image", and neutron is "network"). I tend to lean towards 
> "artifact"
> though.
> 
> As for the "default" (I assume DevStack) name, why not just "glare", the
> description should be "Glance Artifact Service" (which I think is slightly 
> more
> end-user important than the name).

++

- Erno
> 
> >Well... we all know, naming is complicated... anyway, I'll appreciate
> >any feedback on this. Thanks!
> >
> >
> >
> >--
> >
> >Regards,
> >Alexander Tivelkov
> >
> 
> --
> Cheers,
> Ian
> 
> __
> 
> 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] [glance][keystone][artifacts] Service Catalog name for Glance Artifact Repository API

[Kuvaja, Erno]

> -Original Message-
> From: McLellan, Steven
> Sent: Friday, December 11, 2015 6:37 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [glance][keystone][artifacts] Service Catalog
> name for Glance Artifact Repository API
> 
> Hi Alex,
> 
> Searchlight uses port 9393 (it also made sense to us when we spun out of
> Glance!), so we would prefer it if there's another one that makes sense.
> Regarding the three hardest things in computer science, searchlight's already
> dealing with cache invalidation so I'll stay out of the naming discussion.
> 
> Thanks!
> 
> Steve

Thanks for the heads up Steve,

Mind to make sure that it gets registered for Searchlight as well. It's not 
listed in config-reference [0] nor iana [1] (seems that at least glance ports 
are not registered in iana either fwiw):

[0] 
http://docs.openstack.org/liberty/config-reference/content/firewalls-default-ports.html
[1] 
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml

- Erno
> 
> From: Alexander Tivelkov
> mailto:ativel...@mirantis.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> mailto:openstack-
> d...@lists.openstack.org>>
> Date: Friday, December 11, 2015 at 11:25 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> mailto:openstack-
> d...@lists.openstack.org>>
> Subject: [openstack-dev] [glance][keystone][artifacts] Service Catalog name
> for Glance Artifact Repository API
> 
> Hi folks!
> 
> As it was decided during the Mitaka design summit, we are separating the
> experimental Artifact Repository API from the main Glance API. This API will
> have a versioning sequence independent from the main Glance API and will
> be run as a standalone optional service, listening on the port different from
> the standard glance-api port (currently the proposed default is 9393).
> Meanwhile, it will remain an integral part of the larger Glance project, 
> sharing
> the database, implementation roadmap, development and review teams
> etc.
> 
> Since this API will be consumed by both end-users and other Openstack
> services, its endpoint should be discoverable via regular service catalog API.
> This rises the question: what should be the service name and service type for
> the appropriate entree in the service catalog?
> 
> We've came out with the idea to call the service "glare" (this is our internal
> codename for the artifacts initiative, being an acronym for "GLance Artifact
> REpository") and set its type to "artifacts". Other alternatives for the name
> may be "arti" or "glance_artifacts" and for the type - "assets" or "objects"
> (the latter may be confusing since swift's type is object-store, so I 
> personally
> don't like it).
> 
> Well... we all know, naming is complicated... anyway, I'll appreciate any
> feedback on this. Thanks!
> 
> --
> Regards,
> Alexander Tivelkov
> 
> __
> 
> 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] [nova][glance][cinder][neutron]How to make use of x-openstack-request-id

[Kuvaja, Erno]

Hi Tan,

While the cross project spec was discussed Glance already had implementation of 
request ids in place. At the time of the Glance implementation we assumed that 
one request id is desired through the chain of services and we implemented the 
req id to be accepted as part of the request. This was mainly driven to have 
same request id through the chain between glance-api and glance-registry but as 
the same code was used in both api and registry services we got this 
functionality across glance.

The cross project discussion turned this approach down and decided that only 
new req id will be returned. We did not want to utilize 2 different code bases 
to handle req ids in glance-api and glance-registry, nor we wanted to remove 
the functionality to allow the req ids being passed to the service as that was 
already merged to our API. Thus is requests are passed without req id defined 
to the services they behave (apart from nova having different header name) same 
way, but with glance the request maker has the liberty to specify request id 
they want to use (within configured length limits).

Hopefully that clarifies it for you.


-  Erno

From: Tan, Lin [mailto:lin@intel.com]
Sent: 26 January 2016 01:26
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][glance][cinder][neutron]How to make use of 
x-openstack-request-id

Thanks Kebane, I test glance/neutron/keystone with ``x-openstack-request-id`` 
and find something interesting.

I am able to pass ``x-openstack-request-id``  to glance and it will use the 
UUID as its request-id. But it failed with neutron and keystone.
Here is my test:
http://paste.openstack.org/show/484644/

It looks like because keystone and neutron are using 
oslo_middleware:RequestId.factory and in this part:
https://github.com/openstack/oslo.middleware/blob/master/oslo_middleware/request_id.py#L35
It will always generate an UUID and append to response as 
``x-openstack-request-id`` header.

My question is should we accept an external passed request-id as the project's 
own request-id or having its unique request-id?
In other words, which one is correct way, glance or neutron/keystone? There 
must be something wrong with one of them.

Thanks

B.R

Tan


From: Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
Sent: Wednesday, December 2, 2015 2:24 PM
To: OpenStack Development Mailing List 
(openstack-dev@lists.openstack.org)
Subject: Re: [openstack-dev] [nova][glance][cinder][neutron]How to make use of 
x-openstack-request-id


Hi Tan,



Most of the OpenStack RESTful API returns `X-Openstack-Request-Id` in the API 
response header but this request id is not available to the caller from the 
python client.

When you use --debug option from command from the command prompt using client, 
you can see `X-Openstack-Request-Id` on the console but it is not logged 
anywhere.



Currently a cross-project specs [1] is submitted and approved for returning 
X-Openstack-Request-Id to the caller and the implementation for the same is in 
progress.

Please go through the specs for detail information which will help you to 
understand more about request-ids and current work about the same.



Please feel free to revert back anytime for your doubts.



[1] 
https://github.com/openstack/openstack-specs/blob/master/specs/return-request-id.rst



Thanks,



Abhishek Kekane









Hi guys

I recently play around with 'x-openstack-request-id' header but have a 
dump question about how it works. At beginning, I thought an action across 
different services should use a same request-id but it looks like this is not 
the true.



First I read the spec: 
https://blueprints.launchpad.net/nova/+spec/cross-service-request-id which said 
"This ID and the request ID of the other service will be logged at service 
boundaries". and I see cinder/neutron/glance will attach its context's 
request-id as the value of "x-openstack-request-id" header to its response 
while nova use X-Compute-Request-Id. This is easy to understand. So It looks 
like each service should generate its own request-id and attach to its 
response, that's all.



But then I see glance read 'X-Openstack-Request-ID' to generate the request-id 
while cinder/neutron/nova read 'openstack.request_id' when using with keystone. 
It is try to reuse the request-id from keystone.



This totally confused me. It would be great if you can correct me or point me 
some reference. Thanks a lot



Best Regards,



Tan


__
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further u

Re: [openstack-dev] [glance] Glance Core team additions/removals

[Kuvaja, Erno]

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: 26 January 2016 14:42
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [glance] Glance Core team additions/removals
> 
> 
> Greetings,
> 
> I'd like us to have one more core cleanup for this cycle:
> 
> Additions:
> 
> - Kairat Kushaev
> - Brian Rosmaita
> 
> Both have done amazing reviews either on specs or code and I think they
> both would be an awesome addition to the Glance team.

+2/+2 for adding them both to Glance _core_reviewer_ team, they are very much 
part of Glance team already ;)

> 
> Removals:
> 
> - Alexander Tivelkov
> - Fei Long Wang
> 
> Fei Long and Alexander are both part of the OpenStack community.
> However, their focus and time has shifted from Glance and, as it stands right
> now, it would make sense to have them both removed from the core team.
> This is not related to their reviews per-se but just prioritization. I'd like 
> to
> thank both, Alexander and Fei Long, for their amazing contributions to the
> team. If you guys want to come back to Glance, please, do ask. I'm sure the
> team will be happy to have you on board again.

This is definitely our loss and I would be happy seeing them back in our first 
line if the focus changes.

- Erno

>
> To all other members of the community. Please, provide your feedback.
> Unless someone objects, the above will be effective next Tuesday.
> 
> Cheers,
> 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

Re: [openstack-dev] [nova][glance][cinder][neutron]How to make use of x-openstack-request-id

[Kuvaja, Erno]

> -Original Message-
> From: Matt Riedemann [mailto:mrie...@linux.vnet.ibm.com]
> Sent: Wednesday, January 27, 2016 9:56 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [nova][glance][cinder][neutron]How to make
> use of x-openstack-request-id
> 
> 
> 
> On 1/27/2016 9:40 AM, Tan, Lin wrote:
> > Thank you so much. Eron. This really helps me a lot!!
> >
> > Tan
> >
> > *From:*Kuvaja, Erno [mailto:kuv...@hpe.com]
> > *Sent:* Tuesday, January 26, 2016 8:34 PM
> > *To:* OpenStack Development Mailing List (not for usage questions)
> > *Subject:* Re: [openstack-dev] [nova][glance][cinder][neutron]How to
> > make use of x-openstack-request-id
> >
> > Hi Tan,
> >
> > While the cross project spec was discussed Glance already had
> > implementation of request ids in place. At the time of the Glance
> > implementation we assumed that one request id is desired through the
> > chain of services and we implemented the req id to be accepted as part
> > of the request. This was mainly driven to have same request id through
> > the chain between glance-api and glance-registry but as the same code
> > was used in both api and registry services we got this functionality
> > across glance.
> >
> > The cross project discussion turned this approach down and decided
> > that only new req id will be returned. We did not want to utilize 2
> > different code bases to handle req ids in glance-api and
> > glance-registry, nor we wanted to remove the functionality to allow
> > the req ids being passed to the service as that was already merged to
> > our API. Thus is requests are passed without req id defined to the
> > services they behave (apart from nova having different header name)
> > same way, but with glance the request maker has the liberty to specify
> > request id they want to use (within configured length limits).
> >
> > Hopefully that clarifies it for you.
> >
> > -Erno
> >
> > *From:*Tan, Lin [mailto:lin@intel.com]
> > *Sent:* 26 January 2016 01:26
> > *To:* OpenStack Development Mailing List (not for usage questions)
> > *Subject:* Re: [openstack-dev] [nova][glance][cinder][neutron]How to
> > make use of x-openstack-request-id
> >
> > Thanks Kebane, I test glance/neutron/keystone with
> > ``x-openstack-request-id`` and find something interesting.
> >
> > I am able to pass ``x-openstack-request-id``  to glance and it will
> > use the UUID as its request-id. But it failed with neutron and keystone.
> >
> > Here is my test:
> >
> > http://paste.openstack.org/show/484644/
> >
> > It looks like because keystone and neutron are using
> > oslo_middleware:RequestId.factory and in this part:
> >
> >
> https://github.com/openstack/oslo.middleware/blob/master/oslo_middlew
> a
> > re/request_id.py#L35
> >
> > It will always generate an UUID and append to response as
> > ``x-openstack-request-id`` header.
> >
> > My question is should we accept an external passed request-id as the
> > project's own request-id or having its unique request-id?
> >
> > In other words, which one is correct way, glance or neutron/keystone?
> > There must be something wrong with one of them.
> >
> > Thanks
> >
> > B.R
> >
> > Tan
> >
> > *From:*Kekane, Abhishek [mailto:abhishek.kek...@nttdata.com]
> > *Sent:* Wednesday, December 2, 2015 2:24 PM
> > *To:* OpenStack Development Mailing List
> > (openstack-dev@lists.openstack.org
> > <mailto:openstack-dev@lists.openstack.org>)
> > *Subject:* Re: [openstack-dev] [nova][glance][cinder][neutron]How to
> > make use of x-openstack-request-id
> >
> > Hi Tan,
> >
> > Most of the OpenStack RESTful API returns `X-Openstack-Request-Id` in
> > the API response header but thisrequest id isnotavailable to the
> > callerfromthe python client.
> >
> > When you use --debug option from command from the command prompt
> using
> > client, you can see `X-Openstack-Request-Id`on the console but it is
> > not logged anywhere.
> >
> > Currently a cross-project specs [1] is submitted and approved for
> > returning X-Openstack-Request-Id to the caller and the implementation
> > for the same is in progress.
> >
> > Please go through the specs for detail information which will help you
> > to understand more about request-ids and current work about the same.
> >
> > Please feel free to revert back anytime for your doubts.
> >
> > [1]
> > https://github

Re: [openstack-dev] [all][tc] Stabilization cycles: Elaborating on the idea to move it forward

[Kuvaja, Erno]

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: Monday, January 25, 2016 3:07 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][tc] Stabilization cycles: Elaborating on 
> the
> idea to move it forward
> 
> On 20/01/16 13:23 -0430, Flavio Percoco wrote:
> >Thoughts? Feedback?
> 
> Hey Folks,
> 
> Thanks a lot for the feedback. Great comments and proposals in the many
> replies.
> I've gone through the whole thread and collected the most common
> feedback.
> Here's the summary:
> 
> - The general idea of planning some sort of stabilization for a project is 
> good
>   but considering a cycle for it is terrible. It'd be easier if development
>   cycles would be shorter but the 6-month based development cycles don't
> allow
>   for planning this properly.
> 
> - Therefore, milestones are more likely to be good for this but there has to
> be
>   a good plan. What will happen with on-going features? How does a project
>   decide what to merge or not? Is it really going to help with reviews/bugs
>   backlog? or would this just increase the bakclog?
> 
> - We shouldn't need any governance resolution/reference for this. Perhaps a
>   chapter/section on the project team guide should do it.
> 
> - As other changes in the commuity, it'd be awesome to get feedback from a
>   project doing this before we start encouraging other projects to do the
> same.
> 
> 
> I'll work on adding something to the project team guide that covers the
> above points.
> 
> did I miss something? Anything else that we should add and or consider?
> 

Sorry for jumping the gun this late, but I have been thinking about this since 
your first e-mail and one thing bothers me. Don't we have stabilization cycle 
for each release starting right from the release?

In my understanding this is exactly what the Stable releases Support Phase I is 
accepting bug fixes but no new features. After 6 months the release is moved to 
Phase II where only critical and security fixes are accepted; I think this is 
good example of stabilization cycle and the output is considered solid.

All concerns looked at I think the big problem really is to get the people 
working on these cycles. Perhaps we should encourage more active maintenance on 
our stable branches and see then what we can bring from that to our development 
branch expertise and knowledge wise.

While I'm not huge believer of constant agile development, this is one of those 
things that needs to be lived with and I think stable branches are our best bet 
for stabilization work (specifically when that work needs to land to master 
first). For long term refactoring I'd like to see us using more feature 
branches so we can keep doing the work without releasing it before it's done.

My 2 Euro cents,
Erno

> Cheers,
> 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

Re: [openstack-dev] [Oslo] Improving deprecated options identification and documentation

[Kuvaja, Erno]

> From: Ronald Bradford [mailto:m...@ronaldbradford.com] 
> Sent: Wednesday, January 20, 2016 6:34 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Oslo] Improving deprecated options 
> identification and documentation
>
> Markus,
>
> 
>> Yes, in what release it is to be removed, e.g. Mitaka.  So when is
>> that release cycle, i.e. now once removed there is no record.
>
> The information at which point in time a removal will happen can be
> derived from a combination of:
> * the "Deprecation Notes" (e.g. Nova's at [1]) and
> * the "follows_standard_deprecation" policy [2].
> I don't see the immediate need to duplicate that information.
>
> The potential duplication you refer to enables code scanning/automation to 
> detect and even initiate steps at the start of a release cycle to remove 
> deprecated options.
> Looking at documented notes is a more inconsistent manual approach. The 
> number of deprecated options should not be high, I do not see the issue in 
> ensuring this information is in code as well as docs.

Specially thinking about libraries and projects that releases multiple times 
per cycle something like "Will be removed in the first release after 17.9.2016" 
rather than "Will be removed at X.Y.Z" would be preferred. This way we can 
ensure the correctness and proper deprecation time without needing to care what 
releases that project happens to do in between. It's not exactly the easiest 
job to predict all the changes going for months ahead so that specific release 
can be identified when the deprecation happens.

Apart from that I'm happily behind the proposal of documenting the deprecations 
better.

- Erno
>
>
> I agree that there should be an explanation in ``deprecation_reason``
> if ``deprecated_for_removal=True`` **why** we deprecated it and which
> follow up actions seem to be reasonable for the ops.
>
> Thanks!  I think for now, stating a reason, stating what release it was 
> deprecated and what release it should be removed provides a starting point 
> with a low barrier of entry to see results.
>
> Ronald (rbradfor)
>
> 
> References:
> [1] Nova's current release notes based on "reno"; "Deprecation Notes":
>
> http://docs.openstack.org/releasenotes/nova/unreleased.html#deprecation-notes
> [2] OpenStack governance docs; tag "assert_follows_standard_deprecation":
>
> https://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html
>
> Regards, Markus Zoeller (markus_z)


__
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

[Kuvaja, Erno]

Victor,

That was related to stable/kilo branch as stated on the line above:

14:39:58  jokke_: was that you on python-glanceclient stable/kilo
14:39:59  also queued up bunch of stable stuff ... glance_store gotta 
wait until Cinder gets their client requirements fixed, but glanceclient 
backports would need some love

;)
- Erno

> -Original Message-
> From: Victor Stinner [mailto:vstin...@redhat.com]
> Sent: Wednesday, July 15, 2015 9:39 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [glance] Progress of the Python 3 port
> 
> Hi,
> 
> On 09/07/2015 16:29, Ian Cordasco wrote:
> > Thanks for your hard work Victor! I'll bring up a new release today in
> > the Glance meeting (currently running) and see if Nik and I can bug
> > the release managers for a new release today.
> 
> Any update on this release?
> 
> In the meeting report, I read:
> "14:39:59  also queued up bunch of stable stuff ... glance_store
> gotta wait until Cinder gets their client requirements fixed, but glanceclient
> backports would need some love"
> 
> What is this Cinder client requirements issue? Is it fixed now? The "stable
> stuff" are required for the new glance_store release?
> 
> http://eavesdrop.openstack.org/meetings/glance/2015/glance.2015-07-09-
> 14.00.log.html
> 
> Victor
> 
> __
> 
> 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] [stable]{kilo][glance] freeze exceptions

[Kuvaja, Erno]

Hi all,

We have been waiting python-cinderclient stable/kilo release for couple of 
weeks to be able to merge glance_store stable/kilo backports. Namigly:
https://review.openstack.org/#/q/status:open+project:openstack/glance_store+branch:stable/kilo,n,z

As Alan blocked them all, I'd like to ask everyone hold your horses with the 
2015.1.1 release until cinder gets their client released so we can fix the 
glance store for the release.

Thanks,
Erno
__
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] [Log] Log Working Group weekly meeting

[Kuvaja, Erno]

Hi all,

Log Working Group has been running weekly meetings Wednesdays at 20:00 UTC. 
There were queries while back to adjust the meeting time to facilitate EMEA/APJ 
folks bit better.

Current regular participants are fine with the time we're having the meeting 
now, but we wanted to probe the community to see if there are people who would 
like to participate but the current time is absolutely not viable for them. So 
please share the message and let us know if earlier time slot would be 
something that would bring more activity to this working group. At the moment 
the plan is to keep our current meeting time and if there is need, move to 
bi-weekly rotation of early and late slots.

We will bring this topic back on the table on next Wednesday's meeting.

Thanks,
Erno (jokke_) Kuvaja
__
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][api] Response when a illegal body is sent

[Kuvaja, Erno]

> -Original Message-
> From: Ian Cordasco [mailto:ian.corda...@rackspace.com]
> Sent: Friday, July 24, 2015 4:58 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [glance][api] Response when a illegal body is
> sent
> 
> 
> 
> On 7/23/15, 19:38, "michael mccune"  wrote:
> 
> >On 07/23/2015 12:43 PM, Ryan Brown wrote:
> >> On 07/23/2015 12:13 PM, Jay Pipes wrote:
> >>> On 07/23/2015 10:53 AM, Bunting, Niall wrote:
>  Hi,
> 
>  Currently when a body is passed to an API operation that explicitly
>  does not allow bodies Glance throws a 500.
> 
>  Such as in this bug report:
>  https://bugs.launchpad.net/glance/+bug/1475647 This is an example
>  of a GET however this also applies to other requests.
> 
>  What should Glance do rather than throwing a 500, should it return
>  a
>  400 as the user provided an illegal body
> >>>
> >>> Yep, this.
> >>
> >> +1, this should be a 400. It would also be acceptable (though less
> >> preferable) to ignore any body on GET requests and execute the
> >> request as normal.
> >>
> >>> Best,
> >>> -jay
> >
> >i'm also +1 on the 400 band wagon
> 
> 400 feels right for when Glance is operating without anything in front of it.
> However, let me present a hypothetical situation:
> 
> Company X is operating Glance behind a load-balancing proxy. Most users
> talk to Glance behind the LB. If someone writes a quick script to send a GET
> and (for whatever reason) includes a body, they'll get a 200 with the data
> that would otherwise have been sent if they didn't include a body.
> This is because most such proxies will strip the body on a GET (even though
> RFC 7231 allows for bodies on a GET and explicitly refuses to define semantic
> meaning for them). If later that script is updated to work behind the load
> balancer it will be broken, because Glance is choosing to error instead of
> ignoring it.
> 
> Note: I'm not arguing that the user is correct in sending a body when there
> shouldn't be one sent, just that we're going to confuse a lot of people with
> this.
> 
> I'm also fine with either a 400 or a 200.

I'd be pro 400 series here. Firstly because our Images API v2 documentation 
clearly states """This operation does not accept a request body.""" Under GET 
section of most of our paths: 
http://developer.openstack.org/api-ref-image-v2.html

I do not think we should change that just to facilitate someone who is breaking 
our API and happens to be lucky to have the proxy sanitizing the request in 
between (which IMO is the second wrong in this corner, the proxy should not 
alter the request content in the first place). Based on our API documentation I 
can see 400 series catch being bug fix and I'll be more than happy to throw the 
discussion about changing our APIs accepting body in the get request as a spec 
and object it there.

It's just wrong to send the message that it's ok to send any garbage to us with 
your request and consume the extra resources by doing so.

- Erno
> 
> __
> 
> 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] [glance] Removing python-swiftclient from requirements.txt

[Kuvaja, Erno]

I do agree, we don't depend or are cleaning the other clients out of the glance 
dependencies as well and I think swift should not be there either.

The default store is filesystem store and if something is depending on the 
actual store clients it should be either glance_store or deployer (well for 
example our gate) glance itself should not have hard dependencies for 'em.


-  Erno

From: William M Edmonds [mailto:edmon...@us.ibm.com]
Sent: Monday, July 27, 2015 10:42 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [glance] Removing python-swiftclient from 
requirements.txt


python-swiftclient is only needed by operators that are using the swift 
backend, so it really doesn't belong in requirements.txt. Listing it in 
requirements forces all operators to install it, even if they're not going to 
use the swift backend. When I proposed a change [1] to move this from 
requirements to test-requirements (would still be needed there because of tests 
using the swift backend), others raised concerns about the impact this could 
have on operators who use the swift backend today and would be upgrading to 
Liberty. I believe everyone agreed this should not be in requirements, but the 
fact is that it has been, so operators may have (incorrectly) been depending on 
that during upgrades. If we remove it in Liberty, and there are changes in 
Liberty that require a newer version of swiftclient, how would those operators 
know that they need to upgrade swiftclient?

The optional dependencies spec [2] could definitely help here. I don't think we 
should have to wait for that, though. This is an issue we obviously already 
have today for other backends, which indicates folks can deal with it without 
an optional dependencies implementation.

This would be a new concern for operators using the default swift backend, 
though. So how do we get the message out to those operators? And do we need to 
put out a message about this change in Liberty and then wait until Mitaka to 
actually remove this, or can we go ahead and remove in Liberty?

[1] https://review.openstack.org/#/c/203242
[2] 
http://specs.openstack.org/openstack/oslo-specs/specs/liberty/optional-deps.html

-Matthew
__
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][stable] Stable exception for bug #1447215: Allow ramdisk/kernel_id to be None

[Kuvaja, Erno]

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: Tuesday, July 28, 2015 3:15 PM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [nova][glance][stable] Stable exception for bug
> #1447215: Allow ramdisk/kernel_id to be None
> 
> Greetings,
> 
> We recently found a bug in the Nova-Glance interaction that prevents
> booting snapshots using Glance's V2 API. The bug is that Nova creates the
> snapshot and sets the ramdisk_id/kernel_id to None when it's not available.
> 
> While this was ok in V1, it causes a failure for V2 since the current schema-
> properties file doesn't allow both fields to be None. The right fix would be 
> for
> Nova not to set these fields at all if no value is found.
> 
> Nonetheless, we have a workaround that would make this work. The
> workaround landed in master and it's been proposed for kilo.
> Therefore, I'm asking for a stable exception to merge this patch, which is
> backwards compatible (unless I'm missing something). The exception is being
> requested because it does change the API.

+1

In my understanding as well we would be backwards compatible and this would 
make the future upgrades so much easier in the case nova starts consuming v2 
Image API.

- Erno

> 
> The change proposed is to allow these fields to be None.
> 
> The review: https://review.openstack.org/#/c/205432/
> 
> Cheers,
> 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

Re: [openstack-dev] [Stable][Nova] VMware NSXv Support

[Kuvaja, Erno]

Hi Gary,

While I do understand the interest to get this functionality included, I really 
fail to see how it would comply with the Stable Branch Policy: 
https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy
Obviously the last say is on stable-maint-core, but normally new features are 
really no-no to stable branches.

My concerns are more on the metadata side of your changes.
Even the refactoring is fairly clean it is major part of the metadata handler.
It also changes the API (In the case of X-Metadata-Provider being present) 
which tends to be sacred on stable branches.

The changes here does not actually fix any bug but just implements new 
functionality that missed kilo not even slightly but by months. Thus my -1 for 
merging these.


-  Erno

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Wednesday, August 05, 2015 8:03 AM
To: OpenStack List
Subject: [openstack-dev] [Stable][Nova] VMware NSXv Support

Hi,
In the Kilo cycle a Neutron driver was added for supporting the Vmware NSXv 
plugin. This required patches in Nova to enable the plugin to work with Nova. 
These patches finally landed yesterday. I have back ported them to stable/kilo 
as the Neutron driver is unable to work without these in stable/kilo. The 
patches can be found at:

  1.  VNIC support - https://review.openstack.org/209372
  2.  Metadata support - https://review.openstack.org/209374
I hope that the stable team can take this into consideration.

Thanks in advance
Gary
__
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][Nova][Cinder] glance_store and glance

[Kuvaja, Erno]

Hi,

Flagged Nova and Cinder into this discussion as they were the first intended 
adopters iirc.

I don't have big religious view about this topic. I wasn't huge fan of the idea 
separating it in the first place and I'm not huge fan of keeping it separate 
either.

After couple of cycles we have so far witnessed only the downside of 
glance_store being on it's own. We break even our own gate with our own lib 
releases, we have one extra bug tracker to look after and even not huge but it 
just increases the load on the release and stable teams as well.

In my understanding the interest within Nova to consume glance_store directly 
has pretty much died off since we separated it, please do correct me if I'm 
wrong.
I haven't heard anyone expressing any interest to consume glance_store directly 
within Cinder either.
So far I have failed to see use-case for glance_store alone apart from Glance 
API Server and the original intended use-cases/consumers have either not 
expressed interest what so ever or directly expressed being not interested.

Do we have any reason what so ever keeping doing the extra work to keep these 
two components separate? I'm more than happy to do so or at least extend this 
discussion for a cycle if there is projects out there planning to utilize it. I 
don't want to be in middle of separating it again next cycle because someone 
wanted to consume and forked out the old tree because we decided to kill it but 
I'm not keen to take the overhead of it either without reason.

- Erno

> -Original Message-
> From: Nikhil Komawar [mailto:nik.koma...@gmail.com]
> Sent: Friday, August 07, 2015 6:21 AM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [Glance] glance_store and glance
> 
> Hi,
> 
> During the mid-cycle we had another proposal that wanted to put back the
> glance_store library back into the Glance repo and not leave it is as a
> separate repo/project.
> 
> The questions outstanding are: what are the use cases that want it as a
> separate library?
> 
> The original use cases that supported a separate lib have not had much
> progress or adoption yet. There have been complaints about overhead of
> maintaining it as a separate lib and version tracking without much gain.
> The proposals for the re-factor of the library is also a worrysome topic in
> terms of the stability of the codebase.
> 
> The original use cases from my memory are:
> 1. Other projects consuming glance_store -- this has become less likely to be
> useful.
> 2. another upload path for users for the convenience of tasks -- not
> preferable as we don't want to expose this library to users.
> 3. ease of addition of newer drivers for the developers -- drivers are only
> being removed since.
> 4. cleaner api / more methods that support backend store capabilities - a
> separate library is not necessarily needed, smoother re-factor is possible
> within Glance codebase.
> 
> Also, the authN/Z complexities and ACL restrictions on the back-end stores
> can be potential security loopholes with the library and Glance evolution
> separately.
> 
> In order to move forward smoothly on this topic in Liberty, I hereby request
> input from all concerned developer parties. The decision to keep this as a
> separate library will remain in effect if we do not come to resolution within 
> 2
> weeks from now. However, if there aren't any significant use cases we may
> consider a port back of the same.
> 
> Please find some corresponding discussion from the latest Glance weekly
> meeting:
> http://eavesdrop.openstack.org/meetings/glance/2015/glance.2015-08-06-
> 14.03.log.html#l-21
> 
> --
> 
> Thanks,
> Nikhil
> 
> 
> __
> 
> 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][Nova] VMware NSXv Support

[Kuvaja, Erno]

> -Original Message-
> From: Gary Kotton [mailto:gkot...@vmware.com]
> Sent: Monday, August 10, 2015 4:18 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Stable][Nova] VMware NSXv Support
> 
> 
> 
> On 8/10/15, 6:05 PM, "Gary Kotton"  wrote:
> 
> >
> >
> >On 8/10/15, 6:03 PM, "Gary Kotton"  wrote:
> >
> >>
> >>
> >>On 8/10/15, 5:46 PM, "Matt Riedemann" 
> wrote:
> >>
> >>>
> >>>
> >>>On 8/10/2015 9:17 AM, Gary Kotton wrote:
> >>>> Hi,
> >>>> I am not really sure what to say here. The code was in review for
> >>>>over
> >>>>8
> >>>> months. On a side note but related - we have a patch for a plugin
> >>>>developed in Liberty - https://review.openstack.org/#/c/165750/.
> >>>>This has  been in review since March. I really hope that that lands
> >>>>in Liberty.
> >>>>If
> >>>> not we will go through the same thing again.
> >>>> Working in Nova on code that is self contained within a driver is
> >>>>difficult - terribly difficult. Not only is this demotivating, it
> >>>>also  effectively does not help any of the drivers actually add any
> >>>>features.
> >>>> A sad day for OpenStack.
> >>>> Thanks
> >>>> Gary
> >>>>
> >>>> On 8/5/15, 4:01 PM, "Ihar Hrachyshka"  wrote:
> >>>>
> >>>>> -BEGIN PGP SIGNED MESSAGE-
> >>>>> Hash: SHA256
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> I think Erno made a valid point here. If that would touch only
> >>>>>vmware  code, that could be an option to consider. But it looks
> >>>>>like both  patches are very invasive, and they are not just
> >>>>>enabling features  that are already in the tree, but introduce new
> >>>>>stuff that is not even  tested for long in master.
> >>>>>
> >>>>> I guess we'll need to wait for those till Liberty. Unless
> >>>>>nova-core-maint has a different opinion and good arguments to
> >>>>>approach  the merge.
> >>>>>
> >>>>> Ihar
> >>>>>
> >>>>> On 08/05/2015 12:37 PM, Kuvaja, Erno wrote:
> >>>>>> Hi Gary,
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> While I do understand the interest to get this functionality
> >>>>>> included, I really fail to see how it would comply with the
> >>>>>> Stable Branch Policy:
> >>>>>> https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy
> >>>>>>
> >>>>>> Obviously the last say is on stable-maint-core, but normally new
> >>>>>> features are really no-no to stable branches.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> My concerns are more on the metadata side of your changes.
> >>>>>>
> >>>>>> Even the refactoring is fairly clean it is major part of the
> >>>>>> metadata handler.
> >>>>>>
> >>>>>> It also changes the API (In the case of X-Metadata-Provider being
> >>>>>> present) which tends to be sacred on stable branches.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> The changes here does not actually fix any bug but just
> >>>>>> implements new functionality that missed kilo not even slightly but
> by months.
> >>>>>> Thus my -1 for merging these.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> -  Erno
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> *From:*Gary Kotton [mailto:gkot...@vmware.com] *Sent:*
> Wednesday,
> >>>>>> August 05, 2015 8:03 AM *To:* OpenStack List *Subject:*
> >>>>>> [openstack-dev] [Stable][Nova] VMware NSXv Support
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Hi,
> >>>>&g

Re: [openstack-dev] [Nova] [Cinder] [Glance] glance_store and glance

[Kuvaja, Erno]

> -Original Message-
> From: Jay Pipes [mailto:jaypi...@gmail.com]
> Sent: Tuesday, August 11, 2015 3:10 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Nova] [Cinder] [Glance] glance_store and
> glance
> 
> On 08/11/2015 09:42 AM, Brian Rosmaita wrote:
> > On 8/7/15, 1:07 PM, "Jay Pipes"  wrote:
> >
> >> So, here's the crux of the issue. Nova and Cinder **do not want to
> >> speak the Glance REST API** to either upload or download image bits
> >> from storage. Streaming image bits through the Glance API endpoint is
> >> a needless and inefficient step, and Nova and Cinder would like to
> >> communicate directly with the backend storage systems.
> >
> > Exactly why do you want to communicate directly with the backend
> > storage systems?  Streaming image bits through Glance appears to be
> > "needless and inefficient", but if an end-user is booting 1K instances
> > from some custom image, Glance's image cache makes an enormous
> difference in delivery time.
> 
> Nova's image cache makes a bigger difference overall in those cases, since
> the image will most likely be cached on compute nodes themselves and
> won't need to be copied at all.

If that would be the case we wouldn't have this problem. If nova image caching 
solves all those boot time issues it probably doesn't matter that the image 
comes from glance?
> 
> Having the image bits streaming through an unrelated endpoint (the Glance
> API server) is just not required if the logic for grabbing the "closest" image
> from a set of locations is all in the glance_store library and different nova-
> compute daemons can just efficiently grab the image from multiple locations
> if the image is stored in multiple locations in backend storage.

I think the _if_ there is really relevant. So what you are actually asking is 
not to merge glance_store to glance but merge glance to glance_store so you get 
all the acl controls, policies, data integrity promise, etc. to glance_store? 
It's not just where the bits are. We could then access it all just through 
nova's image API. Perhaps provide Nova Images API V2 for cinder and Horizon; V3 
for the future artifacts consumers. Jay, if you miss glance so much, we happily 
take your contribution to the project, you don't need to be ranting there that 
you want it back to part of nova to contribute. ;)
> 
> In addition, Glance's image cache, while excellent for improving performance
> of first-pull of images from slower backend storage like Swift, also requires
> the operator to have a bunch of disk space used on the controller nodes that
> run glance-api. In many deployments that I know of, the controller nodes do
> not run stateful services (DB and MQ are on separate node clusters entirely
> from nova-api, glance-api, cinder-api, etc), and because of this, don't have a
> large root disk (sometimes nothing more than a small SSD for the OS kernel
> and some swap). Setting up Glance's image cache on these types of nodes
> means you need to be careful not to run out of local disk space, since a 
> single
> popular Windows image can easily be 20-40+ GB. In addition to that, each
> glance-api server is going to have its own image cache, not all with the same
> images in them, since different requests will be routed to different glance-
> api servers, and each image cache is its own LRU layout.

This explains a lot.
> 
> Having the image cache local to the compute nodes themselves gives the
> best performance overall, and with glance_store, means that glance-api isn't
> needed at all, and Glance can become just a metadata repository, which
> would be awesome, IMHO.

You have any figures to back this up in scale? We've heard similar claims for 
quite a while and as soon as people starts to actually look into how the 
environments behaves, they quite quickly turn back. As you're not the first 
one, I'd like to make the same request as to everyone before, show your data to 
back this claim up! Until that it is just like you say it is, opinion.;)

- Erno
> 
> Best,
> -jay
> 
> > So I'm curious about what exactly the use cases for direct backend
> > storage communication are, and why Glance can't meet them.
> 
> __
> 
> 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] [Nova] [Cinder] [Glance] glance_store and glance

[Kuvaja, Erno]

> -Original Message-
> From: Mike Perez [mailto:thin...@gmail.com]
> Sent: 11 August 2015 19:04
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Nova] [Cinder] [Glance] glance_store and
> glance
> 
> On 15:06 Aug 11, Kuvaja, Erno wrote:
> > > -Original Message-
> > > From: Jay Pipes [mailto:jaypi...@gmail.com]
> 
> 
> 
> > > Having the image cache local to the compute nodes themselves gives
> > > the best performance overall, and with glance_store, means that
> > > glance-api isn't needed at all, and Glance can become just a
> > > metadata repository, which would be awesome, IMHO.
> >
> > You have any figures to back this up in scale? We've heard similar
> > claims for quite a while and as soon as people starts to actually look
> > into how the environments behaves, they quite quickly turn back. As
> > you're not the first one, I'd like to make the same request as to
> > everyone before, show your data to back this claim up! Until that it
> > is just like you say it is, opinion.;)
> 
> The claims I make with Cinder doing caching on its own versus just using
> Glance with rally with an 8G image:
> 
> Creating/deleting 50 volumes w/ Cinder image cache: 324 seconds
> Creating/delete 50 volumes w/o Cinder image cache: 3952 seconds
> 
> http://thing.ee/x/cache_results/
> 
> Thanks to Patrick East for pulling these results together.
> 
> Keep in mind, this is using a block storage backend that is completely
> separate from the OpenStack nodes. It's *not* using a local LVM all in one
> OpenStack contraption. This is important because even if you have Glance
> caching enabled, and there was no cache miss, you still have to dd the bits to
> the block device, which is still going over the network. Unless Glance is 
> going
> to cache on the storage array itself, forget about it.
> 
> Glance should be focusing on other issues, rather than trying to make
> copying image bits over the network and dd'ing to a block device faster.
> 
> --
> Mike Perez
> 
Thanks Mike,

So without cinder cache your times averaged roughly 150+second marks. The 
couple of first volumes with the cache took roughly 170+seconds. What the data 
does not tell, was cinder pulling the images directly from glance backend 
rather than through glance on either of these cases?

Somehow you need to seed those caches and that seeding time/mechanism is where 
the debate seems to be. Can you afford keeping every image in cache so that 
they are all local or if you need to pull the image to seed your cache how much 
you will benefit that your 100 cinder nodes are pulling it directly from 
backend X versus glance caching/sitting in between. How block storage backend 
handles that 100 concurrent reads by different client when you are seeding it 
between different arrays? The scale starts matter here because it makes a lot 
of difference on backend if it's couple of cinder or nova nodes requesting the 
image vs. 100s of them. Lots of backends tends to not like such loads or we 
outperform them due not having to fight for the bandwidth with other consumers 
of that backend.

That dd part we gladly leave to you, the network takes what it takes to 
transfer and we will be happily handing the bits over at the other end still, 
so you have something to dd. That is our business and we do it pretty well. 

- Erno
> __
> 
> 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] [Nova] [Cinder] [Glance] glance_store and glance

[Kuvaja, Erno]

> -Original Message-
> From: Mike Perez [mailto:thin...@gmail.com]
> Sent: Wednesday, August 12, 2015 4:45 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Nova] [Cinder] [Glance] glance_store and
> glance
> 
> On Wed, Aug 12, 2015 at 2:23 AM, Kuvaja, Erno  wrote:
> >> -Original Message-
> >> From: Mike Perez [mailto:thin...@gmail.com]
> >> Sent: 11 August 2015 19:04
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> Subject: Re: [openstack-dev] [Nova] [Cinder] [Glance] glance_store
> >> and glance
> >>
> >> On 15:06 Aug 11, Kuvaja, Erno wrote:
> >> > > -Original Message-
> >> > > From: Jay Pipes [mailto:jaypi...@gmail.com]
> >>
> >> 
> >>
> >> > > Having the image cache local to the compute nodes themselves
> >> > > gives the best performance overall, and with glance_store, means
> >> > > that glance-api isn't needed at all, and Glance can become just a
> >> > > metadata repository, which would be awesome, IMHO.
> >> >
> >> > You have any figures to back this up in scale? We've heard similar
> >> > claims for quite a while and as soon as people starts to actually
> >> > look into how the environments behaves, they quite quickly turn
> >> > back. As you're not the first one, I'd like to make the same
> >> > request as to everyone before, show your data to back this claim
> >> > up! Until that it is just like you say it is, opinion.;)
> >>
> >> The claims I make with Cinder doing caching on its own versus just
> >> using Glance with rally with an 8G image:
> >>
> >> Creating/deleting 50 volumes w/ Cinder image cache: 324 seconds
> >> Creating/delete 50 volumes w/o Cinder image cache: 3952 seconds
> >>
> >> http://thing.ee/x/cache_results/
> >>
> >> Thanks to Patrick East for pulling these results together.
> >>
> >> Keep in mind, this is using a block storage backend that is
> >> completely separate from the OpenStack nodes. It's *not* using a
> >> local LVM all in one OpenStack contraption. This is important because
> >> even if you have Glance caching enabled, and there was no cache miss,
> >> you still have to dd the bits to the block device, which is still
> >> going over the network. Unless Glance is going to cache on the storage
> array itself, forget about it.
> >>
> >> Glance should be focusing on other issues, rather than trying to make
> >> copying image bits over the network and dd'ing to a block device faster.
> >>
> >> --
> >> Mike Perez
> >>
> > Thanks Mike,
> >
> > So without cinder cache your times averaged roughly 150+second marks.
> > The couple of first volumes with the cache took roughly 170+seconds.
> > What the data does not tell, was cinder pulling the images directly
> > from glance backend rather than through glance on either of these cases?
> 
> Oh but I did, and that's the beauty of this, the files marked cinder-cache-
> x.html are avoiding Glance as soon as it can, using the Cinder generic image
> cache solution [1]. Please reread my when I say Glance is unable to do
> caching in a storage array, so we don't rely on Glance. It's too slow 
> otherwise.
> 
> Take this example with 50 volumes created from image with Cinder's image
> cache
> [2]:
> 
> * Is using Glance cache (oh no cache miss)
> * Downloads the image from whatever glance store
> * dd's the bits to the exported block device.
> * the bits travel to the storage array that the block device was exported
> from.
> * [2nd-50th] request of that same image comes, Cinder instead just
> references
>   a cinder:// endpoint which has the storage array do a copy on write. ZERO
>   COPYING since we can clone the image. Just a reference pointer and done,
> move
>   on.
> 
> > Somehow you need to seed those caches and that seeding
> time/mechanism
> > is where the debate seems to be. Can you afford keeping every image in
> > cache so that they are all local or if you need to pull the image to
> > seed your cache how much you will benefit that your 100 cinder nodes
> > are pulling it directly from backend X versus glance caching/sitting
> > in between. How block storage backend handles that 100 concurrent
> > reads by different client when you are seeding it between different
> > arrays? The scale starts matter he

Re: [openstack-dev] [stable] [infra] How to auto-generate stable release notes

[Kuvaja, Erno]

> -Original Message-
> From: Robert Collins [mailto:robe...@robertcollins.net]
> Sent: Wednesday, August 19, 2015 11:38 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [stable] [infra] How to auto-generate stable
> release notes
> 
> On 19 August 2015 at 21:19, Thierry Carrez  wrote:
> > Robert Collins wrote:
> >> [...]
> >> Proposed data structure:
> >> - create a top level directory in each repo called release-notes
> >> - within that create a subdirectory called changes.
> >> - within the release-notes dir we place yaml files containing the
> >> release note inputs.
> >> - within the 'changes' subdirectory, the name of the yaml file will
> >> be the gerrit change id in a canonical form.
> >>E.g. I1234abcd.yaml
> >>This serves two purposes: it guarantees file name uniqueness (no
> >> merge conflicts) and lets us
> >>determine which release to group it in (the most recent one, in
> >> case of merge+revert+merge patterns).

We try to have python-glanceclient and glance_store including release notes 
upon the release time. We use in tree doc/source/index.rst for ease of access. 
This provides our release notes through: 
docs.openstack.org/developer/python-glanceclient/ and you can easily follow up 
stable branches via git: 
https://github.com/openstack/python-glanceclient/blob/stable/kilo/doc/source/index.rst

I've been trying to push mentality in to our community that last thing before 
release, we merge release notes update and tag that. What comes to stable, I 
think it's worth of adding release notes in the backport workflow.
> >
> > One small issue I see with using changeid in the filename is that it
> > prevents people from easily proposing a backport with a release note
> > snippet in them (since they can't predict the changeID). They will
> > have to get it generated and then amend their commit.
> 
> Backports typically use the original changeID - they will if they use git 
> cherry-
> pick.
> 
> > I think we need to enforce some more structure. Release notes are
> > easier to read if you group them by category. For stable branches you
> > should put "critical upgrade notes" first, then "security updates",
> > then random release notes. For master branch notes we usually have
> > "critical upgrade notes", then "major features", then "known issues",
> > then random release notes. So I would encourage a slightly more
> > detailed schema with categories to keep consistency and readability.

Strong maybe, pointless in stable if our aim is to have each commit being 
release or if we anyways have one or two changes per topic.

This would make sense on initial release from master excluding libs and clients 
which tends to have less changes per release anyways.
> 
> Sure - please fill it in :). I was winging it, since I don't do release 
> notes, I had
> no idea of your needs.
> 
> >> Processing:
> >> 1) determine the revisions we need to generate release notes for. By
> >> default generate notes for the current minor release. (E.g. if the
> >> tree version is 1.2.3.dev4 we would generate release notes for 1.2.0,
> >> 1.2.1, 1.2.2, 1.2.3[which dev4 is leading up to]).
> >
> > How would that work in a post-versioned world ? What would you
> > generate if the tree version is 1.2.3.post12 ?
> 
> 1.2.3 is still the version, not that we can use post versions at all with pbr.
> (Short story - we can't because we used them wrongly and we haven't had
> nearly enough time to flush out remaining instances in the wild).
> 
> >> 2) For each version: scan all the commits to determine gerrit change-id's.
> >>  i) read in all those change ids .yaml files and pull out any notes within
> them.
> >>  ii) read in any full version yaml file (and merge in its contained
> >> notes)
> >>  iii) Construct a markdown document as follows:
> >>   a) Sort any preludes (there should be only one at most, but lets
> >> not error if there are multiple)
> >>   b) sort any notes
> >
> > We would sort them by category.
> 
> The requirement for deterministic results means we'd just sort them.
> If they are divided into categories, we'd sort the list of categories (perhaps
> according to some schema) and then within each category sort the notes.
> 
> >>   c) for each note transform it into a bullet point by prepending its
> >> first line with '- ' and every subsequent line with '  ' (two spaces
> >> to form a hanging indent).
> >>   d) strip any trailing \n's from everything.
> >>   e) join the result - '\n'.join(chain(preludes, notes))
> >>  iv) we output the resulting file to release-notes/$version.md where
> >> $version is the pbr reported version for the tree (e.g. in the
> >> example above it would be 1.2.3.dev4, *not* 1.2.3).
> >
> > So you would have release-notes/1.2.2.yaml and release-notes/1.2.2.md
> > in the same directory, with one being a subset of the data present in
> > the other ? That feels a bit confusing. I would rather use two
> > separate directories (

Re: [openstack-dev] [stable] [infra] How to auto-generate stable release notes

[Kuvaja, Erno]

> -Original Message-
> From: Dave Walker [mailto:em...@daviey.com]
> Sent: 21 August 2015 12:43
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [stable] [infra] How to auto-generate stable
> release notes
> 
> On 21 August 2015 at 11:38, Thierry Carrez  wrote:
> 
> > Since then, replying to another concern about common downstream
> > reference points, we moved to "tagging everything", then replying to
> > Clark's pollution remark, to "tag from time to time". That doesn't
> > remove the need to *conveniently* ship the best release notes we can
> > with every commit. Including them in every code tarball (and relying
> > on well-known python sdist commands to generate them for those
> > consuming the git tree directly) sounded like the most accessible way
> > to do it, which the related thread on the Ops ML confirmed. But then
> > I'm (and maybe they are) still open to alternative suggestions...
> 
> This is probably a good entry point for my ACTION item from the cross-
> project meeting:
> 
> I disagree that "time to time" tagging makes sense in what we are trying to
> achieve.  I believe we are in agreement that we want to move way from co-
> ordinated releases and treat each commit as an accessible release.
> Therefore, tagging each project at arbitrary times introduces snowflake
> releases, rather than the importance being on each commit being a release.
> 
> I agree that this would take away the 'co-ordinated' part of the release, but
> still requires release management of each project (unless the "time to time"
> is automated), which we are not sure that each project will commit to.
> 
> If we are treating each commit to be a release, maybe we should just bite
> the bullet and enlarge the ref tag length.  I've not done a comparison of what
> this would look like, but I believe it to be rare that people look at the list
> anyway.  Throwing in a | grep -v "^$RELEASE*", and it becomes as usable as
> before.  We could also expunge the tags after the release is no longer
> supported by upstream.
> 
> In my mind, we are then truly treating each commit as a release AND we
> benefit from not needing hacky tooling to fake this.
> 
> --
> Kind Regards,
> Dave Walker
> 

I do not like about the time to time tagging either, but I don't think it's 
totally horrible situation. Lets say we tag every even week Wednesday and in 
event of OSSA.

The big problem with every commit being release in stable is that lots of 
tooling around git really doesn't care if the reference is branch or tag in 
branch X. Say I can't remember how I named my branch I'm working on and I do 
`git checkout ` there is difference if that list suddenly is on 
hundreds rather than dozens. So yes some level of deprecation period to clean 
those old tags would be great at the point we stop support for certain branches.

I do realize that I'm not the git guru, so if there is really simple way to 
configure that, please let me know and ignore the above. ;)

- Erno
> __
> 
> 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] [oslo][release] oslo freeze this week?

[Kuvaja, Erno]

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: Monday, August 24, 2015 1:47 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [oslo][release] oslo freeze this week?
> 
> On Aug 23, 2015, at 5:51 PM, Robert Collins 
> wrote:
> > On 24 August 2015 at 09:28, Doug Hellmann 
> wrote:
> >> I have marked on my version of the release schedule that we will have
> the Oslo libraries frozen this week. Are we still planning to do that? We
> should figure out what that means as far as creating stable branches and
> version caps and all of those things that caused us so much trouble last 
> cycle.
> >
> > We're not capping anything. We're depending on constraints to carry us
> > forward. The constraints for tox stuff works but isn't widely
> > deployed: it is partly waiting on a governance change... I think we
> > should use this as a forcing function for projects to opt-in to that.
> > grenade uses constraints so only stable branches should be affected by
> > that.
> 
> Back in YVR we had the following process drafted on a whiteboard:
> 
> 1. Enable master->stable cross-check
> 2. Release Oslo, make stable branches for Oslo
> 2.1 Converge constraints
> 3. liberty-3 / FF / soft requirements freeze 4. hard requirements freeze 5.
> RC1 / make stable branches for services 6. Branch requirements, disable
> cross-check 7. Unfreeze requirements
> 
> Is there anything new that makes this proposed process invalid ?
> 
> If not, since (3) is Thursday next week, that means we need to cover the first
> 3 items in the coming week ?
> 
> --
> Thierry Carrez (ttx)
> 

That does sound absolutely reasonable.

I'd like to add/ask where in there we have the last point to cut rest of the 
libs? That should probably happen by 3. As well?

- Erno

__
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] Feature Freeze Exception proposal

[Kuvaja, Erno]

Malini, all,

My current opinion is -1 for FFE based on the concerns in the spec and 
implementation.

I'm more than happy to realign my stand after we have updated spec and a) it's 
agreed to be the approach as of now and b) we can evaluate how much work the 
implementation needs to meet with the revisited spec.

If we end up to the unfortunate situation that this functionality does not 
merge in time for Liberty, I'm confident that this is one of the first things 
in Mitaka. I really don't think there is too much to go, we just might run out 
of time.

Thanks for your patience and endless effort to get this done.

Best,
Erno

> -Original Message-
> From: Bhandaru, Malini K [mailto:malini.k.bhand...@intel.com]
> Sent: Thursday, September 03, 2015 10:10 AM
> To: Flavio Percoco; OpenStack Development Mailing List (not for usage
> questions)
> Subject: Re: [openstack-dev] [Glance] Feature Freeze Exception proposal
> 
> Flavio, first thing in the morning Kent will upload a new BP that addresses 
> the
> comments. We would very much appreciate a +1 on the FFE.
> 
> Regards
> Malini
> 
> 
> 
> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: Thursday, September 03, 2015 1:52 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Glance] Feature Freeze Exception proposal
> 
> On 02/09/15 22:11 -0400, Nikhil Komawar wrote:
> >Hi,
> >
> >I wanted to propose 'Single disk image OVA import' [1] feature proposal
> >for exception. This looks like a decently safe proposal that should be
> >able to adjust in the extended time period of Liberty. It has been
> >discussed at the Vancouver summit during a work session and the
> >proposal has been trimmed down as per the suggestions then; has been
> >overall accepted by those present during the discussions (barring a few
> >changes needed on the spec itself). It being a addition to already
> >existing import task, doesn't involve API change or change to any of
> >the core Image functionality as of now.
> >
> >Please give your vote: +1 or -1 .
> >
> >[1] https://review.openstack.org/#/c/194868/
> 
> I'd like to see support for OVF being, finally, implemented in Glance.
> Unfortunately, I think there are too many open questions in the spec right
> now to make this FFE worthy.
> 
> Could those questions be answered to before the EOW?
> 
> With those questions answered, we'll be able to provide a more, realistic,
> vote.
> 
> Also, I'd like us to evaluate how mature the implementation[0] is and the
> likelihood of it addressing the concerns/comments in time.
> 
> For now, it's a -1 from me.
> 
> Thanks all for working on this, this has been a long time requested format to
> have in Glance.
> Flavio
> 
> [0] https://review.openstack.org/#/c/214810/
> 
> 
> --
> @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

__
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] differences between def detail() and def index() in glance/registry/api/v1/images.py

[Kuvaja, Erno]

This was the case until about two weeks ago.

Since 1.0.0 release we have been defaulting to Images API v2 instead of v1 [0].

If you want to exercise the v1 functionality from the CLI client you would need 
to specify the either environmental variable OS_IMAGE_API_VERSION=1 or use the 
command line option –os-image-api-version 1. Either case –debug can be used 
with glanceclient to provide detailed information about where the request is 
being sent and what the responses are.

If you haven’t moved to the latest client yet, forget about the above apart 
from the –debug part.

[0] 
https://github.com/openstack/python-glanceclient/blob/master/doc/source/index.rst


-  Erno

From: Fei Long Wang [mailto:feil...@catalyst.net.nz]
Sent: Thursday, September 10, 2015 1:04 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [glance] differences between def detail() and def 
index() in glance/registry/api/v1/images.py

I assume you're using Glance client, if so, by default, when you issuing 
command 'glance image-list', it will call /v1/images/detail instead of 
/v1/images, you can use curl or any browser http client to see the difference. 
Basically, just like the endpoint name, /v1/images/detail will give you more 
details. See below difference of their response.

Response from /v1/images/detail
{
"images": [
{
"status": "active",
"deleted_at": null,
"name": "fedora-21-atomic-3",
"deleted": false,
"container_format": "bare",
"created_at": "2015-09-03T22:56:37.00",
"disk_format": "qcow2",
"updated_at": "2015-09-03T23:00:15.00",
"min_disk": 0,
"protected": false,
"id": "b940521b-97ff-48d9-a22e-ecc981ec0513",
"min_ram": 0,
"checksum": "d3b3da0e07743805dcc852785c7fc258",
"owner": "5f290ac4b100440b8b4c83fce78c2db7",
"is_public": true,
"virtual_size": null,
"properties": {
"os_distro": "fedora-atomic"
},
"size": 770179072
}
]
}

Response with /v1/images
{
"images": [
{
"name": "fedora-21-atomic-3",
"container_format": "bare",
"disk_format": "qcow2",
"checksum": "d3b3da0e07743805dcc852785c7fc258",
"id": "b940521b-97ff-48d9-a22e-ecc981ec0513",
"size": 770179072
}
]
}
On 10/09/15 11:46, Su Zhang wrote:

Hello,

I am hitting an error and its trace passes def index () in 
glance/registry/api/v1/images.py.

I assume def index() is called by glance image-list. However, while testing 
glance image-list I realized that def detail() is called under 
glance/registry/api/v1/images.py instead of def index().

Could someone let me know what's the difference between the two functions? How 
can I test out def index() under glance/registry/api/v1/images.py through CLI 
or API?

Thanks,

--
Su Zhang



__

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


--

Cheers & Best regards,

Fei Long Wang (王飞龙)

--

Senior Cloud Software Engineer

Tel: +64-48032246

Email: flw...@catalyst.net.nz

Catalyst IT Limited

Level 6, Catalyst House, 150 Willis Street, Wellington

--
__
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] glance core rotation part 1

[Kuvaja, Erno]

+1

From: Alex Meade [mailto:mr.alex.me...@gmail.com]
Sent: Friday, September 11, 2015 7:37 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] glance core rotation part 1

+1

On Fri, Sep 11, 2015 at 2:33 PM, Ian Cordasco 
mailto:ian.corda...@rackspace.com>> wrote:


-Original Message-
From: Nikhil Komawar mailto:nik.koma...@gmail.com>>
Reply: OpenStack Development Mailing List (not for usage questions) 
mailto:openstack-dev@lists.openstack.org>>
Date: September 11, 2015 at 09:30:23
To: openstack-dev@lists.openstack.org 
mailto:openstack-dev@lists.openstack.org>>
Subject:  [openstack-dev] [Glance] glance core rotation part 1

> Hi,
>
> I would like to propose the following removals from glance-core based on
> the simple criterion of inactivity/limited activity for a long period (2
> cycles or more) of time:
>
> Alex Meade
> Arnaud Legendre
> Mark Washenberger
> Iccha Sethi

I think these are overdue

> Zhi Yan Liu (Limited activity in Kilo and absent in Liberty)

Sad to see Zhi Yan Liu's activity drop off.

> Please vote +1 or -1 and we will decide by Monday EOD PT.

+1

--
Ian Cordasco
__
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][TC] 'team:danger-not-diverse tag' and my concerns

[Kuvaja, Erno]

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: Monday, September 14, 2015 9:03 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all][TC] 'team:danger-not-diverse tag' and my
> concerns
> 

> 
> Or are you suggesting it is preferable to hide that risk from our
> operators/users, to protect that project team developers ?
> 
> --
> Thierry Carrez (ttx)
> 
Unfortunately this seems to be the trend, not only in  
but in society. Everything needs to be everyone friendly and politically 
correct, it's not ok to talk about difficult topics with their real names 
because someone involved might get their feelings hurt, it's not ok to compete 
as losers might get their feelings hurt.

While being bit double edged sword I think this is exact example of such. One 
could argue if the project has reason to exist if saying out loud "it does not 
have diversity in its development community" will kill it. I think there is 
good amount of examples both ways in open source world where abandoned projects 
get picked up as there is people thinking they still have use case and value, 
on the other side maybe promising projects gets forgotten because no-one else 
really felt the urge to keep 'em alive.

Personally I feel this being bit like stamping feature experimental. "Please 
feel free to play around with it, but we do discourage you to deploy it in your 
production unless you're willing to pick up the maintenance of it in the case 
the team decides to do something else." There is nothing wrong with that.

I don't think these should be hiding behind the valance of the big tent and the 
consumer expectations should be set at least close to the reality without them 
needing to do huge amount of detective work. That was the point of the tags in 
first place, no?

Obviously above is just my blunt self. If someone went and rage killed their 
project because of that, good for you, now get yourself together and do it 
again. ;)

- Erno (jokke) Kuvaja

__
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][ptl][release] final liberty cycle client library releases needed

[Kuvaja, Erno]

Hi Doug,

Please find python-glanceclient 1.0.1 release request 
https://review.openstack.org/#/c/222716/

- Erno

> -Original Message-
> From: Doug Hellmann [mailto:d...@doughellmann.com]
> Sent: Monday, September 14, 2015 1:46 PM
> To: openstack-dev
> Subject: [openstack-dev] [all][ptl][release] final liberty cycle client 
> library
> releases needed
> 
> PTLs and release liaisons,
> 
> In order to keep the rest of our schedule for the end-of-cycle release tasks,
> we need to have final releases for all client libraries in the next day or 
> two.
> 
> If you have not already submitted your final release request for this cycle,
> please do that as soon as possible.
> 
> If you *have* already submitted your final release request for this cycle,
> please reply to this email and let me know that you have so I can create your
> stable/liberty branch.
> 
> Thanks!
> 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] [glance] proposed priorities for Mitaka

[Kuvaja, Erno]

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: Monday, September 14, 2015 1:41 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [glance] proposed priorities for Mitaka
> 
> On 14/09/15 08:10 -0400, Doug Hellmann wrote:
> >
> >After having some conversations with folks at the Ops Midcycle a few
> >weeks ago, and observing some of the more recent email threads related
> >to glance, glance-store, the client, and the API, I spent last week
> >contacting a few of you individually to learn more about some of the
> >issues confronting the Glance team. I had some very frank, but I think
> >constructive, conversations with all of you about the issues as you see
> >them. As promised, this is the public email thread to discuss what I
> >found, and to see if we can agree on what the Glance team should be
> >focusing on going into the Mitaka summit and development cycle and how
> >the rest of the community can support you in those efforts.
> >
> >I apologize for the length of this email, but there's a lot to go over.
> >I've identified 2 high priority items that I think are critical for the
> >team to be focusing on starting right away in order to use the upcoming
> >summit time effectively. I will also describe several other issues that
> >need to be addressed but that are less immediately critical. First the
> >high priority items:
> >
> >1. Resolve the situation preventing the DefCore committee from
> >   including image upload capabilities in the tests used for trademark
> >   and interoperability validation.
> >
> >2. Follow through on the original commitment of the project to
> >   provide an image API by completing the integration work with
> >   nova and cinder to ensure V2 API adoption.
> 
> Hi Doug,
> 
> First and foremost, I'd like to thank you for taking the time to dig into 
> these
> issues, and for reaching out to the community seeking for information and a
> better understanding of what the real issues are. I can imagine how much
> time you had to dedicate on this and I'm glad you did.

++ Really thanks for taking the time for this.
> 
> Now, to your email, I very much agree with the priorities you mentioned
> above and I'd like for, whomever will win Glance's PTL election, to bring 
> focus
> back on that.
> 
> Please, find some comments in-line for each point:
> 
> 
> >
> >I. DefCore
> >
> >The primary issue that attracted my attention was the fact that DefCore
> >cannot currently include an image upload API in its interoperability
> >test suite, and therefore we do not have a way to ensure
> >interoperability between clouds for users or for trademark use. The
> >DefCore process has been long, and at times confusing, even to those of
> >us following it sort of closely. It's not entirely surprising that some
> >projects haven't been following the whole time, or aren't aware of
> >exactly what the whole thing means. I have proposed a cross-project
> >summit session for the Mitaka summit to address this need for
> >communication more broadly, but I'll try to summarize a bit here.
> 

Looking how different OpenStack based public clouds limits or fully prevents 
their users to upload images to their deployments, I'm not convinced the Image 
Upload should be included to this definition.
 
> +1
> 
> I think it's quite sad that some projects, especially those considered to be
> part of the `starter-kit:compute`[0], don't follow closely what's going on in
> DefCore. I personally consider this a task PTLs should incorporate in their 
> role
> duties. I'm glad you proposed such session, I hope it'll help raising 
> awareness
> of this effort and it'll help moving things forward on that front.
> 
> 
> >
> >DefCore is using automated tests, combined with business policies, to
> >build a set of criteria for allowing trademark use. One of the goals of
> >that process is to ensure that all OpenStack deployments are
> >interoperable, so that users who write programs that talk to one cloud
> >can use the same program with another cloud easily. This is a *REST
> >API* level of compatibility. We cannot insert cloud-specific behavior
> >into our client libraries, because not all cloud consumers will use
> >those libraries to talk to the services. Similarly, we can't put the
> >logic in the test suite, because that defeats the entire purpose of
> >making the APIs interoperable. For this level of compatibility to work,
> >we need well-defined APIs, with a long support period, that work the
> >same no matter how the cloud is deployed. We need the entire community
> >to support this effort. From what I can tell, that is going to require
> >some changes to the current Glance API to meet the requirements. I'll
> >list those requirements, and I hope we can discuss them to a degree
> >that ensures everyone understands them. I don't want this email thread
> >to get bogged down in implementation details or API designs, though, so
> >let's tr

Re: [openstack-dev] [glance] proposed priorities for Mitaka

[Kuvaja, Erno]

> -Original Message-
> From: Doug Hellmann [mailto:d...@doughellmann.com]
> Sent: Monday, September 14, 2015 5:40 PM
> To: openstack-dev
> Subject: Re: [openstack-dev] [glance] proposed priorities for Mitaka
> 
> Excerpts from Kuvaja, Erno's message of 2015-09-14 15:02:59 +:
> > > -Original Message-
> > > From: Flavio Percoco [mailto:fla...@redhat.com]
> > > Sent: Monday, September 14, 2015 1:41 PM
> > > To: OpenStack Development Mailing List (not for usage questions)
> > > Subject: Re: [openstack-dev] [glance] proposed priorities for Mitaka
> > >
> > > On 14/09/15 08:10 -0400, Doug Hellmann wrote:

> > > >
> > > >I. DefCore
> > > >
> > > >The primary issue that attracted my attention was the fact that
> > > >DefCore cannot currently include an image upload API in its
> > > >interoperability test suite, and therefore we do not have a way to
> > > >ensure interoperability between clouds for users or for trademark
> > > >use. The DefCore process has been long, and at times confusing,
> > > >even to those of us following it sort of closely. It's not entirely
> > > >surprising that some projects haven't been following the whole
> > > >time, or aren't aware of exactly what the whole thing means. I have
> > > >proposed a cross-project summit session for the Mitaka summit to
> > > >address this need for communication more broadly, but I'll try to
> summarize a bit here.
> > >
> >
> > Looking how different OpenStack based public clouds limits or fully
> prevents their users to upload images to their deployments, I'm not
> convinced the Image Upload should be included to this definition.
> 
> The problem with that approach is that it means end consumers of those
> clouds cannot write common tools that include image uploads, which is a
> frequently used/desired feature. What makes that feature so special that we
> don't care about it for interoperability?
> 

I'm not sure it really is so special API or technical wise, it's just the one 
that was lifted to the pedestal in this discussion.

> >
> > > +1
> > >
> > > I think it's quite sad that some projects, especially those
> > > considered to be part of the `starter-kit:compute`[0], don't follow
> > > closely what's going on in DefCore. I personally consider this a
> > > task PTLs should incorporate in their role duties. I'm glad you
> > > proposed such session, I hope it'll help raising awareness of this effort
> and it'll help moving things forward on that front.
> > >
> > >
> > > >
> > > >DefCore is using automated tests, combined with business policies,
> > > >to build a set of criteria for allowing trademark use. One of the
> > > >goals of that process is to ensure that all OpenStack deployments
> > > >are interoperable, so that users who write programs that talk to
> > > >one cloud can use the same program with another cloud easily. This
> > > >is a *REST
> > > >API* level of compatibility. We cannot insert cloud-specific
> > > >behavior into our client libraries, because not all cloud consumers
> > > >will use those libraries to talk to the services. Similarly, we
> > > >can't put the logic in the test suite, because that defeats the
> > > >entire purpose of making the APIs interoperable. For this level of
> > > >compatibility to work, we need well-defined APIs, with a long
> > > >support period, that work the same no matter how the cloud is
> > > >deployed. We need the entire community to support this effort. From
> > > >what I can tell, that is going to require some changes to the
> > > >current Glance API to meet the requirements. I'll list those
> > > >requirements, and I hope we can discuss them to a degree that
> > > >ensures everyone understands them. I don't want this email thread
> > > >to get bogged down in implementation details or API designs,
> > > >though, so let's try to keep the discussion at a somewhat high
> > > >level, and leave the details for specs and summit discussions. I do
> > > >hope you will correct any misunderstandings or misconceptions,
> > > >because unwinding this as an outside observer has been quite a
> challenge and it's likely I have some details wrong.
> >
> > This just reinforces my doubt above. By including upload to the defcore
> requirements probably just closes out lots of the public clouds out there. Is
> that the intention here?
> 
> No, absolutely not. The intention is to provide clear technical direction 
> about
> what we think the API for uploading images should be.
> 

Gr8, that's easy goal to stand behind and support!

> >
> > > >

> > >
> > > The task upload process you're referring to is the one that uses the
> > > `import` task, which allows you to download an image from an
> > > external source, asynchronously, and import it in Glance. This is
> > > the old `copy-from` behavior that was moved into a task.
> > >
> > > The "fun" thing about this - and I'm sure other folks in the Glance
> > > community will disagree - is that I don't consider tasks to be a
> > > public API. That is to say, 

[openstack-dev] Cross-Project Meeting Tue 29th of Sep, 21:00 UTC

[Kuvaja, Erno]

Dear PTLs, cross-project liaisons and anyone else interested,



We'll have a cross-project meeting today at 21:00 UTC, with the

following agenda:



* Review of past action items

* Team announcements (horizontal, vertical, diagonal)

* Cross-Project Specs to discuss:

** Service Catalog Standardization [0]

** Backwards compatibility for clients and libraries [1]

* Open discussion



[0] https://review.openstack.org/181393

[1] https://review.openstack.org/226157



If you're from an horizontal team (Release management, QA, Infra, Docs,

Security, I18n...) or a vertical team (Nova, Swift, Keystone...) and

have something to communicate to the other teams, feel free to abuse the

relevant sections of that meeting and make sure it gets #info-ed by the

meetbot in the meeting summary.



See you there !



For more details on this meeting, please see:

https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting



--

Erno (jokke_) Kuvaja

__
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] [stable][glance] glance-stable-maint group refresher

[Kuvaja, Erno]

Hi all,

I'd like to propose following changes to glance-stable-maint team:

1)  Removing Zhi Yan Liu from the group; unfortunately he has moved on to 
other ventures and is not actively participating our operations anymore.

2)  Adding Mike Fedosin to the group; Mike has been reviewing and 
backporting patches to glance stable branches and is working with the right 
mindset. I think he would be great addition to share the workload around.

Best,
Erno (jokke_) Kuvaja
__
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] Models and validation for v2

[Kuvaja, Erno]

Kairat,

We do not validate against schema on image-list (see 
43769d6cc7266d7c81db31ad58b4fa403c35b611). This said there was discussion 
around throwing all that validation code out, exactly like Jay said, we should 
not validate responses coming from our own servers.

This discussion happened just under 1.0.0 release of glanceclient which moved 
to defaulting v2 Images API at CLI and we didn’t see it reasonable to wait 
until we get that validation cleanup done. That said, the work is in pipeline 
to be done after we get more important things (like Liberty release) out of 
hands first.


-  Erno

From: Kairat Kushaev [mailto:kkush...@mirantis.com]
Sent: Wednesday, September 30, 2015 7:33 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] Models and validation for v2

Agree with you. That's why I am asking about reasoning. Perhaps, we need to 
realize how to get rid of this in glanceclient.

Best regards,
Kairat Kushaev

On Wed, Sep 30, 2015 at 7:04 PM, Jay Pipes 
mailto:jaypi...@gmail.com>> wrote:
On 09/30/2015 09:31 AM, Kairat Kushaev wrote:
Hi All,
In short terms, I am wondering why we are validating responses from
server when we are doing
image-show, image-list, member-list, metadef-namespace-show and other
read-only requests.

AFAIK, we are building warlock models when receiving responses from
server (see [0]). Each model requires schema to be fetched from glance
server. It means that each time we are doing image-show, image-list,
image-create, member-list and others we are requesting schema from the
server. AFAIU, we are using models to dynamically validate that object
is in accordance with schema but is it the case when glance receives
responses from the server?

Could somebody please explain me the reasoning of this implementation?
Am I missed some usage cases when validation is required for server
responses?

I also noticed that we already faced some issues with such
implementation that leads to "mocking" validation([1][2]).

The validation should not be done for responses, only ever requests (and it's 
unclear that there is value in doing this on the client side at all, IMHO).

-jay

__
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] [neutron][stable] proactive backporting

[Kuvaja, Erno]

> -Original Message-
> From: Ihar Hrachyshka [mailto:ihrac...@redhat.com]
> Sent: Friday, October 16, 2015 1:34 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [neutron][stable] proactive backporting
> 
> Hi all,
> 
> I’d like to introduce a new initiative around stable branches for neutron
> official projects (neutron, neutron-*aas, python-neutronclient) that is
> intended to straighten our backporting process and make us more proactive
> in fixing bugs in stable branches. ‘Proactive' meaning: don’t wait until a
> known bug hits a user that consumes stable branches, but backport fixes in
> advance quickly after they hit master.
> 
> The idea is simple: every Fri I walk thru the new commits merged into master
> since last check; produce lists of bugs that are mentioned in Related-
> Bug/Closes-Bug; paste them into:
> 
> https://etherpad.openstack.org/p/stable-bug-candidates-from-master
> 
> Then I click thru the bug report links to determine whether it’s worth a
> backport and briefly classify them. If I have cycles, I also request backports
> where it’s easy (== a mere 'Cherry-Pick to' button click).
> 
> After that, those interested in maintaining neutron stable branches can take
> those bugs one by one and handle them, which means: checking where it
> really applies for backport; creating backport reviews (solving conflicts,
> making tests pass). After it’s up for review for all branches affected and
> applicable, the bug is removed from the list.
> 
> I started on that path two weeks ago, doing initial swipe thru all commits
> starting from stable/liberty spin off. If enough participants join the 
> process,
> we may think of going back into git history to backport interesting fixes from
> stable/liberty into stable/kilo.
> 
> Don’t hesitate to ask about details of the process, and happy backporting,
> 
> Ihar

Hi,

This looks like neat way to do it. In Glance we're doing constantly proactive 
backporting and I have been nominating bugs for series' and approving backports 
for a while now. We prefer not to have user coming to us and telling that they 
hit to bug in "stable" we had known already for ages, just didn't bother to 
backport the fix.  It has worked out really well and people are learning to 
propose these without me needing to read every single commit message. 

Good luck, has worked great for us!

- Erno
__
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] [all] Liberty summit: Updates in Glance

[Kuvaja, Erno]

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: 27 May 2015 00:58
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Glance] [all] Liberty summit: Updates in Glance
> 
> Jesse, you beat me on this one :)
> 
> On 26/05/15 13:54 -0400, Nikhil Komawar wrote:
> >Thank you Jesse for your valuable input (here and at the summit) as
> >well as intent to clarify the discussion.
> >
> >Just trying to ensure people are aware about the EXPERIMENTAL nature of
> >the v3 API and reasons behind it. Please find my responses in-line.
> >However, I do want to ensure you all, that we will strive hard to move
> >away from the EXPERIMENTAL nature and go with a rock solid
> >implementation as and when interest grows in the code-base (that helps
> stabilize it).
> >
> >On 5/26/15 12:57 PM, Jesse Cook wrote:
> >
> >
> >On 5/22/15, 4:28 PM, "Nikhil Komawar" 
> wrote:
> >
> >
> >Hi all,
> >
> >tl;dr; Artifacts IS staying in Glance.
> >
> > 1. We had a nice discussion at the contributors' meet-up at the
> >Vancouver summit this morning. After weighing in many 
> > possibilities
> >and evolution of the Glance program, we have decided to go ahead
> >with the Artifacts implementation within Glance program under the
> >EXPERIMENTAL v3 API.
> >
> >Want to clarify a bit here. My understanding is: s/Artifacts/v3 API/g. 
> > That
> >is to say, Artifacts is the technical implementation of the v3 API. This
> >also means the v3 API is an objects API vs just an images API.
> >
> >
> >Generic "data assets'" API would be a nice term along the lines of the
> >mission statement. Artifacts seemed fitting as that was the focus of
> >discussion at various sessions.
> 
> Regardless of how we call it, I do appreciate the clarity on the fact that
> Artifacts - data assests - is just the technical implementation of what will 
> be
> Glance's API v3. It's an important distinction to avoid sending the wrong
> message on what it's going to be done there.
> 
> >
> >We also had some hallway talk about putting the v1 and v2 APIs on top of
> >the v3 API. This forces faster adoption, verifies supportability via v1 
> > and
> >v2 tests, increases supportability of v1 and v2 APIs, and pushes out the
> >need to kill v1 API.
> >
> >Let's discuss more as time and development progresses on that
> >possibility. v3 API should stay EXPERIMENTAL for now as that would help
> >us understand use-cases across programs as it gets adopted by various
> >code-bases. Putting v1/v2 on top of v3 would be tricky for now as we
> >may have breaking changes with code being relatively-less stable due to
> narrow review domain.
> 
> I actually think we'd benefit more from having V2 on top of V3 than not doing
> it. I'd probably advocate to make this M material rather than L but I think 
> it'd
> be good.

We perhaps would, but that would realistically push v2 adoption across the 
projects to somewhere around O release. Just looking how long it took the v2 
code base to mature enough that we're seriously talking moving to use that in 
production.
> 
> I think regardless of what we do, I'd like to kill v1 as it has a sharing 
> model
> that is not secure.

The above would postpone this one somewhere around Q-R (which is btw. not so 
far from U anymore).

More I think about this the more convinced I am about focusing to the move to 
v2 on our consumers, deprecating the v1 out and after that we can start talking 
about moving v2 on top of the v3 codebase if possible, not other way around 
hoping that it would speed up the v3 adoption.

- Erno
> 
> Flavio
> 
> > 1.
> > 2. The effort would primarily be conducted as a sub-team-like
> >structure within the program and the co-coordinators and drivers 
> > of
> >the necessary Artifacts features would be given core-reviewer
> >status temporarily with an informal agreement to merge code that 
> > is
> >only related to Artifacts.
> > 3. The entire Glance team would give reviews as time and priorities
> >permit. The approval (+A/+WorkFlow) of any code within the
> program
> >would need to come from core-reviewers who are not temporarily
> >authorized. The list of such individuals and updated time-line
> >would be documented in phases during the course of Liberty cycle.
> > 4. We will continue to evaluate & update the governance, maturity of
> >the code and future plans for the v1, v2 and v3 Glance APIs as 
> > time
> >progresses. However, for now we are aiming to integrate all of
> >Glance (specifically Images) as Artifacts in the v3 API.
> >
> >
> >As I understand it, that is to say that v3 requests in the first
> >“micro-version” that specify the object type as image would get a not
> >implem

[openstack-dev] [log] No Log WG meeting today

[Kuvaja, Erno]

Hi all,

We do not have any burning items (or any what so ever that I'm aware of) on the 
agenda today, Rocky is away and I have myself conflicting schedules. Lets 
gather together again next week.

Meeting cancelled today Wed 3rd of June!

Best,
Erno
__
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] [stable] No longer doing stable point releases

[Kuvaja, Erno]

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: Friday, June 05, 2015 1:46 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all] [stable] No longer doing stable point
> releases
> 
> So.. summarizing the various options again:
> 
> Plan A
> Just drop stable point releases.
> (-) No more release notes
> (-) Lack of reference points to compare installations
> 
> Plan B
> Push date-based tags across supported projects from time to time.
> (-) Encourages to continue using same version across the board
> (-) Almost as much work as making proper releases
> 
> Plan C
> Let projects randomly tag point releases whenever
> (-) Still a bit costly in terms of herding cats
> 
> Plan D
> Drop stable point releases, publish per-commit tarballs
> (-) Requires some infra changes, takes some storage space
> 
> Plans B, C and D also require some release note / changelog generation from
> data maintained *within* the repository.
> 
> Personally I think the objections raised against plan A are valid. I like 
> plan D,
> since it's more like releasing every commit than "not releasing anymore". I
> think it's the most honest trade-off. I could go with plan C, but I think it's
> added work for no additional value to the user.
> 
> What would be your preferred option ?
> 
> --
> Thierry Carrez (ttx)
> 

I don't think plans B & C are any benefit for  anyone based on the statements 
discussed earlier so won't be repeating those. One thing I like about plan D is 
that it would give also indicator how much the stable branch has moved in each 
individual project. 

Yes this can be seen from git, but also having just running number on the 
stable release for each commit would be really quick glimpse opposed to SHAs or 
counting  the changes from git  log.

- Erno

__
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] [all] Proposal for Weekly Glance Drivers meeting.

[Kuvaja, Erno]

As this Fri Jun 19th did not seem to have weight, I just express my opinion to 
the mailing list for the records.

Personally I think this is bad idea, but as not being Glance Driver I can't say 
how much need there is for such meeting. The specs should be raised during our 
weekly meeting and/or discussed on the mailing list and gerrit. Having another 
irc meeting just for these discussions (specially at this time) is giving quite 
clear signal that the input from Eastern EMEA & APJ is not needed nor desired.  
Based on the description from Nikhil and the weekly nature of this meeting I 
would assume that the intention was not just have a quick sync between the 
drivers, which I could have understood.

I'd be happy to be told to be wrong on the assumptions above ;)

- Erno

> -Original Message-
> From: Nikhil Komawar [mailto:nik.koma...@gmail.com]
> Sent: 16 June 2015 18:23
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Glance] [all] Proposal for Weekly Glance
> Drivers meeting.
> 
> FYI, We will be closing the vote on Friday, June 19 at 1700 UTC.
> 
> On 6/15/15 7:41 PM, Nikhil Komawar wrote:
> > Hi,
> >
> > As per the discussion during the last weekly Glance meeting
> > (14:51:42at
> > http://eavesdrop.openstack.org/meetings/glance/2015/glance.2015-06-
> 11-
> > 14.00.log.html ), we will begin a short drivers' meeting where anyone
> > can come and get more feedback.
> >
> > The purpose is to enable those who need multiple drivers in the same
> > place; easily co-ordinate, schedule & collaborate on the specs, get
> > core-reviewers assigned to their specs etc. This will also enable more
> > synchronous style feedback, help with more collaboration as well as
> > with dedicated time for giving quality input on the specs. All are
> > welcome to attend and attendance from drivers is not mandatory but
> encouraged.
> > Initially it would be a 30 min meeting and if need persists we will
> > extend the period.
> >
> > Please vote on the proposed time and date:
> > https://review.openstack.org/#/c/192008/ (Note: Run the tests for your
> > vote to ensure we are considering feasible & non-conflicting times.)
> > We will start the meeting next week unless there are strong conflicts.
> >
> 
> --
> 
> Thanks,
> Nikhil
> 
> 
> __
> 
> 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] [cinder][stable] Cinder client broken in Juno

[Kuvaja, Erno]

Hi Mike,

We have similar functionality in Glance and I think this is critical enough fix 
to backport to Juno.

Considered for Icehouse, definitely not: 
http://lists.openstack.org/pipermail/openstack-announce/2015-June/000372.html

- Erno (jokke_)

> -Original Message-
> From: Mike Perez [mailto:thin...@gmail.com]
> Sent: 23 June 2015 16:50
> To: OpenStack Development Mailing List
> Cc: Jesse Keating
> Subject: [openstack-dev] [cinder][stable] Cinder client broken in Juno
> 
> There was a bug raised [1] from some large deployments that the Cinder
> client 1.2.0 and beyond is not working because of version discovery.
> Unfortunately it's not taking into account of deployments that have a proxy.
> 
> Cinder client asks Keystone to find a publicURL based on a version.
> Keystone will gather data from the service catalog and ask Cinder for a list 
> of
> the public endpoints and compare. For the proxy cases, Cinder is giving
> internal URLs back to the proxy and Keystone ends up using that instead of
> the publicURL in the service catalog. As a result, clients usually won't be 
> able
> to use the internal URL and rightfully so.
> 
> This is all correctly setup on the deployer's side, this an issue with the 
> server
> side code of Cinder.
> 
> There is a patch that allows the deployer to specify a configuration option
> public_endpoint [2] which was introduced in a patch in Kilo [3]. The problem
> though is we can't expect people to already be running Kilo to take
> advantage of this, and it leaves deployers running stable releases of Juno in
> the dark with clients upgrading and using the latest.
> 
> Two options:
> 
> 1) Revert version discovery which was introduced in Kilo for Cinder client.
> 
> 2) Grant exception on backporting [4] a patch that helps with this problem,
> and introduces a config option that does not change default behavior. I'm
> also not sure if this should be considered for Icehouse.
> 
> 
> [1] - https://launchpad.net/bugs/1464160
> [2] - http://docs.openstack.org/kilo/config-reference/content/cinder-conf-
> changes-kilo.html
> [3] - https://review.openstack.org/#/c/159374/
> [4] - https://review.openstack.org/#/c/194719/
> 
> --
> 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

__
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] The sorry state of our spec process

[Kuvaja, Erno]

First of all, Thanks Flavio for bring this open to the daylight!

I have been really frustrated about the Glance spec process since the beginning 
and as glance core tried to work around the limitations the best I can. I'm not 
sure if the process is similar way broken on the other projects, but I think 
after piloting the process in Glance for couple of cycles we should take some 
action on it.

Few comments inline as that way they are easier to scope.

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: Wednesday, July 01, 2015 2:49 PM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [glance] The sorry state of our spec process
> 
> Greetings,
> 
> We're 1 week through L-2 (or is it 2?, I can't do time) and we, the glance
> project, haven't even merged a single spec. Regardless of the reasons
> behind this situation and the fact that we've been indeed taking steps to
> improve this situation, I think we should put this issue to an end.

This is really sad state to be in. We haven't approved a single spec by the 
time other projects are already freezing their spec repos for L.
> 
> There are many issues we've faced in Glance:
> 
> 1. The glance-drivers team is too small [0] 2. Many specs have been held back
> waiting for code [1] 3. Huge expectations from the spec and very low review
> rate (even from other members of the glance team).

This issue was discussed while ago and was postponed to clarify the Glance Spec 
process. After that this is first initiative to bring the issue back to table 
and I'd like to hear if that process defining work is still blocking the 
expansion to share the workload. If so, could we please get the proposal of 
that workload or at least the parts of it that needs to be ironed out open in 
public so we can move that forward as community?
> 
> There was a recent discussion on this m-l[2] about the spec process in Nova
> and while I don't agree with everything that was said there, I do think it
> highlights important problems that we're facing in glance as well.
> 
> Therefore, I'd like to propose the following:
> 
> 1. Expand our drivers team. I thik people in the glance community are getting
> annoyed of reading this requests from me and "The Mythical Man-Month"
> would agree with them. However, it's really sad that some of our oldest (in
> terms of tenure) contributors that have shown interest in joining the team
> haven't been added yet. I proposed to bring all cores to the drivers team
> already and I still think that's a good thing. Assuming that's something we
> don't want, then I'd like us to find 2 or 3 people willing to volunteer for 
> this
> task.

If this still "cannot" happen I'd like to get full commitment from our current 
drivers to dedicate the time and effort for speedy workflow on our specs or 
step down and trash the whole spec process.
> 
> 2. Lets try to get things into the backlog instead of expecting them to be
> perfectly shaped and targeted for this release. Lets let people start from  a
> base, generally agreed, idea so that code can be written and reviews on the
> actual feature can be made. Once the feature is implemented, we can move
> the spec to the release directory. I believe this was also proposed in 
> Nikola's
> thread[2].

I'm huge supporter of this. Specs being part of our normal review workflow 
makes changing them as needed easy and trackable. Why in earth we need to have 
perfect plan and implementation for that plan before we're willing to indicate 
approval for the initial idea?
> 
> 3. Not all specs need to have 3-month-long discussions to be approved.
> I'm not suggesting to just merge specs that are in poor state but we can't
> always ask for code to understand whether a spec makes sense or not.
> 
> Unfortunately, we're already in L-2 and I believe it'll be really hard for 
> some
> of those features to land in Liberty, which is also sad and quite a waste of
> time.

How long we will have people trying to improve the project if any given 
proposed functionality takes cycles and lots of politics to merge.
> 
> I don't believe the above is the ultimate solution to this issue but I 
> believe it
> will help. For the next cycle, we really need to organize this process
> differently.

++

- Erno

> 
> The email is already long enough so, I hope we'll agree on something and
> finally take some actions.
> 
> Cheers,
> Flavio
> 
> [0] https://review.openstack.org/#/c/126550/
> [1] https://review.openstack.org/#/admin/groups/342,members
> (Mark Washenberger and Arnaud Legendre are not contributors anymore)
> [2] http://lists.openstack.org/pipermail/openstack-dev/2015-
> June/067861.html
> 
> 
> --
> @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/op

Re: [openstack-dev] [Product] [all][log] Openstack HTTP error codes

[Kuvaja, Erno]

> -Original Message-
> From: Sean Dague [mailto:s...@dague.net]
> Sent: 02 February 2015 16:19
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Product] [all][log] Openstack HTTP error codes
> 
> On 02/01/2015 06:20 PM, Morgan Fainberg wrote:
> > Putting on my "sorry-but-it-is-my-job-to-get-in-your-way" hat (aka
> security), let's be careful how generous we are with the user and data we
> hand back. It should give enough information to be useful but no more. I
> don't want to see us opened to weird attack vectors because we're exposing
> internal state too generously.
> >
> > In short let's aim for a slow roll of extra info in, and evaluate each data 
> > point
> we expose (about a failure) before we do so. Knowing more about a failure is
> important for our users. Allowing easy access to information that could be
> used to attack / increase impact of a DOS could be bad.
> >
> > I think we can do it but it is important to not swing the pendulum too far
> the other direction too fast (give too much info all of a sudden).
> 
> Security by cloud obscurity?
> 
> I agree we should evaluate information sharing with security in mind.
> However, the black boxing level we have today is bad for OpenStack. At a
> certain point once you've added so many belts and suspenders, you can no
> longer walk normally any more.

++
> 
> Anyway, lets stop having this discussion in abstract and actually just 
> evaluate
> the cases in question that come up.

++

- Erno
> 
>   -Sean
> 
> --
> Sean Dague
> http://dague.net
> 
> __
> 
> 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] [Product] [all][log] Openstack HTTP error codes

[Kuvaja, Erno]

Now in my understanding our services does not log to user. The user gets 
whatever error message/exception it happens to be thrown at. This is exactly 
Why we need some common identifier between them (and who ever offers request ID 
being that, I can get some of my friends with well broken English calling you 
and trying to give that to you over phone ;) ).

More inline.

> -Original Message-
> From: Rochelle Grober [mailto:rochelle.gro...@huawei.com]
> Sent: 02 February 2015 21:34
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Product] [all][log] Openstack HTTP error codes
> 
> What I see in this conversation is that we are talking about multiple 
> different
> user classes.
> 
> Infra-operator needs as much info as possible, so if it is a vendor driver 
> that is
> erring out, the dev-ops can see it in the log.

NO! Absolutely not. This is where we need to be careful what we classify as 
DEBUG and what INFO+ as the ops definitely do not need nor want it all. 
> 
> Tenant-operator is a totally different class of user.  These guys need VM
> based logs and virtual network based logs, etc., but should never see as far
> under the covers as the infra-ops *has* to see.

They see pretty much just the error messages raised to them, not the cloud 
infra logs anyways. What we need to do is to be more helpful towards them what 
they should and can help themselves with and where they would need ops help.
> 
> So, sounds like a security policy issue of what makes it to tenant logs and
> what stays "in the data center" thing.

Logs should never contain sensitive information (URIs, credentials, etc.) 
regardless where they are stored. Again obscurity is not security either.
> 
> There are *lots* of logs that are being generated.  It sounds like we need
> standards on what goes into which logs along with error codes,
> logging/reporting levels, criticality, etc.

We need guidelines. Now it's really hard to come by with tight rules how things 
needs to be logged as backend failure can be critical for some services while 
others might not care too much about that. (For example if swift has disk down, 
it's not catastrophic failure, they just move to next copy. But if back end 
store is down for glance, we can do pretty much nothing. Now should these two 
back end store failures be logged same way, no they should not.)

We need to keep the decision in the projects as mostly they are the only ones 
knowing how specific error condition affects the service. Also if the rules 
does not fit, it's really difficult to enforce for those, so let's not pick 
that fight.

- Erno
> 
> --Rocky
> 
> (bcc'ing the ops list so they can join this discussion, here)
> 
> -Original Message-
> From: Sean Dague [mailto:s...@dague.net]
> Sent: Monday, February 02, 2015 8:19 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Product] [all][log] Openstack HTTP error codes
> 
> On 02/01/2015 06:20 PM, Morgan Fainberg wrote:
> > Putting on my "sorry-but-it-is-my-job-to-get-in-your-way" hat (aka
> security), let's be careful how generous we are with the user and data we
> hand back. It should give enough information to be useful but no more. I
> don't want to see us opened to weird attack vectors because we're exposing
> internal state too generously.
> >
> > In short let's aim for a slow roll of extra info in, and evaluate each data 
> > point
> we expose (about a failure) before we do so. Knowing more about a failure is
> important for our users. Allowing easy access to information that could be
> used to attack / increase impact of a DOS could be bad.
> >
> > I think we can do it but it is important to not swing the pendulum too far
> the other direction too fast (give too much info all of a sudden).
> 
> Security by cloud obscurity?
> 
> I agree we should evaluate information sharing with security in mind.
> However, the black boxing level we have today is bad for OpenStack. At a
> certain point once you've added so many belts and suspenders, you can no
> longer walk normally any more.
> 
> Anyway, lets stop having this discussion in abstract and actually just 
> evaluate
> the cases in question that come up.
> 
>   -Sean
> 
> --
> Sean Dague
> http://dague.net
> 
> __
> 
> 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 f

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

[Kuvaja, Erno]

> -Original Message-
> From: Flavio Percoco [mailto:fla...@redhat.com]
> Sent: Wednesday, February 11, 2015 9:55 AM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [all][tc] Lets keep our community open, lets fight
> for it
> 
> Greetings all,
> 
> During the last two cycles, I've had the feeling that some of the things I 
> love
> the most about this community are degrading and moving to a state that I
> personally disagree with. With the hope of seeing these things improve, I'm
> taking the time today to share one of my concerns.
> 
> Since I believe we all work with good faith and we *all* should assume such
> when it comes to things happening in our community, I won't make names
> and I won't point fingers - yes, I don't have enough fingers to point based on
> the info I have. People that fall into the groups I'll mention below know that
> I'm talking to them.
> 
> This email is dedicated to the openness of our community/project.
> 
> ## Keep discussions open
> 
> I don't believe there's anything wrong about kicking off some discussions in
> private channels about specs/bugs. I don't believe there's anything wrong in
> having calls to speed up some discussions.
> HOWEVER, I believe it's *completely* wrong to consider those private
> discussions sufficient. If you have had that kind of private discussions, if
> you've discussed a spec privately and right after you went upstream and said:
> "This has been discussed in a call and it's good to go", I beg you to stop 
> for 2
> seconds and reconsider that. I don't believe you were able to fit all the
> community in that call and that you had enough consensus.

++
> 
> Furthermore, you should consider that having private conversations, at the
> very end, doesn't help with speeding up discussions. We've a community of
> people who *care* about the project they're working on.
> This means that whenever they see something that doesn't make much
> sense, they'll chime in and ask for clarification. If there was a private
> discussion on that topic, you'll have to provide the details of such 
> discussion
> and bring that person up to date, which means the discussion will basically
> start again... from scratch.

And when they do come and ask for clarification do not just state that this was 
discussed and agreed already.
> 
> ## Mailing List vs IRC Channel
> 
> I get it, our mailing list is freaking busy, keeping up with it is hard and 
> time
> consuming and that leads to lots of IRC discussions. I don't think there's
> anything wrong with that but I believe it's wrong to expect *EVERYONE* to
> be in the IRC channel when those discussions happen.
> 
> If you are discussing something on IRC that requires the attention of most of
> your project's community, I highly recommend you to use the mailing list as
> oppose to pinging everyone independently and fighting with time zones.
> Using IRC bouncers as a replacement for something that should go to the
> mailing list is absurd. Please, use the mailing list and don't be afraid of 
> having
> a bigger community chiming in in your discussion.  *THAT'S A GOOD THING*
> 
> Changes, specs, APIs, etc. Everything is good for the mailing list.
> We've fought hard to make this community grow, why shouldn't we take
> advantage of it?

This is tough call ... ~ real time communication is just so much more 
efficient. You can get things done in minutes that would take hours & days to 
deal with over e-mail. It also does not help that the -dev mailing list is 
really crowded, the tags are not consistent (sorry for finger pointing but oslo 
seems to be specially inconsistent with some tagging [oslo] some tagging 
[oslo.something] etc. Please keep that [oslo] there ;D ).

I would not discourage people to use irc or other communication means, just 
being prepared to answer those questions again.
> 
> ## Cores are *NOT* special
> 
> At some point, for some reason that is unknown to me, this message
> changed and the feeling of core's being some kind of superheros became a
> thing. It's gotten far enough to the point that I've came to know that some
> projects even have private (flagged with +s), password protected, irc
> channels for core reviewers.
> 
> This is the point where my good faith assumption skill falls short.
> Seriously, don't get me wrong but: WHAT IN THE ACTUAL F**K?
> 
> THERE IS ABSOLUTELY NOTHING PRIVATE FOR CORE REVIEWERS*
> TO DISCUSS.

Here I do disagree. There is stuff called private bugs for security etc. that 
_should_ kept private. Again speeds up progress hugely when the discussion does 
not need to happen in Launchpad and it keeps the bug itself cleaner as well. I 
do agree that there should not be secret society making common decisions behind 
closed doors, but there is reasons to keep some details initially between 
closed group only. And most commonly that closed group seems to be cores.
> 
> If anything core reviewers should be the ones *FORCING* - it seems that
> *encou

Re: [openstack-dev] [all][tc] Lets keep our community open, lets fight for it

[Kuvaja, Erno]

> -Original Message-
> From: Donald Stufft [mailto:don...@stufft.io]
> Sent: Wednesday, February 11, 2015 4:34 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [all][tc] Lets keep our community open, lets
> fight for it
> 
> 
> > On Feb 11, 2015, at 11:15 AM, Jeremy Stanley  wrote:
> >
> > On 2015-02-11 11:31:13 + (+), Kuvaja, Erno wrote:
> > [...]
> >> If you don't belong to the group of privileged living in the area and
> >> receiving free ticket somehow or company paying your participation
> >> you're not included. $600 + travel + accommodation is quite hefty
> >> premium to be included, not really FOSS.
> > [...]
> >
> > Here I have to respectfully disagree. Anyone who uploads a change to
> > an official OpenStack source code repository for review and has it
> > approved/merged since Juno release day gets a 100% discount comp
> > voucher for the full conference and design summit coming up in May.
> > In addition, much like a lot of other large free software projects do
> > for their conferences, the OpenStack Foundation sets aside funding[1]
> > to cover travel and lodging for participants who need it.
> > Let's (continue to) make sure this _is_ "really FOSS," and that any of
> > our contributors who want to be involved can be involved.
> >
> > [1] https://wiki.openstack.org/wiki/Travel_Support_Program
> 
> For whatever it's worth, I totally agree that the summits don't make
> Openstack "not really FOSS" and I think the travel program is great, but I do
> just want to point out (as someone for whom travel is not monetarily dificult,
> but
> logistically) that decision making which requires travel can be exclusive. I
> don't personally get too bothered by it but it feels like maybe the
> fundamental issue that some are expericing is when there are decisions
> being made via a single channel, regardless of if that channel is a phone 
> call,
> IRC, a mailing list, or a design summit. The more channels any particular
> decision involves the more likely it is nobody is going to feel like they 
> didn't
> get a chance to participate.
> 
> ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

Thanks Donald,

My point exactly even I now see it did not come out really that way.

Thanks Jeremy,

I'd like to point out that that this discussion has been pushing all inclusive 
open approach. Not ATC, not specially approved individuals, but everyone. 
Mailing list can easily facilitate participation of everyone who wishes to do 
so. Summits cannot. If we pull the line to ATCs and specially invited 
individuals, we can throw this whole topic to the trash as 90% of the discussed 
was just dismissed.

All,

I'm not attacking against having summits, I think the face to face time is 
incredibly valuable for all kind of things. My point was to bring up general 
flaw of the flow between all inclusive decision making vs. decided in summit 
session.

- Erno

> 
> 
> __
> 
> 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] [glance] Cleanout of inactive change proposals from review

[Kuvaja, Erno]

Hi all,

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.

The documentation can be found from 
https://etherpad.openstack.org/p/glance-cleanout-of-inactive-PS and any input 
would be appreciated. For your convenience current state below:

Glance - Cleanout of inactive change proposals from review


We Should start cleaning out our review list to keep the focus on changes that 
has momentum. Nova is currently abandoning change proposals that has been 
inactive for 4 weeks.

Proposed action (if all of the following is True, abandon the PS):

  1.  The PS has -1/-2 (including Jenkins)

  1.  The change is proposed to glance, glance_store or python-glanceclient; 
specs should not be abandoned as their workflow is much slower

  1.  No activity for 28 days from Author/Owner after the -1/-2

  1.  There has been  query made to the owner to update the patch between 5 and 
10 days  before abandoning (comment on PS/Bug or something similar)


  *   Let's be smart on this. Flexibility is good on holiday seasons, during 
feature freeze, etc.




-  Erno
__
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

[Kuvaja, Erno]

Hi Boris,

Thanks for your input. I do like the idea of picking up the changes that have 
not been active. Do you have resources in mind to dedicate for this?

My personal take is that if some piece of work has not been touched for a 
month, it’s probably not that important after all and the community should use 
the resources to do some work that has actual momentum. The changes itself will 
not disappear the owner is still able to revive it if felt that there is right 
time to continue it. The cleanup will just make it easier for people to focus 
on things that are actually moving. It also will make bug tracking bit easier 
when one will see on the bug report that the patch got abandoned due to 
inactivity and indicates that the owner of that bug might not be working on it 
after all.


-  Erno

From: Boris Pavlovic [mailto:bpavlo...@mirantis.com]
Sent: Friday, February 13, 2015 1:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] Cleanout of inactive change proposals 
from review

Hi,

I believe that keeping review queue clean is the great idea.
But I am not sure that set of these rules is enough to abandon patches.

Recently I wrote blogpost related to making OpenStack community more user 
friendly:
http://boris-42.me/thoughts-on-making-openstack-community-more-user-friendly/

tl;dr;

Patches on review are great source of information what is missing in project.
Removing them from queue means losing this essential information. The result
of such actions is that project doesn't face users requirements which is quite 
bad...

What if that project team continue work on all "abandoned" patches  that are 
covering
valid use cases and finish them?

Best regards,
Boris Pavlovic



On Fri, Feb 13, 2015 at 3:52 PM, Flavio Percoco 
mailto:fla...@redhat.com>> wrote:
On 13/02/15 11:06 +, Kuvaja, Erno wrote:
Hi all,

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.

The documentation can be found from https://etherpad.openstack.org/p/
glance-cleanout-of-inactive-PS and any input would be appreciated. For your
convenience current state below:

Thanks for putting this together. I missed the meeting yday and this
is important.
Glance - Cleanout of inactive change proposals from review


We Should start cleaning out our review list to keep the focus on changes that
has momentum. Nova is currently abandoning change proposals that has been
inactive for 4 weeks.



Proposed action (if all of the following is True, abandon the PS):

1. The PS has -1/-2 (including Jenkins)

I assume you're talking about voting -1/-2 and not Workflow, right?
(you said jenkins afterall but just for the sake of clarity).
2. The change is proposed to glance, glance_store or python-glanceclient;
   specs should not be abandoned as their workflow is much slower

3. No activity for 28 days from Author/Owner after the -1/-2

I'd reword this in "No activity". This includes comments, feedback,
discussions and or other committers taking over a patch.
4. There has been  query made to the owner to update the patch between 5 and
   10 days  before abandoning (comment on PS/Bug or something similar)

 ● Let's be smart on this. Flexibility is good on holiday seasons, during
   feature freeze, etc.

+2 to the above, I like it.

Thanks again,
Flavio

--
@flaper87
Flavio Percoco

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://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] [glance] Cleanout of inactive change proposals from review

[Kuvaja, Erno]

Hi,

Getting so mixed that I’ll jump to the inline commenting as well.

From: Boris Pavlovic [mailto:bo...@pavlovic.me]
Sent: 13 February 2015 15:01
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] Cleanout of inactive change proposals 
from review

Erno,


My personal take is that if some piece of work has not been touched for a 
month, it’s probably not that important after all and the community should use 
the resources to do some work that has actual momentum.

Based on my experience, one of the most common situation in OpenStack is next:
1) Somebody makes fast (but with right idea) changes, because he (and usually 
others) needs it
2) It doesn't pass review process fast
3) Author of this patch has billions others tasks (not related to upstream) and
can't work on this change anymore
4) Patch get's abounded and forgotten

I’m unfortunately starting to sound like a broken record but again. If no-one 
has touched the change (or taken it over) in 4 weeks at the point when there is 
clear indication that if the change does not get traction it will be cleaned 
from the review, it’s probably not worth of keeping there any longer either.

The changes itself will not disappear the owner is still able to revive it if 
felt that there is right time to continue it.

Nobody never reviews abounded changes..

Repeating the previous, if your change gets abandoned because of inactivity and 
you don’t care about it, why should someone else who haven’t cared so far?

 The cleanup will just make it easier for people to focus on things that are 
actually moving.

Making decision based on activity around patches is not the best way to do 
things.

So what would be better way to do it? We have currently 4 pages of change 
proposals in the review that has been touched by anyone in Feb. Honest 
question, who scrolls further than that or even down to that 4th page? From 
page 6 forward there are changes that has been last time touched last year. And 
this is purely from “updated” column, so I did not look when the 
owner/author/committer has last time touched these.

If we take a look at the structure of OpenStack projects we will see next 
things:

1) Things that re moving fast/good are usually related to things that core team 
(or active members) are working on.
This team is resolving limited set of use cases (this is mostly related because 
not every member is running it's own production cloud)

This is very true, dropping that core team away and let’s keep the active 
members here. Because it’s a community it’s extremely difficult to get people 
working on something else than what they or their employers sees important.

2) Operators/Admins/DevOps that are running their own cloud have a lot of 
experience knows a lot of missing use cases and
source of issues. But usually they are not involved in community process so 
they don't know whole road map of project, so they are not able to fully align 
their patches with road map, or eventually just don't have enough time to work 
on features.

So abounding patches from 2 group just because of inactivity can make big harm 
to project.

I don’t think pushing for activity is bad thing and would do big harm for 
project(s). These are matters of priority and I do not see any benefit keeping 
changes in review that haven’t been touched for months (current situation). If 
this group 2 is the fundamental issue of our changes stalling in review, we 
need to fix that rather than let it clutter the queue. We are talking open 
source project and community here. I find it extremely hard to justify asking 
anyone in the community to take responsibility of someone else’s production 
cloud if they have no interest to resource the above for the benefit of their 
own business.

 Do you have resources in mind to dedicate for this?

Sometimes I am doing it by my self, sometimes newbies in community (that want 
some work to get involved), sometimes core team is working on old patches.

We will not run out of the bug fixing work and the commits against those bugs 
will stay in the bug even after they get abandoned.

Important chagesets are supposed to have bugs (or blueprints) assigned
to them, so, even if the CS is abandoned, its description still
remains on Launchpad in one form or another, so we will not loose it
from general project's backlog

This is not true in a lot of cases. =)
 In many cases DevOps/Operators don't know or don't want to spend time for 
launchpad/specs/ and so on.

Then we need to educate and encourage them instead of support the behavior of 
“Throw it in and someone at some day will maybe take care of it”-attitude.


-  Erno

Best regards,
Boris Pavlovic


On Fri, Feb 13, 2015 at 5:17 PM, Kuvaja, Erno 
mailto:kuv...@hp.com>> wrote:
Hi Boris,

Thanks for your input. I do like the idea of picking up the changes that have 
not been active. Do you have resour

Re: [openstack-dev] [glance] Cleanout of inactive change proposals from review

[Kuvaja, Erno]

> -Original Message-
> From: James E. Blair [mailto:cor...@inaugust.com]
> Sent: 13 February 2015 16:44
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [glance] Cleanout of inactive change proposals
> from review
> 
> "Kuvaja, Erno"  writes:
> 
> > Hi all,
> >
> > 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.
> 
> Hi,
> 
> 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.
> 
> -Jim

Hi Jim,

I think you hit spot on here. It's extremely difficult to automate anything 
like this being smart and flexible. ;)

- Erno
> 
> __
> 
> 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] The root-cause for IRC private channels (was Re: [all][tc] Lets keep our community open, lets fight for it)

[Kuvaja, Erno]

> -Original Message-
> From: Clark Boylan [mailto:cboy...@sapwetik.org]
> Sent: Tuesday, February 17, 2015 6:06 PM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] The root-cause for IRC private channels (was
> Re: [all][tc] Lets keep our community open, lets fight for it)
> 
> On Tue, Feb 17, 2015, at 09:32 AM, Stefano Maffulli wrote:
> > Changing the subject since Flavio's call for openness was broader than
> > just private IRC channels.
> >
> > On Tue, 2015-02-17 at 10:37 +, Daniel P. Berrange wrote:
> > > If cases of bad community behaviour, such as use of passwd protected
> > > IRC channels, are always primarily dealt with via further private
> > > communications, then we are denying the voters the information they
> > > need to hold people to account. I can understand the desire to avoid
> > > publically shaming people right away, because the accusations may be
> > > false, or may be arising from a simple mis-understanding, but at
> > > some point genuine issues like this need to be public. Without this
> > > we make it difficult for contributors to make an informed decision
> > > at future elections.
> >
> > You got my intention right: I wanted to understand better what lead
> > some people to create a private channel, what were their needs. For
> > that objective, having an accusatory tone won't go anywhere and
> > instead I needed to provide them a safe place to discuss and then I
> > would report back in the open.
> >
> > So far, I've only received comments in private from only one person,
> > concerned about public logging of channels without notification. I
> > wished the people hanging out on at least one of such private channels
> > would provide more insights on their choice but so far they have not.
> >
> > Regarding the "why" at least one person told me they prefer not to use
> > official openstack IRC channels because there is no notification if a
> > channel is being publicly logged. Together with freenode not
> > obfuscating host names, and eavesdrop logs available to any spammer,
> > one person at least is concerned that private information may leak.
> > There may also be legal implications in Europe, under the Data
> > Protection Directive, since IP addresses and hostnames can be
> > considered sensitive data. Not to mention the casual dropping of
> > emails or phone numbers in public+logged channels.
> >
> > I think these points are worth discussing. One easy fix this person
> > suggests is to make it default that all channels are logged and write
> > a warning on wiki/IRC page. Another is to make the channel bot
> > announce whether the channel is logged. Cleaning up the hostname
> > details on join/parts from eavesdrop and put the logs behind a login
> > (to hide them from spam harvesters).
> >
> > Thoughts?
> >
> It is worth noting that just about everything else is logged too. Git repos 
> track
> changes individuals have made, this mailing list post will be publicly 
> available,
> and so on. At the very least I think the assumption should be that any
> openstack IRC channel is logged and since assumptions are bad we should be
> explicit about this. I don't think this means we require all channels 
> actually be
> logged, just advertise than many are and any can be (because really any
> individual with freenode access can set up public logging).
> 
> I don't think we should need to explicitly cleanup our logs. Mostly because
> any individual can set up public logs that are not sanitized.
> Instead IRC users should use tools like cloaks or Tor to get the level of
> obfuscation and security that they desire. Freenode has docs for both, see
> https://freenode.net/faq.shtml#cloaks and
> https://freenode.net/irc_servers.shtml#tor
> 
> Hope this helps,
> Clark

Hi Clark,

Sorry to say, but the above is totally irrelevant regarding the current 
legislation.
The legal system does not care individual assumptions like "everybody should 
know we are breaking law here". What comes to individuals setting up such 
services, the responsibility of those records are on that individual and that 
individual could potentially get off the hook quite easy by claiming not 
knowing. What comes to OpenStack Foundation doing such activity, one could 
argue how far that "but we did not know"-attitude carries in court.

[1] The Directive is based on the 1980 OECD "Recommendations of the Council 
Concerning guidelines Governing the Protection of Privacy and Trans-Border 
Flows of Personal Data."

These recommendations are founded on seven principles, since enshrined in EU 
Directive 94/46/EC:

Notice: subjects whose data is being collected should be given notice of 
such collection.
Purpose: data collected should be used only for stated purpose(s) and for 
no other purposes.
Consent: personal data should not be disclosed or shared with third parties 
without consent from its subject(s).
Security: once collected, personal data should be kept safe and secure f

Re: [openstack-dev] [api][all][log] - Openstack.error common library

[Kuvaja, Erno]

Hi Eugeniya,

Please have a look on the discussion under tag [log]. We’ve been discussing 
around this topic (bit wider, not limiting to API errors) quite regular since 
Paris Summit and we should have X-project specs for review quite soon after the 
Ops meetup. The workgroup meetings will start as well.

Obviously at this point the implementation is open for discussion but so far 
there has been push to implement the tracking into the project trees rather 
than consolidating it under one location.

Could you elaborate bit what you want to have in the headers and why? Our plan 
has been so far having the error code in the message payload so that it’s 
easily available for users and operators.  What this library you’re proposing 
would be actually doing?

We’re more than happy to take extra hands on this so please follow up the [log] 
discussion and feel free to contact me (IRC: jokke_) or Rockyg (in cc as well)  
around what has been done and planned in case you need more clarification.


-  Erno
From: Eugeniya Kudryashova [mailto:ekudryash...@mirantis.com]
Sent: 25 February 2015 14:33
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [api][all] - Openstack.error common library


Hi, stackers!


As was suggested in topic [1], using an HTTP header was a good solution for 
communicating common/standardized OpenStack API error codes.

So I’d like to begin working on a common library, which will collect all 
openstack HTTP API errors, and assign them string error codes. My suggested 
name for library is openstack.error, but please feel free to propose something 
different.


The other question is where we should allocate such project, in openstack or 
stackforge, or maybe oslo-incubator? I think such project will be too massive 
(due to dealing with lots and lots of exceptions)  to allocate it as a part of 
oslo, so I propose developing the project on Stackforge and then eventually 
have it moved into the openstack/ code namespace when the other projects begin 
using the library.


Let me know your feedback, please!


[1] - 
http://lists.openstack.org/pipermail/openstack-dev/2015-January/055549.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] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])

[Kuvaja, Erno]

> -Original Message-
> From: Thierry Carrez [mailto:thie...@openstack.org]
> Sent: 03 March 2015 10:00
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] auto-abandon changesets considered harmful
> (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])
> 
> Doug Wiegley wrote:
> > [...]
> > But I think some of the push back in this thread is challenging this notion
> that abandoning is negative, which you seem to be treating as a given.
> >
> > I don't. At all. And I don't think I'm alone.
> 
> I was initially on your side: the "abandoned" patches are not really deleted,
> you can easily restore them. So "abandoned" could just mean "inactive" or
> "stale" in our workflow, and people who actually care can easily "unabandon"
> them to make them active again. And since "abandoning" is currently the
> only way to permanently get rid of stale / -2ed / undesirable changes
> anyway, so we should just use that.
> 
> But words matter, especially for new contributors. For those contributors,
> someone else "abandoning" a proposed patch of theirs is a pretty strong
> move. To them, abandoning should be their decision, not yours (reviewers
> can -2 patches).
> 
> Launchpad used to have a similar struggle between real meaning and
> workflow meaning. It used to have a single status for rejected bugs
> ("Invalid"). In the regular bug workflow, that status would be used for valid
> bugs that you just don't want to fix. But then that created confusion to
> people outside that workflow since the wrong word was used.
> So "WontFix" was introduced as a similar "closed" state (and then they added
> "Opinion" because "WontFix" seemed too harsh, but that's another story).
> 
> We have (like always) tension around the precise words we use. You say
> "Abandon" is generally used in our community to "set inactive". Jim says
> "Abandon" should mean abandon and therefore should probably be left to
> the proposer, and other ways should be used to "set inactive".
> 
> There are multiple solutions to this naming issue. You can rename "abandon"
> so that it actually means "set inactive" or "mark as stale".
> 
> Or you can restrict "abandon" to the owner of a change, stop defaulting to
> "is:open" to list changes, and introduce features in Gerrit so that a 
> "is:active"
> query would give you the right thing. But that query would need to be the
> Gerrit default, not some obscure query you can run or add to your dashboard
> -- otherwise we are back at step 1.
> 
> --
> Thierry Carrez (ttx)
> 

I'd like to ask few questions regarding this as I'm very much pro cleaning the 
review queues of abandoned stuff.

How often people (committer/owner/_reviewer_) abandon changes actively? Now I 
do not mean the reviewer here only cores marking other peoples abandoned PSs as 
abandoned I mean how many times you have seen person stating that (s)he will 
not review a change anymore? I haven't seen that, but I've seen lots of changes 
where person has reviewed it on some early stage and 10 revisions later still 
not given ones input again. What I'm trying to say here is that it does not 
make the change any less abandoned if it's not marked abandoned by the owner. 
It's rarely active process.

Regarding the contributor experience, I'd say it's way more harmful not to mark 
abandoned changes abandoned than do so. If the person really don't know and 
can't figure out how to a) join the mailing list b) get to irc c) write a 
comment to the change or d) reach out anyone in the project in any other means 
to express that (s)he does not know how to fix the issue flagged in weeks, I'm 
not sure if we will miss that person as a contributor so much either? And yes, 
the message should be strong telling that the change has passed the point it 
most probably will have no traction anymore and active action needs to be taken 
to continue the workflow. Same time lets turn this around. How many new 
contributors we drive away because of the reaction "Whoa, this many changes 
have been sitting here for weeks, I have no chance to get my change quickly in"?

Specifically to Nova, Swift & Cinder folks:
How much do you see benefit on bug lifecycle management with the abandoning? I 
would assume bugs that has message their proposed fix abandoned getting way 
more traction than the ones where the fix has been stale in queue for weeks. 
And how many of those abandoned ones gets reactivated?

Last I'd like to point out that life is full of disappointments. We should not 
try to keep our community in bubble where no-one ever gets disappointed nor 
their feelings never gets hurt. I do not appreciate that approach on current 
trend of raising children and I definitely do not appreciate that approach 
towards adults. Perhaps the people with "bad experience" will learn something 
and get over it or move on. Neither is bad for the community.

- Erno

__
OpenStack Develo

Re: [openstack-dev] [Glance] Core nominations.

[Kuvaja, Erno]

Nikhil,

If I recall correctly this matter was discussed last time at the start of the 
L-cycle and at that time we agreed to see if there is change of pattern to 
later of the cycle. There has not been one and I do not see reason to postpone 
this again, just for the courtesy of it in the hopes some of our older cores 
happens to make review or two.

I think Flavio's proposal combined with the new members would be the right way 
to reinforce to momentum we've gained in Glance over past few months. I think 
it's also the right message to send out for the new cores (including you and 
myself ;) ) that activity is the key to maintain such status.


-  Erno

From: Nikhil Komawar [mailto:nikhil.koma...@rackspace.com]
Sent: 03 March 2015 04:47
To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage 
questions)
Cc: krag...@gmail.com
Subject: Re: [openstack-dev] [Glance] Core nominations.


Hi all,



After having thoroughly thought about the proposed rotation and evaluating the 
pros and cons of the same at this point of time, I would like to make an 
alternate proposal.



New Proposal:

  1.  We should go ahead with adding more core members now.
  2.  Come up with a plan and give additional notice for the rotation. Get it 
implemented one month into Liberty.

Reasoning:



Traditionally, Glance program did not implement rotation. This was probably 
with good reason as the program was small and the developers were working 
closely together and were aware of each others' daily activities. If we go 
ahead with this rotation it would be implemented for the first time and would 
appear to have happened out-of-the-blue.



It would be good for us to make a modest attempt at maintaining the friendly 
nature of the Glance development team, give them additional notice and 
preferably send them a common email informing the same. We should propose at 
least a tentative plan for rotation so that all the other core members are 
aware of their responsibilities. This brings to my questions, is the poposed 
list for rotation comprehensive? What is the basis for missing out some of 
them? What would be a fair policy or some level of determinism in expectations? 
I believe that we should have input from the general Glance community (and the 
OpenStack community too) for the same.



In order for all this to be sorted out, I kindly request all the members to 
wait until after the k3 freeze, preferably until a time at which people would 
have a bit more time in their hand to look at their mailboxes for unexpected 
proposals of rotation. Once a decent proposal is set, we can announce the 
change-in-dynamics of the Glance program and get everyone interested familiar 
with it during the summit. Whereas, we should not block the currently active 
to-be-core members from doing great work. Hence, we should go ahead with adding 
them to the list.



I hope that made sense. If you've specific concerns, I'm free to chat on IRC as 
well.



(otherwise) Thoughts?


Cheers,
-Nikhil

From: Alexander Tivelkov mailto:ativel...@mirantis.com>>
Sent: Tuesday, February 24, 2015 7:26 AM
To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage 
questions)
Cc: krag...@gmail.com
Subject: Re: [openstack-dev] [Glance] Core nominations.

+1 on both proposals: rotation is definitely a step in right direction.



--
Regards,
Alexander Tivelkov

On Tue, Feb 24, 2015 at 1:19 PM, Daniel P. Berrange 
mailto:berra...@redhat.com>> wrote:
On Tue, Feb 24, 2015 at 10:47:18AM +0100, Flavio Percoco wrote:
> On 24/02/15 08:57 +0100, Flavio Percoco wrote:
> >On 24/02/15 04:38 +, Nikhil Komawar wrote:
> >>Hi all,
> >>
> >>I would like to propose the following members to become part of the Glance 
> >>core
> >>team:
> >>
> >>Ian Cordasco
> >>Louis Taylor
> >>Mike Fedosin
> >>Hemanth Makkapati
> >
> >Please, yes!
>
> Actually - I hope this doesn't come out harsh - I'd really like to
> stop adding new cores until we clean up our current glance-core list.
> This has *nothing* to do with the 4 proposals mentioned above, they
> ALL have been doing an AMAZING work.
>
> However, I really think we need to start cleaning up our core's list
> and this sounds like a good chance to make these changes. I'd like to
> propose the removal of the following people from Glance core:
>
> - Brian Lamar
> - Brian Waldon
> - Mark Washenberger
> - Arnaud Legendre
> - Iccha Sethi
> - Eoghan Glynn
> - Dan Prince
> - John Bresnahan
>
> None of the folks in the above list have neither provided reviews nor
> have they participated in Glance discussions, meetings or summit
> sessions. These are just signs that their focus have changed.
>
> While I appreciate their huge efforts in the past, I think it's time
> for us to move forward.
>
> It goes without saying that all of the folks above are more than
> welcome to join the glance-core team again if their focus goes back to
> Glance.
Yep, rotating out

Re: [openstack-dev] auto-abandon changesets considered harmful (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])

[Kuvaja, Erno]

From: John Griffith [mailto:john.griffi...@gmail.com]
Sent: 03 March 2015 14:46
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] auto-abandon changesets considered harmful (was 
Re: [stable][all] Revisiting the 6 month release cycle [metrics])



On Tue, Mar 3, 2015 at 7:18 AM, Kuvaja, Erno 
mailto:kuv...@hp.com>> wrote:
> -Original Message-
> From: Thierry Carrez 
> [mailto:thie...@openstack.org<mailto:thie...@openstack.org>]
> Sent: 03 March 2015 10:00
> To: 
> openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] auto-abandon changesets considered harmful
> (was Re: [stable][all] Revisiting the 6 month release cycle [metrics])
>
> Doug Wiegley wrote:
> > [...]
> > But I think some of the push back in this thread is challenging this notion
> that abandoning is negative, which you seem to be treating as a given.
> >
> > I don't. At all. And I don't think I'm alone.
>
> I was initially on your side: the "abandoned" patches are not really deleted,
> you can easily restore them. So "abandoned" could just mean "inactive" or
> "stale" in our workflow, and people who actually care can easily "unabandon"
> them to make them active again. And since "abandoning" is currently the
> only way to permanently get rid of stale / -2ed / undesirable changes
> anyway, so we should just use that.
>
> But words matter, especially for new contributors. For those contributors,
> someone else "abandoning" a proposed patch of theirs is a pretty strong
> move. To them, abandoning should be their decision, not yours (reviewers
> can -2 patches).
>
> Launchpad used to have a similar struggle between real meaning and
> workflow meaning. It used to have a single status for rejected bugs
> ("Invalid"). In the regular bug workflow, that status would be used for valid
> bugs that you just don't want to fix. But then that created confusion to
> people outside that workflow since the wrong word was used.
> So "WontFix" was introduced as a similar "closed" state (and then they added
> "Opinion" because "WontFix" seemed too harsh, but that's another story).
>
> We have (like always) tension around the precise words we use. You say
> "Abandon" is generally used in our community to "set inactive". Jim says
> "Abandon" should mean abandon and therefore should probably be left to
> the proposer, and other ways should be used to "set inactive".
>
> There are multiple solutions to this naming issue. You can rename "abandon"
> so that it actually means "set inactive" or "mark as stale".
>
> Or you can restrict "abandon" to the owner of a change, stop defaulting to
> "is:open" to list changes, and introduce features in Gerrit so that a 
> "is:active"
> query would give you the right thing. But that query would need to be the
> Gerrit default, not some obscure query you can run or add to your dashboard
> -- otherwise we are back at step 1.
>
> --
> Thierry Carrez (ttx)
>
I'd like to ask few questions regarding this as I'm very much pro cleaning the 
review queues of abandoned stuff.

How often people (committer/owner/_reviewer_) abandon changes actively? Now I 
do not mean the reviewer here only cores marking other peoples abandoned PSs as 
abandoned I mean how many times you have seen person stating that (s)he will 
not review a change anymore? I haven't seen that, but I've seen lots of changes 
where person has reviewed it on some early stage and 10 revisions later still 
not given ones input again. What I'm trying to say here is that it does not 
make the change any less abandoned if it's not marked abandoned by the owner. 
It's rarely active process.

Regarding the contributor experience, I'd say it's way more harmful not to mark 
abandoned changes abandoned than do so. If the person really don't know and 
can't figure out how to a) join the mailing list b) get to irc c) write a 
comment to the change or d) reach out anyone in the project in any other means 
to express that (s)he does not know how to fix the issue flagged in weeks, I'm 
not sure if we will miss that person as a contributor so much either? And yes, 
the message should be strong telling that the change has passed the point it 
most probably will have no traction anymore and active action needs to be taken 
to continue the workflow. Same time lets turn this around. How many new 
contributors we drive away because of the reaction "Whoa, this many changes 
have been sitting here for wee

Re: [openstack-dev] [Glance] Core nominations.

[Kuvaja, Erno]

> From: Nikhil Komawar [mailto:nikhil.koma...@rackspace.com] 
> Sent: Tuesday, March 03, 2015 4:10 PM
> To: OpenStack Development Mailing List (not for usage questions); Daniel P. 
> Berrange
> Cc: krag...@gmail.com
> Subject: Re: [openstack-dev] [Glance] Core nominations.
>
> If it was not clear in my previous message, I would like to again emphasize 
> that I truly appreciate the vigor and intent behind Flavio's proposal. We 
> need to be proactive and keep making the community better in such regards.
>
> However, at the same time we need to act fairly, with patience and have a 
> friendly strategy for doing the same (thus maintaining a good balance in our 
> progress). I should probably respond to another thread on ML mentioning my 
> opinion that the community's success depends on "trust" and "empathy" and 
> everyone's intent as well as effort in maintaining these principles. Without 
> them, it will not take very long to make the situation chaotic.



> Hence, I think coming with a good plan during the feature freeze period 
> including when and how are we going to implement it, when would be a final 
> draft of cores to be rotated be published, etc. questions would be answered 
> with _patience_ and input from other cores. We would have a plan in K so, 
> that WOULD be a step forward as discussed in the beginning and be implemented 
> in L, ensuring out empathetic stand.  

> The essence of the matter is:
> We need to change the dynamics slowly and with patience for maintaining a 
> good balance.

Based on the above I must vote -- for adding 4 new cores without doing the 
housekeeping. To maintain good balance one needs to achieve that first and I do 
not see how the proposal is slow and patient towards that goal.

- Erno

> Best,
> -Nikhil


__
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] [all][log] Log Working Group priorities

[Kuvaja, Erno]

Hi all,

We had our first logging workgroup meeting [1] yesterday where we agreed 3 main 
priorities for the group to focus on. Please review and provide your feedback:


1)  Educating the community About the Logging Guidelines spec

a.   
http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html

b.  Please familiarize yourself with it and try to follow the pointers, fix 
where you see your project being off from these.

c.   If this is the first time you see this spec and you think there is 
something awfully off, please let us know.

2)  Cross project specs for Request IDs and Error codes

a.   There is a spec proposals in Cinder tree [2] for Request IDs and in 
Glance tree [3] for Error codes

b.  The cross project specs are being written on the basis of these specs 
adjusted with the feedback and ideas collected from wider audience at and since 
Paris Summit

c.   Links for the specs will be provided as soon as they are available for 
review

3)  Project Liaisons for Log Working Group [4]

a.   Person helping us out to implement the work items in the project

b.  No need to be core

c.   Please, no fighting for the slots. We happily take all available hands 
onboard on this. :)

[1] http://eavesdrop.openstack.org/meetings/log_wg/2015/
[2] https://review.openstack.org/#/c/156508/
[3] https://review.openstack.org/#/c/127482
[4] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Logging_Working_Group



Thanks,

Erno
__
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] [log] Log working group -- Alternate moderator needed for today

[Kuvaja, Erno]

You mean for tomorrow? No worries, I can kick off the meeting and run through 
agenda if we have something to address.

Take best out of the ops meetup!


-  Erno

From: Rochelle Grober [mailto:rochelle.gro...@huawei.com]
Sent: Tuesday, March 10, 2015 4:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [log] Log working group -- Alternate moderator needed 
for today

Or Cancellation.  I'm in the Ops Midcycle meeting and can't guarantee I can 
join.

Meeting meets Wednesdays at 20:00UTC, which is now 11am PDT.

--Rocky
__
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.

[Kuvaja, Erno]

I'd prefer 1400 as well. But "A Foolish Consistency is the Hobgoblin of Little 
Minds"

- Erno

> -Original Message-
> From: Nikhil Komawar [mailto:nikhil.koma...@rackspace.com]
> Sent: 11 March 2015 20:40
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Glance] Proposal to change Glance meeting
> time.
> 
> I'd prefer to go with 1400 UTC unless there's a majority for 1500UTC.
> 
> P.S. It's my feeling that ML announcements and conversations are not
> effective when taking poll from wider audience so we'd discuss this a bit
> more in the next meeting and merge the votes.
> 
> Thanks,
> -Nikhil
> 
> 
> From: Louis Taylor 
> Sent: Wednesday, March 11, 2015 10:34 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: 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.
> 
> __
> 
> 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] [Glance] Nitpicking in code reviews

[Kuvaja, Erno]

Hi all,

Following the code reviews lately I've noticed that we (the fan club seems to 
be growing on weekly basis) have been growing culture of nitpicking [1] and 
bikeshedding [2][3] over almost every single change.

Seriously my dear friends, following things are not worth of "-1" vote if even 
a comment:

1)  Minor spelling errors on commit messages (as long as the message comes 
through and flags are not misspelled).

2)  Minor spelling errors on comments (docstrings and documentation is 
there and there, but comments, come-on).

3)  Used syntax that is functional, readable and does not break consistency 
but does not please your poem bowel.

4)  Other things you "just did not realize to check if they were there". 
After you have gone through the whole change go and look your comments again 
and think twice if your concern/question/whatsoever was addressed somewhere 
else than where your first intuition would have dropped it.

We have relatively high volume for glance at the moment and this nitpicking and 
bikeshedding does not help anyone. At best it just tightens nerves and breaks 
our group. Obviously if there is "you had ONE job" kind of situations or there 
is relatively high amount of errors combined with something serious it's 
reasonable to ask fix the typos on the way as well. The reason being need to 
increase your statistics, personal perfectionist nature or actually I do not 
care what; just stop or go and do it somewhere else.

Love and pink ponies,

-  Erno

[1] 
www.urbandictionary.com/define.php?term=nitpicking
[2] http://bikeshed.com
[3] http://en.wiktionary.org/wiki/bikeshedding

__
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