Re: [openstack-dev] [glance] priorities for O-1

[Bashmakov, Alexander]

Please take note of another patch related to the list below:

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

This one updates the existing Community Images spec with implementation details 
and justification for the design decision to make image visibility default to 
'shared'.

Regards,
Alex

-Original Message-
From: Ian Cordasco [mailto:sigmaviru...@gmail.com] 
Sent: Monday, November 14, 2016 9:58 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [glance] priorities for O-1

-Original Message-
From: Brian Rosmaita 
Reply: OpenStack Development Mailing List (not for usage questions) 

Date: November 10, 2016 at 08:32:51
To: OpenStack Development Mailing List (not for usage questions) 

Subject:  [openstack-dev] [glance] priorities for O-1

> Hello Glancers,
>
> O-1 is around the corner (i.e., next week). The priority for Glance is 
> Community Images.
>
> Please review the following patches:
>
> https://review.openstack.org/#/c/369110/
> https://review.openstack.org/#/c/387660/
> https://review.openstack.org/#/c/391968/

Glance reviewers,

Please prioritize reviewing the above patches. These are the highest priority 
items for Ocata-1 and need to merge so we can stabilize them throughout the 
rest of this very short cycle.

I will be proposing a review to openstack/releases to tag Ocata-1. For now, I 
will block the workflow, but on Thursday, I will update it and encourage the 
Release team to move forward with it regardless of whether these have merged or 
not. While these are a priority, as Release Czar I cannot force you to review 
them but I must move forward with our release plans.

Cheers,
--
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] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

[Bashmakov, Alexander]

Hi Jay,

Thanks for the explanation. While I agree that there is a distinction between a 
distributed architecture like Nova and a centralized one like Glance, I would 
respectfully disagree with the statement that Glance cannot participate in 
rolling upgrades in a very similar fashion. We are currently working on a 
rolling upgrade POC in Glance (https://review.openstack.org/331740/). To date, 
we've successfully been able to run through a simple scenario with two Glance 
nodes running Newton and Ocata code base respectively. The latter introduces 
schema changes which are reconciled in the DB via a two-way trigger.

Regards,
Alex

-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com] 
Sent: Friday, October 14, 2016 1:56 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [keystone][nova][neutron][all] Rolling upgrades: 
database triggers and oslo.versionedobjects

Alex, so sorry for the long delayed response! :( This just crept to the back of 
my inbox unfortunately. Answer inline...

On 09/14/2016 07:24 PM, Bashmakov, Alexander wrote:
>> Glance and Keystone do not participate in a rolling upgrade, because 
>> Keystone and Glance do not have a distributed component architecture. 
>> Online data migrations will reduce total downtime experienced during 
>> an *overall upgrade procedure* for an OpenStack cloud, but Nova, 
>> Neutron and Cinder are the only parts of OpenStack that are going to 
>> participate in a rolling upgrade because they are the services that 
>> are distributed across all the many compute nodes.
>
> Hi Jay, I'd like to better understand why your definition of rolling 
> upgrades excludes Glance and Keystone? Granted they don't run multiple 
> disparate components over distributed systems, however, they can still 
> run the same service on multiple distributed nodes. So a rolling 
> upgrade can still be applied on a large cloud that has, for instance 
> 50 Glance nodes.

If you've seen a cloud with 50 Glance nodes, I would be astonished :) That 
said, the number 50 doesn't really have to do with my definition of rolling... 
lemme explain.

The primary thing that, to me at least, differentiates rolling upgrades of 
distributed software is that different nodes can contain multiple versions of 
the software and continue to communicate with other nodes in the system without 
issue.

In the case of Glance, you cannot have different versions of the Glance service 
running simultaneously within an environment, because those Glance services 
each directly interface with the Glance database and therefore expect the 
Glance DB schema to look a particular way for a specific version of the Glance 
service software.

In contrast, Nova's distributed service nodes -- the nova-compute services and 
(mostly) the nova-api services do *not* talk directly to the Nova database. If 
those services need to get or set data in the database, they communicate with 
the nova-conductor services which are responsible for translating (called 
back-versioning) the most updated object model schema that matches the Nova 
database to the schema that the calling node understands. This means that Nova 
deployers can update the Nova database schema and not have to at the same time 
update the software on the distributed compute nodes. In this way deployers can 
"roll out" an upgrade of the Nova software across many hundreds of compute 
nodes over an extended period of time without needing to restart/upgrade 
services all at once.

Hope this clarifies things.

Best,
-jay

p.s. I see various information on the web referring to "rolling updates" 
or "rolling releases" as simply the process of continuously applying new 
versions of software to a deployment. This is decidedly *not* what I refer to 
as a "rolling upgrade". Perhaps we should invent a different term from "rolling 
upgrade" to refer to the attributes involved in being able to run multiple 
versions of distributed software with no impact on the control plane? Is that 
what folks call a "partial upgrade"? Not sure...

  > In this case different versions of the
> same service will run on different nodes simultaneously. Regards, Alex



__
OpenStack Development Mailing 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] Cores using -2 votes

[Bashmakov, Alexander]

These queries might be a good addition to the Glance dashboard in 
https://github.com/openstack/gerrit-dash-creator under the "Patches I -2'd" 
section: 
https://github.com/openstack/gerrit-dash-creator/blob/master/dashboards/glance.dash#L33

> -Original Message-
> From: Ian Cordasco [mailto:sigmaviru...@gmail.com]
> Sent: Friday, September 23, 2016 8:12 AM
> To: Nikhil Komawar ; OpenStack Development
> Mailing List (not for usage questions) 
> Subject: Re: [openstack-dev] [Glance] Cores using -2 votes
> 
> 
> 
> -Original Message-
> From: Nikhil Komawar 
> Reply: Nikhil Komawar 
> Date: September 23, 2016 at 10:04:51
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Cc: Ian Cordasco 
> Subject:  Re: [openstack-dev] [Glance] Cores using -2 votes
> 
> > thanks Ian, this is great info.
> >
> > Just a side question, do you have example for -Workflow , say in cases
> > when I'd +2ed but to keep a check on process and approve after the
> > freeze -W'ed it?
> 
> So the important thing to keep in mind is that: "Code-Review", "Verified",
> and "Workflow" are all labels. And they all have different values (-2, -1, 0, 
> +1,
> +2). So you could absolutely have a search for
> 
>     label:Code-Review=+2, AND label:Workflow=-1, name>
> 
> That could combine with other portions of the queries I wrote in my first
> email. :-)
> 
> Cheers,
> --
> 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] Useful tool for easier viewing of IRC logs online

[Bashmakov, Alexander]

That's a good idea, I was just thinking along the same lines today. It's 
definitely out of the scope of my tool, though. Some targeted filtering could 
be implemented, but it would still be in "offline" mode. If you want it live, 
then perhaps some IRC clients offer that functionality or maybe there is a ZNC 
module for that.

> -Original Message-
> From: Boden Russell [mailto:boden...@gmail.com]
> Sent: Wednesday, September 21, 2016 11:22 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [all] Useful tool for easier viewing of IRC logs
> online
> 
> 
> > Source code is here: https://github.com/abashmak/chrome-irc-filter
> >
> > Comments, suggestions are welcome.
> 
> Nice thanks!
> 
> I've always wanted a tool that could alert me of "missed mentions" when I'm
> offline IRC rather than having to manually parse the IRC logs for those times
> I'm offline. However I'm guessing that falls outside the scope of this tool or
> could be done with some other tool (I haven't investigated yet)?
> 
> __
> 
> OpenStack Development Mailing 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] [all] Useful tool for easier viewing of IRC logs online

[Bashmakov, Alexander]

Hello Stackers,

If you ever find yourself needing to peruse OpenStack IRC logs online 
(http://eavesdrop.openstack.org/irclogs/) and if you use the Chrome browser to 
do it, then the following tool may come in handy:

https://chrome.google.com/webstore/detail/openstack-eavesdrop-irc-f/lcmadadicbflcamibnpplpgdcdahkade

It's a simple extension to filter messages of the type: " has quit" and 
" has joined", which makes the log much more compact and readable.

Source code is here: https://github.com/abashmak/chrome-irc-filter

Comments, suggestions are welcome.
__
OpenStack Development Mailing 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] [keystone][nova][neutron][all] Rolling upgrades: database triggers and oslo.versionedobjects

[Bashmakov, Alexander]

> Glance and Keystone do not participate in a rolling upgrade, because
> Keystone and Glance do not have a distributed component architecture.
> Online data migrations will reduce total downtime experienced during an
> *overall upgrade procedure* for an OpenStack cloud, but Nova, Neutron and
> Cinder are the only parts of OpenStack that are going to participate in a 
> rolling
> upgrade because they are the services that are distributed across all the
> many compute nodes.

Hi Jay,
I'd like to better understand why your definition of rolling upgrades excludes 
Glance and Keystone? Granted they don't run multiple disparate components over 
distributed systems, however, they can still run the same service on multiple 
distributed nodes. So a rolling upgrade can still be applied on a large cloud 
that has, for instance 50 Glance nodes.  In this case different versions of the 
same service will run on different nodes simultaneously.
Regards,
Alex
__
OpenStack Development Mailing 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] [api][doc][neutron] what releases should API reference support?

[Bashmakov, Alexander]

FYI,

A similar discussion was held for an api-ref change in Glance:
https://review.openstack.org/#/c/356693/

On Sep 6, 2016, at 6:39 AM, Andreas Jaeger 
> wrote:

On 2016-09-06 15:30, Ihar Hrachyshka wrote:
Andreas Jaeger > wrote:

On 2016-09-06 15:02, Ihar Hrachyshka wrote:
[...]
Since neutron-lib is branched on stable/* boundary, I feel that it would
be fine to keep one-to-one relationship between neutron and neutron-lib
api-ref branches.

We only publish the api-ref documents from master,

Is it a hard requirement from infra, or just the current state of
affairs? If the latter, we could revisit the approach. If the former, of
course we will accommodate.

It's the current state of affair - and how api-ref was designed AFAIK:
To have one tree,

Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} 
Twitter: jaegerandi
 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
  GF: Felix Imendörffer, Jane Smithard, Graham Norton,
  HRB 21284 (AG Nürnberg)
   GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126


__
OpenStack Development Mailing 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] versioning the api-ref?

[Bashmakov, Alexander]

Any more feedback on this?

> On Aug 18, 2016, at 10:30 AM, Bashmakov, Alexander 
> <alexander.bashma...@intel.com> wrote:
> 
> Concrete example of an api-ref difference between Mitaka and Newton:
> https://review.openstack.org/#/c/356693/1/api-ref/source/v2/images-parameters.yaml
> 
> -Original Message-
> From: Sean Dague [mailto:s...@dague.net] 
> Sent: Thursday, August 18, 2016 10:20 AM
> To: Nikhil Komawar <nik.koma...@gmail.com>; OpenStack Development Mailing 
> List (not for usage questions) <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [all] versioning the api-ref?
> 
>> On 08/18/2016 11:57 AM, Nikhil Komawar wrote:
>> I guess the intent was to indicate the need for indicating the micro 
>> or in case of Glance minor version bump when required.
>> 
>> The API isn't drastically different, there are new and old elements as 
>> shown in the Nova api ref linked.
> 
> Right, so the point is that it should all be describable in a single 
> document. It's like the fact that when you go to python API docs you get 
> things like - https://docs.python.org/2/library/wsgiref.html
> 
> "New in version 2.5."
> 
> Perhaps if there is a concrete example of the expected differences between 
> what would be in the mitaka tree vs. newton tree was can figure out an 
> appropriate way to express that in api-ref.
> 
>-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 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] versioning the api-ref?

[Bashmakov, Alexander]

Concrete example of an api-ref difference between Mitaka and Newton:
https://review.openstack.org/#/c/356693/1/api-ref/source/v2/images-parameters.yaml

-Original Message-
From: Sean Dague [mailto:s...@dague.net] 
Sent: Thursday, August 18, 2016 10:20 AM
To: Nikhil Komawar ; OpenStack Development Mailing List 
(not for usage questions) 
Subject: Re: [openstack-dev] [all] versioning the api-ref?

On 08/18/2016 11:57 AM, Nikhil Komawar wrote:
> I guess the intent was to indicate the need for indicating the micro 
> or in case of Glance minor version bump when required.
> 
> The API isn't drastically different, there are new and old elements as 
> shown in the Nova api ref linked.

Right, so the point is that it should all be describable in a single document. 
It's like the fact that when you go to python API docs you get things like - 
https://docs.python.org/2/library/wsgiref.html

"New in version 2.5."

Perhaps if there is a concrete example of the expected differences between what 
would be in the mitaka tree vs. newton tree was can figure out an appropriate 
way to express that in api-ref.

-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