Re: [openstack-dev] [oslo] Can we stop global requirements update?

On Wed, Apr 19, 2017, at 05:54 AM, Julien Danjou wrote: > Hoy, > > So Gnocchi gate is all broken (agan) because it depends on "pbr" and > some new release of oslo.* depends on pbr!=2.1.0. > > Neither Gnocchi nor Oslo cares about whatever bug there is in pbr 2.1.0 > that got in banished by

Re: [openstack-dev] [all][ptls][tc] help needed filling out project-navigator data

Ideally, as far back as your project goes. That way we will have a complete API history, per release, on the project navigator. This also helps us determine the project age. Thanks! Jimmy Telles Nobrega April 19, 2017 at 9:48 AM Hi Monty, quick question, how

Re: [openstack-dev] [openstack-doc] [dev] Docs team meeting tomorrow

Hey everyone, Just to clarify – that is Thursday the 20th of April, 2100 UTC. Apologies for any confusion – just attempting to get ahead of the game and forgot to remove “today”. See you there, Alex From: Alexandra Settle Reply-To: "OpenStack Development Mailing List

Re: [openstack-dev] Development workflow for bunch of patches

I've always used rebase rather than cherry-pick in this situation. Bonus is that sometimes (if no conflicts) I can do the rebase in gerrit with two clicks rather than locally with a bunch of typing. @kevinbenton, is there a benefit to using cherry-pick rather than rebase? Thanks, Eric Fried

Re: [openstack-dev] [oslo][infra][pbr] Nominating Stephen Finucane for pbr-core

There is no objection in past 7 days, so I added Stephen Finucane as pbr-core group, welecom Stephen ! 2017-04-19 0:01 GMT+08:00 Jeremy Stanley : > On 2017-04-12 08:14:31 -0500 (-0500), Monty Taylor wrote: > [...] > > Recently Stephen Finucane (sfinucan) has stepped up to

Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

I think LABEL is great idea for all the "informative" stuff. In fact if we could somehow abuse LABEL to fill it up after we get packages installed, we could use it for version manifesto. That will make logic around "if version changed" much easier since we'll have easy access to this information

Re: [openstack-dev] [mistral] New CI Job definitions

On Tue, Apr 18, 2017 at 2:10 AM Ренат Ахмеров wrote: > Thanks Brad! > > So kombu gate is now non-apache, right? > > No. It would be running under mod_wsgi. We can make it non-apache if you like. Would be pretty easy to do so. > Thanks > > Renat Akhmerov > @Nokia > >

Re: [openstack-dev] [all][ptls][tc] help needed filling out project-navigator data

Hi Monty, quick question, how far into past releases should we go? Thanks, On Tue, Apr 18, 2017 at 5:06 PM Monty Taylor wrote: > Hey everybody! > > The Foundation is rolling out a new version of the Project Navigator. > One of the things it contains is a section that

Re: [openstack-dev] [oslo] Can we stop global requirements update?

Excerpts from Clark Boylan's message of 2017-04-19 08:10:43 -0700: > On Wed, Apr 19, 2017, at 05:54 AM, Julien Danjou wrote: > > Hoy, > > > > So Gnocchi gate is all broken (agan) because it depends on "pbr" and > > some new release of oslo.* depends on pbr!=2.1.0. > > > > Neither Gnocchi nor

[openstack-dev] [oslo] do we still need non-voting tests for older releases?

I noticed again today that we have some test jobs running for some of the Oslo libraries against old versions of services (e.g., gate-tempest-dsvm-neutron-src-oslo.log-ubuntu-xenial-newton, gate-tempest-dsvm-neutron-src-oslo.log-ubuntu-xenial-ocata, and

[openstack-dev] [All][Elections] Vote Vote Vote in the TC election!

Hello All, We are coming down to the last hours for voting in the TC election. Voting ends until 23:45 April 20th, 2017. Search your gerrit preferred email address[0] for the following subject: Poll: OpenStack Technical Committee (TC) Election - October 2016 Yes, the poll has an inaccurate

Re: [openstack-dev] [TripleO][CI] Bridging the production/CI workflow gap with large periodic CI jobs

More nodes is always better but I don't think we need to push the host cloud to it's absolute limits right away. I have a list of several pain points I expect to find with just 30ish nodes that should keep us busy for a while. I think the optimizations are a good idea though, especially if we

Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

That works for detecting changes in the build system. It does not solve the issue of how to keep containers atomic on end user systems. All images in a k8s deployment should be the same image. This is done by specifying the same tag. When a new update is done, the updated deployment should

Re: [openstack-dev] [oslo] Can we stop global requirements update?

On Wed, Apr 19 2017, Clark Boylan wrote: > I think we know from experience that just stopping (eg reverting to the > situation we had before requirements and constraints) would lead to > sadness. Installations would frequently be impossible due to some > unresolvable error in dependency

Re: [openstack-dev] [TripleO][CI] Bridging the production/CI workflow gap with large periodic CI jobs

TLDR: We have the capacity to do this. One scale job can be absorbed into our existing test infrastructure with minimal impact. On 04/19/2017 07:50 AM, Flavio Percoco wrote: On 18/04/17 14:28 -0400, Emilien Macchi wrote: On Mon, Apr 17, 2017 at 3:52 PM, Justin Kilpatrick

[openstack-dev] [kolla] Demystifying the kolla-kubernetes gate

Hey folks, I am holding a workshop on how the kolla-kubernetes gate operates. If you are interested in this workshop, please sign up here: http://doodle.com/poll/bee7umevf43nwi6y Regards, -steve __ OpenStack Development

Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

K8s cant pull containers based on labels. I think labels are maybe a good way of storing container fingerprints though. Thanks, Kevin From: Britt Houser (bhouser) [bhou...@cisco.com] Sent: Wednesday, April 19, 2017 3:39 AM To: OpenStack Development Mailing List

[openstack-dev] [Taskflow] Current state or the project ?

Hello Guys, I'm Robin a Software developer for a VFX company based in Canada. As the company grow up, we are currently looking into redesigning our internal processes and workflows in a more nodal/graph based approach. Ideally we would like to start from an existing library so we don't

Re: [openstack-dev] [tripleo][release] release-model of tripleo-common

On 04/18/2017 10:29 PM, Steve Baker wrote: On Wed, Apr 19, 2017 at 1:14 PM, Doug Hellmann > wrote: Excerpts from Steve Baker's message of 2017-04-19 13:05:37 +1200: > Other than being consumed as a library, tripleo-common is the

[openstack-dev] [kolla][all] Core mentorship program kickoff

Hello everyone, On todays meeting we officially started mentorship program in Kolla:) If you are core or you are interested in becoming one, please sign up on this etherpad https://etherpad.openstack.org/p/kolla-mentorship-signup Idea is to provide safe environment to ask questions, get

Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

one other thing. checksums also do not relay any information about newer/older'ness. Only that a change happened. From: Britt Houser (bhouser) [bhou...@cisco.com] Sent: Wednesday, April 19, 2017 3:39 AM To: OpenStack Development Mailing List (not for usage

Re: [openstack-dev] [Taskflow] Current state or the project ?

Robin- > Others (with a slightly less bias than I might have, haha) though I > think should chime in on there experiences :) I can tell you we've been using TaskFlow in some fairly nontrivial ways in the PowerVM compute driver [1][2][3] and pypowervm [4], the library that supports it. We've

Re: [openstack-dev] Development workflow for bunch of patches

Sometimes it's possible to avoid the stacking, and instead just rely on Depends-On (usually in those cases where patches touch completely different files). In that way, you won't need to restack on each dependency respin. (But you may want to recheck to get fresh results.) Of course it won't work

Re: [openstack-dev] [tc][elections]questions about one platform vision

I appreciate the remarks. I think we are perhaps looking at early data and discussing two separate things: events versus trends. While I do not doubt K8S has been deployed on OpenStack, I'm looking at how folks are planning to use those two platforms. Is it possible to host one in another,

Re: [openstack-dev] [kolla][all] Core mentorship program kickoff

On Wed, Apr 19, 2017 at 1:22 PM, Michał Jastrzębski wrote: > Hello everyone, > > On todays meeting we officially started mentorship program in Kolla:) > If you are core or you are interested in becoming one, please sign up > on this etherpad > >

Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

So after discussion started here [1] we came up with something like that: 1. Docker build will create "fingerprint" - manifesto of versions saved somewhere (LABEL?) 2. We create new CLI tool kolla-registry for easier management of pushing and versioning 3. kolla-registry will be able to query

Re: [openstack-dev] [Taskflow] Current state or the project ?

Robin De-Lillo wrote: Hello Guys, I'm Robin a Software developer for a VFX company based in Canada. As the company grow up, we are currently looking into redesigning our internal processes and workflows in a more nodal/graph based approach. Ideally we would like to start from an existing

[openstack-dev] [ceilometer]Looking for endpoint where event passed after first time

Hi folks, I am posting some self-defined events to amqp ceilometer exchange notification topic, during the debug session, I find that at the first time, event are arriving at notification bus as the AMQPIncomingMessage, and then handled by EventsNotificationEndpoint() , however, the second

Re: [openstack-dev] Emails for OpenStack R Release Name voting going out - please be patient

All, For those of you haven't received an e-mail, check the inbox you use for Gerrit. You can verify what that is by going to review.openstack.org , click your name, go to settings, the e-mail address is set there. The naming vote and the TC vote e-mails got lost in that inbox for me.

[openstack-dev] [infra] Gerrit maintenance Friday, April 21, 20:00-21:00 UTC

The Infra team will be taking the Gerrit service on review.openstack.org offline briefly between 20:00 and 21:00 UTC this Friday, April 21 to perform some pending renames of Git repositories. We typically also take down the Zuul scheduler for our CI system at the same time to avoid unfortunate

Re: [openstack-dev] Development workflow for bunch of patches

On 04/19/2017 03:11 AM, Sławek Kapłoński wrote: Hello, I have a question about how to deal with bunch of patches which depends one on another. I did patch to neutron (https://review.openstack.org/#/c/449831/) which is not merged yet but I wanted to start also another patch which is depend on

Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

I'm not saying we keep around hundreds of tags, just that our tags have enough meaning that user systems can distinguish when something changes. We can keep the most N revisions of the container around for some value of N. Older containers just get deleted from the hub. No reason to keep them

[openstack-dev] [nova] Reflections on the pike-1 milestone

Hey everyone, Now that the pike-1 milestone is behind us I wanted to have a recap of the milestone to compare what progress we made against goals we set at the PTG, and to look forward to the pike-2 milestone. First some highlights of things accomplished in the pike-1 milestone in no

[openstack-dev] [nova] Launchpad bugs cleaning day on Tuesday 4/25

We are going to have a Launchpad bugs cleaning day for Nova on Tuesday 4/25. This day will be purely about cleaning the garbage out of the Launchpad - it is not the bug squashing day where people propose patches. If you are not familiar with bug triage, please refer to [1]. As indicated by the

Re: [openstack-dev] Development workflow for bunch of patches

On Wed, Apr 19, 2017, at 01:11 AM, Sławek Kapłoński wrote: > Hello, > > I have a question about how to deal with bunch of patches which depends > one on another. > I did patch to neutron (https://review.openstack.org/#/c/449831/ > ) which is not merged

Re: [openstack-dev] [oslo] Can we stop global requirements update?

We have started this work. I've been working on: https://review.openstack.org/#/c/444718/ Which will do requirement checks, as specified in the Pike PTG ehterpad for Tuesday morning: https://etherpad.openstack.org/p/relmgt-stable-requirements-ptg-pike (line 40+). Once done, Tony and I were going

[openstack-dev] [kolla] [daisycloud-core]Do we really need to upgrade pbr, docker-py and oslo.utils 

Hello, As global requirements changed in Ocata, Kolla upgrads pbr＞=1.8 [1] , docker-py＞=1.8.1[2] . Besides, Kolla also starts depending on oslo.utils＞=3.18.0 to use uuidutils.generate_uuid() instead of uuid.uuid4() to generate UUID. IMHO, Upgrading of [1] and [2] are actually not what

Re: [openstack-dev] [kolla] [daisycloud-core] [requirements] [magnum] [oslo] Do we really need to upgrade pbr, docker-py and oslo.utils 

Hu, Kolla does not manage the global requirements process as it is global to OpenStack. The Kolla core reviewers essentially rubber stamp changes from the global requirements bot assuming they pass our gating. If they don’t pass our gating, we work with the committer to sort out a working

Re: [openstack-dev] [TripleO][Heat] Conditionally passing properties in Heat

On 04/13/2017 12:01 AM, Rabi Mishra wrote: > On Thu, Apr 13, 2017 at 2:14 AM, Dan Sneddon > wrote: > > On 04/12/2017 01:22 PM, Thomas Herve wrote: > > On Wed, Apr 12, 2017 at 9:00 PM, Dan Sneddon

Re: [openstack-dev] [ceilometer]Looking for endpoint where event passed after first time

On 19/04/17 03:05 PM, Hui Xiang wrote: > Hi folks, > > I am posting some self-defined events to amqp ceilometer exchange > notification topic, during the debug session, I find that at the first > time, event are arriving at notification bus as the AMQPIncomingMessage, > and then handled by

[openstack-dev] [oslo] Can we stop global requirements update?

Hoy, So Gnocchi gate is all broken (agan) because it depends on "pbr" and some new release of oslo.* depends on pbr!=2.1.0. Neither Gnocchi nor Oslo cares about whatever bug there is in pbr 2.1.0 that got in banished by requirements Gods. It does not prevent it to be used e.g. to install the

Re: [openstack-dev] [TripleO][CI] Bridging the production/CI workflow gap with large periodic CI jobs

On 18/04/17 14:28 -0400, Emilien Macchi wrote: On Mon, Apr 17, 2017 at 3:52 PM, Justin Kilpatrick wrote: Because CI jobs tend to max out about 5 nodes there's a whole class of minor bugs that make it into releases. What happens is that they never show up in small clouds,

Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

I'm wondering if moving to using docker labels is a better way of solving the various issue being raised here. We can maintain a tag for each of master/ocata/newton/etc, and on each image have a LABEL with info such as 'pbr of service/pbr of kolla/link to CI of build/etc'. I believe this

Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

On 19/04/17 11:20 +0100, Paul Bourke wrote: I'm wondering if moving to using docker labels is a better way of solving the various issue being raised here. We can maintain a tag for each of master/ocata/newton/etc, and on each image have a LABEL with info such as 'pbr of service/pbr of

[openstack-dev] [acceleration]Cyborg Weekly Meeting 2017.04.19 agenda

Hi Team, In today's meeting we will review our ongoing spec as usual, hopefully got some of them approved and moving on to implementation. We will also need to discuss the DB spec for which Mellanox team won't be able to finish on time. The last item would be to discuss the Boston Summit related

Re: [openstack-dev] [tc][elections]questions about one platform vision

On 19/04/17 11:17 +0200, Thierry Carrez wrote: Adam Lawson wrote: [...] I've been an OpenStack architect for at least 5+ years now and work with many large Fortune 100 IT shops. OpenStack in the enterprise is being used to orchestrate virtual machines. Despite the additional capabilities

Re: [openstack-dev] [mistral] New CI Job definitions

On 19 Apr 2017, 21:37 +0700, Brad P. Crochet , wrote: > > On Tue, Apr 18, 2017 at 2:10 AM Ренат Ахмеров > > wrote: > > > Thanks Brad! > > > > > > So kombu gate is now non-apache, right? > > > > > > > No. It would be running under mod_wsgi. We can make

Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

On Thu, Apr 20, 2017 at 8:12 AM, Michał Jastrzębski wrote: > So after discussion started here [1] we came up with something like that: > > 1. Docker build will create "fingerprint" - manifesto of versions > saved somewhere (LABEL?) > This would be great, especially a full

Re: [openstack-dev] [ceilometer]Looking for endpoint where event passed after first time

Thanks gordon. I am using Mitaka version. And yes I have known that ceilometer notification agent will listen for the notification topics, but my question is which file/class will do it. When I am debugging the code, at the first time when the event send out to ceilometer exchange notification

Re: [openstack-dev] [kolla] [daisycloud-core] [requirements] [magnum] [oslo] Do we really need to upgrade pbr, docker-py and oslo.utils

Zun required docker-py to be 1.8 or higher because older version of docker-py didn't have the API we need. Sorry if it caused difficulties on your side but I don't think it is feasible to downgrade the version for now since it will affect a ton of other projects. Best regards, Hongbin On Thu,

Re: [openstack-dev] [oslo] Can we stop global requirements update?

Doug Hellmann wrote: Excerpts from Clark Boylan's message of 2017-04-19 08:10:43 -0700: On Wed, Apr 19, 2017, at 05:54 AM, Julien Danjou wrote: Hoy, So Gnocchi gate is all broken (agan) because it depends on "pbr" and some new release of oslo.* depends on pbr!=2.1.0. Neither Gnocchi nor

Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

I agree with Paul here. I like the idea of solving this with labels instead of tags. A label is imbedded into the docker image, and if it changes, the checksum of the image changes. A tag is kept in the image manifest, and can be altered w/o changing the underlying image. So to me a label

Re: [openstack-dev] [kolla] Tags, revisions, dockerhub

On 19.04.2017 12:39, Britt Houser (bhouser) wrote: > I agree with Paul here. I like the idea of solving this with labels instead > of tags. A label is imbedded into the docker image, and if it changes, the > checksum of the image changes. A tag is kept in the image manifest, and can > be

[openstack-dev] [openstack-doc] [dev] Docs team meeting tomorrow

Hey everyone, The docs meeting will continue today in #openstack-meeting-alt as scheduled (Thursday at 21:00 UTC). For more details, and the agenda, see the meeting page: - https://wiki.openstack.org/wiki/Meetings/DocTeamMeeting#Agenda_for_next_meeting Specialty team leads – if you are unable

Re: [openstack-dev] [tripleo] Proposing Florian Fuchs for tripleo-validations core

On Wed, Apr 19, 2017 at 12:38 AM, Emilien Macchi wrote: > On Tue, Apr 18, 2017 at 6:20 PM, Jason E. Rist wrote: >> On 04/18/2017 02:28 AM, Steven Hardy wrote: >>> On Thu, Apr 06, 2017 at 11:53:04AM +0200, Martin André wrote: >>> > Hellooo, >>> > >>> > I'd

[openstack-dev] Development workflow for bunch of patches

Hello, I have a question about how to deal with bunch of patches which depends one on another. I did patch to neutron (https://review.openstack.org/#/c/449831/ ) which is not merged yet but I wanted to start also another patch which is depend on this

[openstack-dev] [cinder]Should os-brick update iSCSI node.startup to "automatic"?

Hi all, I reported a following bug of os-brick's iSCSI feature and pushed a patch for it. * os-brick's iscsi initiator unexpectedly reverts node.startup from "automatic" to "manual". https://bugs.launchpad.net/os-brick/+bug/1670237 The patch got -2, but I think that this -2 is based on a

[openstack-dev] [congress] meeting topics

Hi all, Proposed topics for the next congress irc meeting are tracked in this etherpad: https://etherpad.openstack.org/p/congress-meeting-topics Feel free to add additional topics and/or comment on existing ones. Thanks! __

Re: [openstack-dev] Development workflow for bunch of patches

Whenever you want to work on the second patch you would need to first checkout the latest version of the first patch and then cherry-pick the later patch on top of it. That way when you update the second one it won't affect the first patch. The -R flag can also be used to prevent unexpected

Re: [openstack-dev] [telemetry] [ceilometer] Difference between publishers and dispatchers?

Thanks for clearing that guys. Cheers! On Tue, Apr 18, 2017 at 9:40 AM, Andres Alvarez wrote: > Hi Julien > > Thanks for your response. So does this mean that dispatchers will also be > deprecated (if not already deprecated) in favor of only using publishers? > > On

Re: [openstack-dev] Development workflow for bunch of patches

Hello, Thanks a lot :) — Best regards Slawek Kaplonski sla...@kaplonski.pl > Wiadomość napisana przez Kevin Benton w dniu 19.04.2017, o > godz. 10:25: > > Whenever you want to work on the second patch you would need to first > checkout the latest version of the first

[openstack-dev] [tricircle]weekly meeting of Apr.19

Hello, team, Agenda of Apr.19 weekly meeting: 1. feature implementation review 2. weekly meeting time 3. Pike-1.5 (May.2) preparation 4. Open Discussion How to join: # IRC meeting: https://webchat.freenode.net/?channels=openstack-meeting on every Wednesday starting from UTC 14:00.

Re: [openstack-dev] [tc][elections]questions about one platform vision

Adam Lawson wrote: > [...] > I've been an OpenStack architect for at least 5+ years now and work with > many large Fortune 100 IT shops. OpenStack in the enterprise is being > used to orchestrate virtual machines. Despite the additional > capabilities OpenStack is trying to accommodate, that's